[oasiz]

I can understand, It's a common misconception that it's just a RR port. But the name is exactly "Redneck" + "Nukem", not "NRedneck"
Instead it's a full legit implementation of duke3d (compatible with 1.5 intro demos) and on that codebase it has alternate paths to support the changes done for RR, including new effects.
A lot of the stuff in RR are actually done in CON otherwise. RR is based on Duke after all, they just slapped their own stuff on top of it.

It does not however share the changes/improvements of CON VM from eduke itself, instead it strives to keep accuracy to the DOS original.
You could say it's stripped down but that's not a fair term when in reality it's an accuracy focused "re-port" of duke3d on top of eduke32's build engine side.
As a bonus you get full RR compatibility
(Remember, even eduke is compatible with WW2GI and such despite being a duke port).

In other words, If you want all the GL improvements, etc.. but still want the "true" dos version then go for this. It is basically crispydoom for duke.

And yes, MP is still worked on. I recall you even participated in one of those builds that was floating on discord?
I'm not saying it will be complete in the next few months but it is still ongoing.

ps. Latest build: My link

[Radar]

Yes, I was given a test build, but some of the discussion in #ion-fury made it looks like MP was on the backburner. Something I've noticed in the Doom community is that MP ports like Zandronum and Odamex are based on older stable versions of ZDoom. I imagine the complex advancements in EDuke32 might be hard to support client/server wise. Rednukem may be a more feasible base for such a thing.

[LeoD]

 Hendricks266, on 23 January 2020 - 01:22 PM, said:

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

So you expect us to get the latest synthesis build every day and search for the one bug that has been randomly chosen to get fixed? It's up to you to issue that message in the related thread. Even checking the SVN logs isn't reliable because comments on source code changes do not necessarily make it obvious which issue they actually address. Those who are able and willing to report issues are probably running Duke or Mapster a lot, and they may not be willing to be annoyed by some longstanding unfixed issues. Therefore downloading and using new synthesis builds 'just because' is not attractive.

 Hendricks266, on 23 January 2020 - 01:22 PM, said:

Helixhorned also made changes that caused difficulty getting our engine to work with other Build games.

So what's the connection between design decisions and "customer"-friendliness?.

 Hendricks266, on 23 January 2020 - 01:22 PM, said:

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

Then why not run classic in the first place? Computers have been fast enough for Polymost for many years. Polymost has always been close enough to classic as far as I'm concerned. Further improvements feel rather academic to me.
I want an EDuke32 that does not burn bridges to all too many great user maps and mods.

 Hendricks266, on 23 January 2020 - 01:22 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.

Please re-adjust your sarcasm detector.

 Hendricks266, on 23 January 2020 - 01:22 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.

I'm paying way more attention than you think and I'm completely aware of that. Actually I was still (sarcastically) referring to user-responsiveness and bug-fixing. I might have even filed a bug report or two for PCExhumed and Wangulator, but guess why I did not.

 Hendricks266, on 23 January 2020 - 01:22 PM, said:

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

It's more a player-serving idea. If a map can't be finished or played as intended, who is supposed to know that it's due to a certain change in a certain EDuke32 build? Is there a database that tells which build fits to which map or mod? Only the hard core insiders may know which to choose.
The long-sighted part of that idea is that there won't be an official EDuke32 release with a reasonable backward compatibility any time soon. In fact, there have never been any releases or stable branches one could rely on to a certain degree. And 'Just use the latest synthesis build.' hasn't been a good advice for years now. To me, this whole project has never made the step to actual 'development'. Although I know how schedules and budget constraints may sneak in, it feels like it's still just hacking.

 Hendricks266, on 23 January 2020 - 01:22 PM, said:

Maybe in the future we will turn Rednukem into a pedantic accuracy core for EDuke32.

Now that at least would be good news.

[LeoD]

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

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.

A database with checksums for not-forward-compatible maps and mods might help a lot and could replace a compatibility menu. Plus, it could provide in-memory patches for maps and CONs. Suppressing warnings from 'known' CON files might reduce some irritations, too.

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

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?

Showstoppers...of course they get fixed. Longstanding annoyances are what may drive away valuable contributors from our community.

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

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

But no one would have been forced to actually use the LUA code instead of the GRP's CONs. Otherwise not a single mod could be played. And given his responsiveness (the only example I was referring to), I wouldn't have been too afraid.

[Forge]

 Hendricks266, on 23 January 2020 - 02:04 AM, said:

It is too early to suggest

define 'too early' because this was initially reported roughly five-six months ago

 Hendricks266, on 23 January 2020 - 01:22 PM, said:

It has never been 1:1 accurate. Weapons have been inaccurate since the beginning.

this (and the FREE comments) pretty much say, "we do what we want, eat a dick and go elsewhere"

that's fine. Just be up front about it.
An announcement, "We aren't going to 'fix' this. Ever." would be nice.
That way I can stop wasting my time downloading broken snapshots and replying to snarky and dismissive comments in the forum.


You do fine work. When you feel like it. But your PR department needs attention

[Danukem]

Hendricks266 was saying that it's too early to consider a compatibility checkbox option, and he's right. He didn't say it was too early to fix the behavior. A compatibility checkbox would be a bad move imo. Players would have to know to check or uncheck the box depending on whether the map uses the old sprite ladder behavior. Also, checking or unchecking the box would introduce unwanted behavior in maps if it's not the setting appropriate for the map.

What it comes down to is this:

 Jblade, on 18 September 2019 - 11:02 PM, said:

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.

And this:

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

Spriteladder climbing can be re-enabled by changing the code in player.cpp as follows:
... [code]
This is what the player collision code did previously. Just like autoducking (which incidentally involves the same getzrange call) ... this involves literally a single line of code

Unless the effects of reverting that line of code are catastrophic, it's hard to see how it could be worse than the current state of affairs. If there are problems caused by reverting it, can't they be dealt with later?

[LeoD]

 Forge, on 23 January 2020 - 05:00 PM, said:

You do fine work. When you feel like it. But your PR department needs attention

I'd opt for the quality management department instead.
I had hoped that after the Ion Fury release-dust had settled, someone would go and try to deal with all the issue reports and fix up the Duke Nukem playability. It didn't happen. There seems to be more interest in fiddling with VoidSW.
Over the course of four years there have been about 75 bug tracker entries only. (Not counting mine at this moment.) Less than two per month. Closed or at least otherwise acknowledged: 25+4 ...
Ion Fury is a great achievement and I enjoyed it. But, from my Duke3D player's point view, was it worth it having EDuke32 fucked up for that?
No, it was not.

[Forge]

 Trooper Dan, on 23 January 2020 - 05:35 PM, said:

consider a compatibility checkbox option

there's a reason I intentionally left that part out of the quote.

the squeaky dead horse gets the sauce, but I'm getting tired of beating it.

[Doom64hunter]

Yikes, I didn't want to start a war in this thread.

I don't have anything against the devs, I see that they are working on fixing the issues and one doesn't always have the time and motivation to focus on one problem in particular, especially when the Duke side of the project is entirely hobby work.
One way or the other it is always a good idea to report the problems you find, even if they aren't addressed immediately.

Yeah, and I take the suggestion about compatibility options back, I wasn't sure if the sprite ladder glitch was removed because it was itself seen as an issue, hence why I mentioned it.

In any case I hope that knowing which change in particular caused the regression will help in developing a fix later.

[germ]

Dear all,


I just wanted to say thanks so much ,to everyone: the devs who release the source code, the fair chaps running this site; peeps working on the code now.

But above all,the main thing I still can't get over is DNF2k13:

So much production value!.. I was expecting it to be over at the end of the first level.
I _have_ to give money for this as it doesn't feel right to play it for free. I couldn't figure how.
I would love to support the code itself as well. I understand the way to do so is to purchase Ion Fury or whatever else comes up after?


So DNF brought me here because I think I am close to the end and stuck on that ladder thing, on the barage
I also remember it kind-of working on a different ladder, but I could have been running on an older build around the time the change was made.

Either way I have spotted the change in code required earlier on the forum so I should be good now, so thanks to the guy who replied that as well..

Other than that I'll try to set a permanent multiplayer server and add it to the wiki.



Peace !

[Danukem]

For anyone not following the EDuke32 discussion on Discord, I just wanted to drop in and assure everyone that very good things are happening. Expect an update that fixes a lot of stuff, soon.

[Mark]

FBX models and Polymer optimized. I can hardly wait.

[Tea Monster]

Editable shaders for PBR and outline effects. Node based logic. Ooooh boy!

[Mark]

Keep it realistic like my post.

[Doom64hunter]

Fixed (or reintroduced) as of r8572.

[Tea Monster]

 Mark, on 29 January 2020 - 03:47 AM, said:

Keep it realistic like my post.

OK, I'll limit it to maybe the alpha bug being swatted?

[Forge]

 Hendricks266, on 23 January 2020 - 01:22 PM, said:

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

and run mode since you brought it up

this vent in the secret corridor behind the first floor rooms In E1L1 of DC can't be jumped in normally without using the crouch-jump exploit
still an issue in r 8573