[Hendricks266]

Gameplay that requires the use of non-obvious glitches to be balanced is not balanced at all. Against a general community who may not be aware of all the ways to abuse a map's layout, warping is cheating, and I'm glad to see it gone. It can stay left behind inside the Meltdown bubble, a place born from a hostile fork of an open source netplay guider made with goodwill, and a family of GPL-ignoring ports.

Anyone complaining about accuracy to this level will already be very unhappy with the many changes, including legitimate improvements, made to EDuke32's game logic over the past 15 years. Hope for you may lie in Rednukem's accuracy-focused core. We'll see what the future holds.

[HellFire]

Lunick, on 19 March 2019 - 04:02 PM, said:

I can understand wanting to keep the game how it was for authenticity but warping was never intended in the first place and is made worse by some ports such as Megaton (albeit a fork) which is the choice port for speedrunning now. As for multiplayer, That's not a huge concern right now But the majority of casual players won't care, it's not like other multiplayer Duke source ports are gonna go anywhere.

Of course it was not intended, no one is saying it was. But its already part of the gameplay. The best players (i know this can sound annoying, buts its the truth, not that it matters tho) in the world use it on online matches and on speedruns, just removing it without having an option to turn it back to how it was originally is a mistake. The new behaviour could be the default one, theres no problem with that, but straight up removing it is a mistake.

What comes next? Removing auto aim because everyone have a mouse these days? Cutting the player speed in half because they never intended Duke to be faster than Usain Bolt?

Of course the other ports won't go anywhere, but at the end of the day, it's Eduke32 that will keep duke alive in the long run, the other ports will end up having less and less significance because they simply dont have such dedicated people working on them. Its a shame that old ass ports will be more like duke than Eduke32.

TerminX, on 19 March 2019 - 04:02 PM, said:

I wouldn't personally use words like polluting, but my general opinion is that players who rely on bugs and glitches to win need to "git gud."

Reminds me of how players didn't want to use Atomic Edition when it came out because they couldn't use the "K cheat" anymore.

It has nothing to do with "git gud". We have been playing this game for years and years, we have perfected the respawn and item routes for the main maps, and most of them rely on warps to be effective.
Thats like saying using auto aim is for noobs and you need to "git gud" and stop using it (good luck with your shotgun shots vs a fast moving player, and i'm not even talking about steroids).

[TerminX]

HellFire, on 19 March 2019 - 04:15 PM, said:

What comes next? Removing auto aim because everyone have a mouse these days? Cutting the player speed in half because they never intended Duke to be faster than Usain Bolt?

Could you explain a bit more about how fixing glitches which allow players who know how to use them to cheat is in any way comparable to the idea of changing the elements the game was actually balanced around?

I'm sorry that you spent 20 years learning item routes that require cheats to accomplish. Here's hoping the next 20 helps you learn the ones the developers actually intended to exist.

[HellFire]

I dont think its comaparable, because i dont think that applies to what we're talking about at all. Warps are not cheats, you can see them as "exploits", but they're definitelly not cheating: anyone can do it, it's not like i'm installing external sfotware or editing the files that originally shipped with the game in any way to be able to do it while everyone else can't. You just happen to dislike it, and then you call it cheating so you can feel good about it.

[HellFire]

Hendricks266, on 19 March 2019 - 04:14 PM, said:

Gameplay that requires the use of non-obvious glitches to be balanced is not balanced at all. Against a general community who may not be aware of all the ways to abuse a map's layout, warping is cheating, and I'm glad to see it gone. It can stay left behind inside the Meltdown bubble, a place born from a hostile fork of an open source netplay guider made with goodwill, and a family of GPL-ignoring ports.

I see it now, you simply dont know what you're talking about. Go tell that to the Starcraft: Broodwar community (which pretty much invented the concept of "esports"). The game has a fair amount of bugs and Blizzard refuses to fix all of them because most of them are now part of the gameplay. You can search on liquidpedia if you want to understand more about this stuff if you want. Basically there are tournament legal bugs and tournament illegal bugs. There's some bugs that are not simple to do that crucial for the balance of the game, and some other ones that can break the game. The later ones are banned on tournament play. If Duke was as big as broodwar, warps would be tournament legal bugs, simply because all the good players enjoy using it and dont find it to be an abuse at all.

As for the "meltdown bubble" thing, this community is also a bubble. As for the fork being hostile, thats fault of the one that made the fork, not the users that just dont have anything better to use than it, or you're telling me that there's an alternative to meltdown that have just as much features and also have "goodwill"? At the end of the day people care about results, and Poda delivered, even though his methods aren't the best (i've also been a crictic of meltdown for quite some time fyi).

Hendricks266, on 19 March 2019 - 04:14 PM, said:

Anyone complaining about accuracy to this level will already be very unhappy with the many changes, including legitimate improvements, made to EDuke32's game logic over the past 15 years. Hope for you may lie in Rednukem's accuracy-focused core. We'll see what the future holds.

I actually agree with this, which is why the dukematch people dont use eduke32 for dukematches(me included). I still like Eduke32 a lot, i use it on mods and for usermaps, and i think it's just sad when i see a change like this.

[MusicallyInspired]

Comparing auto-aim (an intentional game feature) to glitch-warping (a thoroughly unintentional one) is ridiculous.

[HellFire]

It being intentional doesnt really matter: in the end, they're have both been part of the game for 20+ years. And yes, they're comparable because they both share some characteristics like: 1)they both can be seen as "cheating" from some people that just don't know what they're talking about; and 2)they both would ruin the "dukematch meta" if removed.

I understand that i'm advocating for a oldschool dukematch thing on the "modders bubble"(using hendricks rationale), so i'm not expecting you guys will agree with me anyway, i just though you guys would be reasonable and admit that is part of the game,even though you may not like it, but i guess this is asking for too much.

[Danukem]

I personally will be glad to see SOS glitch warping fixed, but I understand the other point of view. The fact is, Eduke32 is compromised by the need to maintain compatibility with old behavior and I know it can't be fun to be held back by it all the time.

What I would love to see is a fork of Eduke32 that removed all the hardcoded Duke 3D crap and did everything the right way. It could be a general platform for Build, maybe call it "Build Pro". Eduke32 could then just be maintained for bug fixes but otherwise left alone. I would be willing to spend a lot of time making new mods and converting old ones to work with a new fork like that, with all the improvements that would be possible.

[Mark]

Forking is a dirty word here. I wanted one years ago for advancing Polymer regardless of 100 percent backwards compatibility.

[Forge]

There already is a new fork. It's called "Eduke32"

Unless I'm paying someone to maintain the program, what I have to say doesn't matter.

[Mblackwell]

Wall pushes/warps are a cheat.


They can be a fun cheat. But it's still a cheat.

[High Treason]

I'm not going to give an opinion either way, not least of which because EDuke32 is already so 'broken' and different compared the the MS-DOS version that it's practically irrelevant at this point.

However, I am going to chime in and say that I don't consider 'cheat' to be the right word in this case, this is an exploit, one is exploiting the way a game feature works in order to gain an advantage, this is no different to using the access switch through the wall in E1L2. It's a fine line and the question is where does one place that line? Is using a jetpack you have left over to skip parts of a level cheating? Is jumping on an enemies head to reach an area you're not meant to be in yet cheating? Does the game need to be modified for their removal, because the developers certainly didn't intend the latter at all or is it simply a case of different people playing the game in different ways?

What about laser tripmines preventing fall damage? Kicking locked doors open? Abusing steroids? Shrinking mini battlelords? Strafe running? Collecting items through walls? Hump-jumping to enter small spaces or pass through badly setup blocking walls (I'll give an opinion on this; poor level design choices)? Placing pipebombs or missiles through certain walls? Just where do you draw the line.

[Mblackwell]

The developers intended for you to be able to use the jetpack in levels other than the one you found it.

[Radar]

Yeah, I'm so against "fixing" the SOS bugs. Throwing shade at online players is obviously not an uninintended side-effect of this "improvement". Just goes to show none of the EDuke32 developers have roots in the online scene. But whatever, do what you want.

[Forge]

for the benefit of people who don't know sarcasm when they see it,
.
this change has nothing to do with Duke3D and everything to do with Ion Maiden.

[MusicallyInspired]

I never even heard of the exploit before. So if I decided to go play online with one of these forks I'd be pwned hard and when I discovered what people were doing I'd totally call cheat. But I would not for auto-aim. Auto-aim is basically a necessity for 2.5D shooters and I've always accepted this. And wall glitching is not like rocket jumping in Quake. Should I not be playing Duke online? Would I be ridiculed and/or excommunicated for not knowing the exploit or for calling out people who use it? This goes both ways. I get that there now exists a subset of people who have come together to exploit together, but they're not the whole community. And if they want to continue exploiting I say stick with the forks.

[TerminX]

Radar, on 19 March 2019 - 07:50 PM, said:

Yeah, I'm so against "fixing" the SOS bugs. Throwing shade at online players is obviously not an uninintended side-effect of this "improvement". Just goes to show none of the EDuke32 developers have roots in the online scene. But whatever, do what you want.

Played on HEAT and was in the top 10 on Case's Ladder, but nice try.

[oasiz]

IMO Cheats or not, it was still a thing that harms content creation and especially sprite decoration and platform creation.
Anyone who has done at least some level of advanced mapping with sprites and SOS surely has ran in to these problems.

It sure does a big change on the original stuff and IM might have been one motivator behind it but it was honestly functioning really badly before and the effects are very undesirable outside of MP. Speedrunners today use megaton, and megaton has it even worse than 1.5.

A lot of idiotic things with sprite clipping limit the potential you can do with build, clipshapes were one way to work around this issue already.
Believe me, I really appreciate SOS teleporting, DM and speedrunning when it comes to duke but once you do more detailed geometry, some times the teleportation can get ridiculous and it can really hold you back, requiring various workarounds such as re-creating sectors to shuffle around the sector numbers and prevent teleportation at certain spots. Not to mention having sprite fences or platforms at all, not helped by the fact that Duke jumps as high as Mario.

I have a feeling that ports like Rednukem will be the better option for those who want pure Duke3D MP but with the benefits of EDuke32.
However by default everything will ultimately work better with correct collision in place without random teleportations or sprite clips.
Right now I would say that absence of teleportation is not really an issue since there is no MP in place for EDuke32.
Intention with any of these fixes is to just make Duke a better game to play.

However I've got little doubts that any issues or corner cases that come up will be checked and possibly worked around and for those that can't get a "fix" and require one.
Probably part of the point with this release is to see what can and what can't be fixed, otherwise all guides online will default to the compatibility flag and nobody will bother reporting or analyzing the bugs, leaving the new code way worse off and not a safe default that would have the best of both worlds in the long run.
Bottom line: Things will be broken for a while as they get fixed.

[Danukem]

Quote

r7437 | terminx | 2019-03-19 10:10:21 -0700 (Tue, 19 Mar 2019) | 1 line

Bump MAXCLIPNUM to 3072 because IM was still hitting it with 2048
------------------------------------------------------------------------

Hmmm, I wonder what that is.

Quote

r7436 | terminx | 2019-03-19 10:10:17 -0700 (Tue, 19 Mar 2019) | 1 line

This should fix most of the remaining issues with projectiles colliding with ledges they shouldn't be hitting

Looks like I can remove my hax for that issue.

Speaking of projectiles: In Duke 3D they have a fixed speed on the xy plane regardless of their vertical angle. So, when you fire a projectile upwards/downwards, it actually makes it move faster. The higher the veritcal angle, the higher the overall speed. If the player could look straight up, the speed would have to be infinite Anyway, this is one of those things that's gotta stay that way in a faithful port, but it sure is dumb when you're making a new Build game. I might want to add a hack to fix this in my own mods, but, is this something the devs have thought about?

[MetHy]

Radar, on 19 March 2019 - 07:50 PM, said:

Yeah, I'm so against "fixing" the SOS bugs. Throwing shade at online players is obviously not an uninintended side-effect of this "improvement". Just goes to show none of the EDuke32 developers have roots in the online scene. But whatever, do what you want.

From my experience, back when it was possible to play EDuke32 online through Dukester etc, the kind of players we were into SoS clipping never played using EDuke32 anyway, despite SoS clipping being possible. They played using xDuke; that's where you'd find the "SoS pros"; while EDuke32 was more casual.

in fact: playing with eduke32 was almost a sure way to avoid the annoying "jetpack/steroid abusing, sos clipping, shotgun/rpg only players that only knew E1L1 and E3L8"

[Doom64hunter]

High Treason, on 19 March 2019 - 07:44 PM, said:

I'm not going to give an opinion either way, not least of which because EDuke32 is already so 'broken' and different compared the the MS-DOS version that it's practically irrelevant at this point.

However, I am going to chime in and say that I don't consider 'cheat' to be the right word in this case, this is an exploit, one is exploiting the way a game feature works in order to gain an advantage, this is no different to using the access switch through the wall in E1L2. It's a fine line and the question is where does one place that line? Is using a jetpack you have left over to skip parts of a level cheating? Is jumping on an enemies head to reach an area you're not meant to be in yet cheating? Does the game need to be modified for their removal, because the developers certainly didn't intend the latter at all or is it simply a case of different people playing the game in different ways?

What about laser tripmines preventing fall damage? Kicking locked doors open? Abusing steroids? Shrinking mini battlelords? Strafe running? Collecting items through walls? Hump-jumping to enter small spaces or pass through badly setup blocking walls (I'll give an opinion on this; poor level design choices)? Placing pipebombs or missiles through certain walls? Just where do you draw the line.

I think the line should be drawn where the utility gained from removing a particular bug/glitch is much greater than the loss in terms of backwards compatibility.
With the collision and SoS warping, there appears to be clear benefits from fixing the problem.

[TerminX]

Forge, on 19 March 2019 - 07:57 PM, said:

for the benefit of people who don't know sarcasm when they see it,
.
this change has nothing to do with Duke3D and everything to do with Ion Maiden.

Sure, but it makes Duke mapping more flexible and will eventually make the game less glitchy overall.

Trooper Dan, on 19 March 2019 - 11:32 PM, said:

Speaking of projectiles: In Duke 3D they have a fixed speed on the xy plane regardless of their vertical angle. So, when you fire a projectile upwards/downwards, it actually makes it move faster. The higher the veritcal angle, the higher the overall speed. If the player could look straight up, the speed would have to be infinite Anyway, this is one of those things that's gotta stay that way in a faithful port, but it sure is dumb when you're making a new Build game. I might want to add a hack to fix this in my own mods, but, is this something the devs have thought about?

It's something we're thinking about but we haven't made a decision yet. It would certainly be a good thing to fix.

MetHy, on 20 March 2019 - 01:00 AM, said:

in fact: playing with eduke32 was almost a sure way to avoid the annoying "jetpack/steroid abusing, sos clipping, shotgun/rpg only players that only knew E1L1 and E3L8"

Heh.

You know it's bad when the exploiters are already whining about the glitches being fixed when we don't even have working multiplayer yet. Recently a multiplayer game I play got a patch that fixed a big problem where people were spamming the lean and crouch keys in a certain way in order to glitch their animations and cause a lot of shots fired at them to miss. The salt from shitty players who relied on such tactics was immense.

Exploiting glitches to gain an advantage in multiplayer is cheating, period. Ironically enough I was actually considering adding a compatibility option before these changes were committed, but I wanted to see what people would say first. Now that I know the biggest complaint is probably going to be that people won't be able to cheat in multiplayer anymore when the client/server implementation is working better, I don't see myself adding such an option.

Doom64hunter, on 20 March 2019 - 01:47 AM, said:

I think the line should be drawn where the utility gained from removing a particular bug/glitch is much greater than the loss in terms of backwards compatibility.
With the collision and SoS warping, there appears to be clear benefits from fixing the problem.

That's how I feel as well.

[Ninety-Six]

My only concern is sprite-based objects like fake ladders and stuff from older maps ceasing to work, but I guess I still have my old r6428 for that...

[TerminX]

Ninety-Six, on 20 March 2019 - 02:10 AM, said:

My only concern is sprite-based objects like fake ladders and stuff from older maps ceasing to work, but I guess I still have my old r6428 for that...

I will be looking over issues with things like this on a case-by-case basis and implementing additional changes or workarounds as appropriate.

[Ninety-Six]

TerminX, on 20 March 2019 - 02:22 AM, said:

I will be looking over issues with things like this on a case-by-case basis and implementing additional changes or workarounds as appropriate.

Fair enough.

[Danukem]

TerminX, on 20 March 2019 - 02:00 AM, said:

It's something we're thinking about but we haven't made a decision yet. It would certainly be a good thing to fix.

I can foresee this breaking a lot of mods that explicitly set zvel on projectiles, using zshoot or just directly manipulating it. It really depends on how it is implemented, though.

[Mark]

I sure wish this new easy going attitude for breaking compatibility and making patches as needed would extend to the suggestion I made before about the band-aid fix for wall sprite flickering in Polymer.

[Danukem]

Mark, on 20 March 2019 - 02:29 AM, said:

I sure wish this new easy going attitude for breaking compatibility and making patches as needed would extend to the suggestion I made before about the band-aid fix for wall sprite flickering in Polymer.

Why bother putting a bandaid on a gunshot wound?

[Mark]

Because the very easy fix has already been done by someone for my own copy of Mapster. But I'm stuck using version 6927 because I don't know how or want to bother to have to learn to compile binarys from source code to keep newer versions patched.

For anyone not familiar with my previous posts about it. If you zoom in all the way in 2D mode, Mapster places wall sprites a tiny fraction of the smallest grid square away from the wall. My band-aid fix was to have Mapster automatically place those new sprites another tiny fraction further away from the wall. Flickering problem gone. For existing sprites just hover the cursor over it in 3D and press O and it pulls the sprite that same small distance away. Flickering gone. I have enjoyed using it since before this I had to manually drag probably a couple thousand sprites over the years. I've been modding with Polymer since 2009-2010.

It was determined at the time of my asking for the fix that a band-aid patch was not proper and would not be implemented. I would have to wait for official Polymer upgrades.

If Polymer ever did get it's upgrade the bandaid could easily be removed. For me I see no harm in the patch. Its only part of Mapster and not the game.I'll have to ask my coding buddy if it would be possible to convert his fix to a script instead of modifying Mapster itself. Then I could run the script on any Mapster version and just shut up about the whole thing.

[oasiz]

This sounds like something for .m32 scripts and source level modifications shouldn't be needed.
I can see some (albeit rare) instances for other renderers where you don't want to use such workarounds automagically.