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

[Mark]

I would think the patch could be made to check that Polymer has been selected before activating? Or add it as a new menu choice when pressing ' and F

[High Treason]

This bug, that exploit, some cheat. This change makes EDuke32 different in ways that are better. Wait, why does nobody use EDuke32 and instead they use crappy Megaton or something? So and so said this, did that, whatever.

Regardless, there are still some actual game breaking things that have never been fixed as far as I know. This is certainly still possible;


In fact I have a whole video coming up on how/why it happens, just for fun.

[Radar]

Warps are not cheats.

Exploits, sure. But not cheats.

Cheats require external modification of the game to give the cheater an advantage over the opponent.

But all players have equal ability to execute warps.

I just think it's funny how we're saying: screw the warps, only people on Meltdown use them. But the decades old sprite ladder exploit, we'll take that on a case-by-case basis. The EDuke32 devs definitely know where their bread is buttered.

TerminX, on 19 March 2019 - 10:42 PM, said:

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

Case's Ladder is still online, so I wonder what your handle was?

[oasiz]

Mark: This is all doable with m32 scripting.
I already have stuff like hotkeys bound to copy slope/shade/picnum/pal/Z, stuff to move selections as a whole, stuff to run "integrations" on props you want to place on maps, stuff like pressing ALT C will autosize a button and place it at correct Z offset from floor for it to be pushable by keyboard players, etc..
I even have same prompts Xvel Yvel Zvel Owner Blend as regular lotag, etc... a lot can be done with just scripts.

Not sure what is the best way but I could probably take a look in to this when I am less busy, hopefully soon.
I'll likely need a 1px nudge hotkey soon for IM so I will craft a duke version of it if I end up doing it.

Scripts are an invaluable tool when mapping, I regret not learning it earlier.
I'll probably at some point "port" my suite of hotkeys to duke as well, currently when mapping without them is like going back to 1.5 build vs. mapster.

[oasiz]

Radar, on 20 March 2019 - 04:33 AM, said:

I just think it's funny how we're saying: screw the warps, only people on Meltdown use them. But the decades old sprite ladder exploit, we'll take that on a case-by-case basis. The EDuke32 devs definitely know where their bread is buttered.

In this case I would say that it's intended behavior by design, the game simply didn't have ladders and abusing an existing quirk was the closes thing you could get.. very different than having them as glitches that the designers weren't even aware about when making the maps, potentially resulting in game breaking teleportation that can harm SP experience. Had the QA caught these bugs, they would have been mitigated or patched out.
I don't understand why you are saying "bread is buttered" as if this was some selfish betrayal when it is something that many designers wished would have been fixed ages ago, me included.
Things might have worked back in KB only days but straferunning, juming and crouching results in very easy teleportation when you least want it.

[HellFire]

oasiz, on 19 March 2019 - 11:08 PM, said:

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.

I understand it all perfectly, i'm a mapper too. I understand the existence of the bug interferes in map making (i dont know if you remember, but i actualyl reported a lot of warping bugs for the IM team on the im testing channel), and i do think its very reasonable to not want to have these bugs around once IM is released, thats only fair. But then what all that have to do with duke, that was already released 20 years ago? Duke should stay as it was on gameplay related matters, which is why i said from the beggining that this should be made as an option, the new behaviour could also be the newdefault in duke, thatwould beok. That option could even be hidden on IM, that would not be a problem too. But just make the changes inside an if/else so we still have the old clipping behaviour, thats all i'm talking about, this should be pretty easy to do, jsut leavbe the old code there and then do the maintainances you have to do on the new code.

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

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.

If i played that game you described, i would agree with that fix in fact. That bug apparently breaks the gameplay, and i guess most players would not enjoy it - warps are a different case and i think i already proved my point on that. I understand that for someone that dont enjoy how dukematch is player currently it can be comparable, and i really understand that, but even then, there's still something that separates the example you made from duke's warps: there wasnt a delay of 20+ years for a patch to come. Now after all this time, be it good or bad, these warps are part of duke.

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

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.

That's how I feel as well.

Nah it's not cheating, you can repeat that as much as you want, but you know that we're not altering the game files in any way so it doesnt make sense to qualify it as cheating. I really think you're not being reasonable with this.
As for we "whinning" even though eduke has no mp, that is to show you that we still care about eduke32, if i personally didnt gave a fuck for eduke32 do you think i would be wasting my time here posting? Why am i posting all this shit here? It's simple, i care about eduke32 and i see this as a big mistake, and this is a valuable opnion in this place to be honest, since most users on this forums dont have roots on dukematches and simply never new about this different perspective.

[Forge]

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

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

I'm not complaining.

I dislike the sos/ror clipping issues in Caribbean.

[MusicallyInspired]

Radar, on 20 March 2019 - 04:33 AM, said:

Warps are not cheats.

Exploits, sure. But not cheats.

Cheats require external modification of the game to give the cheater an advantage over the opponent.

Ah you're right. I forgot about those external modifications of the game like "cheat codes" and "console commands."

[Radar]

oasiz, on 20 March 2019 - 05:10 AM, said:

In this case I would say that it's intended behavior by design, the game simply didn't have ladders and abusing an existing quirk was the closes thing you could get.. very different than having them as glitches that the designers weren't even aware about when making the maps, potentially resulting in game breaking teleportation that can harm SP experience. Had the QA caught these bugs, they would have been mitigated or patched out.
I don't understand why you are saying "bread is buttered" as if this was some selfish betrayal when it is something that many designers wished would have been fixed ages ago, me included.
Things might have worked back in KB only days but straferunning, juming and crouching results in very easy teleportation when you least want it.

By "bread is buttered", I mean that duke4.net has the tendency to see mod exploits as "intended behavior by design", while dukematch exploits are seen as cheating. No, the sprite ladder exploit is just as much a bug as warps are. In a "proper" Build engine, you'd just get sandwiched between the sprites. And if the sprites are clustered very closely on the ladder, you shouldn't even be able to walk through them if their blocking bit is on.