[Paul B]

Invisible vertical floor aligned sprites for use with ladders has been broken for along time. Can someone when they have a chance revisit the code and amend the code from a previous build to enable sprite ladders to function as they use to. It would be much appreciated, it use to work so well before.

The problem seems to start at 20190723-7831.

This version works: 20190721-7817. (Prior builds to this work better but its not a show stopper)

Also the ladders that I am testing happen to go through a TROR extended sector. Perhaps this will help isolate the problem.

[Forge]

still does not work with r8122

this breaks so many user maps................

[Radar]

I know this isn't going to be a popular opinion, but IMO if the warps are gone, this trick should also be gone. It is clearly an exploit. The fixed behavior should block the player from being able to clip through sandwiched sprites that have their blocking bit on.

[Forge]

it only works on 1-sided blocking floor aligned sprites - it you don't want your sandwiched sprites to behave like a ladder, then don't make them 1-sided.
It's also an assumption that it's an exploit and not intended behavior simply because it wasn't taken advantage of in the original 3 episodes, afaik

The issue is people have been making maps that use this "exploit" since 1996.
Same with blocking floor aligned sprites behavior underwater

also:

TerminX, on 21 March 2019 - 12:56 PM, said:

Yeah, the changes that fix the player clipping through walls and into other sectors are actually completely different from the changes that could potentially prevent a sprite ladder constructed in a certain way from working. The former was an engine bug and the latter was just poor design in Duke3D-specific code.

[Radar]

It's clearly an exploit because it literally makes no sense for blocking sprites to push you up, but never push you down. If the game behaved properly, you would just get sandwhiched between the sprites.

[Forge]

Radar, on 17 September 2019 - 08:30 AM, said:

It's clearly an exploit because it literally makes no sense for blocking sprites to push you up, but never push you down. If the game behaved properly, you would just get sandwhiched between the sprites.

the player isn't being "pushed" up or accelerated. Sprite platforms are intentional. Walking up to a sprite at a certain height and stepping up onto it is intentional behavior. 1-sided properties of a sprite is an intentional feature.

have you tried making a reverse ladder? And how would you tell the difference between going down and falling?

you're entitled to your opinion on the matter.

[Radar]

All I'm saying is that a bug is still a bug, regardless if Pascal used it or the |Iodanzig| clan used it.

[Forge]

And I say it is not a bug. It is basically a sprite based staircase with the steps stacked.
It could have been addressed and "fixed" between 1.3 & 1.4 by 3DRealms, but it wasn't.

[ck3D]

Radar, on 17 September 2019 - 08:30 AM, said:

It's clearly an exploit because it literally makes no sense for blocking sprites to push you up, but never push you down. If the game behaved properly, you would just get sandwhiched between the sprites.

But why would you if said upper sprites were deliberately programmed to be one-sided? That would only make you the butter on a toast of sorts, not a sandwich. It's not like you're clipping through anything you shouldn't be clipping through since the side of the sprites you seemingly go though is intended not to exist.

That being said, personally I always thought that trick was a bit wonky and unreliable so I never really liked using it. I don't think there's anything to 'fix' about it per se though, it's just the game working the way it's supposed to work, and some mappers taking advantage of the inherent possibilities, the way I see it. Whereas clipping through solid walls and up tall ledges was never meant to be a part of the game and is just bad programming on the developers' end (not that I have any stance on that issue, though - I no longer play the game nearly as enough to have one, don't play online, and can also see both sides). The comparison would only stand if Build had a built-in feature to allow the design of (solid, not masked) walls and ledges that can either be clipped through or not as intended by the map's author. The point you're making isn't unreasonable, but I'm not sure I'm convinced (for what that's worth).

[Hendricks266]

I don't see why floor-aligned sprites can't be considered in the autostepping code.

Does anyone have a test case for this behavior?

[Forge]

Hendricks266, on 17 September 2019 - 10:00 AM, said:

I don't see why floor-aligned sprites can't be considered in the autostepping code.

Does anyone have a test case for this behavior?

What do you mean by test case?

old behavior - the player would automatically step up onto a 1-sided blocking floor aligned sprite that was between the heights of 0 to 9728. (afterwards it's over the player's "head")
-If the player ducks under a floor aligned 1-sided sprite that is 9728 or lower & then stands up, they will step up onto it.

new behavior -the player is blocked by a floor aligned 1-sided sprite that is at a height of 4864 to 9728. (as if they walked into a wall-aligned sprite)
-If the player ducks under a floor aligned 1-sided sprite that is 4864 to 9728 & then stands up, they will not step up onto it, they will maintain having their feet on floor and the rest of their body clipping through the middle of the sprite. (so it appears as if the player is 'wading' through the sprite)

[Hendricks266]

I mean a map file where we can see the behavior working or not working.

[Paul B]

Please see below a sample map with the problem of it not working. It works just fine with older builds prior to: 20190721-7817.

https://www.dropbox....ladder.zip?dl=0


Thanks,

[Forge]

here's a normal ladder

crossing tror barriers from sprite platforms is a completely different issue

Attached File(s)

•  ladder3.zip (557bytes)
  Number of downloads: 165

[Forge]

Don't even need a whole ladder, just a one-sided sprite at 9728 elevation units from the floor, then repeat the behavior I posted earlier between DOS & snapshots after 7831(?)

[Jimmy]

Radar, on 17 September 2019 - 08:52 AM, said:

All I'm saying is that a bug is still a bug, regardless if Pascal used it or the |Iodanzig| clan used it.

It's not a bug. Techopedia defines a bug as "a problem causing a program to crash or produce invalid output. The problem is caused by insufficient or erroneous logic. A bug can be an error, mistake, defect or fault, which may cause failure or deviation from expected results." The ladder trick is not a failure nor is it a deviation. It works the same every time because it's working exactly as it was intended to. The difference is that it either never occurred to 3DR to use this functionality to build ladders or they scrapped the usage of it.

[Forge]

Duke3d shareware was released Jan 1996. Patola had a tutorial out that included how to build a sprite ladder in March 1996 (or early 97), before the retail version of the game hit the market. This isn't some obscure behavior that barely works, it's intentional & left that way intentionally.

Fixed because I failed to actually read it in its entirety to verify date accuracy; which Hendricks pointed out in the following post.

[Hendricks266]

Forge, on 18 September 2019 - 07:40 AM, said:

March 1996, before the retail version of the game hit the market

How could that be possible? I'm not aware of BUILD.EXE ever being published before v1.3D was released.

[Forge]

Hendricks266, on 18 September 2019 - 09:17 AM, said:

How could that be possible? I'm not aware of BUILD.EXE ever being published before v1.3D was released.

I only relayed the date on the files in the archive, without actually reading it. So I was lazy about how deep I looked.

After looking into the intro text, it is noted that it was written after the 1.3 commercial release. The date of the files was not a good choice to use when referencing it in such an offhanded manner, textually it references using Brett Gmoser's faq from june/july 1996, so it was probably released shortly after that.


Doesn't change that an original well known & documented feature has been altered which now renders numerous user-made maps, mods, & TCs unplayable with the current version of the port.

[Jblade]

a lot of usermaps used ladder sprites, this definitely should be fixed. I can understand fixing the odd esoteric bug that affects 1 or 2 levels but a significant amount of maps relied on the sprite ladder trick.

[ViDi]

r8454
Problems with ladders. Can't climb.
But if I crouch or dnclip towards the ladder I can climb that ladder3.
In Dawn in Arctic I can climb only through dnclipping, crouching doesn't help.

User map

[Doom64hunter]

Spriteladder climbing can be re-enabled by changing the code in player.cpp as follows:

Index: source/duke3d/src/player.cpp
===================================================================
--- source/duke3d/src/player.cpp        (revision 8534)
+++ source/duke3d/src/player.cpp        (working copy)
@@ -4692,7 +4692,7 @@
     }
 
     pPlayer->pos.z += getZRangeOffset;
-    getzrange(&pPlayer->pos, pPlayer->cursectnum, &ceilZ, &highZhit, &floorZ, &lowZhit, pPlayer->clipdist - GETZRANGECLIPDISTOFFSET, CLIPMASK0);
+    getzrange(&pPlayer->pos, pPlayer->cursectnum, &ceilZ, &highZhit, &floorZ, &lowZhit, pPlayer->clipdist - 1, CLIPMASK0);
     pPlayer->pos.z -= getZRangeOffset;
 
     pPlayer->spritebridge = 0;

This is what the player collision code did previously. Just like autoducking (which incidentally involves the same getzrange call), I'm not sure why exactly this change was made.
However, considering that this involves literally a single line of code, I would suggest that a compatibility option might not be totally out of the question, no?

[Hendricks266]

Hendricks266, on 23 January 2020 - 01:59 AM, said:

git blame says this was introduced in r7428.

Doom64hunter, on 22 January 2020 - 12:44 PM, said:

However, considering that this involves literally a single line of code, I would suggest that a compatibility option might not be totally out of the question, no?

It is too early to suggest our least favorite solution to any problem, especially when:

Doom64hunter, on 22 January 2020 - 12:44 PM, said:

I'm not sure why exactly this change was made.

Surely some additional logic could be added to address more/all concerns.

[Forge]

translation: we're ignoring it

remember when Tx & Evan actually listened and tried to keep the eDUKE port compatible with the original game it's named after?
Pepperidge Farm remembers.

[LeoD]

Forge, on 23 January 2020 - 08:11 AM, said:

remember when Tx & Evan actually listened and tried to keep the eDUKE port compatible with the original game it's named after?

I guess that back in the days Helixhorned was leading by example on this behalf. Maybe this is what just happens when open source projects turn from hobby/addiction to commercial. I recommend renaming it into VoidDuke.
The NBlood project has quite a number of active contributors currently. I hope they'll help us out one day...
Currently it might be best to figure out an EDuke32 build with no known bugs at the time of its release and try to backport later improvements like CON enhancements. As far as Polymer is concerned that could mean to go back as far as r4376 IIRC.

[Hendricks266]

Forge, on 23 January 2020 - 08:11 AM, said:

translation: we're ignoring it

Have you tried jumping into a vent in walk mode lately?

Forge, on 23 January 2020 - 08:11 AM, said:

remember when Tx & Evan actually listened and tried to keep the eDUKE port compatible with the original game it's named after?
Pepperidge Farm remembers.

It has never been 1:1 accurate. Weapons have been inaccurate since the beginning. The way ifrnd works was changed early on.

If you want perfect accuracy, warts and all, play Rednukem. EDuke32 fixes broken systems without editorializing or changing the spirit of the gameplay. That was not my decision but I always saw the pragmatism in it. Now that we have Rednukem I am 100% on board with it. Maybe in the future we will turn Rednukem into a pedantic accuracy core for EDuke32.

LeoD, on 23 January 2020 - 12:37 PM, said:

I guess that back in the days Helixhorned was leading by example on this behalf.

Helixhorned also made changes that caused difficulty getting our engine to work with other Build games. The editor is a BIG mess because tons of functionality that should be in the engine was written in or moved into the Duke game side. SW's editor currently doesn't even have a tile selector.

LeoD, on 23 January 2020 - 12:37 PM, said:

Maybe this is what just happens when open source projects turn from hobby/addiction to commercial.

When this happens you get a Polymost that is pretty much a perfect hardware-accelerated version of Classic.

LeoD, on 23 January 2020 - 12:37 PM, said:

I recommend renaming it into VoidDuke.

What could possibly be gained by throwing away our existing name recognition while keeping Duke in the title? If you had said EFury32 I could at least see some semblance of a point here.

LeoD, on 23 January 2020 - 12:37 PM, said:

The NBlood project has quite a number of active contributors currently. I hope they'll help us out one day...

If you were paying attention you would know that the entire Duke, SW, KenBuild, Blood, RR, Exhumed port family is in development under one umbrella. Patches flow in both directions between the EDuke32 repository and the NBlood repository, and shared code is kept closely in sync. Count how many "Patch from Nuke.YKT" and "Backported from NBlood/Rednukem/PCExhumed" messages you see in EDuke32's development history.

LeoD, on 23 January 2020 - 12:37 PM, said:

Currently it might be best to figure out an EDuke32 build with no known bugs at the time of its release and try to backport later improvements like CON enhancements. As far as Polymer is concerned that could mean to go back as far as r4376 IIRC.

This is an extremely shortsighted and self-serving idea. If you can find when something broke, port the fix forward.

[oasiz]

The guys you're mentioning already contribute to eduke32 codebase quite a bit.
If you want eduke32 engine and closest to DOS "game" then I suggest checking out rednukem.
There is constant cooperation and shared code/patches between the teams for pce/n-ports/eduke

I would argue that there never was a time where eduke itself was feature complete, every revision has it's share of bugs/changes that gets fixed. It's a constant work in progress.
If you look at current state, the engine has never been smoother/better, not to mention that MP work is still being carried out. There is yet another commit incoming that will improve input handling a lot, it's extremely smooth compared to what it used to be.
But let's face it, eduke has never been 100% comparable to DOS duke in terms of accuracy, let's get that out of the way.

And now to the elephant...
I think while complaints about the collision are valid, I think those kind of statements are being a bit hyperbolic here.
When this discussion about collision was brought up internally, it was actually something that was in the plans for a long time (even before Fury) and wasn't even explicitly requested by the devteam.
Commercial motivator? Of course there is that too, would be stupid to deny that. However you need to remember that it has also allowed more people to contribute to the codebase, it's quite active right now compared to 2 years ago. Focus has been on fury for a reason during the last few years and Duke has also been able to benefit from things like better gamepad support as well.

But when it comes to the collision (like in this case), it actually broke fury even more than it did for duke
There were months where you could even barely work around without getting randomly killed/stuck, ladders did not work at all, etc..
Not knowing the full story it's easy to say that this was done with Fury only in mind but it wasn't. I would say that Fury had much more issues than Duke did, it took months of workarounds from mappers/scripts to make things work again. Things were actually quite broken until the last weeks if I'm being honest.

Bottom line: This is not a conspiracy and abandoning of Duke, the guys work on these things all the time. Right now priorities have been on supporting Fury (ps. cut the guys some slack, they've been maintaining this project for well over a decade, for free). Irony of these is that the clipping changes were actually 100% tested against duke when developed so I'm just amused when people think it was only done with fury in mind
They want to fix things but also don't want an options menu with 20+ compatibility flag settings that nobody will know about what works the best for any given map.
Aside from some bugs like being able to go through gaps and the ladders, are there REALLY any major showstoppers left for it that justify calling out the devs that they don't even care after addressing pretty much every other concern?

If you're going to add Helix as an example, his plans were to rewrite entire game CON in LUA instead (and replace it). I would be willing to bet that this alone would have resulted quite a bit of breakage. TROR was never truly usable in polymost and that has recently been fixed also. Not to mean bad, but each one have their own interests on what to tackle ultimately.

[Danukem]

I'm committed to using the most recent EDuke32 revisions possible for my projects, and I'm not throwing any shade at the devs. A lot of good changes have been implemented in the last few years, especially with polymost which is tremendously better than it was before.

My only serious gripe is that some clipping revisions that clearly broke longstanding desirable behavior (such as ladder climbing which is used in many user maps) have just been left in and it doesn't seem like fixing those breakages has been a priority. I would have thought that the introduction of a breakage would be cause for immediately reverting the revision that caused it, going back to the drawing board and then reintroducing the revision when it works properly.

[Mark]

My post is not to point fingers or trash the devs. Just my observation that others might share.

There was a 3 month period starting sometime last fall, I don't remember which months without having to search the threads, where bugs were being reported fast and furious compared to usual. They were not all neatly grouped together in one place and loaded with concise reports,logs, examples, etc...which is another thing we need to be more aware of. My perception at the time was a few were fixed in a timely fashion, some were acknowledged but no fixes, and some were never addressed at all ( ignored ) in the threads. It wasn't encouraging to see. I'm guessing I wasn't the only one a bit frustrated.

But this was expected because IIRC it was 266 that posted ( paraphrasing ) that things are likely to break in the near future as we move forward with I.F. 100% backward compatibility was going to take a hit. I'm willing to cut some slack for the devs who take care of so much behind the scenes. But I'll admit it does bother me when some bugs/issues go unheeded or a less than satisfactory response was given. Some of that comes from the fact that the rest of us aren't coders and when we see a response that changing one line might fix an issue or that a revision has been identified as the source of an issue and it isn't followed up on for some reason.

Dan posted while I was typing. I agree with his points.

My bottom line is to thank the guys for what they have done over the years. Its allowed me to spend 100s and 100s of hours at home modding instead of getting into trouble and spending a small fortune at the bars.

[Radar]

Lately I've been warming up to the new direction that EDuke32 is taking, the only thing I would mention is that I do believe accuracy to the original game is worth preserving. I don't expect that from EDuke32, but it would be nice if there was a stable alternative that did such a thing. I know that Rednukem was mentioned, but I don't know how "accurate" it is, as opposed to just being a stripped-down version of EDuke32 for the purpose of supporting RR.

oasiz, on 23 January 2020 - 01:25 PM, said:

not to mention that MP work is still being carried out.

Really?