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.
Original GAME.CON fixes
#91 Posted 14 April 2020 - 03:26 PM
#92 Posted 15 April 2020 - 05:21 AM
LeoD, on 14 April 2020 - 01:18 PM, said:
Sorry if that bother you, but it's more convenient for me to find my way around, since I have more visible space.
#93 Posted 15 April 2020 - 10:52 AM
Darkus, on 14 April 2020 - 12:13 PM, said:
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.
#94 Posted 17 April 2020 - 02:16 PM
I took care to make schematic tables for that.
This post has been edited by F!re-Fly: 17 April 2020 - 02:17 PM
#95 Posted 22 April 2020 - 01:37 PM
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.
#96 Posted 22 April 2020 - 03:14 PM
Darkus, on 06 October 2016 - 03:35 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.
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.
#97 Posted 22 April 2020 - 04:48 PM
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.
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.
#98 Posted 24 April 2020 - 06:30 AM
Ninety-Six, on 22 April 2020 - 03:14 PM, said:
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
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 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: 296
#99 Posted 24 April 2020 - 06:44 AM
Darkus, on 24 April 2020 - 06:30 AM, said:
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:
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:
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?
This post has been edited by Ninety-Six: 24 April 2020 - 06:48 AM
#100 Posted 24 April 2020 - 06:59 AM
Ninety-Six, on 24 April 2020 - 06:44 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
#101 Posted 24 April 2020 - 07:00 AM
This post has been edited by necroslut: 24 April 2020 - 07:01 AM
#102 Posted 24 April 2020 - 07:01 AM
Darkus, on 24 April 2020 - 06:59 AM, said:
EDuke32.exe -mx mut_pigshoot.con -mx mut_drone_expl.con
Aha. I didn't know there was a dedicated command for them.
Danke.
#103 Posted 24 April 2020 - 07:04 AM
necroslut, on 24 April 2020 - 07:00 AM, said:
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."
This post has been edited by Ninety-Six: 24 April 2020 - 07:04 AM
#104 Posted 24 April 2020 - 07:14 AM
{ 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).
#105 Posted 24 April 2020 - 07:22 AM
Darkus, on 24 April 2020 - 07:14 AM, said:
{ 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.
This post has been edited by Ninety-Six: 24 April 2020 - 07:31 AM