[Seta]

Hi, dunno if this is somehow me, but... the fixed GAME.CON triggers 1 warning and 26 errors with Life's a Beach, so it can't boot. Here's what the log says:

USER.CON:844: warning: sound 261 already defined (hydro43.voc)
GAME.CON: In actor `SHARK':
GAME.CON:254: error: symbol `ACTOR_GROWING' is not a variable.
GAME.CON: In state `breakobject':
GAME.CON:400: error: symbol `MOUSEANNOY' is not a variable.
GAME.CON: In state `femcode':
GAME.CON:2266: error: symbol `ACTOR_GROWING' is not a variable.
GAME.CON: In actor `EGG':
GAME.CON:2672: error: symbol `ACTOR_GROWING' is not a variable.
GAME.CON: In actor `APLAYER':
GAME.CON:3091: error: symbol `ACTOR_GROWING' is not a variable.
GAME.CON: In state `checktroophit':
GAME.CON:3719: error: symbol `ACTOR_GROWING' is not a variable.
GAME.CON: In state `checklizhit':
GAME.CON:4387: error: symbol `ACTOR_GROWING' is not a variable.
GAME.CON: In state `checkoctahitstate':
GAME.CON:4902: error: symbol `ACTOR_GROWING' is not a variable.
GAME.CON: In state `checkpighitstate':
GAME.CON:5314: error: symbol `ACTOR_GROWING' is not a variable.
GAME.CON: In state `checkcommhitstate':
GAME.CON:6501: error: symbol `ACTOR_GROWING' is not a variable.
GAME.CON: In actor `SPEAKER':
GAME.CON:6897: error: symbol `STORE_MUSIC' is not a variable.
GAME.CON:6898: error: symbol `STORE_MUSIC_BROKE' is not a variable.
GAME.CON:6902: error: symbol `STORE_MUSIC' is not a variable.
GAME.CON:6904: error: symbol `STORE_MUSIC' is not a variable.
GAME.CON: In state `boss4layeggs':
GAME.CON:7196: error: symbol `BOS4_ATTACK' is not a variable.
GAME.CON: In state `checkboss4hitstate':
GAME.CON:7227: error: symbol `BOS4_PAIN' is not a variable.
GAME.CON:7230: error: symbol `BOS4_PAIN' is not a variable.
GAME.CON: In actor `NEWBEASTHANG':
GAME.CON:7308: error: symbol `NEWBEAST_PAIN' is not a variable.
GAME.CON:7315: error: symbol `NEWBEAST_RECOG' is not a variable.
GAME.CON: In state `newbeastthinkstate':
GAME.CON:7477: error: symbol `NEWBEAST_ROAM' is not a variable.
GAME.CON: In state `newbeastscratchstate':
GAME.CON:7544: error: symbol `NEWBEAST_ATTACK' is not a variable.
GAME.CON:7546: error: symbol `NEWBEAST_ATTACK' is not a variable.
GAME.CON: In state `checknewbeasthit':
GAME.CON:7592: error: symbol `ACTOR_GROWING' is not a variable.
GAME.CON:7606: error: symbol `NEWBEAST_DYING' is not a variable.
GAME.CON:7612: error: symbol `NEWBEAST_PAIN' is not a variable.
GAME.CON: In state `newbeastcode':
GAME.CON:7764: error: symbol `NEWBEAST_SPIT' is not a variable.

[Darkus]

It works only with the original Atomic Edition, the officials addons are not supported.

LeoD, on 14 April 2020 - 01:18 PM, said:

I think that's not a great idea, because it is a lot harder now to compare to the original CON and check out your modifications.

Sorry if that bother you, but it's more convenient for me to find my way around, since I have more visible space.

[F!re-Fly]

Darkus, on 14 April 2020 - 12:13 PM, said:

I don't use autoaim, but the problem sould be from EDuke. Normally, the auto aim is lowered as the sprite size is lower, even if it's the same actor who is changing it's own size (whatever it is shrinking, or playing crouching animation). The same trick could be also applied to the DOS version (if patched).



1) I wanted to do it first, but I thought it was useless, and could cause problems. Then I saw your post and I thought "why not, I'll take the risk"

2) It's just reorganization by deleting empty spaces/lines, that kind of thing.

Ok, great ! Minimizing empty spaces in script files has never bothered me. I think it's just a writing style.

I have other suggestions which could be sympathetic and which I will propose to you soon. Right now, I can manage the coding without asking too much for help again.

I just managed to create a new deadly floor and other stuff.

[F!re-Fly]

Here are some scrapped ideas. I thought it would be much nicer to have full animations of the different gun-related deaths. Namely the shrunker, the freezethrower and the expander.

I took care to make schematic tables for that.

[F!re-Fly]

Hi Darkus! I have other small remarks on the various deaths of Duke.

1. When he dies normally, his corpse does not disappear even when an explosion is nearby (for example a Commander who is still attacking).

2. Duke is not supposed to explode when he's on a deadly floor (FLOORSLIME, HURTRAIL, FLOORPLASMA and PURPLELAVA). Suggest a normal death.

[Ninety-Six]

Alright, so I know this is an old point but after having used these fixes for a good few years now, I'd like to think I can present my case much better.

Darkus, on 06 October 2016 - 03:35 PM, said:

Originaly, when you hit him, he can switch between three states: being hit, shoot while standing and shoot while crouching. The problem was he could restart the same shooting animation several times, making him shoot projectiles at very fast rate especially if you hit him with the chaingun. I fixed this by avoiding that the animation could restart, or switching betwen stand/crouch while he's shooting, and he can still change to 'being hit' animation when shooting, the probability is the same as before.

While this is technically true, the pig could trigger the actual "flinch" state at the same rate as before since the pain chance is untouched...in practice it's not as true.

Playing with he unaltered pig code, I can definitely say I have indeed seen the error you pointed out: sometimes the pig will shoot twice or rarely, three times in a second. But more often than not, he doesn't at all. I don't know what causes the difference, maybe it depends on the exact moment you begin shooting, but nevertheless the chaingun was extremely effective against the pig for exactly this reason. But with this fix in place, it loses a lot of its effectiveness as in the time to kill it takes to kill the pig, they will usually get off one shot about half the time. Up against a swarm, this can be deadly.

Compare this to an unfixed pig, and if you tried the same fight side-by-side several times, you'd see that you would, on average, take less damage with the unaltered behavior. By a not insignificant margin.


This is a considerable problem in user maps, as almost all of them depend on the unaltered interaction between the pigs and the chaingun. Ever take an elevator down only to be let out into a narrow hallway with a pig in your face? Nowhere to strafe to with the shotgun? Even the expansions work off this behavior, and I would argue it's quite likely the original maps did as well. While it may seem odd that the levels would be designed around buggy behavior, let's not forget that devastator ammo was almost always found in proximity to Battlelords despite the shrinker being able to deal with them in a single hit (which was difficult, albeit not impossible, without the fix you provided).


I'm never one to suggest throwing out hard work, as the new code is much cleaner, but I would recommend making it an option for users to switch to, much like how the sentry drone explosion delay/no delay was provided.

[F!re-Fly]

Ninety-Six, on 22 April 2020 - 03:14 PM, said:

Alright, so I know this is an old point but after having used these fixes for a good few years now, I'd like to think I can present my case much better.



While this is technically true, the pig could trigger the actual "flinch" state at the same rate as before since the pain chance is untouched...in practice it's not as true.

Playing with he unaltered pig code, I can definitely say I have indeed seen the error you pointed out: sometimes the pig will shoot twice or rarely, three times in a second. But more often than not, he doesn't at all. I don't know what causes the difference, maybe it depends on the exact moment you begin shooting, but nevertheless the chaingun was extremely effective against the pig for exactly this reason. But with this fix in place, it loses a lot of its effectiveness as in the time to kill it takes to kill the pig, they will usually get off one shot about half the time. Up against a swarm, this can be deadly.

Compare this to an unfixed pig, and if you tried the same fight side-by-side several times, you'd see that you would, on average, take less damage with the unaltered behavior. By a not insignificant margin.


This is a considerable problem in user maps, as almost all of them depend on the unaltered interaction between the pigs and the chaingun. Ever take an elevator down only to be let out into a narrow hallway with a pig in your face? Nowhere to strafe to with the shotgun? Even the expansions work off this behavior, and I would argue it's quite likely the original maps did as well. While it may seem odd that the levels would be designed around buggy behavior, let's not forget that devastator ammo was almost always found in proximity to Battlelords despite the shrinker being able to deal with them in a single hit (which was difficult, albeit not impossible, without the fix you provided).


I'm never one to suggest throwing out hard work, as the new code is much cleaner, but I would recommend making it an option for users to switch to, much like how the sentry drone explosion delay/no delay was provided.

I had encountered the same thing with the pig cop. I think it is very easy to correct the syntax, while keeping the same behavior.

[Darkus]

Ninety-Six, on 22 April 2020 - 03:14 PM, said:

While this is technically true, the pig could trigger the actual "flinch" state at the same rate as before since the pain chance is untouched...in practice it's not as true.

Playing with he unaltered pig code, I can definitely say I have indeed seen the error you pointed out: sometimes the pig will shoot twice or rarely, three times in a second. But more often than not, he doesn't at all. I don't know what causes the difference, maybe it depends on the exact moment you begin shooting, but nevertheless the chaingun was extremely effective against the pig for exactly this reason. But with this fix in place, it loses a lot of its effectiveness as in the time to kill it takes to kill the pig, they will usually get off one shot about half the time. Up against a swarm, this can be deadly.

Compare this to an unfixed pig, and if you tried the same fight side-by-side several times, you'd see that you would, on average, take less damage with the unaltered behavior. By a not insignificant margin.

Maybe the pig cops are supposed to be that deadly? In the original behavior, sometimes the shooting animation keep reseting/switching so fast, that he couldnt shoot, but there are few cases that he manage to shoot at very fast rate. The latter can be problematic, he can get you down very quickly, even if you have 100% health.

Quote

This is a considerable problem in user maps, as almost all of them depend on the unaltered interaction between the pigs and the chaingun. Ever take an elevator down only to be let out into a narrow hallway with a pig in your face? Nowhere to strafe to with the shotgun? Even the expansions work off this behavior, and I would argue it's quite likely the original maps did as well. While it may seem odd that the levels would be designed around buggy behavior, let's not forget that devastator ammo was almost always found in proximity to Battlelords despite the shrinker being able to deal with them in a single hit (which was difficult, albeit not impossible, without the fix you provided).

I don't think it's a good thing when maps rely on bugs/glitches, they could be broke when something else is fixed (pun intended). I remember when the 'sector over sector' warp bug was corrected, a thing I awaited for long, some have complained because they could no longer use the teleport trick in some maps (E1L1 for example), because they were used to it. Basically: "it's not a bug, it's a feature"

I could also add example of the case of the Overlord and Cycloid mini-bosses, in the original, they only have 1 HP and often end killing themselves.

Quote

I'm never one to suggest throwing out hard work, as the new code is much cleaner, but I would recommend making it an option for users to switch to, much like how the sentry drone explosion delay/no delay was provided.

I don't want to modify my code just for that... However, these mutators will suffice:

mut_pigshoot.con - revert back hit behavior
mut_drone_expl.con - implemented delayed explosion how it was supposed to be
mut_boss1_shprob.con - Battlelords are more difficult to shrink (12,5% probability)

 mutators_revert.zip (2.67K)
Number of downloads: 335

[Ninety-Six]

Darkus, on 24 April 2020 - 06:30 AM, said:

Maybe the pig cops are supposed to be that deadly? In the original behavior, sometimes the shooting animation keep reseting/switching so fast, that he couldnt shoot, but there are few cases that he manage to shoot at very fast rate. The latter can be problematic, he can get you down very quickly, even if you have 100% health.



I don't think it's a good thing when maps rely on bugs/glitches, they could be broke when something else is fixed (pun intended). I remember when the 'sector over sector' warp bug was corrected, a thing I awaited for long, some have complained because they could no longer use the teleport trick in some maps (E1L1 for example), because they were used to it. Basically: "it's not a bug, it's a feature"

For the most part, I would agree. However, for the majority of those maps, I would say that the mappers were not intentionally relying on a bug. As far as they knew, that was the intended behavior. Take the very first level of DC. You are given a chaingun right before a swarm of pigs. There is no other way to interpret that other than "here is a bunch of pigs, here is the chaingun that's great against them, go nuts."

Even some of the vanilla levels seem to encourage gunning down pig swarms with the chaingun. Mostly in Levelord and Birth levels, granted, but still present. Again, devastator ammo was present around Battlelords even though that was buggy behavior.

There's evidence of a disconnect between intended code and even 3DR level design, is my point. In fact it's quite possible that instead of the level designers being unaware of these bugs, it was decided that the game was better off with these quirks. It would hardly be the first time that a bug inspired new behavior in a commercial project, and certainly not the last.

Darkus, on 24 April 2020 - 06:30 AM, said:

I could also add example of the case of the Overlord and Cycloid mini-bosses, in the original, they only have 1 HP and often end killing themselves.

On this point, I would again mostly agree with you. Levels that intentionally use that behavior... they aren't so great.

But I would argue the vast majority of maps that use them (in their original incarnation) were done by amateurs. Amateurs that saw them in the editor, went "oh so they're like the mini battlelords! Cool!" and put them in without realizing that they are broken.

Darkus, on 24 April 2020 - 06:30 AM, said:

I don't want to modify my code just for that... However, these mutators will suffice:

mut_pigshoot.con - revert back hit behavior
mut_drone_expl.con - implemented delayed explosion how it was supposed to be
mut_boss1_shprob.con - Battlelords are more difficult to shrink (12,5% probability)

Yeah, that's an effective compromise. Thank you.

How would I insert this? #include command or should I copypaste the code over the fixed GAME itself?

[Darkus]

Ninety-Six, on 24 April 2020 - 06:44 AM, said:

How would I insert this? #include command or should I copypaste the code over the fixed GAME itself?

They're mutators, this allows to make changes without modifying the original file, just use the '-mx' command line, like this:

EDuke32.exe -mx mut_pigshoot.con -mx mut_drone_expl.con

[necroslut]

I don't get the confusion regarding Pigcop behavior. It seems quite clear to me that you are meant to be able to stunlock Pigcops, but that the rapid-fire is an unintended side effect.

[Ninety-Six]

Darkus, on 24 April 2020 - 06:59 AM, said:

They're mutators, this allows to make changes without modifying the original file, just use the '-mx' command line, like this:

EDuke32.exe -mx mut_pigshoot.con -mx mut_drone_expl.con

Aha. I didn't know there was a dedicated command for them.

Danke.

[Ninety-Six]

necroslut, on 24 April 2020 - 07:00 AM, said:

I don't get the confusion regarding Pigcop behavior. It seems quite clear to me that you are meant to be able to stunlock Pigcops, but that the rapid-fire is an unintended side effect.

I spent a long time over the past couple of years staring at the block of code regarding the pig's pain chance, trying to tweak it to see if I could get it to reasonably match the vanilla behavior. I've started to wonder if the higher pain chance wasn't actually raised to specifically work within the boundaries of the "piggy dance."

[Darkus]

The code of the hurt animation is here, find the commented line:

    { ifai AIPIGSHRINK break
      ifrnd 32 // don't reset shooting animations when hit
      { ifactor PIGCOPDIVE cactor PIGCOP ai AIPIGHIT }

To modify the probability, just change the number of ifrnd 32 with a range of 0 (never) to 255 (always). The same line is in the mutator as well (with a different comment).

[Ninety-Six]

Darkus, on 24 April 2020 - 07:14 AM, said:

The code of the hurt animation is here, find the commented line:

    { ifai AIPIGSHRINK break
      ifrnd 32 // don't reset shooting animations when hit
      { ifactor PIGCOPDIVE cactor PIGCOP ai AIPIGHIT }

To modify the probability, just change the number of ifrnd 32 with a range of 0 (never) to 255 (always). The same line is in the mutator as well (with a different comment).

I know, which I've done. But I never could quite get it to match, always seeming still just off, which is why I said I started wondering if the pig got his lower pain chance to balance specifically the piggy dance of the unaltered code. But that's more idle wondering than anything.

Though it was my constant tinkering with that number that led me to present my case much more confidently. The first time I got it backwards and lowered the number to 16, which actually made it rarer. After realizing that, I experimented with more numbers, running the gambit from 32, to 64 (the standard for the other aliens), and a few higher ones just to see what happened. Nothing really fit; either the pig flinched not enough, or way too much. None of the numbers I tried managed to find the sweet spot that struck the same balance that the unfixed code did, that most maps depended on.