[Added] Read text from arbitrary lumps from ZScript

[XxMiltenXx]

I guess the latter, as lumps are mostly checked within the root folder, while other files within folders are mostly included (e.g. for ZScript files via #include)

If possible I guess it would keep things neater if it could be implemented.

[Graf Zahl]

I don't think I ever exported the long name lookup functions because I never needed them for the internal code.

[_mental_]

Wads.FindLump() searches for a lump name, not a full file name. But the latter will be implemented via separate function.

EDIT:
Wads.CheckNumForFullName() function has been added in 415ed57.

Use Wads.CheckNumForFullName() or even better Wads.FindLump() function to find a lump by name, i.e. up to 8 characters long string like those names stored in .wad files.
Use Wads.CheckNumForFullName() to find a lump by its full name a.k.a. path. This is only applicable to archives that support directories, for example .pk3 and .pk7 files.

[Edward-san]

Actually, I think there could be a problem with this approach. What happens if two players have a file with the same name but the custom lump is different? If a derived source port implements a protected-lump system, it can't take account on these custom lumps, because the custom lump string|name|id would be available only when the call to these lump lookup functions are made ingame.
In other words, such source ports wouldn't be able to protect the custom lumps without some external way (command line?).

A solution to this could be having such custom lumps contain as first token a keyword which implies it'll be called by zscript.

[_mental_]

Could you please be more specific? What's the custom lump? And how is the lump protection affected by ability (or inability) to read lump's content?
Please provide a real use case with actual file and lump names.

[The Zombie Killer]

Would it also be possible to have some form of ReadChar() (which would return an int) method instead of ReadString()?

[_mental_]

Why do you need that? I think that parsing binary files is out of scope for ZScript. Reading array of bytes is doable but I see no real purpose in it.

[The Zombie Killer]

Being unable to read binary data kinda defeats half the purpose of a file API though. I think it's a necessary bit of versatility.

Plus, it's far easier to read in binary data in a language without proper stream-like APIs than it is to parse text data.

[Edward-san]

Could you please be more specific? What's the custom lump? And how is the lump protection affected by ability (or inability) to read lump's content?
Please provide a real use case with actual file and lump names.

I can't provide a test case right now. By 'custom lump' I mean the lump accessible from the mod zscript code.
Let's say there are two wads with the same content, except for the one custom lump (for example the one needed for the 'janitor' thing like OP said, containing in one file like 'Zombieman' and the in the other file 'Shotgunguy').

Two players playing a multiplayer game would get a desync if they load different wads. Sure, even with different maps the desync would happen, but it would be possible to protect it because it's a 'map-like' lump. Same for the Decorate and Zscript files, etc, because they can be recognized statically when starting the game.

If they try to load different wads which differ by the custom lump, the zscript code would execute things differently for each other, leading to desync in the same way. This leads to the necessity to protect this custom lump, so that every player would run the correct wad.

Now if you get what I mean, with this implementation, any modder could make such a lump without any specific pattern, as it would be only read by the zscript code. In other words, how can a program know if a lump is a custom lump or not, without reading zscript's code?

[XxMiltenXx]

I do not know how it is handled right now;
but wouldn't it be smart to implement a checksum check for all connecting players, to ensure they are using the exact same WADs, PK3s and so on? In this case such an error cannot occur, as the game wouldn't allow those players to start, until they have matching files.

Also, to let every player use "custom files" - as you specified, simply files that only change visuals or 'janitors', that some files can be loaded "optional" and are not required by every player?

[Edward-san]

I do not know how it is handled right now;
but wouldn't it be smart to implement a checksum check for all connecting players, to ensure they are using the exact same WADs, PK3s and so on? In this case such an error cannot occur, as the game wouldn't allow those players to start, until they have matching files.

Also, to let every player use "custom files" - as you specified, simply files that only change visuals or 'janitors', that some files can be loaded "optional" and are not required by every player?

the problem is that the program cannot know if a lump is called by zscript or not. You cannot indiscriminately apply a protection to all the lumps. Sounds, music, skins are an example of this.

[XxMiltenXx]

I didn't mean for every lump, nor if a lump would be called by ZScript but in general.

Currently in multiplayer, players can have different files loaded and the game will start. Depending on the differences of their file, they will go out of sync eventually. So, wouldn't it be smart in general for every multiplayer game, to make a checksum check of the files loaded, to ensure the files are 100% the same? And if they do not match, the game won't start giving the error message about a checksum mismatch.
And I do not mean a checksum check for every lump, but for the container (e.g. Doom2.wad) or every loaded mod archive.
This way the error you said, cannot occur as well.

[_mental_]

@Edward-san
Like I already said nothing protects from loading additional files with global ACS library or altered DECORATE/ZScript by one of players. This may or may not cause a desync depending on differences between players' files.
Enumerating lumps or reading from a lump won't change anything regarding this. By the way, checking for a lump by name was already there for about a year and no one complained about it.

It's a responsibility of mod's author to evaluate potential issues when making decisions based on availability of custom lump or its content.
I agree that this feature can be misused but we have other features that can abused in the same way.
For example, someone can use Object.MSTime() for game logic adjustment. We cannot stop him/her from creating buggy mods.

Honestly, I don't know how lump protection work. I guess you are talking about Zandronum, right?
But to me it's that pretty much everything needs to be protected, maybe with exception of sounds and music.
Also, presence of additional DECORATE/ZScript/ACS needs to be discarded too.

@The Zombie Killer
If you so inclined to work with binary data you can access character codes via String.CharCodeAt() function.
The engine doesn't do any interpretation of lump's data, so working with raw bytes is already doable.

[Gutawer]

Thanks for adding this, _mental_! Could you give an example of how you'd use the system to read all of the lumps with a certain name over multiple archives (I assume the presence of int wadnum = -1 in the CheckNumForName function allows this), including if there are lumps with identical names in the same archive (in the same way that you can create multiple lumps with the same name and gzdoom will parse them all)?

[_mental_]

The initial example does this exactly.