[brullov]

I can misunderstand something, cause I don't know anything about software and how to handle all of that stuff. Seems like Duke 3D is broken now because of IF engine updates? Please correct me if I am wrong. It would be very nice to have a separate "Eduke32 for Duke 3D" release someday which won't be connceted with Fury. I don't talk about cool features like IF has or multiplayer. Just a stable stuff to play my favourite game and enjoy making user content for it.

TerminX, your input for the last 15 years is priceless. Your name and soul has every map, mod or TC.

[Mark]

I don't know about the rest of you but I feel a bit better after reading TX's explanation. See, a little communication can go a long way. That kind of response for long standing bugs helps me have a little more patience. Hearing nothing = the opposite.

[Radar]

IMO Duke3D and IF should stay combined in one executable. IF is after all based directly on Duke. What's the point of producing a second executable for code that is 98% identical? But I would recommend that stuff that is broken shouldn't be committed. For example, once it was clear you could warp through the ticket window in E1L1, why wasn't that change reverted immediately? Also, stuff that fixes issues in IF that breaks things in Duke should be set to load only on condition of IF being selected.

[Danukem]

Radar 100 Watts, on 26 January 2020 - 01:32 PM, said:

IMO Duke3D and IF should stay combined in one executable. IF is after all based directly on Duke. What's the point of producing a second executable for code that is 98% identical?

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.

[Mblackwell]

The player's clip boundary in IF is actually smaller than Duke's btw. So despite not having "shrinking" the player can squeeze into lots of places.

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.

[Danukem]

Mblackwell, on 26 January 2020 - 03:45 PM, said:

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.

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.

[Tea Monster]

They are right though. The "Duke" part of EDuke32 has been abandoned so that priority is given to IF features. I understand why. You are making a commercial game and you need to prioritise that over fan stuff. I'm pretty sure we all understand that. None of us dismiss the work you guys do. None of us expect you to give up your dreams of writing your own chapter in the history of the BUILD engine. Neither do the members here expect anything else than prioritising your career and family over an open source game engine's bugs.

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.

[Mblackwell]

You now know exactly when the player or objects will clip with things rather than just randomly autostepping. Autostepping and warping (all collision) are nightmares with the engine and modding that require substantial workarounds. These have mostly been cleared up by this point. That's the predictability component.

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.

[Mark]

Thus spake the Monster of Tea

[Radar]

Trooper Dan, on 26 January 2020 - 02:01 PM, said:

We share 98% of our DNA with chimps but I wouldn't want humans and chimps coming out of the same uterus...

Sure, but unlike DNA, C++ allows conditional statements.

[Radar]

Anyway, I was initially excited for the commercial direction EDuke32 was going in solely because I thought dedicated servers were coming soon. Yeah I know IF multiplayer would be dead in a week and Duke3D on Doomseeker would see 20 people daily. But I was hoping the commercial incentive would be the motivating factor to finally get this crucial mode of the game in a playable state. But I'm getting mixed signals from the team regarding the value of multiplayer. I feel like some folks think not only does it hold no value, but the gameplay mode itself is detrimental to the source port, because the Dukematch community produces so much toxicity. Over there, people get angry over lost games. Over here, people get angry over lines of code. What's the difference?

[Ninety-Six]

TerminX, on 26 January 2020 - 09:57 AM, said:

The reason it has remained broken is because I've been unable to come up with a suitable set of rules to allow me to fix the issues, yet leave things just barely broken enough that all of the existing maps work.

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.

[Danukem]

Radar 100 Watts, on 26 January 2020 - 06:11 PM, said:

Sure, but unlike DNA, C++ allows conditional statements.

However it's accomplished, we all want the same result. Also:

Spoiler

Some genes are always expressed, but a great many genes are only expressed under certain conditions which is analogous to conditional statements.

Quote

Gene Regulation can be summarized by the response of the respective system:
Inducible systems - An inducible system is off unless there is the presence of some molecule (called an inducer) that allows for gene expression. The molecule is said to "induce expression". The manner by which this happens is dependent on the control mechanisms as well as differences between prokaryotic and eukaryotic cells.
Repressible systems - A repressible system is on except in the presence of some molecule (called a corepressor) that suppresses gene expression. The molecule is said to "repress expression". The manner by which this happens is dependent on the control mechanisms as well as differences between prokaryotic and eukaryotic cells.

https://en.wikipedia...gene_expression

Ninety-Six, on 26 January 2020 - 07:08 PM, 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

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.

[Radar]

Trooper Dan, on 26 January 2020 - 07:13 PM, said:

Some genes are always expressed, but a great many genes are only expressed under certain conditions which is analogous to conditional statements.

https://en.wikipedia...gene_expression

God does exist.

[oasiz]

Mblackwell, on 26 January 2020 - 05:06 PM, said:

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.

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

[Jimmy]

I do not intend to throw gasoline on the fire in any way, and I actually find this conversation very comforting. But I must be frank, I haven't played anything Duke 3D in over two years just because the port is so unstable, and I have no idea when the last stable release was. While it's given me plenty of time to get into stuff I missed from Doom (been digging into DTWID, NUT!) I've been kind of bummed about Duke. Further into the point, I've pretty much abandoned modding the game because there's scant documentation these days unless you want to dig into source comments and so much shit has been changed, and you don't know whats broken half the time. I've just kind of put myself into limbo until things shape up more. The main reason I bring this up is because I really can't be the only one. It's something to think about.

[Mark]

"I do not intend to throw gasoline on the fire in any way"

Just when I thought I'd seen it all...

[Doom64hunter]

Fixed in r8572.

[Forge]

Thank you Tx & the rest of the dev team.

[Danukem]

I did notice one oddity. There was a version I tested prior to the big clipping change where you could still kick when shrunk, but your kick couldn't hit anything. In the latest version, you can't kick at all. I don't know which of those two behaviors is the DOS Duke behavior.

[Forge]

In vanilla DOS duke3d, you can quick-kick while shrunk, the boot & leg come up, but it's doesn't hit or hurt enemies

[Doom64hunter]

Trooper Dan, on 30 January 2020 - 03:29 PM, said:

I did notice one oddity. There was a version I tested prior to the big clipping change where you could still kick when shrunk, but your kick couldn't hit anything. In the latest version, you can't kick at all. I don't know which of those two behaviors is the DOS Duke behavior.

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.

[Danukem]

Doom64hunter, on 30 January 2020 - 05:53 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.

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.

[Fox]

If you are using a development snapshot, you should expect it to not be working 100%.

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.

[Danukem]

Fox, on 16 February 2020 - 05:01 PM, said:

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.

  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.

[Jimmy]

Yeah I don't think it was a bug so much as something that worked intrinsically for no particular reason. The shrinker has no bite if enemies can't kill you.

[Fox]

I said it was accidentally fixed.

Trooper Dan, on 16 February 2020 - 06:36 PM, said:

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.

"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.

[Darkus]

I'm the only one who finds it absurd to reintroduce old bugs to 'fix' the game? I liked how player behave when shrunk and the new clipping collision with sprites, but now I feel like we're going backwards by reintroducing those bugs. I guess that many maps relied too much on them.

[Danukem]

Darkus, on 17 February 2020 - 06:40 AM, said:

I'm the only one who finds it absurd to reintroduce old bugs to 'fix' the game? I liked how player behave when shrunk and the new clipping collision with sprites, but now I feel like we're going backwards by reintroducing those bugs. I guess that many maps relied too much on them.

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.

[Fox]

Radar 100 Watts, on 26 January 2020 - 09:36 PM, said:

God does exist.

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