ZDoom

One thing I found out is, apparently the engine doesn't check for duplicate #includes when used with ZScript and DECORATE. Thus it tries to register certain classes more than once as a result.

If feasible, I suggest either ignoring duplicates or erroring out if they share a file that's already been read, or outright skipping it. Either or works for me. I round-aboutly discovered this by accidentally forgetting to remove one include, since there is one which points to another included file that points to the file already.

I'd like to second this since it means you can't just mix Episodic EX and Immerse without commenting the following out in one of them. (RESCINDED: It doesn't seem like those helper scripts can be split off into its own file but that's ugly anyway).

Please define duplicate. Does it mean the same file by its full path, by its file name, by its short name (8 characters without extension), or by its content?

fakemai wrote:you can't just mix Episodic EX and Immerse without commenting the following out in one of them.

The problem with these mods is placing almost identical files under different locations.
In theory, de-duplication by name could solve already defined class errors in this case.
However, file contents are not exactly the same, so loading order may break things anyway.

I think a far better system would be a #pragma once type thing specified inside the #included file. Blankly allowing a file to be included multiple times, I think, will encourage messiness and that may be something the author does not always intend. However, forcing the author to consciously override this behavior will mean they did so intentionally, not by accident.

An automatic "#pragma once" for all files. It would make sense since I don't think zscript is going to ever feature macro redefinition tricks that would justify including a same source file twice and getting different results the second time (like what ZDoom does with namedef.h to generate both an array of string constants and an enum of string identifiers while making sure both are always kept in sync).

Gez wrote:An automatic "#pragma once" for all files.

I was thinking about the same. Files would be distinguished by their full paths, or technically, by their lump indices.
Although, it won't fix the problem with two mods having the same file with different full paths.

There's one problem here: Constants are implicitly namespaced to avoid name clashes of mods with engine extensions and code generation depends on the script version. So the second one can actually depend on different values.
This is also what currently stalls opening up 'extends' to user mods. Just reading all as one compile unit would be easy, but it's a bit trickier than that. Different compile units can have different versions and different constants and lumping everything together will create conflicts.

So sorry, there is no way to do this safely. If mods conflict they cannot be used together. Also what _mental_ said, another issue is that if both mods use the same file names but different content the lump manager's file matching rules will only see the second instance which creates a completely different set of problems.

I think that erroring out if the same file gets included twice is the only viable option.

Well even if this is a no I'll just post my attempt to make all 3 fit together in case it's helpful. Conflicting files from the main 2 mods were commented out, and I moved the ones from Immerse (plus a couple extra dependencies) into a separate mod. It at least loads, and briefly testing it doesn't seem to crash. Load order compat, episodicex (1.1.0), immerse (1.0.4)

Drat, too big. https://mega.nz/#!MNs2RaJR!B_EYfN8Ec396 ... QOHzvExxXc

Graf Zahl wrote:Also what _mental_ said, another issue is that if both mods use the same file names but different content the lump manager's file matching rules will only see the second instance which creates a completely different set of problems.

I won't surprise you if I tell you this has been used deliberately to create patches for mods. Specifically the example I've seen was overriding some of (what else?) Brutal Doom's lumps this way.

To be clear, in the base Decorate.txt I have:
And inside Decorate/Include.txt: That was the accident I had.
So that wound up generating warnings of duplicate actors and renaming them.
I never intended to do that, and because D4D has a gameinfo loading screen it was obscured.

(No, D4D doesn't have any remaining decorate. I'm just making adjustments for another mod's compatibility.)

Mainly, I'm only asking this for files within the current archive of scanning. I.e. if it's inside D4D.pk3 and it finds an include to a file twice in the SAME package, it should error out. That's what I was going for.