[Fixed] Sprite Ladders
#1 Posted 15 September 2019 - 03:19 PM
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.
#2 Posted 17 September 2019 - 07:35 AM
this breaks so many user maps................
#3 Posted 17 September 2019 - 07:52 AM
#4 Posted 17 September 2019 - 08:03 AM
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:
This post has been edited by Forge: 17 September 2019 - 08:10 AM
#5 Posted 17 September 2019 - 08:30 AM
#6 Posted 17 September 2019 - 08:44 AM
Radar, on 17 September 2019 - 08:30 AM, said:
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.
This post has been edited by Forge: 17 September 2019 - 08:48 AM
#7 Posted 17 September 2019 - 08:52 AM
#8 Posted 17 September 2019 - 09:12 AM
It could have been addressed and "fixed" between 1.3 & 1.4 by 3DRealms, but it wasn't.
#9 Posted 17 September 2019 - 09:43 AM
Radar, on 17 September 2019 - 08:30 AM, said:
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).
This post has been edited by ck3D: 17 September 2019 - 09:52 AM
#10 Posted 17 September 2019 - 10:00 AM
Does anyone have a test case for this behavior?
#11 Posted 17 September 2019 - 11:05 AM
Hendricks266, on 17 September 2019 - 10:00 AM, said:
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)
This post has been edited by Forge: 17 September 2019 - 11:08 AM
#12 Posted 17 September 2019 - 11:06 AM
#13 Posted 17 September 2019 - 11:10 AM
https://www.dropbox....ladder.zip?dl=0
Thanks,
This post has been edited by Paul B: 17 September 2019 - 11:12 AM
#14 Posted 17 September 2019 - 11:18 AM
crossing tror barriers from sprite platforms is a completely different issue
Attached File(s)
-
ladder3.zip (557bytes)
Number of downloads: 167
This post has been edited by Forge: 17 September 2019 - 11:18 AM
#15 Posted 17 September 2019 - 11:47 AM
#16 Posted 17 September 2019 - 08:34 PM
Radar, on 17 September 2019 - 08:52 AM, said:
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.
#17 Posted 18 September 2019 - 07:40 AM
Fixed because I failed to actually read it in its entirety to verify date accuracy; which Hendricks pointed out in the following post.
This post has been edited by Forge: 18 September 2019 - 10:02 AM
#18 Posted 18 September 2019 - 09:17 AM
Forge, on 18 September 2019 - 07:40 AM, said:
How could that be possible? I'm not aware of BUILD.EXE ever being published before v1.3D was released.
#19 Posted 18 September 2019 - 09:31 AM
Hendricks266, on 18 September 2019 - 09:17 AM, said:
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.
This post has been edited by Forge: 18 September 2019 - 12:14 PM
#20 Posted 18 September 2019 - 11:02 PM
#21 Posted 21 December 2019 - 04:39 PM
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
#22 Posted 22 January 2020 - 12:44 PM
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?
#23 Posted 23 January 2020 - 02:04 AM
Hendricks266, on 23 January 2020 - 01:59 AM, said:
Doom64hunter, on 22 January 2020 - 12:44 PM, said:
It is too early to suggest our least favorite solution to any problem, especially when:
Doom64hunter, on 22 January 2020 - 12:44 PM, said:
Surely some additional logic could be added to address more/all concerns.
#24 Posted 23 January 2020 - 08:11 AM
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.
#25 Posted 23 January 2020 - 12:37 PM
Forge, on 23 January 2020 - 08:11 AM, said:
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.
This post has been edited by LeoD: 23 January 2020 - 12:39 PM
#26 Posted 23 January 2020 - 01:22 PM
Forge, on 23 January 2020 - 08:11 AM, said:
Have you tried jumping into a vent in walk mode lately?
Forge, on 23 January 2020 - 08:11 AM, said:
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:
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:
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:
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:
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:
This is an extremely shortsighted and self-serving idea. If you can find when something broke, port the fix forward.
#27 Posted 23 January 2020 - 01:25 PM
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.
#28 Posted 23 January 2020 - 01:38 PM
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.
#29 Posted 23 January 2020 - 01:49 PM
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.
This post has been edited by Mark: 23 January 2020 - 01:55 PM
#30 Posted 23 January 2020 - 02:15 PM
oasiz, on 23 January 2020 - 01:25 PM, said:
Really?