LOL I’ll give it a shot. Thanks for the feedback and tips.
EDuke32 Scripting "CON coding help"
#3451 Posted 11 April 2024 - 11:57 AM
#3452 Posted 12 April 2024 - 01:22 AM
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?
#3453 Posted 12 April 2024 - 01:42 AM
NukeDukem89, on 31 March 2024 - 03:24 PM, said:
Finally found what was causing this bug.
This:
And this:
Changed it to "AIBOSS#SEEKENEMY" (applies to boss 1, 2 and 3) and "getlastpal" respectively.
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.
#3454 Posted 12 April 2024 - 02:01 AM
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.
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.
#3455 Posted 13 April 2024 - 04:16 PM
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...
#3456 Posted 14 April 2024 - 12:32 AM
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...
#3457 Posted 14 April 2024 - 11:03 PM
Something else:
When using this code from Darkus' game.con fixes, NEWBEAST actors would freeze ingame.
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.)
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.)
#3458 Posted 15 April 2024 - 12:42 AM
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.
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.
#3459 Posted 15 April 2024 - 01:19 AM
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:
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
#3460 Posted 15 April 2024 - 05:52 AM
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
#3461 Posted 15 April 2024 - 11:04 AM
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.
#3462 Posted 15 April 2024 - 11:26 AM
You mean when using EVENT_LOADACTOR I can use my original code without any check for player skill or xrepeat?
#3463 Posted 15 April 2024 - 11:42 AM
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.
#3464 Posted 15 April 2024 - 12:24 PM
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?
#3465 Posted 15 April 2024 - 12:37 PM
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.
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.
This post has been edited by Danukem: 15 April 2024 - 12:45 PM
#3466 Posted 15 April 2024 - 12:45 PM
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!
Thanks a lot again, Dan. You've been a great help. Like always!
#3467 Posted 15 April 2024 - 01:13 PM
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!
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.
#3468 Posted 16 April 2024 - 06:23 AM
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:
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?
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?
#3469 Posted 16 April 2024 - 07:02 AM
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":
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:
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:
That maybe would work.
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.
This post has been edited by Reaper_Man: 16 April 2024 - 07:23 AM
#3470 Posted 16 April 2024 - 07:22 AM
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
#3471 Posted 16 April 2024 - 07:29 AM
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.
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.
#3472 Posted 16 April 2024 - 07:42 AM
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!
#3473 Posted 16 April 2024 - 05:52 PM
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.
This post has been edited by VGames: 16 April 2024 - 05:52 PM
#3474 Posted 16 April 2024 - 08:28 PM
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
#3475 Posted 16 April 2024 - 09:18 PM
@VGames
If it's about the EDuke32 mini HUD, it should be something like
If it's about the EDuke32 mini HUD, it should be something like
ife userdef[].screen_size 4 ife userdef[].althud 1
#3476 Posted 17 April 2024 - 04:34 AM
Ah very nice. Thank u for the heads up. I knew I was missing something.
#3477 Posted 19 April 2024 - 07:01 AM
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.
#3478 Posted 29 April 2024 - 11:36 AM
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.
#3479 Posted 29 April 2024 - 12:50 PM
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.
#3480 Posted 29 April 2024 - 01:31 PM
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.