[Fixed] Impossible to get crushed by enemies when shrunk
#31 Posted 26 January 2020 - 12:08 PM
TerminX, your input for the last 15 years is priceless. Your name and soul has every map, mod or TC.
#32 Posted 26 January 2020 - 12:28 PM
This post has been edited by Mark: 26 January 2020 - 12:29 PM
#33 Posted 26 January 2020 - 01:32 PM
#34 Posted 26 January 2020 - 02:01 PM
Radar 100 Watts, on 26 January 2020 - 01:32 PM, said:
We share 98% of our DNA with chimps but I wouldn't want humans and chimps coming out of the same uterus...
My two bits...
IF doesn't have shrinking, and the shrinking in Duke has some peculiar behavior that is never going to be a natural consequence of any sensible clipping or physics. This is a case where it's fine if there is hardcoded stuff specifically in Duke 3D that overrides normal behavior just to make shrinking work as intended. But since IF doesn't even have shrinking, it's probably harmless to leave that hardcoded stuff in there in the IF build, since it would never be encountered anyway.
The climbing on sprites ladder clipping stuff is a different animal. You definitely don't want IF behaving like Duke in that respect, any more than you want your human baby behaving like a chimp. But that quirky clipping behavior is deep in Duke's DNA.
#35 Posted 26 January 2020 - 03:45 PM
Most of the changes done were tested against Duke Nukem 3D, and were based on years of user, mapper, and modder complaints and feedback on how terrible and inaccurate the clipping was and how many issues it caused (deaths, out of bounds objects, etc). Contrary to popular belief, while you guys experienced a bunch of old glitches being fixes and a few new limitations and things that need tweaking, I spent 4-6 months constantly tweaking and fixing things in Ion Fury to keep everyone's level's and effects working, because we sometimes relied on exploiting the glitchy behavior as well as a shortcut.
In the end we got a state of predictability that many people have been hoping for for decades, and it's still being improved (including some way of having compatibility with some specific things is intended). It's easy to complain when you lack another's perspective, and it's not helpful to ascribe negative feelings about someone's motives based on an incorrect speculation.
#36 Posted 26 January 2020 - 04:46 PM
Mblackwell, on 26 January 2020 - 03:45 PM, said:
It's true that ignorant complaints are unhelpful, and it's also true that such incorrect speculation can (largely) be quelled with communication. We've now been going on over half a year with major breakages, such as the shrinking bugs that completely negate the ability of monsters to crush the player etc., as discussed in this thread. It feels a bit disingenuous to describe that as "a state of predictability that many people have been hoping for for decades".
I'm not excusing people who impugn the devs with false motives and throw bombs, but part of the core mission of EDuke32 has always been to run Duke 3D properly (i.e. not break the game), and if it's breaking the game in significant ways for many months with hardly a comment on some of the issues, despite numerous reports on them, you can't expect people to have good feelings about it. The fact that you spent a lot of time working on IF prior to those reports hardly seems relevant.
#37 Posted 26 January 2020 - 04:49 PM
But this is a Duke Nukem forum, and people will be annoyed that stuff is broken while playing Duke 3D. I don't think that people are being especially arsey about this. If you look at the first page of this thread, it's very professional. You have people who are actively trying to track down where the problem lies and describe it so that we understand what is going on. This is advanced bug reporting. It's not whiny, even when some amount of sarcasm appears. We are all aware of the weapons-grade levels of trolling that would occur if people truly lost their shit with you guys, and none of that is on show here.
I think that people are naturally frustrated when there is no word from you guys as to what is happening. A lot of the current situation has been pieced together by ourselves. I've personally said to at least one member that to cure the problem of the code that you are working on, it will have to be very broken for a while in order for you guys to narrow down what is the problem and how to fix it so it works in IF and DN3D. I personally regard that as expected, and I'm not a coder. Just a bit of communication would have really helped people deal with this (again, not that they are dealing with it badly). Even if it's just "We have to break it to fix it, normal service will resume at some point".
None of the discussion or mild annoyance on this thread warranted you verbally ripping people's heads off. It just doesn't. Respect should go both ways. Currently it is only in one direction.
#38 Posted 26 January 2020 - 05:06 PM
The core mission of EDuke32 and EDuke 2.0 before it has been to enable making cool mods. It's never been 100% accurate but changes are generally done in ways that won't break the base Duke Nukem 3D game and keep things as close as possible. I think what folks might fail to understand is that when a particular issue does crop up it's because the engine is spaghetti, and hacks on hacks, and the VP guys are trying to untangle it from all the BS precisely so that in the future these things happen intentionally and not as a consequence of 10 bugs colliding.
Doom64hunter is one of many people the folks at VP talk to about these issues on a regular basis, and about these specific issues and potentially what can be done with them. This topic has spilled over between multiple threads now with a lot of nastiness, and while maybe the devs could be more communicative, you also shouldn't make assumptions.
And no, the Duke part wasn't abandoned for IF. In fact as I said it's exactly the opposite. The clipping changes were being tested against Duke Nukem 3D and no one gave two shits about Ion Fury (I exaggerate, again don't make assumptions ) and it was my job to make it work anyway. Duke was the already released title and therefore the baseline behavior.
You assume that the EDuke32 devs "work on IF" but they actually work with Duke Nukem 3D when testing behaviors, and it's generally everyone's job on the IF team to just play catch up, unless there is a clear breakage from the engine side. D3D is a well known quantity by comparison.
#40 Posted 26 January 2020 - 06:11 PM
Trooper Dan, on 26 January 2020 - 02:01 PM, said:
Sure, but unlike DNA, C++ allows conditional statements.
#41 Posted 26 January 2020 - 07:06 PM
#42 Posted 26 January 2020 - 07:08 PM
TerminX, on 26 January 2020 - 09:57 AM, said:
Pardon my ignorance as I'm sure this has been considered already, but why can't some kind of compatibility menu or launch parameter be implemented like the zdoom family or prboom? I understand it would be a bit inconvenient for the end user, but to mitigate that maybe eduke could automatically detect certain user maps and episodes (like the major ones that almost everyone has played) and set those parameters automatically, and leave the menu or whatever for those not covered.
#43 Posted 26 January 2020 - 07:13 PM
Radar 100 Watts, on 26 January 2020 - 06:11 PM, said:
However it's accomplished, we all want the same result. Also:
Ninety-Six, on 26 January 2020 - 07:08 PM, said:
Please let's not bring this red herring into the conversation again. Every time it comes up, it gets us sidetracked. The devs hate the idea and they are right to hate it. Besides, it's not like there's a Duke map where you are going to want player shrinking to be broken AF.
#44 Posted 26 January 2020 - 09:36 PM
Trooper Dan, on 26 January 2020 - 07:13 PM, said:
https://en.wikipedia...gene_expression
God does exist.
#45 Posted 26 January 2020 - 10:09 PM
Mblackwell, on 26 January 2020 - 05:06 PM, said:
You assume that the EDuke32 devs "work on IF" but they actually work with Duke Nukem 3D when testing behaviors, and it's generally everyone's job on the IF team to just play catch up, unless there is a clear breakage from the engine side. D3D is a well known quantity by comparison.
This.
I know it's easy for us to say but this is really how the codebase was developed, always duke first.
If more than anything, some things were done against fury.
i.e. conveyor belts: it used to behave more naturally (not DOS behavior) but was later reverted to duke behavior, breaking escalators and belts in fury almost completely. This was done for sake of Duke being a first class citizen.
Hell, the whole clipping overhaul practically cost us few months of work where we had to retrofit many maps and remember that this was done after preview campaign had already shipped and around hhoh release (and full game maps had already been started ages ago).
The game could still be done without the clipping no problem.
Now after months of hard work, the game DOES rely on the new (better) clipping so yes, reverting it back would indeed break fury but it didn't use to be the case. I simply want to dispel the misconception that Changes were only done with fury in mind. It wasn't about fury'izing eduke, it broke both, fury even more as it relied so much on many of the quirks.
Although the game did now reach a point where new clipping does beat the old one (due to no legacy baggage), but this wasn't until around last weeks of dev where it was stable enough. Even late betas (incl. maybe earliest press copies?) still had horrible collision issues that rendered parts near unplayable as you would just get stuck on walls or die randomly when backing to a wall.
I can't stop people form believing what they want to believe but this is literally the case
#46 Posted 26 January 2020 - 10:09 PM
#47 Posted 27 January 2020 - 04:44 AM
Just when I thought I'd seen it all...
#50 Posted 30 January 2020 - 03:29 PM
#51 Posted 30 January 2020 - 03:42 PM
This post has been edited by Forge: 30 January 2020 - 03:44 PM
#52 Posted 30 January 2020 - 05:53 PM
Trooper Dan, on 30 January 2020 - 03:29 PM, said:
Strange, quick kick while shrunk works for me in r8573. You can still hit things if you jetpack up while shrunk, which is the same behavior as in DOS.
#53 Posted 30 January 2020 - 09:16 PM
Doom64hunter, on 30 January 2020 - 05:53 PM, said:
I'm not sure how I did it, but if I can replicate it in vanilla I'll report back.
EDIT: I tried to replicate this in vanilla cons just now, and I ran into a bug you mentioned elsewhere. The shrinker from the newbeast was hitting me and did not shrink me. Three times. Funnily enough, the shrinker works fine on the player in AA, since I use a modified shrinker radius.
This post has been edited by Trooper Dan: 30 January 2020 - 09:23 PM
#54 Posted 16 February 2020 - 05:01 PM
Regarding the shrinking problem:
There's nothing in the code to allow the player to move under enemies or to get stomped by them. These behaviors are all bugs. And these were accidentally fixed in the new collision code.
I just want everyone to understand how bizarre it is from a programming angle. If the game was done the right way, the CON code would have some lines for monsters killing the player when he's shrunk or frozen. But there's nothing. Not even for the Protector Drone.
#55 Posted 16 February 2020 - 06:36 PM
Fox, on 16 February 2020 - 05:01 PM, said:
I just want everyone to understand how bizarre it is from a programming angle. If the game was done the right way, the CON code would have some lines for monsters killing the player when he's shrunk or frozen. But there's nothing. Not even for the Protector Drone.
ifmove PSHRINKING { ifcount 32 { ifcount SHRUNKDONECOUNT { move 0 cstat 257 } else ifcount SHRUNKCOUNT { sizeto 42 36 ifgapzl 24 { strength 0 sound SQUISHED palfrom 48 64 break } } else ifp ponsteroids count SHRUNKCOUNT }
Even if Todd Replogle did not originally intend for the player to go underneath enemies when shrunk, he did intend for the player to get crushed by whatever was above when growing back to regular size. Moreover, the behavior of slipping under enemies when shrunk was in the game when they made the maps for it. As far as the level designers were concerned, it was a feature, and this is pretty obvious from the situations that the player is put into.
I understand what you are trying to say, but not all behavior that was originally unintended is buggy behavior. Sometimes you get behavior that is an accidental consequence of code, but it's useful and you go with it. Maybe it gets redone in the "right way" later on, but not necessarily. Think about this in a cosmic sense. If someone wrote out the laws of physics, they might not realize that as a consequence there could be black holes. But that does not mean that black holes are "bugs", it just means they are an unintended consequence. If an interstellar engineer designed a giant theme park around the effects of black holes, they would be pretty pissed off if god patched them out.
#56 Posted 16 February 2020 - 09:33 PM
#57 Posted 17 February 2020 - 12:00 AM
Trooper Dan, on 16 February 2020 - 06:36 PM, said:
"ifgapzl" only checks if the distance between the floorz and ceilingz is less than the value specified (multiplied by 256). It doesn't check for sprite or anything.
#58 Posted 17 February 2020 - 06:40 AM
#59 Posted 17 February 2020 - 08:59 AM
Darkus, on 17 February 2020 - 06:40 AM, said:
It would be absurd except that part of EDuke32's mission is to provide a port of Duke Nukem 3D, where that behavior is important. I would not be opposed to seeing a "faithful port" fork that has all the old behavior, buggy and all, and a "perflect platform" fork that is designed for making new games with everything done correctly. But last I checked, the devs don't want to fork it, so we have a compromise.
#60 Posted 17 February 2020 - 11:01 AM
Radar 100 Watts, on 26 January 2020 - 09:36 PM, said:
Gene regulation is not evidence of the existence of a god
Such operation is akin to programming, while a god would have the ability to grant his own wishes
If anything, the similarity with programming is evidence that we live in a simulated reality