[lllllllllllllll]

I mean duke stepping into sector 1 and getting the credit+quote for sector 2's secret place without getting it twice by stepping into sector 2 afterwards,
where sector 2 is tagged with SECRET AREA and sector 1 is not.

[Reaper_Man]

I don't understand what you're asking at all. It sounds like you have 2 sectors tagged as secrets, and you want them to register as a single secret when collected? Like they're paired or something like that?

[Danukem]

lllllllllllllll, on 21 December 2022 - 03:12 PM, said:

I mean duke stepping into sector 1 and getting the credit+quote for sector 2's secret place without getting it twice by stepping into sector 2 afterwards,
where sector 2 is tagged with SECRET AREA and sector 1 is not.

Tag BOTH sectors as secrets. Define a special sprite and add one copy of it to each tagged sector, and make the sprites share a lotag. Code the sprite to detect whether the player is entering its sector, when the player does have it look for the other sprite with the same lotag, if it finds it then untag the other sector.

[lllllllllllllll]

Thanks

I couldn't think of a way to use findsprite and ignore the closest instance of in favor of finding one with a particular lotag.
If I place a Trigger -> Respawn -> Sprite that sets its sector's Lotag to 0 and kills itself,
will I need to also detect and kill the Trigger in the other secret sector to prevent the secret sector duke just entered from being tinkered with later? Or is the game setting Lotag to 0 after tallying the secret anyway?

(both sectors tagged Secret, both sectors have a Trigger linked to the other's Respawn,,, duke enters sector 1 which spawns a sprite in sector 2 and strips sector 2's lotag, then duke enters sector 2 which in turn spawns a sprite that strips sector 1's lotag)

[jimbob]

lllllllllllllll, on 21 December 2022 - 03:12 PM, said:

I mean duke stepping into sector 1 and getting the credit+quote for sector 2's secret place without getting it twice by stepping into sector 2 afterwards,
where sector 2 is tagged with SECRET AREA and sector 1 is not.

just only tag one sector as the actual secret area, not all of them, it will count every single sector with the tag as an individual secret area. so simply only tag one.

[Danukem]

lllllllllllllll, on 22 December 2022 - 12:09 AM, said:

(both sectors tagged Secret, both sectors have a Trigger linked to the other's Respawn,,, duke enters sector 1 which spawns a sprite in sector 2 and strips sector 2's lotag, then duke enters sector 2 which in turn spawns a sprite that strips sector 1's lotag)

That should work. I was going to suggest a different method but it would have required you to learn some new stuff, so your method is better in that respect.

[lllllllllllllll]

Using respawns was making flashes and leaving excess secret totals

define SECRETSPOOF 9999

onevent EVENT_LOADACTOR
  ifactor SECRETSPOOF
  {
    getactor[THISACTOR].lotag othersector
    setactor[THISACTOR].lotag 0
    getactor[THISACTOR].hitag duplicatesecrets
    setactor[THISACTOR].hitag 0
  }
endevent

onevent EVENT_SPAWN
  ifactor SECRETSPOOF
  {
	getplayer[THISACTOR].max_secret_rooms secretstotal       
	subvarvar secretstotal duplicatesecrets
	setplayer[THISACTOR].max_secret_rooms secretstotal
  }
endevent

actor SECRETSPOOF
  getsector[THISACTOR].lotag sectorlotag
  ifvare sectorlotag 0
  {
    setsector[othersector].lotag 0
    killit
  }
enda

var othersector 0 2
var duplicatesecrets 0 2
var secretstotal 0 2
var sectorlotag 0 2

Usage:

Spoiler

Only use on secrets with multiple credit sectors<<

Place 1 sprite in each Secret sector. Lotag it with the opposing sector's number, then Hitag just one of them with the amount of duplicate Secret sectors (for a pair, 1).
Wall align and face a wall to conceal them.
Ensure player will be visible to it before he enters the sector.


For a Secret with 3 total credit sectors you will need to place 2 sprites in each Secret sector Lotagged with the opposing sector numbers, then Hitag just one with duplicate Secret sectors (2)

For 4 credit sectors, 3 sprites per, and so on.

No bugs after 20 seconds of rigorous testing

[VGames]

I've noticed something very odd. Explosive projectiles like RPG's and projectiles that explode on contact with enemies that also produce a blast radius cause the enemies to move toward the player as if they're being affected by a reverse pushback system. I thought something about my push back system from projectiles impacting enemies could be causing an issue, but this is happening with enemies that don't even use the push back system along with enemies that do use the pushback system. Has anybody seen this before? I can't keep it from happening.

[Reaper_Man]

This is normal behavior from the engine, you can experiment by increasing the RPG damage in the base game. The amount of pushback is dependent on the amount of overdamage the actor receives - that is, when their .extra property goes negative. The exact logic is here from the game source:

            if (!A_CheckSpriteFlags(otherSprite, SFLAG_NODAMAGEPUSH))
            {
                if (pOther->xvel < 0) pOther->xvel = 0;
                pOther->xvel += (pSprite->extra<<2);
            }

Note that any actor with the spriteflag NODAMAGEPUSH is immune to pushback.

"Pushback" may be a misnomer because obviously it pushes forward, not backwards. I don't think this is a bug, but rather it ensures the player can see the actor in front of the explosion sprite.

[Danukem]

 Reaper_Man, on 22 December 2022 - 08:40 PM, said:

"Pushback" may be a misnomer because obviously it pushes forward, not backwards. I don't think this is a bug, but rather it ensures the player can see the actor in front of the explosion sprite.

I never considered that might be the reason for it. Instead I suspected that xvel was given the wrong sign and it was supposed to move the enemy backwards.

@Vgames: In AA what I do is multiply xvel by -1 at the moment of impact, and in addition some weapons have their own separate knockback effect. If you want the scripted knockback to be the only source, then you can set xvel to 0 at the moment of impact.

[VGames]

 Danukem, on 22 December 2022 - 08:59 PM, said:

I never considered that might be the reason for it. Instead I suspected that xvel was given the wrong sign and it was supposed to move the enemy backwards.

@Vgames: In AA what I do is multiply xvel by -1 at the moment of impact, and in addition some weapons have their own separate knockback effect. If you want the scripted knockback to be the only source, then you can set xvel to 0 at the moment of impact.

Thanks. I’ll give this a try

[VGames]

Worked perfectly thanks

[MC84]

I was hoping to get some pointers as to how I would go about making a touchplate-activated call light for an elevator. Basically I just want the light actor to light up for a few seconds when the player steps on the touchplate sector, and then revert back to the default state.

I've started with this;

action CALLON 1 1 1 1 1 // advance one frame

define CALLUP 5872
useractor notenemy CALLUP 
{
 ifn sprite[].lotag 0
 geta[].lotag lotagsaved
}
enda

define CALLDN 5874
useractor notenemy CALLDN 
{
 ifn sprite[].lotag 0
 geta[].lotag lotagsaved
}
enda

Although there are 2 actors, only one will be tagged at a time; the other untagged one will just be for decoration.

I'm not asking to be spoon-fed the answer, but will I need to manipulate a game event so that if the touchplate lotag equals the 'lotagsaved' variable then the action CALLON will run for a certain actioncount?

The art tiles:

Attached thumbnail(s)

• 

[MC84]

Sorry to double post, but I went ahead and moved some things around. In onevent_EVENT_GAME, under a sprite[].picnum switch statement, I included these lines;

	case CALLUP
	{ ifn sprite[].lotag 0 geta[].lotag lotagsaved }
	break
	
	case CALLDN
	{ ifn sprite[].lotag 0 geta[].lotag lotagsaved }
	break
	
	case TOUCHPLATE
	{ ife sprite[].lotag lotagsaved
	   { set linked 1 } }
	break

Then under the actor declaration I've put this;

action CALLON 1 1 1 1 50 // advance one frame

useractor notenemy CALLUP 
{
 cstat 80

 ifaction CALLON
  {
   soundonce 35
   ifactioncount 64
    {
	 action ZERO
	 break
	}
  }

 ife linked 0 nullop
  else 
   ife linked 1
    { 
	 action CALLON 
	}
}
enda

However, even if I remove the above actor code, it appears that just this statement on its own

	case CALLUP
	{ ifn sprite[].lotag 0 geta[].lotag lotagsaved }
	break

causes the actor CALLUP to disappear when the game runs... Maybe I'm trying to be too ambitious here but can anyone point out why this is occurring?

[Danukem]

Lotags should be read into per-actor gamevars in EVENT_LOADACTOR. During that same event, the tag should be set back to 0 on the sprite and the variable should be the only thing holding the tag. Otherwise, you risk hardcoded effects if the tag is left on the sprite, such as the sprite disappearing just like an enemy would if you started a game at a lower difficulty than its lotag.

The exceptions to what I just wrote are the hardcoded effector sprites such as SE, RESPAWN, etc which were designed to have the tags left on them.

[Fantinaikos]

Don't want to open a new thread, I post this here just because it's the nearest thing.
AVG antivirus does not really likes the latest Eduke32 and Mapster32 synthesis, they are seen as malware/virus, without even control if the files are false positives. Does not happen with Debug versions.

[Reaper_Man]

Antivirus programs easily trigger on small executables, as viruses are often small executables themselves. You can compile the source yourself to verify, but if the debug version is running then it is definitely a false positive, as the debug version is the same code with some additional compile flags.

If it's any consolation, I once had my own antivirus trigger after running the eduke32.exe that I just had compiled seconds beforehand.

[MC84]

EDIT - I don't think I can delete my posts - anyways I figured out that I misplaced a bracket.

[VGames]

Is there any way to manipulate the holoduke actor that the enemies go after? I wanted to make it electrocute nearby enemies, but I can't find any code for the actual holoduke you create when you use the holoduke item.

[Danukem]

 VGames, on 30 December 2022 - 08:17 PM, said:

Is there any way to manipulate the holoduke actor that the enemies go after? I wanted to make it electrocute nearby enemies, but I can't find any code for the actual holoduke you create when you use the holoduke item.

use EVENT_GAME since it doesn't have actor status. In that event,

ifactor APLAYER
     ife THISACTOR player[].holoduke_on
{
     // put your holoduke code here
}

[lllllllllllllll]

I'm trying to illuminate actors when they shoot.
Setting the actor's shade once or multiple times does not work, nor does shadeto, presumably because it is taking the floor's shade/pal after.
So next to try is cstator noshade then set the shade to 0 or -127 and wait to remove noshade on the next tick. If taking off noshade makes the shade jump straight to the floor value instead of fading then 1 or 2 ticks of shadeto before.
Is there an existing command to brighten on shots (or invoke the hardcoded version for another sprite)?

[Danukem]

No, there's no command like that AFAIK. You'll have to control the shade manually in your code, or just use a different solution like adding fullbright pixels to their shooting frame or making them spawn a separate muzzleflash actor that is bright.

EDIT: I've never used it before, but there is an htflag for hardcoded badguy. I have no idea whether it would cause the sprite to brighten upon firing.

[Reaper_Man]

 lllllllllllllll, on 31 December 2022 - 12:41 AM, said:

I'm trying to illuminate actors when they shoot.
Setting the actor's shade once or multiple times does not work

What are you setting the shade to in your code? Setting the actor shade to -127 should illuminate them when they shoot the way hardcoded enemies illuminate. Like:

	shoot SOMETHING
	seta .shade -127

That should be all it takes.

[lllllllllllllll]

the htflag worked
Setting it at spawn I don't see any side effects so far

 Reaper_Man, on 31 December 2022 - 09:51 AM, said:

What are you setting the shade to in your code? Setting the actor shade to -127 should illuminate them when they shoot the way hardcoded enemies illuminate. Like:

	shoot SOMETHING
	seta .shade -127

That should be all it takes.

It doesn't visibly change

[jimbob]

nevermind, im didnt sleep very well

[Danukem]

 lllllllllllllll, on 31 December 2022 - 10:21 AM, said:

the htflag worked
Setting it at spawn I don't see any side effects so far

We are talking about the 262144 flag right?

[VGames]

What’s the eduke scripting equivalent of ||?Like “or”. I want to couple multiple if statements together but I don’t know how? Like if this happens or if this happens then do this.

[lllllllllllllll]

Yeah 262144 SFLAG_HARDCODED_BADGUY


Dunno when I need "or" I set the vars in such a way that 2 of the 3 values can be lumped together using >, <, and not=

[Danukem]

 VGames, on 31 December 2022 - 01:52 PM, said:

What’s the eduke scripting equivalent of ||?Like “or”. I want to couple multiple if statements together but I don’t know how? Like if this happens or if this happens then do this.

There really isn't, at least not for generically evaluating statements. You can however use ifor to evaluate pairs of values, providing that they are constants, vars, or specific struct members. For example:

ifor player[].heat_on player[].jetpack_on
al THISACTOR

That code will put the value of THISACTOR in the log when either the goggles are on or the jetpack is on. But the following will NOT compile:


ifor { ifg player[].htextra 0 } { ifg player[].shield_amount 0 } al THISACTOR

And removing the { } would change the meaning.

[Danukem]

 lllllllllllllll, on 31 December 2022 - 02:08 PM, said:

Yeah 262144 SFLAG_HARDCODED_BADGUY

By the way, I don't understand why your enemies aren't already lighting up when they fire. Mine do automatically, and I have not added that flag to them. I do define them as enemy -- are you not doing that?