[Ax 34noff]

I think at this point we need some sort of Cross-Port Addons Compilation, and when some addon stops working on one port then fix the port instead of fixing the addon.

[Radar]

IMO addons should have never been modified for any reason.

Just download the mod standalone and use an older EDuke32 that works.

[Phredreeke]

Nah. There are thing you lose out on by running old EDuke32 builds. Controller support, proper Polymost skies, KMT Vsync mode, Fluidsynth support, shade interpolation, the camera not intersecting the floor when shrunk in Polymost, and there are probably other things that I didn't think of. Also, it gets to be a particularly major pain in the ass for Linux and Mac users as those builds aren't readily available.
Things like fixing Shaky Grounds to work in Rednukem is fine too IMO, as it was just a mapping error that EDuke32 ignores but Rednukem doesn't. However I don't agree with neutering addons made with EDuke32 features in mind to run on Rednukem.
Another example of a good fix is when the original map put sector coordinates in such a way as to break rendering in Polymer, such as the floor in the bar in Penthouse Paradise (fixed for the EAC). An unrelated but similar issue can occur with maps that were only tested with the software renderer, as the mapper placed floor aligned textures too low causing them to fail to appear in Polymost and Polymer (I can't think of such a case for Duke, but it happens in Shadow Warrior's Crude Oil)

[Radar]

Why do you need to play a mod with any source port it wasn't made for? If Shaky Grounds wasn't tested with Rednukem, use EDuke32. Simple as.

You shouldn't be editing legacy maps to prevent rendering issues or crashes in renderers. That is a bug in the renderer. If anything, legacy maps are the benchmark.

inb4 "but they'll never fix it!!!"

Then just switch to the renderer that works. I would never play someone's edit of a historical mod (barring a semi official re release). Legacy mods are ridden with design flaws, let alone technical flaws. It is part of their charm.


Also,

>Penthouse Paradise coombrain addon

Nothing of value was lost.

[Nacho]

 Radar, on 26 September 2023 - 11:20 AM, said:

IMO addons should have never been modified for any reason.

Just download the mod standalone and use an older EDuke32 that works.

That's kind of the point I'm making, while that might work, it isn't clear which version you should download for which mod, so unless you are on top of EVERYTHING it makes it rather inaccessible to average fans like me, or completely daunting for someone completely new to Duke, which is an instant turn off.

I guess I just feel eDuke32 is super solid already, so I just selfishly want there to be a bigger focus on streamlining accessibility so that if someone completely new to Duke was asked to sit down and play, they could just do so through eDuke without needing to read up on anything else. That's why I love the idea of this compilation and the add-on system, they seems to be really solid steps in the direction I think things should go to help grow the community.

[Phredreeke]

Yes, and while we're at it, why play Alien World Order or Plug n Pray on EDuke32, when Alien World Order was made for the cursed Randy edition and Total Meltdown cam be played on Duckstation epsxe (a TRUE and HONEST PlayStation emulator)

[Radar]

False equivalence. The principle behind supporting retail games is different than that of modifying past artistic works.

[NightFright]

Fact is, like this we aren't really getting anywhere. As much as continuing product development of the port has to be appreciated, it basically means there'll never be a way to make the entire compilation run with latest builds. At the end of the day, it comes down to what others have been doing in the past: Pick the most recent, yet also most stable build and optimize everything for that. Unfortunately, you're going to lose a lot of recent features like that.

Anyway, at this point it's hard to say if it's a recently introduced issue or one that's mod-related and had been overlooked whenever someone reports a problem. And if you know it used to work fine until some point, you need to find out which build broke it. And by the time you got that addressed, new builds have been released which is usually the equivalent of using the reset button, even if issues are popping up elsewhere instead.

[Phredreeke]

Yes, but that's one build you'll need to run the EAC. As opposed to separate builds for each mod. Whether upgrading the EAC for a given build is worth it will depend on what features are introduced

[NightFright]

Question is how far one would have to go back in the builds to find one that requires as little optimization work as possible.

[Phredreeke]

that's starting at the wrong end IMO. is there any desirable feature (from an end user perspective) introduced after the build you currently target?

[Ninety-Six]

NightFright, on 27 September 2023 - 11:58 AM, said:

Question is how far one would have to go back in the builds to find one that requires as little optimization work as possible.

Bare minimum would be before the clipping changes. That's probably broken the most levels out there.

[Aleks]

Most older levels/mods work perfectly fine in Rednukem (at least I've never encountered one that doesn't), so I'd just keep that one for "legacy" stuff and a recent EDuke build for the new stuff.

[Radar]

Aleks, on 29 September 2023 - 10:44 AM, said:

Most older levels/mods work perfectly fine in Rednukem (at least I've never encountered one that doesn't), so I'd just keep that one for "legacy" stuff and a recent EDuke build for the new stuff.

I've thought of something similar to this. Personally I think the only sort of pack that makes sense is a legacy pack that includes every mod from the DOS era. I'm not really sure why a bunch of relatively new mods like WGR2 or Duke Hard or Metropolitan Mayhem (with random "fixes" applied?) need to get added to a compilation as these are mods that stand on their own perfectly well. Also, the only fixes I would agree with are basic CON syntax corrections if EDuke32 fails to load the mod. Anything beyond that is overreach. And I would not consider every fatal error to be means for editing either, as it may indicate a bug in EDuke32. The recommended port of such a compilation should probably be Rednukem, with EDuke32 being "mostly compatible" but not fully supported.

[Phredreeke]

I get the feeling that Radar is the reincarnated Orson Welles telling Ted Turner (Nightfright) to keep his damn crayons off his films

[Radar]

I actually don't consider myself to be a purist (although colorized black & white films are very bad). There just needs to be a principle behind editing people's work. You guys are painting with too broad of a brush.

[Reaper_Man]

My extremely small 2 cents on the topic, from having helped fix bugs in a few older mods/TCs:

The engine updates and improvements have certainly caused their fair share of problems and incompatibilities that affect legacy content. If a TC has been working for the last 5 / 10 / 20 years and suddenly it stops working with a new engine version, that obviously means something in the engine changed that affects legacy behavior. My understanding of the goals of EDuke is that they want that to not be the case, and so while it does happen, reporting the issues so the behaviors can be reverted is the Correct Solution.

Yes, it's a pain in the ass, and yes one could argue "just don't change things", but again my understanding for the main impetus for major changes to the engine the last several years has been Ion Fury. Now that Aftershock is out, hopefully the engine development team can circle back around and fix things that got broken, as they're not focusing on adding new things or making major changes.

On the other side of the coin... More than a few bugs or breaks or show-stopping issues that I personally have seen or intervened with have been with effects that are exploiting genuinely broken behaviors, and should never have worked in the first place. Yes, the effect in question worked back then, but it shouldn't have worked back then, and the only reason it did is because the engine was fast and loose with error handling or whatever thing it's exploiting. I don't think EDuke is in the wrong to fix these sort of things, even at the cost of breaking some legacy content.

[Ninety-Six]

I think the ideal solution is somewhere in the middle, between fixing bugs and leaving things untouched.

That is, some bugs probably shouldn't be fixed.


I know from a coding perspective that sounds ridiculous, and anyone, even older content, knowingly using bugs should get broken. Problem is, not all bugs are visible except from a coder's perspective only. To anyone playing or even scripting, they're less obvious as bugs and either are seen as by-design, or otherwise don't know any better.


Some bugs are very obvious and definitely need fixing, as an example shrinker blasts passing through enemies. Everyone can agree, that's a bug, and that's generally not something even possibleto be balanced around.

Then you have more subtle things, like the clipping issues. In certain ways Build collision can be legendarily spotty, and fixing those is not something anyone other than diehard purists would argue against, but then it was also changed in other but far less obvious ways. Such that Duke's bounding box before and after the fix are effectively two completely different things, meaning anything built for the older collision (including certain vanilla maps or addon maps) will either not work, or instead make something possible that either wasn't otherwise before, or changes just how easy or difficult it was to pull off.




It really comes down to just how deeply certain aspects of the code were seen as either a bug or as a feature by the community, because sometimes which is which is in the eye of the beholder. Hell, sometimes even the people who wrote the code and realized it was broken, would end up deciding it was better that way. It might not have resulted in clean code, but with the time crunch these 90s engine devs were always under (and honestly still are today), cleaning up code that basically already works is pretty low-priority.

(I'm not saying that all bad code is like that, just that sometimes they are happy accidents.)

[Radar]

ck3D, on 04 October 2023 - 06:43 AM, said:

What is it that was changed in those three maps in the add-on compilation, does anyone know, this is my first time hearing about this. I would appreciate if people read the readme's in general and realized most maps are free to circulate as long as unmodified and that if an edit is in question then they should get in touch with the author prior to actually doing anything themselves. I'm speaking out of principle since I have no doubt the edits were benevolent, and it's possible someone actually might have consulted me eons ago about that and I just forgot (sorry for rambling if that is the case); just for mere efficiency purposes, working with the author directly, they're guaranted appropriate results instead of risking breaking something or contradicting intent.

Just wanted to post MRCK's words here from the October Mod of the Month thread in case anyone missed it. I think this reflects most authors' view on their work being edited.

Link to post.

[NightFright]

The maps in question from this post have basically not been altered at all. The only change I did was to change the lotag of the nukebutton in "AMC Pleaser" (sprite #246, lotag 65535) so the map could be finished - an edit probably necessary only in the context of an episodic presentation of the old "Urban Map Pack". Could probably be undone by now since I have moved away from playing several maps as an episode (now you select each map separately). I can undo this change easily if MRCK insists. "Overtime" and MRCK's map in "The Spiegul Contest" are 100% untouched.

[Radar]

Quote

- LONG101 "Plant Alpha 1": Sprite realignments for #202-204 (numbers 1-3), #553 (security monitor)
and #367 (blue key); fixed water before exit (lotag 1 for sector 241 +
realignment of sprite #433 [SE7])
- LONG102 "Roller": Floor clipping for 3 restroom doors (surface tram) fixed; sprite realignments
for #998-1004, #1010-1013 ("Records" and "Pool" sign letters)
- LONG103 "City": Heavy map corruptions fixed (solving Polymer rendering glitch near YMCA building);
useless sprite #6 (respawn marker) removed; sprites #240-242 panned (prevents
reaching sector B-21 far too early by clipping into the area); realignment of
switch sprite #1195; sprite #1146 (floating graffiti near conveyor belt)
wall-aligned; fixed floor clipping for secret crate door
- LONG104 "Launch": Floor clipping fixes for several doors (check-in and restrooms)
- LONG105 "Delta 7": Floor clipping of big hangar door (near entrance) fixed
- LONG107 "Lunar Base Echo": Floor clipping of secret monitor door fixed
- LONG201 "Mansion": Floor clipping fixed for two mansion swing doors near start; wall alignment
fix for sprite #610 (entrance skull switch)
- LONG202 "Temple 1": Removed unwanted water effect for sectors 129+133; added missing SE7 for
sector 126; realigned sprite #178 (rotating hologram); sprite #331
(underwater grate) panned to fit opening
- LONG203 "Temple 2": Realignment of sprites #1112-1114 (numbers 1-3)
- LONG204 "Boot 1": Fix for sprite #32 (recon car) not moving (changed pal22 to pal0); removed
floor clipping of left entrance door next to red key access panel
- LONG205 "Boot 2": 1) Showstopper bug fixed by changing hitag of sprite #1593 (touchplate)
from 0 to 1, making it one-time activated only. This eliminates the
problem that the door of the "Nukem Field" building might not stay open
after leaving the swimming pool area (due to unintended multiple touchplate
triggerings).
2) Sprites #1583 (red key) and #1781 (shotgun ammo) were repositioned so
that you are unable to grab them outside of the hospital "RX" room (which
would allow you to skip some gameplay).
3) Changed sprite #132 from tile 164 (DIPSWITCH2) to 140 (FRANKENSTINESWITCH).
This way, you are no longer able to end the level very early by flying to
the "Nukem Fields" building and shooting the exit switch from outside.
4) Other fixes: Floor clipping of hospital swing doors eliminated; realignments
of sprites #168 (grate) and #667 ("G" from "Emergency")
- LONG206 "Boot City": Sprite #626 (blue keycard) removed (since there is no blue access panel);
wall #2394 ("Balls of Steel" machine) made two-sided, preventing a bug
allowing you to clip through the wall behind, potentially getting crushed
- LONG207 "Church": Wall #3314 (light) realigned/panned
- LONG208 "Sub": Sprite #842 (underwater valve) realigned; size of health crates near sub reduced
(to avoid them clipping into each other when opening secret crate door);
underwater floor below sub properly aligned
- LONG210 "Spa": Needless sectors 66-73 (columns) deleted; sprite #260 (underwater grate)
panned to fit opening; underwater walls of giant fan made blocking (walls 3276,
3280, 3504-3509, 3511-3529)
- LONG211 "Rounder": Walls #3305 and #3321 (lights) panned to match each other
- LONG301 "Portal": Wall alignment fixes for sprites #279 (3DR logo), #245/252 (handprint switches);
floor clipping fix for sector 417 (swing door in "Chief" room)
- LONG302 "Tiberius": Wall alignment fix for sprite #18 (handprint switch)
- LONG303 "Slider": Wall alignment fixes for sprites #311/321/380/640/917 (skull face switches);
floor alignment fix for sprites #76/89 (FEM6 babes)
- LONG304 "Slider 2": Polymer rendering issue in "Wolf Beer" factory solved (sectors 958/959);
floor clipping fixes for sectors 536, 544 (swing doors)
- LONG306 "Slider 4": Walls of sector 372 made blockable to avoid getting stuck when climbing up
the left side of the rocks in front of the castle entrance
- LONG307 "Slider 5": Wall alignment fix for sprites #37/65/73/183/270/302/352 (valves)
- LONG308 "Slider 6": Polymer rendering issue with two overlapping red wall sectors 67, 431 fixed
(car engine lid, rocks)
- LONG310 "Slider 8": Wall alignment fix for sprite #287 ("Danger" sign)
- LONG311 "Slider 9": Wall alignment fix for sprite #517 (access switch), floor clipping fixes for
sectors 68, 635 (swing doors)
- LONG312 "Slider 10": Floor clipping fixes for sectors 533, 671, 672, 835 (swing doors)
- LONG314 "Final Battle": Floor clipping fixes for sectors 382, 383 (final boss gate swing door)

Replying to this here as there's no reason for this to be in the October Mod of the Month thread. I don't mean to beat a dead horse, but IMO this whole list is completely unnecessary. Most of these issues are not even game breaking, they are just sprite and floor clipping issues? It just seems out of place to go through these old mods hyper fixated on rendering issues when they suffer heavily from poor architecture, balance issues, and bad gameplay to begin with. There is something very oxymoronic about delivering a "polished" experience of Secrets of the Acropolis or The Gate.

[NightFright]

Well, the work has already been done. And coming with this criticism many years after the fact seems a bit too late, frankly spoken. I'm certainly not going to undo all these changes now. I mean yes, most maps in the compilation have been made for the original software renderer, so if you play them like that, you won't have issues. My original agenda was to make everything more compatible towards the new renderers.

Admittedly, these are not the best examples to justify this entire project. However, there are some prominent cases like "The Gate" where in some maps it was forgotten to properly close inner sectors and the whole level visually completely falls apart in Polymost.

At least there's a simple solution for addons with crappy design: You don't play them and shake your head in disbelief when you see what was done to address numerous minor issues which don't improve the gaming experience at all. Neither will I ever judge nor blame anyone for that, it's absolutely fine. I guess a large percentage of the effort that went into this seems unnecessary from a more distant POV. Maybe it's testimony of extreme OSD, who knows? If it's any consolation: Many of the edits I wouldn't do any more today since they are too minor. Luckily, new releases also don't "require" such changes, so I keep my fingers off. I've also stopped adding new entries for similar reasons.

My big hopes rest upon the WIP addon feature of EDuke32 which might turn this entire project pretty much obsolete. Some parts of it might still be worth preserving, so at least it won't have been completely in vain. As it stands now, my motivation to still work on this is rather limited, also due to the fact that port-wise, the situation is getting a bit out of hand.

[Phredreeke]

The WIP addon feature won't help with broken map geometry.

Maybe the compilation should be renamed the Polished Duke Addon Compilation? idk

Years ago nukeykt made a fork of Polymost that emulated the sprite clipping behavior of the classic renderer. It was abandoned for reasons unknown to me

[Radar]

NightFright, on 07 October 2023 - 01:24 AM, said:

Well, the work has already been done. And coming with this criticism many years after the fact seems a bit too late, frankly spoken. I'm certainly not going to undo all these changes now.

That's poor reasoning if you actually believe it was the wrong approach. There's no reason to feel committed to a bad idea just because you already spent a lot of time on it. (Many bad ideas would be around forever if that were the case). Or maybe, you think it was a great idea and you stand by your edits. If so, it doesn't matter how much time you spent on it. Not sure how to read this.

Also, I brought this up years ago.

NightFright, on 07 October 2023 - 01:24 AM, said:

Admittedly, these are not the best examples to justify this entire project. However, there are some prominent cases like "The Gate" where in some maps it was forgotten to properly close inner sectors and the whole level visually completely falls apart in Polymost.

I recently uploaded a full playthrough of the original unpatched version of The Gate and never noticed any visual glitches in polymost. This just goes to show that whatever is being "fixed" is probably unnecessary. The Gate sure falls apart visually, but that ain't polymost's fault.

NightFright, on 07 October 2023 - 01:24 AM, said:

At least there's a simple solution for addons with crappy design: You don't play them and shake your head in disbelief when you see what was done to address numerous minor issues which don't improve the gaming experience at all. Neither will I ever judge nor blame anyone for that, it's absolutely fine. I guess a large percentage of the effort that went into this seems unnecessary from a more distant POV. Maybe it's testimony of extreme OSD, who knows? If it's any consolation: Many of the edits I wouldn't do any more today since they are too minor. Luckily, new releases also don't "require" such changes, so I keep my fingers off. I've also stopped adding new entries for similar reasons.

I like playing old crappy mods for their crappiness. It's why whenever I do consider playing an older mod, I unfortunately do not refer to this pack because I want to play the mod the way it was released in the 90s, albeit with modern EDuke32 QoL improvements. (As I said before, I don't consider myself to be a purist).

NightFright, on 07 October 2023 - 01:24 AM, said:

My big hopes rest upon the WIP addon feature of EDuke32 which might turn this entire project pretty much obsolete. Some parts of it might still be worth preserving, so at least it won't have been completely in vain. As it stands now, my motivation to still work on this is rather limited, also due to the fact that port-wise, the situation is getting a bit out of hand.

But all the addon feature does is determine the packaging format. What are you hoping that solves?

[NightFright]

Well, I've never tried to convince anybody that this was the one and only way to play all the included addons these days. If one thinks they're better off with 100% vanilla, by all means. Go for it. At the end of the day, everyone needs to decide for themselves what matters. Right now the compilation at least provides easy accessibility for those who want the setup process to be less complicated.

[Forge]

using dosbox or an emulator on a lot of these old tc's is a pain in the ass.

while i don't agree with aesthetic fixes; fixes that patch game-breaking bugs is a reasonable compromise.

'oh noes!, you edited somebody's work that's not compatible with a modern port'
'oh noes! then don't play it, go fire up your dosbox version and enjoy it the way you want to'

[Danukem]

I've never used the compilation myself but overall it sounds like a noble and ambitious project that has been largely successful but with a bit of mission creep.

[Radar]

Forge, on 09 October 2023 - 12:54 PM, said:

using dosbox or an emulator on a lot of these old tc's is a pain in the ass.

while i don't agree with aesthetic fixes; fixes that patch game-breaking bugs is a reasonable compromise.

'oh noes!, you edited somebody's work that's not compatible with a modern port'
'oh noes! then don't play it, go fire up your dosbox version and enjoy it the way you want to'

Rednukem.

[Phredreeke]

Not good enough. You gotta unload the EAC off the internet then write a personal handwritten apology letter to every mapper whose map you modified. And then you have to send Radar a picture of your balls.

[Forge]

Radar, on 09 October 2023 - 01:04 PM, said:

Rednukem.

rednukem - circa 2018
eduke32 addon compilation - circa 2014