[NightFright]

Map edits are only done to fix rendering issues (mostly eliminating map corruptions for better rendering in Polymost, but mostly Polymer) or obvious gameplay glitches that couldn't be fixed otherwise. There are one or two maps in "The Gate" that profit massively from this if you are not using software renderer since there are improperly closed sectors that would show visual glitches all over the place in certain areas under Polymost/Polymer. Just to name one example.

If that goes beyond your acceptable boundries, I guess this project is something you may want to avoid.

I also wished EDuke32 wouldn't continue to break things while trying to fix others, but that's the nature of a port that is in constant development.

[Radar 100 Watts]

Do you have a written scope for this project? Clearly, compiling an easily accessible historical record of Duke mods is not the goal here. Since we have Rednukem, there's no point in "fixing" mods made for DOS that take no advantage of EDuke32 effects and are most likely broken in many other ways, as seen in the GoD ladder thread.

[Phredreeke]

If breaking compatibility is the price for fixing a major bug then that's probably worthwhile.

What are you doing that breaks compatibility for all maps though?

[Radar 100 Watts]

 Phredreeke, on 13 February 2020 - 07:32 AM, said:

If breaking compatibility is the price for fixing a major bug then that's probably worthwhile.

Except none of the fixes applied are categorically incompatible with the DOS game. They were applied in order to fix EDuke32 issues and have now lost backwards-compatibility.

 Phredreeke, on 13 February 2020 - 07:32 AM, said:

What are you doing that breaks compatibility for all maps though?

Read my posts. I'm trying to launch GoD in Rednukem and it doesn't even start.

[NightFright]

Radar 100 Watts, on 13 February 2020 - 07:25 AM, said:

Do you have a written scope for this project? Clearly, compiling an easily accessible historical record of Duke mods is not the goal here. Since we have Rednukem, there's no point in "fixing" mods made for DOS that take no advantage of EDuke32 effects and are most likely broken in many other ways, as seen in the GoD ladder thread.

Well, it started as a demonstration of the capabilities of the grpinfo feature and grew from there. Hendricks once told me that this collection is not completely irrelevant since there are some things that may not be possible to fix in a mod within EDuke32 and therefore have to be resolved on the mod side. Fixing map corruptions for example is something you need to do by yourself, no port can do that for you. If you are only using the classic renderer and you don't care what a map looks like in Polymost or Polymer, fine, you can safely ignore this project and load the groupfiles just as they come out of the zip archives (provided there are any and it's not a bunch of files).

I'm fine with people doubting the purpose or approach of this project, but it started during a time when we still had one proper Duke3D port available, which was EDuke32. Extending support to other ports that emerged later on has never been within the scope of this project and I doubt it ever will, even though I guess some mods already work or would only require small effort to "convert". There are some for which it would be a lot harder, and since I am basically ending with .grp support in the next version in favor of the .zip format, which saves a considerable amount of filesize, the road only leads further away from Rednukem compatibility. I appreciate the effort put into that port and welcome its existance, but sometimes you just can't run with the hare and hunt with the hounds.

[Phredreeke]

Radar 100 Watts, on 13 February 2020 - 07:53 AM, said:

Read my posts. I'm trying to launch GoD in Rednukem and it doesn't even start.

That question was in response to NightFright saying

NightFright, on 13 February 2020 - 05:26 AM, said:

In the form I am about to release the next version, ALL entries in the compilation will definitely and irrevertably only work with EDuke32, anyway.

NightFright, on 13 February 2020 - 08:44 AM, said:

Extending support to other ports that emerged later on has never been within the scope of this project and I doubt it ever will, even though I guess some mods already work or would only require small effort to "convert". There are some for which it would be a lot harder, and since I am basically ending with .grp support in the next version in favor of the .zip format, which saves a considerable amount of filesize, the road only leads further away from Rednukem compatibility. I appreciate the effort put into that port and welcome its existance, but sometimes you just can't run with the hare and hunt with the hounds.

RedNukem can parse ZIP files, and I'm certain DukeGDX can as well (I've never tested in that specific game but I have loaded several zipped addons in BloodGDX)

[Radar 100 Watts]

 NightFright, on 13 February 2020 - 08:44 AM, said:

I'm fine with people doubting the purpose or approach of this project, but it started during a time when we still had one proper Duke3D port available, which was EDuke32.

Which essentially means the scope of this project is outdated and not up to par with the capabilities of the modern EDuke32 family of source ports.

Considering EDuke32 is always changing, how do you know a previous fix won't break again with a later version of EDuke32? How do you know issues you've fixed won't eventually be fixed EDuke32-side?

 Phredreeke, on 13 February 2020 - 08:48 AM, said:

That question was in response to NightFright saying

Oh ok. Sorry for the misunderstanding.

[LeoD]

NightFright, on 13 February 2020 - 08:44 AM, said:

If you are only using the classic renderer and you don't care what a map looks like in Polymost or Polymer, fine, you can safely ignore this project and load the groupfiles just as they come out of the zip archives (provided there are any and it's not a bunch of files).

Polymer awareness much appreciated!

NightFright, on 13 February 2020 - 08:44 AM, said:

[...] I am basically ending with .grp support in the next version in favor of the .zip format, which saves a considerable amount of filesize

Fine. Usage of GRP format or merely the file extension feels like pointless nostalgia. And I could scrap my 32-bit TotalCMD and its GRP browser plugin.

Radar 100 Watts, on 13 February 2020 - 09:13 AM, said:

Which essentially means the scope of this project is outdated and not up to par with the capabilities of the modern EDuke32 family of source ports.
Considering EDuke32 is always changing, how do you know a previous fix won't break again with a later version of EDuke32? How do you know issues you've fixed won't eventually be fixed EDuke32-side?

(Oops, pressed "+" instead of multiquote, didn't mean to downvote either, though.)
I don't see the other ports as "modern" compared to EDuke32. Quite an achievement by GDX to start support for some more old Build games. But otherwise I'm not convinced yet of any enduring advancement over EDuke32/NBlood concerning their set of games. However, they seem to put some pressure on Voidpoint 's quality management/bug handling, which is fine. And getting some additional attention for Duke in other communities can't be underrated as well.
I'm pretty sure that NightFright's map fixes won't break in other ports (NF, do you check back in DOS Duke?), and are meant comply to unwritten design rules which DOS Duke simply didn't care about. When other ports improve on their engine or rendering codes, they will surely come across many of the same issues and their solutions like EDUke32 did. And therefore they may break the very same set of "corrupted" or otherwise imperfectly (or, sadly, extremely cleverly) designed maps.

[NightFright]

I never took a look at any of the edited maps in DOS Duke. I assume the edits I made are non-invasive, i.e. maps from DOS era addons should still work, just not necessarily if I edited con files, too.

Perfect example for my map edits: Polymer doesn't like at all when redlines of sectors overlap. It doesn't render the floor/wall/ceiling textures of those. So I minimally moved them to not touch each other. That's it. Sure, Polymer should be adjusted to simply render the textures anyway, but something tells me it's not that easy and won't happen for some reason.

I get that regarding addon preservation, EDuke32 may not be a perfect choice due to its frequent code changes. Something more stable is desired, just vanilla Duke with enhanced limits. Back in the days, we didn't have much of a choice. It was either EDuke32 or running the original executables in DOSBox. Now we have several ports to choose from all of a sudden, it can make you picky. I get that. At this time, I wonder why nobody has asked for DukeGDX or Raze support yet.

What I can do is take all the groupfiles and run them in Rednukem, see what works and what doesn't, then compile a list and we try to find out what's going on.

[LeoD]

NightFright, on 13 February 2020 - 12:18 PM, said:

I wonder why nobody has asked for DukeGDX or Raze support yet.

While the grpinfo feature was your reason to start this project, the whole point for me now is your work on reviewing and improving maps and fixing CONs and keep things playable. I don't use grpinfo at all and just copy the part I want to play into my EDuke32 directory or my autoload folder. Maybe the GDX players do the same. Anyway, most likely we're all just waiting for the next release before [re]playing the contents of your pack.

[NightFright]

I guess the actual point of the compilation is convenience, plain and simple. No need to mess with startup parameters, batch files or folders, there's one folder with all the groupfiles, one batch file to launch everything, then you choose what you want and that's it. Polishing maps and code is just a bonus, unless it's done to fix renderer issues or other obvious mistakes.

Well, whatever can be done to make it work with more ports, it would have to wait till I get the next version out of the door. It's no use doing anything based on the groupfiles from the current release since file structure will change drastically.

[Phredreeke]

If it's anything like NBlood and BloodGDX, DukeGDX would actually be less picky when it comes to zipped addons.

[NightFright]

If any Non-EDuke32 port can read maps, sounds etc from subdirs inside of zipfiles and access them if defined in con files, the biggest obstacle should already be gone. Guess the bigger problem may be con coding, but since EDuke32 code is used as a base, I would assume the differences shouldn't be massive at least as far as Rednukem is concerned. Then again, if an addon won't even launch, I wouldn't call that a minor issue...

[Phredreeke]

How many of the addons actually have their own CON code though? I don't think anyone here is expecting WGRealms2 to work on the non-EDuke32 ports.

[NightFright]

I would have to check that. I know conversions like GoD or Starship Troopers are pretty code heavy, however they were not written with EDuke32 in mind. Anyway, some addons have seen fantastic con improvements, but not done by myself. The final boss in The Gate was almost not beatable with the bugged original code. Only with EDuke32 and its capabilities it was possible to create a version that does not break. Yes, we intentionally ruined vanilla compatibility in this case, but it was absolutely worth it.

[Photonic]

Phredreeke, on 13 February 2020 - 02:21 PM, said:

How many of the addons actually have their own CON code though? I don't think anyone here is expecting WGRealms2 to work on the non-EDuke32 ports.

I do expect Raze to run most current eduke32 compatible mods and tcs. Obviously older ones like WGR2 would require a bit of con fixes, the first thing I tried to do with Raze was play through an old project of mine to test compatibility. I can't seem to get through startup to the menu without a commercial GRP loaded.

[Phredreeke]

Photonic, on 13 February 2020 - 03:00 PM, said:

I do expect Raze to run most current eduke32 compatible mods and tcs.

Spoiler

Raze's Duke code is forked from eduke32

[Photonic]

Yeah I took your post out of context, just finished reading the last few pages.
I din't even know what thread I was in... I'm tired. I'll have more excuses in the morning.

[Player Lin]

Phredreeke, on 13 February 2020 - 03:34 PM, said:

Spoiler

Raze's Duke code is forked from eduke32

Spoiler

But not guarantees all large mods for EDuke32 will all working on Raze, as its current states, something may still go wrong.

[NightFright]

The thing is: Is it even worth optimizing stuff for Rednukem? What's the longterm plan? Is it supposed to become part of EDuke32 at some point or vice versa, or is it going to keep doing its own thing, as some kinda more "vanilla-ish" EDuke32 approach?

Anyway, right now my main focus remains on Hendricks getting that user menu done for custom maps. Priorities are important.

[Radar 100 Watts]

If the scope of this project is purely a "convenience" pack, then I understand that vision. I had more of a purist convenient historical archive idea in mind, but I understand if that's not the kind of pack you want to maintain.

Rednukem is the PrBoom+ of Duke. From what I understand, it will remain its own thing.

[NightFright]

Well, once I have everything else in place, I'll take a look at how this is doing with Rednukem. But naturally there will be entries that are never going to work with it, I'm afraid.

[Phredreeke]

As I said, I don't think anyone expects full compatibility, just that the maps that could be compatible without extra effort are

[Radar 100 Watts]

NightFright, on 14 February 2020 - 01:40 PM, said:

Well, once I have everything else in place, I'll take a look at how this is doing with Rednukem. But naturally there will be entries that are never going to work with it, I'm afraid.

You definitely shouldn't modify any mods made after 2003 to work with Rednukem, unless they're also designed to work with DOS 1.5. Otherwise, DOS era mods should certainly retain backwards compatibility imo.

[Blood Vengeance]

I've just discovered that this beautiful compilation works also with Raze if you change some lines in addons.grpinfo