[Hendricks266]

I never thought I'd see the day where TROR works better in Polymost than Classic.

[DisgustedGrunt]

Zaxtor, on 08 April 2019 - 12:08 AM, said:

What error youtube gives you?

it was stuck at 0 upload, already fixed itself.



the console, menu background and screen flashes from picking up items and getting damaged randomly turn white. i can force it to happen by setting r_showfps to 1 and then to 0.
It ONLY affects polymost, switching to software or polymer "fixes" it but turning back to polymost turns it white again.
it's a clear install.

[Zaxtor]

I saw that glitch mentioned before
Menu get white,
Console display get white
Etc

White flash from being hurt and items grabbing.
Weird

[oasiz]

Phredreeke, on 08 April 2019 - 07:35 AM, said:

I guess what happens in classic is the renderer determines the sector should be visible in a given column, and ends up drawing it in the entire column, while Polymost determines visibility on a per pixel basis?

Very strong possibility

[Darkus]

I saw this in the changelog:

------------------------------------------------------------------------
r7536 | hendricks266 | 2019-04-07 23:28:43 -0700 (Sun, 07 Apr 2019) | 1 line

SW: Fix -Wlogical-op
------------------------------------------------------------------------
r7535 | hendricks266 | 2019-04-07 23:28:39 -0700 (Sun, 07 Apr 2019) | 1 line

SW: Fix -Wsizeof-pointer-memaccess
------------------------------------------------------------------------
r7534 | hendricks266 | 2019-04-07 23:28:31 -0700 (Sun, 07 Apr 2019) | 1 line

SW: Fix -Wformat-overflow and -Wstringop-overflow

Is this related to Shadow Warrior?

[LeoD]

Darkus, on 09 April 2019 - 11:16 AM, said:

I saw this in the changelog: [...]
Is this related to Shadow Warrior?

Yes. Changes in the sw source sub-tree.

[DisgustedGrunt]

in r7551 the crane that lifts you at the start in derelict gets stuck halfway through, never reaches the player

[Darkus]

Tested r7551

Now TROR works like a dream. Also working mirrors in polymost with TRORed maps.

However, another problem appeared:
Sometimes I get stuck 'between' sectors. It's not like bumping wall, it's like it won't let me crossing a line to another sector. Wriggling up/down or left/right helps to unblock.

Quote

in r7551 the crane that lifts you at the start in derelict gets stuck halfway through, never reaches the player

I think it's the same problem. I saw some case of projectiles that stopped moving.

[TerminX]

Where can the problem where you get stuck between sectors be reproduced?

[DisgustedGrunt]

Lazy Dog, on 08 April 2019 - 09:44 AM, said:

it was stuck at 0 upload, already fixed itself.



the console, menu background and screen flashes from picking up items and getting damaged randomly turn white. i can force it to happen by setting r_showfps to 1 and then to 0.
It ONLY affects polymost, switching to software or polymer "fixes" it but turning back to polymost turns it white again.
it's a clear install.

fixed in r7552. Thanks!

[Darkus]

TerminX, on 09 April 2019 - 02:17 PM, said:

Where can the problem where you get stuck between sectors be reproduced?

Fixed in r7574 apparently. This happened in any map, but it was very random.

However, the SOS warp bug I mentioned in E4L9 is back.

Also in the same map, entering the ship through the windows (without jumping, just keep walking) lead to this:



Very similar to the 'stuck between sectors' I said above, but moving back, crouching or jump unblock.

[DisgustedGrunt]

in r7574 touching this door in e4l1 kills you

[Radar]

What is the cause of the large influx of physics related bugs lately? Is it due to the warp fixes, tror improvements, or both?

[Micky C]

It’s probably all due to the collision detection changes.

Given that the transition hasn’t been straightforward, perhaps it’d be best to have an option for players to choose classic collision after all? While I have faith that the devs will eventually have these issues ironed out, there’s no guarantee that really obscure bugs won’t remain, if the maps and mods containing these bugs haven’t been played recently, and then had the bugs reported.

[Zaxtor]

Reminds me of Dragon's lair.
you can't even touch a door

[Radar]

Micky C, on 10 April 2019 - 02:08 PM, said:

It’s probably all due to the collision detection changes.

Given that the transition hasn’t been straightforward, perhaps it’d be best to have an option for players to choose classic collision after all? While I have faith that the devs will eventually have these issues ironed out, there’s no guarantee that really obscure bugs won’t remain, if the maps and mods containing these bugs haven’t been played recently, and then had the bugs reported.

And even after all the kinks are ironed out, there's a chance it will just open the door to different types of exploits. A lot of folks forget that many of the warps in the final game were actually side effects after trying to fix the 1.3D style warps.

[Zaxtor]

No Eduke32 "core C and or C++ Programming language" expert but
if is possible to extract all the recent stable stuff and put it on an earlier stable Eduke32? before those white flash etc occured?

maybe could fix stuff without sacrificing the hard work.
I dunno no Programming language expert.

[Hendricks266]

Radar, on 10 April 2019 - 02:25 PM, said:

And even after all the kinks are ironed out, there's a chance it will just open the door to different types of exploits.

Negative. 1.5 fought hacks with hacks and we're actually fixing things.

[Radar]

Hendricks266, on 10 April 2019 - 02:52 PM, said:

Negative. 1.5 fought hacks with hacks and we're actually fixing things.

And I can tell EDuke32 devs are trying to hit the root causes of these issues. All I'm saying is that everything has bugs. You never know what exploits people will figure out.

For example, there's one "warp" I am still able to do in Holly with the latest build. But I think it's better if I don't specify what it is (but I'll tell you it if you really want to know). Reason being that if the scope of this project is to truly rework hit detection, as opposed to just patching up TEN Network 90s-style exploits, it should eventually be fixed anyway as a side effect.

[Danukem]

Radar, on 11 April 2019 - 12:43 PM, said:

Reason being that if the scope of this project is to truly rework hit detection, as opposed to just patching up TEN Network 90s-style exploits, it should eventually be fixed anyway as a side effect.

That's bad reasoning. It never hurts to have more data points; especially when there's a relatively small number to begin with. Also, you shouldn't assume that the cause of the glitch you discovered is exactly the same as the cause of other glitches.

[Radar]

IMO They should already know where all the warps are before even embarking on this kind of project. I think that just kind of makes sense. Though they probably haven't finished fixing them yet so maybe I'm getting ahead of myself. Btw, I found a second one.

[Danukem]

Radar, on 11 April 2019 - 01:40 PM, said:

IMO They should already know where all the warps are before even embarking on this kind of project. I think that just kind of makes sense.

No it doesn't.

[oasiz]

The motivator with this project was never to "fix" multiplayer warps, not sure where you got that idea ?

Instead the objective is to fix the godawful collision code that is fundamentally broken in Duke due to various hacks tacked on top. Warps getting "fixed" is simply a side effect of this overhaul.

Sure, it might work on the surface but having done speedrunning, content creation and dukematch, I can safely say that it's a miracle that the stock game works as well as it does. It's extremely easy to do some of the warps/bugs even by accident, many resulting in the player getting killed or teleporting to areas that lock you out. These collision bugs are very undesirable outside of MP where people have learned to abuse those over the years. Fixing these to make Duke3D ultimatlely a better game is what the goal is. There were possible talks about intentionally re-introducing these bugs as workarounds but it's currently on hold. Current breakage is a result of many programming mistakes existing in d3d so intentionally "breaking" things again might end up causing more/different issues than you'd want. Not as straightforward as you think.
Keep in mind, this is an overhaul, not just a few odd changes. Also the reason why there is quite a bit breakage during this phase.

Duke is still better than TekWar, where too fast movement can clip you inside stairs/stuff and cause the game to crash due to player being on sector -1 -- What a joy that was to speedrun

[Radar]

Thanks for the informative post. If this is truly the scope of improving hit detection in EDuke32, then I don't have a problem with it. What irked me before was the hostility towards online players. But if you're saying multiplayer was never a motivating factor for these fixes, then I'll take your word for it.

[oasiz]

FYI, Intentions are more clear from TX's first post upon release:
"Yes, these changes will likely break maps and random CON mods related to jumping, etc. Let us all work together toward a brave new world in which you cannot pass through solid walls and metal grates in sewers do not cause you to explode."

In other words, referring to what I said on my previous post.

Things did escalate unnecessarily quite a bit as MP was brought in and I would say that it felt a bit biased to either direction: one party wanted to improve/overhaul things legitimately and one party was concerned about keeping a specific subset intact.
This later descended in to fruitless questioning about it's use cases when the real problem here was the lack of a silver bullet solution that would make both practical.
I'm sure you can understand that something has to be done in order to get the ball rolling. I would argue here that the approach of building a solid foundation first is the better one. One could say that it might be a bit annoying with the timing as loads of cool improvements made in at the same time and you're locked out of those unless you opt-in to "beta test" sort of.
This overhaul is still way overdue and now just happened to be the time. This improvement can and will do a lot to make Duke ultimately a better game to mod and play.

You also have the other end of the spectrum with Megaton, which has even worse hit detection for some reason, more clips and more random deaths. Not a good gaming experience.

EDIT: Also if you find any spots, I think reporting them would be greatly appreciated. Like Dan said, these might be wholly unrelated and might be new issues that can cause unexpected issues elsewhere.

[Radar]

Fyi from my point of view, TerminX's post was exactly what confused me, since if maps and mods are the bread and butter of EDuke32, it seemed so odd to me that he would openly admit to implementing changes that break maps and mods. But you clarified it all very nicely and I appreciate it.

2 warps that still work (both in Holly):

1. You can still throw pipe bombs into the projector room from the hallway underneath it. (Even though the player isn't teleporting, online folks still call this one a warp)

2. From the ceiling in the theater room, you can still warp into the hallway that exits the theater.

[oasiz]

Thanks!

I think pipebombs are fundamentally fucked in many cases, in original duke you could get them through any child sector by just giving them a light tap
This gets you inside various places like the booth in E1L1 (just throw it through the wallcrack) and duke burger end area.

Also I think his post was partially sarcastic while also pointing out that "things will break" since it's not like a lot of huge things happened in duke for years and people have relied / got used to on "crazy" for years
But as you've seen, things also are getting fixed and it will very likely require quite a bit of time in the long run.

(2) This where the doors are or the two hallways at the projector SOS ?

[Radar]

(2) the doors, not the two hallways.

[brullov]

Hey, I have got a little problem here. TROR blocks player if he jumps on sprite. How can I resolve it?



EDIT: Works fine in older builds.

[oasiz]

How about ONE UNIT of unfucked polymost transparency ?

Thanks pogokeen for fixing this longstanding bug, looks really nice so far!

(Now / Before)

TL;DR -- Transparent sprites would eat in to each other before, killing any effects you might have wanted to do with overlaps or such.

Attached thumbnail(s)

• 
•