[NightFright]

I am looking again at the boss code for "The Gate", wondering if there is a way to fix the boss (partially) without having to use EDuke32 code (like Mere_Duke did in the Addon Compilation). It would be great if a vanilla-friendly solution could be found since Rednukem users (for whom I am trying to do this adjustment) shouldn't suffer from this rather severe problem.

A short introduction:
The boss requires 5 brains to be destroyed before it can be damaged. However, since the mod authors used GET_BOOTS as inventory variable, game logic breaks when you step onto slime or other materials that the protection boots may interact with.

Brain code:

define BRAIN 5674
define      BRAINSTRENGTH 75

move brainstopped

action      MONSTER1 0 2 1 1 18
ai          INACT    MONSTER1
ai          SHOOT    MONSTER1 brainstopped faceplayersmart

useractor notenemy BRAIN BRAINSTRENGTH MONSTER1
ifai NO
  {
//  sizeat 50 50
  cstat 257
  clipdist 32
  ai SHOOT
  }
ifai INACT
  {
  ifpinventory GET_BOOTS 350
    {
    addinventory GET_BOOTS 350
    killit
    }
  }
ifcansee
  {
  ifcount 10
    {
    resetcount
    }
  }
ifhitweapon
  {
  ifdead
    {
    state standard_jibs
    state standard_jibs
    state standard_jibs
    state standard_jibs
    sound SQUISHED
    ai INACT
    }
    else
    sound SQUISHED
  }
enda

Boss code (relevant parts):

state bdpbosscodeinactive

ifaction ABOSS2DEAD break

ifpdistl 2048
  addphealth -1500

ifai NO
  {
  strength BDPBOSSSTRENGTH
  clipdist 64
//  sizeat 80 80
  ai AIBDPBOSSSEEKENEMY
  }

ifai AIBDPBOSSSEEKENEMY
  state bdpbossseek
  else
ifai AIBDPBOSSSHOOTENEMY
  state bdpbossshoot
  else
ifai AIBDPBOSSRUNENEMY
  state bdpbossrun
  else
ifai AIBDPBOSSDYING
  state bdpbossdying


ifspritepal 15
  {
  ifhitweapon { state bdpbosshitstate }
  }
  else
  {
  strength BDPBOSSSTRENGTH
  ifhitweapon { spawn BOSSFORCEFIELD }
  }

ifpinventory GET_BOOTS 350
   nullop
   else
   {
   addinventory GET_BOOTS 0
   ifspritepal 3
     {
     spritepal 9
     sound BOS2_PAIN
     quote 130
     spawn BLOOD
     spawn BLOOD
     }
     else
     {
     ifspritepal 9
       {
       quote 131
       spawn BLOOD
       sound BOS2_PAIN
       spawn BLOOD
       spritepal 10
       }
       else
       {
       ifspritepal 10
         {
         spawn BLOOD
         quote 132
         sound BOS2_PAIN
         spritepal 11
         }
         else
         {
         ifspritepal 11
           {
           spawn BLOOD
           quote 133
           sound BOS2_PAIN
           spritepal 12
           }
           else
           {
           ifspritepal 12
             {
             spawn BLOOD
             globalsound BOS2_PAIN
             spritepal 15
             quote 134
             }
           }
         }
       }
     }
   }

ends

[Reaper_Man]

You basically have 2 options - ensure no damageable surfaces are in the map, or use another inventory item (that also isn't being used). BOOTS and SCUBA are ideal candidates because they are activated automatically, so there's no way for the player to alter the value and you don't require they unbind an inventory key.

If the original mod used BOOTS to store data, but also did include damageable floors, then that's a massive oversight on their part.

[NightFright]

I don't have the entire map in my mind right now, but obviously there is a way to trigger the boots during the entire sequence (basically a single slimer egg is already enough), otherwise it wouldn't break. Using SCUBA isn't a good idea either if there is submergible water in that level. I am not sure if that's the case, I would have to play through the entire map to see if there is any.

*UPDATE*
I have been checking the level with Mapster32 a bit. There are some ducts with slimers in them, which can leave slime on the floor if killed IIRC. In those ducts, evading a puddle once it has been created is pretty much impossible, so it's basically trial-and-error whether you step into one or not. There's also an access card in the middle of slimer eggs, so that's another chance to get in contact with the "forbidden" surface. I couldn't see any water anywhere so far, so maybe one could simply replace GET_BOOTS with GET_SCUBA?

[Reaper_Man]

Assuming there's no underwater areas then you could swap out BOOTS for SCUBA. I don't think you'd have to adjust the amount it adds/checks, those numbers should still work fine. The only other problem you might run into is if the player has SCUBA amount coming into the map, in which case you could place a helper actor right by the player start to wipe out the current scuba amount.

[NightFright]

Alright. What would that helper actor look like, then? It's a sprite very close to the player spawning point with a certain hi-/lotag or custom code written for it?

[Reaper_Man]

If you are sticking to 1.5 commands then unfortunately that means no access to a sprite's hitag/lotag. The cleanest method would be to modify the scuba pickup item itself to pull double duty. Put this code at the very top of the AIRTANK actor code, before the fall command, and set the sprite to PAL 4 in the map and place it somewhere near the player start (but not within pickup range):

	ifspritepal 4
	{
		addinventory GET_SCUBA 0
		killit
	}

[NightFright]

Alright, thanks! Will try that tomorrow.

There's yet another issue since the boss may sometimes follow the player through one of the portals in the central arena, in which case it's also difficult to complete the map since the boss may go to a place where it can't be reached. There isn't a method, either by mapping or coding, that forces the boss to stay within a certain area without being able to follow the player past it?

[Reaper_Man]

Not through code, not really at least. You're describing a multi-sector stayput basically right? I'm not familiar with The Gate so I don't know how this arena is laid out. Is modifying the area possible to make the portals inaccessible to the boss? Raising them up or having some sort of barrier blocking them?

Using code, one really hacky possibility would be to make a wall sprite that always renders invisible, and is blocking unless the player is within range. This would allow only the player to "pass through", but this isn't foolproof.

[NightFright]

There is a gameplay vid you can check for references:


The boss arena is shown around 1:50 or so. During the course of the level, you open several gates leading to teleporters which get you to the places of the brains you have to destroy so the boss loses invulnerability. Those gates are on even ground, and so are the teleporters, so it's easy for the boss to follow.

How high would the teleporters have to be placed so the boss cannot climb up? It's a Cycloid Emperor variant, if that helps.

I was dreaming of an invisible line that is only blocking for NPCs, but I guess that's a miracle not even Mapster32 is able to pull off.

[ck3D]

The Cycloid normally is already coded to only be able to ever step into sectors with a lo-tag of 3, but only in default/base game end boss form and so with a palette of 0; any mini-boss variant of it (which looks like the case here) will just ignore the idea and walk anywhere. Now if one ever found a way to have mini Cycloids behave like big Cycloids, then your navigation issues could be fixed in Mapster32 by scattering lo-tags of 3 throughout every sector it's meant to be able to traverse, and leaving the other ones (around the teleporters) untagged. I have no idea how difficult or even possible that may be, though. Duke 3D's bosses really are wired in weird ways; the Battlelord code is pretty solid, but in a lot of situations that aren't the base game's design, the Cycloid and especially the Overlord can act unpredictably and be pretty broken (i.e.. the big Overlord regularly completely ignores blocked walls altogether).

[NightFright]

The Cycloid was used in a very straight-forward way in the original game. A giant flat arena, boss can go anywhere besides the seat rows. Here it's unfortunately less convenient. Then again, this has always been the issue with this specific map and you just need to keep the boss in the center as much as possible, then rush for the next teleporter.

Maybe you can at least switch the boss to return to dormant state faster when the player is out of sight?

Also:
If you kill two brains in a row without activating the boss inbetween, it breaks the sequence as well. Does this require a separate code fix?

[Reaper_Man]

 NightFright, on 14 December 2022 - 11:58 AM, said:

Also:
If you kill two brains in a row without activating the boss inbetween, it breaks the sequence as well. Does this require a separate code fix?

In the code you posted, are those the only 2 references to GET_BOOTS? When I read it before it didn't 100% make sense to me, by which I mean I assumed other code or context was missing, or there is just simply a bug or other logic flaw in how the encounter is designed. How should the encounter work exactly? In your original comment I understood it to mean "all 5 brains must be destroyed, THEN the boss is vulnerable", but if destroying 2 or more brains in a row breaks the effect, now it sounds like you're supposed to destroy 1, attack the boss, THEN destroy others?

Regarding the Cycloid, this fixes the problem. It has a hard coded ability to only move into sectors with a LOTAG of 3. This is the closest thing to a Stayput+ type effect. The only other alternative is a regular Stayput, which only stays within the sector it spawns in. So you should be able to tag all of the sectors of the boss area and you're off to the races.

Unfortunately there are no blocking bits that effect only actors and/or ignores the player. Walls are either blocking or non-blocking.

Thanks for the video link, I'll check it out in a bit.

[NightFright]

I posted everything that has GET_BOOTS in it, besides the BOOTS actor, ofc. There is more code for the boss, but the brains code is complete.

IIRC you go to the first area, kill brain #1, return to the arena after unlocking the next teleporter, kill brain #2, back to the arena etc. Attacking the boss before you are done is useless, he is shielded and won't take damage. If I understand the code correctly, killing a brain gives you the boots which will make the boss change his palette after resetting the boots, and you keep doing the same until the boss has pal 15, which is his final and vulnerable state.

I am not sure how you can skip activating the boss if you have to return to the arena all the time, but if he followed you through one of the teleporters and isn't back in the arena when you are, it is possible to do more than one brain kill w/o a boss encounter.

The other bug was that sometimes those brains didn't disappear after being killed (maybe if you didn't activate boss in the meantime?), which made things even more confusing since this way you couldn't even be sure if you really did all five kills before confronting the boss.

There's just so many things that can make you screw up:
1) You step into slime (probably while having boots from previous maps).
2) Boss follows you through teleporter (leading to next problem).
3) You don't activate the boss between brain kills.
4) Brains don't vanish after a kill (also no kill message).

Replacing boots with scuba will eliminate one of the major reasons to break the map, but I'd like to make it as fool-proof as possible without having to use EDuke32 magic.

[Reaper_Man]

Can you post the EDuke32 code, or at least the parts that were changed to fix the effect? I assume this completely fixes the issues you mention here.

You can insert this command into the boss code somewhere at the top, usually near the fall command. This prevents it from ever going back to sleep once it wakes up:

	sleeptime 300

As for the actual brain code, I'm guessing the original mod author didn't realize "addinventory" doesn't actually add to the inventory, it just sets it to the amount you set. So instead of adding 350 five times, it just sets it to 350 over and over. Otherwise I can't explain what should be happening here, the code simply seems broken. I would try changing the "ifai INACT" section to this:

	ifai INACT
	{
		ifpinventory GET_SCUBA 0
			addinventory GET_SCUBA 350
		else
		ifpinventory GET_SCUBA 350
			addinventory GET_SCUBA 700
		else
		ifpinventory GET_SCUBA 700
			addinventory GET_SCUBA 1050
		else
		ifpinventory GET_SCUBA 1050
			addinventory GET_SCUBA 1400
		else
		ifpinventory GET_SCUBA 1400
			addinventory GET_SCUBA 1750
		/*
		else
			nullop
			// critical error, invalid SCUBA amount
		*/

		killit
		break
	}

I changed BOOTS to SCUBA. This should correctly advance the "brain kill count", and should fix the problem of them sometimes not being deleted. Now the boss's logic may be broken, as it appears to be checking for a SCUBA value of 350 instead of 1750. However the code for it to advance the palette also seems broken, I'm not sure how it ever advances past the "ifpinventory GET_BOOTS 350" line if nothing else resets the BOOTS amount to 0. Going back to the original bug, with Boots taking slime damage, it's almost like they accidentally took Boot / slime damage while testing and unintentionally advanced the sequence and thought the effect was working right.

Is actually changing palette colors part of the effect, like is the player intended to see the visual change, or is the palette simply a variable to keep track of the boss or brain kill count? I'm assuming it's a vital part of the effect, if so then something like this should work, this should replace the last section starting at "ifpinventory GET_BOOTS 350":

	ifpinventory GET_SCUBA 0
	{
		nullop
		// Is there a quote 129 for zero brains killed hit message? If so place it here
	}
	else
	ifpinventory GET_SCUBA 350
	{
		spritepal 9
		quote 130
	}
	else
	ifpinventory GET_SCUBA 700
	{
		spritepal 10
		quote 131
	}
	else
	ifpinventory GET_SCUBA 1050
	{
		spritepal 11
		quote 132
	}
	else
	ifpinventory GET_SCUBA 1400
	{
		spritepal 12
		quote 133
	}
	else
	ifpinventory GET_BOOTS 1750
	{
		spritepal 15
		quote 134
	}

	spawn BLOOD
	globalsound BOS2_PAIN

I took a look at that video finally, at 3:47 you can see them scroll their inventory and they have both Boots and Scuba already. This effect definitely seems half baked, or at very least not thoroughly tested.

I just realized that a far less invasive fix would be to 1.) change all references from BOOTS to SCUBA, 2.) setup the helper AIRTANK to clear out the previous SCUBA amount, then finally 3.) fix the brain deletion by moving the "killit" command to be outside of the brace instead of inside (or remove them altogether):

ifai INACT
  {
  ifpinventory GET_BOOTS 350
    addinventory GET_BOOTS 350
  killit
  }

Assuming all other logic works properly, no further changes should need to be done. But if the logic is in fact scuffed then the more extensive changes may fix it.

You can still add the sleeptime command to the boss to prevent it from going to sleep, and setup the sector lotags to jail it to just the arena sectors as well.

[NightFright]

I guess it would have worked with the boots if they had placed a helper actor that removes the boots on level start, but it would be kinda counter-productive since they are obviously of good use in a level with slimers. This mistake probably happened because they might have been testing the map isolated from the rest of the episode, i.e. with no previously collected boots in inventory when starting the map.

I have checked there's no other AIRTANK sprite in that level besides the pal4 one I have placed now. There also shouldn't be any submergible passages that would require a scuba gear, at least I didn't see any in that gameplay video.

Regarding the boss activation fix: Something like this, I guess?

actor BOSS2 BOSS2STRENGTH
fall
sleeptime 300
ifspritepal 0
  state boss2code
  else
  ifspritepal 21
    state boss2code
    else
    ifspritepal 16
      state bdpbosscodeactive
      else
      state bdpbosscodeinactive
enda

And regarding the sector palette changes:
I have made a test edit with lotagging sectors the boss can enter. The boss as it was placed (pal3) will ignore them. If I edit the boss sprite to pal0, he obeys the sector limits. So I guess we can forget about this solution unless there's another way for the boss to remember which state he is in. Basically all that would have to be done is to prevent the boss from entering any of the five teleport chambers in that map.

I have attached the fixed scripts below. This way you can check if everything is in order. I can still post the EDuke32 solution later on, but right now let's focus on the vanilla-friendly approach.

[Aleks]

Hmmm, I never knew this would be a problem in EDuke, was it also a problem in the original version?

Anyway, as much as I'm all for fixing the problem with the boots and sequence breaking, I don't think the boss should be tinkered with not to follow the player into the teleporters, since it seems to go strongly against what the authors were trying to achieve there. Basically, this boss has always been challenging precisely because of this, having to outmaneuver it around the central area, so he doesn't follow you through the teleporters, because then you're screwed anyway. Taking that out would make him kinda pointless IMO.

[NightFright]

Should he get trapped in one of those side chambers, you can get back there after teleporting back to the arena. Main thing is you can still reach him after the brains are killed.

My main focus is to get the brain killing procedure right without any chances of breaking it, and I guess if the suggested code above works, it's good enough. It changes nothing about the way the map works, just avoids reaching a game-breaking state.

The best option would probably have been to introduce a new inventory item just for this purpose, without touching any existing items, but my guess is that's not doable in vanilla.

[Reaper_Man]

I didn't even think about how changing the boss's palette would negate the ST 3 jailing. In either case, if the sectors are not already tagged with ST 3 then that suggests the encounter was not designed with jailing the boss in mind, and obviously changing the as-designed system and experience as little as possible is preferable. Hopefully the less invasive fix I suggested works.

That sleeptime placement looks good, once woken up he shouldn't fall back asleep now. To clarify what this is doing, all actors have an internal sleep counter that once it reaches a certain value (specifically 32768), will put the enemy back into a sleeping state. The command sleeptime sets this internal counter to an arbitrary value, and when executed every gametic, never allows the counter to advance thus always keeping them awake.

I'm looking at the full boss code in the CONs you posted and honestly this code seems kind of a mess. It checks for spritepal 16 and calls a state bdpbosscodeactive, and yet that state is completely empty. It doesn't even call nullop, which I think technically can throw errors or cause a crash or other bugs. I noticed this with the brain too, it checks ifcount and resets the count but doesn't actually do anything with the count. I don't want to start pulling at things and rewriting or fixing things if they're "working".

 NightFright, on 15 December 2022 - 02:25 AM, said:

The best option would probably have been to introduce a new inventory item just for this purpose, without touching any existing items, but my guess is that's not doable in vanilla.

Not even kinda, not even a little bit. The 1.5 language is extremely limited. Abusing inventory items as pseudo global variables is probably the last great hack we figured out before the enhanced CON language of EDuke came around. There is essentially no other way to pass global data, and there is no way to setup private data (IE per-actor gamevars) at all. Adding new anything, basically except new actors via useractor, isn't possible.

[NightFright]

How close does that AIRTANK sprite have to be to the player start position? Even with the additional ifspritepal 4 code in place, it doesn't remove any old scuba gear from my inventory when entering that map. (I used DNSTUFF at the end of the previous map to get the scuba gear, hopefully that didn't ruin the test setup.)

Code:

actor AIRTANK
  ifspritepal 4
  {
    addinventory GET_SCUBA 0
    killit
  }
  fall
[...]

Looks like this in Mapster32:

[Reaper_Man]

Distance doesn't matter, as long as it has line of sight with the player. Too close may be triggering the pickup portion of the code. You can try placing it further away from the player, or adding "break" on the next line after "killit":

  ifspritepal 4
  {
    addinventory GET_SCUBA 0
    killit
    break
  }

Or setting the value to 0 doesn't work and/or doesn't do what I thought. If neither of the above changes solves it, I'll scope out the source code and see what addinventory is doing exactly.

[NightFright]

I tried to put the sprite further away, but still in a straight line from player starting position, didn't change anything.
Then, on top of that, I added a "break" in the code as suggested, same result.

My suspicion is that addinventory can only *ADD* values, but not actually set them to the specified value. I.e. if you to addinventory GET_SCUBA 0, it just adds 0% to the existing value (?).

Quote

addinventory <item> <amount>
Adds <amount> to the current or closest player's value for the appropriate <item>.

But wait - the boss actor is using the same method to reset GET_BOOTS/GET_SCUBA, so...

Is there another example map where the same trick was used? Maybe we could see then if we are missing anything.

[Reaper_Man]

addinventory should only explicitly add for Armor, but all others it sets it to whatever value you enter. It's a confusing named command for sure. I don't think EDuke would have changed this functionality as it's vital to 1.5 era effects that use it, and a lot of mods and TCs used it. Even this mod's code sets it to 0 in the original boss code you posted.

The PAL 4 AIRTANK disappears instantly right, like it isn't sitting there waiting to be picked up or anything? I assume the rest of it's code is working, just addinventory is broken.

I'll dig into the source and test this out in a bit and see what's going on and check back. Maybe doing -1 instead of 0 would work. Maybe the SCUBA does other checks because the player isn't underwater and so the value is locked somehow.

[NightFright]

I am using Rednukem for testing, but it should not matter since we are using vanilla code here. The AIRTANK sprite is not visible when you enter the game, that part is apparently working.
I don't think acquiring the scuba gear via cheat on the previous map should mess with the result, you are still getting the same stuff. Anyway, I tried with -1, that wouldn't do the trick, either.

BTW:
Just to make sure I also tried with placing pal4 boots in the same spot and changed the BOOTS code accordingly, like the AIRTANK before:

actor BOOTS
  ifspritepal 4
  {
    addinventory GET_BOOTS 0
    killit
  }

Same result, unfortunately.

[Reaper_Man]

I forgot that setting the palette on weapons, ammo, and items flags them as multiplayer only pickups, and in singleplayer it deletes them on map load. Unfortunately this means you'll have to create a new actor for the helper, but the good news is that the code does work as expected:

define BRAINHELPER 0 //needs a new or unused tilenum

useractor BRAINHELPER notenemy
{
	addinventory GET_SCUBA 0
	killit
}
enda

Looking at the source code, addinventory does in fact SET the value, except for armor which ADDS the value (including adding negatives to subtract).

[ck3D]

Is everyone mindful of how whenever a Duke 3D item is given any other palette than zero, it will qualify as a multiplayer-only item and so be ignored upon map load in SP?... I don't know when the check exactly happens but could imagine the possibility where the whole system won't work if the item doesn't spawn at all and the player never gets to see it.

Re: Cycloid guidance, yeah, that's why I had brought up the behavioral difference between normal palette and miniboss palette first thing, specifying that even that the lo-tag of 3 option would come with its share of issues. I was only bringing that up because it still sounded more viable than coming up with complex one-way walls the boss would most likely ignore anyway even if the programmer got the feature right, since the bosses themselves are broken and known to clip through most everything the game considers blocked otherwise.

edit - was too slow. But while I'm at it, @NightFright, I've been wondering for a while: are you the same person as a user known as NightFlight who once released a Dukematch bot mod for SP (must have been pre-2000), or was that a different person?

[NightFright]

Do I need to create a tile for this or it's enough if the sprite has a blank tilenum in Mapster32? I mean it's not a problem since it can be anything and it won't be seen ingame, anyway. So it must be a pal0 item. (Reminds me of a level in Nuclear Winter where I wanted to add a jetpack with just 10% fuel. That one also didn't work with anything other than pal 0 - had to clone the actor in the end.)

And no, I never created any bot. Must have been someone else, in spite of the similar nick.

[Reaper_Man]

No, you don't need a new tile, just any that is not currently in use by another actor. I used tile0 for my test but you could use the Brain's second frame tile or a random Cycloid tile. Like you said it won't be seen. It's possible it may appear for a single frame or gametic, if so then you could just resize it so it's tiny, or even put it around the corner by the player start. Even if it's out of direct line-of-sight, it will still load as it's part of a visible sector.

Regarding palettes and pickup items, they are hardcoded to be destroyed during spawn (specifically during EVENT_SPAWN in EDuke) in a singleplayer game with a non-zero palette. It's not just PAL 1, it's any non-zero palette. So that's why you wouldn't be able to have a palette version of the Jetpack only give partial amount and why it needed to be a new actor. I vaguely remember that NW thread, if Wizard or whoever NW had a coded version of the Jetpack trying to pal swap it, but didn't fix or change the behavior in the source code, that would explain why it doesn't work. Or why they left the code in CON but never actually used it anywhere in the game, maybe they couldn't figure out what was going wrong and just left the code behind.

[NightFright]

OK, I set it to 5400, which is a blank tile which I filled with a copy of the scuba gear sprite, just to be on the safe side.

Code (placed at the very end, after game.con):

define BRAINHELPER 5400

useractor BRAINHELPER notenemy
{
  addinventory GET_SCUBA 0
  killit
}
enda

Observations:
- Sprite appears ingame and is not deleted, even if size is set to 1/1
- Scuba gear amount remains unchanged
- Placing the sprite (pal0) in front of the spawning point, right behind etc. it won't matter

[Reaper_Man]

I know you said you are running this in Rednukem, but does that work in EDuke? I'm using EDuke and that exact setup worked for me. Is it throwing an error when you run it? Those are all vanilla commands so I don't know why wouldn't be working at all, the fact that it's not deleting itself makes it sound like it's not running or executing as an actor at all. I know nothing about Rednukem, does it need something special setup to register actors?

Oh whoops I have the useractor parameters reversed, it should be: useractor notenemy BRAINHELPER . I was using tile ID 0, so my example always succeeded.

[NightFright]

With the code line fixed, this finally works!

The only thing you'll notice: On level start, Scuba Gear will be selected as your active inventory item and show with 0% left, but will disappear from the list as soon as you start cycling through available items. That's good enough since main thing is: Scuba is gone and none can be found in the map.

Now I need to see if the boss or those brains are acting up. I went for the minimized code fix that keeps giving and taking Scuba with amount 350.

Should this work out, I'll replace the EDuke32-ified version currently used in the Addon Compilation with it. Vanilla-friendly code should always be preferred.