[NightFright]

Is it normal that mini Battlelords can't be attacked and don't do anything after returning from shrunk state? If it's a bug in con code: Is there a way to fix it?

[Danukem]

 NukeDukem89, on 31 March 2024 - 03:24 PM, said:

Finally found what was causing this bug.

This:

state boss1palshrunkstate
  ifcount SHRUNKDONECOUNT
    ai AITROOPSEEKENEMY <--------------------
  else
    ifcount SHRUNKCOUNT
      sizeto 40 40
  else
    state genericshrunkcode
ends

And this:

state boss1code

  ifaction ABOSS1FROZEN
  {
    ifcount THAWTIME
    {
      ai AIBOSS1SEEKENEMY
      spritepal 21 <----------------------------------------
    }
    else
      ifcount FROZENDRIPTIME
    {
      ifactioncount 26
      {
        spawn WATERDRIP
        resetactioncount
      }
    }

Changed it to "AIBOSS#SEEKENEMY" (applies to boss 1, 2 and 3) and "getlastpal" respectively.

That old bug was talked about in this thread less than 2 weeks ago and the fix was posted.

[NightFright]

Geez, I literally must have tomatoes on my eyes. It's even on the same page. Never entered my mind it could be right in front of me. Thanks!

PS: If I want to use this fix as a mutator, it's not enough to just provide the edited state, right? I need to include the actor as well.

[NukeDukem89]

Danukem, on 12 April 2024 - 01:42 AM, said:

That old bug was talked about in this thread less than 2 weeks ago and the fix was posted.

Also happens with Incinerator. It's easy fix though.

I'm doing a World Tour mod version with a bunch of basic fixes and additions, this is one of these fixes. I've also polished Firefly and Cycloid Incinerator, nothing crazy, but better nonetheless. Shame I probably can't share it here...

[NightFright]

If it's mostly a con mod, I don't see how this could be an issue. You can also include corrections of art tiles, for example. As long as one cannot run the entire game/bonus episode with it...

[NightFright]

Something else:
When using this code from Darkus' game.con fixes, NEWBEAST actors would freeze ingame.

appendevent EVENT_SPAWN
    ifn MONSTERS_OFF 1
    {
        switch sprite[].picnum
            case TANK
                cstat 257
                sizeat 60 60
                clipdist 100
                spriteflags 8192
            break
            case NEWBEAST
            case NEWBEASTSTAYPUT
            case NEWBEASTHANG
            case NEWBEASTHANGDEAD
            case NEWBEASTJUMP
                cstator 257
                sizeat 40 40
                clipdist 64
            break
         endswitch
    }
endevent

When changing "sizeat" to "sizeto", they would function again (which wouldn't be the point of that particular fix, though). Any idea why? (The tank fix above it works fine, btw.)

[Danukem]

I don't think you mean all NEWBEAST become frozen, I think you mean that ones with lotags above the current difficulty (i.e. the ones that are supposed to be deleted because they are for a higher difficulty).

The reason they get frozen is the game tried to delete them by setting their size to 0 0 and changing their statnum, but then this code comes along afterwards and just sets them to 40 40 regardless, rendering them lifeless zombies.

Sizeto is only going to happen once because the spawn event happens once, so my guess is it would increase the formerly frozen ones from 0 0 to 1 1 in size. Perhaps that's not big enough to be very visible or stop the deleting from happening? Therefore you wouldn't see frozen ones around. There might be little tiny frozen ones if you look closely.

[NightFright]

I see. So what you are saying is those "frozen" (inactive) sprites are those which shouldn't be there due to the selected difficulty, but this code forces them to be shown, anyway.
In that case, I guess the fix would be to include a check for selected skill, like this:

appendevent EVENT_SPAWN
    ifn MONSTERS_OFF 1
        ifle sprite[].lotag userdef[].player_skill
        {
            switch sprite[].picnum
                case TANK
                    ...
                break
                case NEWBEAST
                case NEWBEASTSTAYPUT
                case NEWBEASTHANG
                case NEWBEASTHANGDEAD
                case NEWBEASTJUMP
                    ...
                break
         endswitch
    }
endevent

[Reaper_Man]

Their lotag might be clobbered at that point, so I wouldn't necessarily trust it either. I ran into this exact same issue very recently and I solved it by checking the xrepeat and bailing out.

appendevent EVENT_SPAWN
{
    // Ignore enemies disabled due to skill level
    ife sprite[].xrepeat 0
        break

    switch sprite[].picnum
    {
        // Fixup sprite sizes

[Danukem]

Reaper_Man, on 15 April 2024 - 05:52 AM, said:

Their lotag might be clobbered at that point, so I wouldn't necessarily trust it either. I ran into this exact same issue very recently and I solved it by checking the xrepeat and bailing out.

appendevent EVENT_SPAWN
{
    // Ignore enemies disabled due to skill level
    ife sprite[].xrepeat 0
        break

    switch sprite[].picnum
    {
        // Fixup sprite sizes

Yes, if the xrepeat is 4 or less, then don't fuck with them. If any mapper actually put a tiny enemy in the map that's on them.

Also, there's no reason why this particular event needs to be used for this purpose at all. EVENT_LOADACTOR could be used instead and then it's a non-issue.

[NightFright]

You mean when using EVENT_LOADACTOR I can use my original code without any check for player skill or xrepeat?

[Danukem]

NightFright, on 15 April 2024 - 11:26 AM, said:

You mean when using EVENT_LOADACTOR I can use my original code without any check for player skill or xrepeat?

Yes. The one thing I'm not 100% sure about is whether spriteflags can be applied to individual sprites that early, or whether they get reset after that. But certainly size and cstat can be set there. But I also don't think spriteflags 8192 should be used for this purpose -- my memory is that in recent edukes smooth movement is now applied by default, and in fact I had an issue at one point where I was accidentally xoring it and turning it off because I didn't know about that change.

[NightFright]

You are right. Spriteflags 8192 makes no difference in EDuke32 at this point, it seems. Tank moves just as before even without the flag being set manually. What about cactor? Would that work in LOADACTOR as well?

[Danukem]

Yes, cactor just changes picnum. The main reason to use EVENT_SPAWN would be to catch the sprites that are spawned in later (such as from RESPAWN) and aren't present in the map at the start.

EDIT: I realize that could be misinterpreted. I'm not saying that EVENT_SPAWN only runs when sprites are spawned in during gameplay. Sprites placed in mapster are "spawned" when they are initialized which is before gameplay starts, but it is after certain things happen to them like the hardcoded size zeroing on enemies with lotag > difficulty. My point was that you don't *need* to use EVENT_SPAWN on sprites already present before gameplay starts because you can use LOADACTOR instead.

[NightFright]

Outstanding. Then I'll just remove the spriteflags line, change the whole event to LOADACTOR and call it a day. Dunno how to check whether clipdist works like that as well, but of all adjustments it's the least important one.

Thanks a lot again, Dan. You've been a great help. Like always!

[Danukem]

NightFright, on 15 April 2024 - 12:45 PM, said:

Outstanding. Then I'll just remove the spriteflags line, change the whole event to LOADACTOR and call it a day. Dunno how to check whether clipdist works like that as well, but of all adjustments it's the least important one.

Thanks a lot again, Dan. You've been a great help. Like always!

clipdist is one of the sprite members and setting it in LOADACTOR surely does set it -- question is does it then get reset to the default number later on when the sprite is initialized for gameplay. My guess is it probably does.

in the newbeast code, you could just grab clipdist into a var and put it in the log during gameplay. If it's 64, then the code worked, if it's 80 then it didn't. Not sure why clipdist is being changed though, the default clipdist isn't a bug. The lower one is more accurate for certain things like rocket hits but the higher one probably has some situations where it is better too.

[NightFright]

Ok, another issue. I'm unable to get this rather simple code (also taken from Darkus' con fixes) working. It's just supposed to fix the health bug of the miniboss versions of BOSS2 and BOSS3:

appendevent EVENT_SPAWN
        switch sprite[].picnum
            case BOSS2
            case BOSS3
                ifg sprite[].pal 0
                    strength BOSS1PALSTRENGTH
            break
        endswitch
endevent

When testing this in a custom map, in this case "Chinatown" (1hk.map), it doesn't work. The miniboss still dies if you cough at him (it's a BOSS3 with pal4). Any ideas?

[Reaper_Man]

Assuming this is using the rest of the default GAME.CON without modifications, BOSS3 is scripted to set its strength to 1 here in this block in "state boss3code":

  ifai 0
  {
    ifspritepal 0
      ai AIBOSS3RUNENEMY
    else
    {
      strength 1
      ai AIBOSS3LOBENEMY
    }
  }

All actor code runs after EVENT_SPAWN, and any other on-spawn type events, would have executed. So technically your code does change it to BOSS1PALSTRENGTH, it just gets changed back to 1 later on.

The easiest fix here is just to edit that code block to change "strength 1" to "strength BOSS1PALSTRENGTH". However I'm assuming you are not wanting to edit the default GAME.CON file, so in that case you'll have to come up with another method.

What I would do is have some a per-actor gamevar to track the fixup, and check for it in EVENT_GAME. Something like:

var BOSSFIXUP 0 2

appendevent EVENT_GAME
{
    // Check this first because EVENT_GAME is expensive
    ifn BOSSFIXUP 0
        break

    // Make all sprites ignore subsequent checks
    set BOSSFIXUP 1

    switch sprite[].picnum
    {
        case BOSS2
        case BOSS3
            ifn sprite[].pal 0
                strength BOSS1PALSTRENGTH

            break
    }
    endswitch
}
endevent

This may be the way wrong approach though, I'm not sure if there's some other event that might be better suited. EVENT_GAME isn't great because it runs for every sprite, every frame, so it can easily get out of hand if you aren't careful or use it all over the place haphazardly.

Now that I think about it and look at the Boss scripts, it looks like the "ifai 0" check could safely be overridden. So you would move the behaviors that are checked/set in the actor code into an EVENT_SPAWN block, something like:

appendevent EVENT_SPAWN
{
    ifn sprite[].pal 0
    {
        ife sprite[].picnum BOSS2
        {
            strength BOSS1PALSTRENGTH
            sound BOS2_ATTACK
            ai AIBOSS2SHOOTENEMY
        }

        ife sprite[].picnum BOSS3
        {
            strength BOSS1PALSTRENGTH
            ai AIBOSS3LOBENEMY
        }
    }
}
endevent

That maybe would work.

[NightFright]

OK, it seems that your second approach did the trick. I used this and it works in the custom map:

appendevent EVENT_SPAWN
  switch sprite[].picnum
    case BOSS2
    ifn sprite[].pal 0
    {
      strength BOSS1PALSTRENGTH
      sound BOS2_ATTACK
      ai AIBOSS2SHOOTENEMY
    }
    case BOSS3
      ifn sprite[].pal 0
      {
        strength BOSS1PALSTRENGTH
        ai AIBOSS3LOBENEMY
      }
    break
  endswitch
endevent

[Reaper_Man]

FWIW the reason I did the pal check first is to process less code in more circumstances. Doing the check inside the switch still has every spawned sprite go through the switch. There's never an instance where this code block should run for a pal 0 sprite, so you can save some CPU checking that condition first.

Also in this instance you aren't getting any benefit from using a switch over a standard if statement, switch blocks are useful when multiple cases share identical code. Not that you can't or shouldn't use it here, or that there's anything wrong with using it here, but that's why I moved from a switch block to an if statement.

[NightFright]

Makes sense. I will adjust that. After all, encountering pal 0 versions of these bosses is happening far more often than any other, so this code should be skipped most of the time. Thanks a lot for the insight!

[VGames]

Using screen_size is there a way to check and see if the last version of the minihud is being used? Checking to see if screen_size equals 4 includes both versions of the minihud and not just the last version that you select before you remove the HUD altogether. I only want to make changes to the second version of the minihud.

[Danukem]

VGames, on 16 April 2024 - 05:52 PM, said:

Using screen_size is there a way to check and see if the last version of the minihud is being used? Checking to see if screen_size equals 4 includes both versions of the minihud and not just the last version that you select before you remove the HUD altogether. I only want to make changes to the second version of the minihud.

https://wiki.eduke32.com/wiki/Althud

[NightFright]

@VGames
If it's about the EDuke32 mini HUD, it should be something like

ife userdef[].screen_size 4
    ife userdef[].althud 1

[VGames]

Ah very nice. Thank u for the heads up. I knew I was missing something.

[VGames]

I have big blast rings that get created when a nuke goes off and I noticed that when they hit a wall they sometimes get all scrunched up and fail to keep their circular shape. They become more oval in shape sometimes. Is there some way to keep this from happening? I feel like there’s a setting I’m not using to make them clip through walls and not get affected by them.

[NightFright]

Is there a method to check for how long the player has been shrunk? I'd like to turn that into a (visible) countdown (in seconds), but so far I haven't found a construct in the EDuke32 wiki which would allow one to tap into that.

[Danukem]

It might be the player's count, assuming the player's move is reset when shrunk. But for easy access during display, I would just make a var for it and have it increment when the player is shrunk, zero otherwise. When the var is nonzero you display it in the hud.

[NightFright]

I guess the same goes for frozen state. The thing is I want the counter to start at max duration and have it reach 0 when frozen/shrunk time ends.

[High Treason]

Then wouldn't you just take the max count (once you know what it is) and subtract the current count from it to get your number?

I'm sure I remember seeing SHRUNKDONECOUNT or FROZENCOUNT somewhere, but perhaps it was just another mod that wanted to keep track of it for something. Perhaps it was in USER.CON.