[NightFright]

TheDragonLiner, on 09 September 2019 - 11:29 PM, said:

Especially since the GRPs in the compilation are kinda protected, they're no longer recognized if modified ...

That's not a protection. Altered GRPs have different sizes/checksums, therefore the grpinfo file would need to be updated. If it's not, it's like the modified GRPs simply don't exist.

[Phredreeke]

Messing with the GRP files is a bad idea anyway. AFAIK when updating a GRP file the entire file has to be rewritten. I guess an option would be creating a new file with the same name but different extension to hold savefiles.

[RunningDuke]

Personally I would prefer if the saves get separated by the grp files you are using. So that they don't show up if you are playing one addon and have saves from other addon.

Example: If you are playing Aqua Series and ADG Episode, if you have saves from ADG episode and then you go to play Aqua series, you shouldn't be able to see the saves from the ADG episode. Either that or have them displayed but they can't be loaded, instead you will get a warning message saying that the save was made with a different mod. Similar to the ZDoom based ports for Doom, if the save was made with a different mod, it will be differently colored and can't be loaded unless you load the correct mods first. I know EDuke32 has a similar case with saves from a different version but it should also prevent loading saves made with different mods.

[Forge]

sorry NightFright.

totally mistaken Tea Monster for you in another thread. I know that's pretty heinous to insult you like that and I hope, in time, you can forgive me.

[NightFright]

Well, we all make mistakes from time to time. Maybe it'll inspire you to not talk badly about people in public sections. That's something for PMs. A lesson that may also be suited for some others, btw. Lecture mode off.

Bottom line: We are good. 😋

[ETPC]

Any updates?

[NightFright]

Basically same as before. Hendricks' implemenation for user map menus works, but not from within groupfiles, sadly. It's the only thing preventing a release basically. Even though there have been so many changes to EDuke32 lately that half of the addons could be broken by now and I wouldn't know about it.

[RunningDuke]

I was also going to ask how are things going at the moment but I was waiting a couple more weeks until sometime in February (after my exam session) and it looks like ETPC already asked in meantime. Surprised that Hendricks didn't downvote ETPC's comment, considering he did downvote at least two of my posts in this topic when I asked about any updates in past years (when there haven't been any news about the compilation in months). Seriously, the last compilation update was released 3 years ago, what's taking so long? Joking of course, I appreciate when there are at least news about progress, I don't mind waiting a couple more months in meantime.

Oh well, at least NightFright was kind enough to let us know how are things at the moment. I can patiently wait until next year, since in mid 2020, after I finish with my Master studies, I will have enough time playing through every user map and mod released for Duke3D (other games as well, in case of Duke I will also be going through old user maps and mods in DOSBox) and then I should be able to report any bugs that I will find along the way, assuming the addon compilation update gets released until then. I'm going to assume the upcoming update will release in mid April, to celebrate the original 1.3D release of Duke3D.

To contribute to the topic, I will say that back in February/March of this year, when I played through original release of Fusion TC (in Atomic 1.5 using DOSBox 0.74, interestingly I couldn't make the original version of addon to make it work in 1.3D as it would never start, I will start a different topic for that but at least the Atomic version of Fusion worked fine), so anyway I encountered many of the oddities that were also found in the addon compilation version, such as becoming randomly invincible at the start of some levels, the slot 0 weapon (with 5 ammo) having infinite ammo (except when falling and underwater, in both cases it would deplete normally), the enemy count bugs (some enemies don't count as killed when you kill them, others don't count as live enemies, etc), enemies randomly becoming invincible, etc. So these issues existed since the addon was released back in early 2000s. As far as I know, all these issues should be fixed in the upcoming version of addon compilation (4.0 I guess?) but I just thought I'd let you know that these bugs happened in DOS version as well. Either way I'm happy to have a fixed and polished version of the addon, even though I don't like this particular addon that much due to how hard it is and how poorly designed is in general, it's worth having a fixed version of the addon in this compilation so it plays a bit better.

I have a question: In the eventual case the new compilation update gets released, which EDuke32 build will you recommend for best experience? I'm also aware of the many glitches that have happened as of late and there's one issue that happened to me and I never got around to report it but it's been introduced since beginning of this year or late 2018 and basically it has to do with 32-bit mode, it seems I get a black screen and game becomes unplayable (the nuke logo displays fine but after that the screen becomes black and have to guess where I am and choose quit game or else bring the Task Manager to close eduke32.exe). I will make a separate topic with that report, just give me a few days to find out which is the first build where this happens.

EDIT: Merry Christmas!

[NightFright]

Right now I can't recommend any EDuke32 snapshot since currently there's no build out there which guarantees full functionality.

I will most likely run an open beta for the code-heavy addons to see how they do with recent snapshots. Would like to avoid another bug report wave about things that broke during code changes. It's good and bad at the same time EDuke32 is undergoing such fundamental changes, but that's one of the reasons why this compilation exists. You need to adjust the addons to work with the new code in some cases. Even though that shouldn't be necessary very often. At least it's a good way to find out about broken code.

As a side note, I have finally switched to Polymost as my personal renderer preference, so I won't necessarily optimize everything for 100% proper Polymer display any more, also since it's simply impossible to do with some level geometry.

[ETPC]

Out of curiosity, how come EDuke32 is undergoing so much change?

[NightFright]

This question should be addressed to the coding team. However, don't think adding new features or fixing stuff only breaks things in EDuke32. GZDoom for example is a very similar story. While working on my statusbar mod and other GZD-related projects, I had several cases where something did not work just because a function broke during the port development cycle, especially around v4.0 when tons of changes were implemented. You basially need to playtest everything on a regular basis when you have a port that's continuously developed. A large community comes in handy for such purposes.

[NightFright]

Patience, my young Padawan learner.

[NightFright]

News update:
Looks like we might get another shot at a proper user maps menu integration in the hopefully-near future. I know I have written stuff like this before, but TerminX's recent EDuke32 code adjustments provided a bit of momentum. As soon as there is a satisfying solution, I am going to release the new version immediately.

[ETPC]

fantastic news!

[NightFright]

Define "work". And it can be that Rednukem is doing a few things differently. I changed some con code which may have broken RN support.

It's always possible that some of the startup warnings I tried to remove were supposed to stay and changing the code to eliminate those warnings broke something.

[RunningDuke]

I definitely remember the version of GOD TC included in the addon compilation was broken when I played it in 2018 for first time, at least levels 2 and 4 because it was impossible to progress normally. In level 2, a switch didn't show up to activate the elevator outside of dam, while in the original version of addon the switch shows up fine. Also in level 4 I couldn't unlock the gate to the exit. I can confirm that because a year ago I played through whole GOD TC in Duke3D v1.5 in DOSBox 0.74 and was able to finish it normally without cheating (although I had to save often in some cases because of those annoying little aliens that are difficult to hit and some other enemies that dealt a lot of damage and killed me).

Also I found the health system a bit annoying, it seems you can't pick up health items unless you are below a certain value, in case of small medkit you must have BELOW 90, while for large medkit, you must have BELOW 70. That sounds good on paper because you won't pick up health by accident when you don't need it but it also means you can't get your health back to 100 unless you use medkit or drink water or find atomic health (which I think functions normally) and if for example I have 71 health at end of level and want to pick up health I left earlier, I must hurt myself (e.g. by falling) and get the large medkit left earlier to have close to maximum. I didn't really enjoy this addon to be honest, it had some good ideas but in general it seems to have been plagued by some weird design choices. At least the level design is alright, some levels I enjoyed but the first one with timelimit of 5 minutes I absolutely hated it! I mean when the timelimit expires in that level, the whole screen turns white and there's nothing you can do at this point other than quitting game and reloading last save because if I remember correctly, even the menu is covered in white.

Oh yeah, I also hated that last level with the landmines! At first I didn't understand what happened and then after dying 3-5 times, I realized there are landmines. Not as bad as the timelimit level but it was annoying the first time playing through it. Good thing I'm saving often (and using 1 slot per each level, with a backup save for current level too) so dying isn't much of an issue for me.

This is my opinion about this addon, feel free to agree or disagree. The TC seemed ambitious for its time but I personally didn't like it that much. I prefer more the classic Duke3D type of addons rather than full TCs that change Duke3D into something else.

[Phredreeke]

Keep in mind that when NightFright started this RedNukem wasn't a thing. Also it's very likely at least some of the newer addons in the compilation always required EDuke32-specific functions.

[NightFright]

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. It's called "EDUKE32 Addon Compilation" for a reason. This project never had the purpose to be DOS compatible. You want to play with a port that emulates DOS, use the old groupfiles from that era.

[LeoD]

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

Since EDuke32 is an ever changing project, it isn't wise building the addon pack around EDuke32 compatibility. Literally, any change could break compatibility yet again.

I still have hopes that there might come an EDuke32 build that can be used as some kind of reference version, even if the devs keep on refusing to make some real releases. "Thanks" to Ion Fury, the source code revision of the upcoming official fury.exe update could serve as such a point.

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

Just wondering, do your edits extend to modifying map files as well?

Yes. I've come across more than sixty so far.

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

[Data Hivemind Thot Entity]

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?

[Data Hivemind Thot Entity]

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)

[Data Hivemind Thot Entity]

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.