Page 1 of 4

Read text from arbitrary lumps from ZScript

Posted: Fri Sep 08, 2017 3:13 pm
by argv
I've written a simple “janitor” class, which monitors how many temporary actors (gibs, shell casings, special effects, etc) exist at the moment, and starts deleting them if there are too many. Should help performance when playing mods that generate lots of those.

In order for this to work, though, there must be some way of determining which actors are to be considered “temporary”. That's especially tricky if they are from other mods, since the janitor code cannot assume that they are loaded, nor can they assume the janitor mod is loaded.

One possible solution comes to mind: have the janitor mod examine all lumps of a certain name (e.g., “JANITOR”) in the current load order, read a list of class names from each, and mark those classes as being temporary. That way, other mods can list which of their classes should be tracked by the janitor, without creating a dependency on the janitor mod. It'd also be convenient for them, since there's no boilerplate—just list the class names in a text file.

However, there doesn't seem to be any way for ZScript code to read text from arbitrary lumps like that. Please consider adding one (and/or an engine feature for limiting, by (super)class, how many actors are drawn at once).

Thanks!

Re: Read text from arbitrary lumps from ZScript

Posted: Fri Oct 27, 2017 7:45 pm
by Major Cooke
At the most, all you can do right now is check to see if something else exists by pairing a class cast with a string. You can only build 'out' right now and make boilerplate of your own for other mods to utilize.

But you can check to see if certain classes exist and make it so other mods can directly interact with said mod, but it must be done by the other mod itself.

Code: Select all

String something = "AlienActor"
Class<Actor> check = something;
if (check) // it exists.
{
}
else // it doesn't.
{
}
I think what this ultimately boils down to is this being needed to expand maximum potential.

Re: Read text from arbitrary lumps from ZScript

Posted: Sat Oct 28, 2017 1:47 am
by argv
But you can check to see if certain classes exist and make it so other mods can directly interact with said mod, but it must be done by the other mod itself.
Doesn't help. Any code that does directly interact with the other mod won't compile if the other mod isn't loaded. I can't, for instance, say “AlienActor(someActor).IsTemporary()” without creating a static dependency on whatever mod defines the class AlienActor. Nor can AlienActor derive from a class I define without creating a static dependency on my mod. I want to avoid static dependencies in either direction, so both mods function correctly without the other.
I think what this ultimately boils down to is this being needed to expand maximum potential.
That will not fly. The names of mod files are not stable. One person's “damnums_1.2.3.pk3” is another person's “damnums.pk7”. Only a mod's contents can be relied upon.

Re: Read text from arbitrary lumps from ZScript

Posted: Sat Oct 28, 2017 3:07 am
by D2JK
I think a better option for this sort of task, could be some sort of generalized A_QueueCorpse functionality (FIFO), which additionally, would now take a parameter that allowed you to separate different effects into their own groups (if you so desired), and also allow unique max limits per group.

Re: Read text from arbitrary lumps from ZScript

Posted: Sat Oct 28, 2017 3:38 am
by _mental_
Regarding this and linked topics I'm considering to expose some of FWadCollection functions to ZScript.

Re: Read text from arbitrary lumps from ZScript

Posted: Sat Oct 28, 2017 3:49 am
by Nash
_mental_ wrote:Regarding this and linked topics I'm considering to expose some of FWadCollection functions to ZScript.
Yes please! I'd very much like to make some custom lumps so that I can write a parser for them.

Re: Read text from arbitrary lumps from ZScript

Posted: Sat Oct 28, 2017 3:58 am
by phantombeta
That could be pretty useful. Unlike general file read functions, that would be safe, and wouldn't allow messing around with people's files or anything like that.
There's one thing, though... A pretty important thing if we're going to have that would be saving file hashes in the save files (if that isn't done by the engine yet). It could be prone to bugs and cheating if you could load saves with incompatible WADs and such.
For example, you load a mod that reads a file to know where to spawn some things and save, but later edit the file it reads. It could break the save. (Of course, one shouldn't do something like that, but it's better to be safe and not allow it, IMO)

Re: Read text from arbitrary lumps from ZScript

Posted: Sat Oct 28, 2017 4:38 am
by _mental_
phantombeta wrote:A pretty important thing if we're going to have that would be saving file hashes in the save files (if that isn't done by the engine yet). It could be prone to bugs and cheating if you could load saves with incompatible WADs and such.
For example, you load a mod that reads a file to know where to spawn some things and save, but later edit the file it reads. It could break the save. (Of course, one shouldn't do something like that, but it's better to be safe and not allow it, IMO)
You can break pretty much everything already without using ZScript at all: loading saved game after modifications of ACS libraries can have arbitrary consequences, same for DECORATE, and same for other declarative lumps.
It's possible to break even without changing anything in mod(s), just by altering a loading order.
So no, saved games remain as they are, without hashes etc. Current map's checksum is stored there and that's all.
The same applies to netplay determinism: if players are loading different set of mod files then it's not a problem of the engine that some issues can be introduced because of this.

Re: Read text from arbitrary lumps from ZScript

Posted: Sat Oct 28, 2017 6:23 am
by Gutawer
I'm in support of this also. I've got some minor projects on the backburner because the most sensible way to expose some API stuff would be as a custom lump which I'd write a ZScript parser for, so this would see some use with me.

Re: Read text from arbitrary lumps from ZScript

Posted: Sun Oct 29, 2017 3:47 am
by _mental_
Added in 2f45218.

The following example dumps content of all zscript lumps to console:

Code: Select all

int lump = -1;

while (-1 != (lump = Wads.FindLump("zscript", lump + 1)))
{
	console.printf("%s", Wads.ReadLump(lump));
}
EDIT:
If you think that reading from a lump is dangerous please think twice.
Mod cannot read arbitrary files on user's system. Lump enumeration and reading is limited to loaded .wad/.pk3/.pk7/whatever.
There is no ability to check actual file names (i.e. doom2.wad), number of lumps in those files, etc.

Also, since its first versions ZScript has Wads.CheckNumForName() function.
Nothing prevents "smart" modder from encoding arbitrary information depending on presence or absence of particular file.
Such encoding is very redundant as the single file name denotes only one bit of information.
Although it's exactly the same idea, just with absurd implementation.

Re: Read text from arbitrary lumps from ZScript

Posted: Sun Oct 29, 2017 4:26 am
by gwHero
Wow, this offers possibilities. I'm certainly gonna try this.

Re: Read text from arbitrary lumps from ZScript

Posted: Sun Oct 29, 2017 4:47 am
by XxMiltenXx
Is it possible already to read lumps from within a PK3 folder instead of only the "root directory"? And if yes, how?

Re: Read text from arbitrary lumps from ZScript

Posted: Sun Oct 29, 2017 5:48 am
by Rachael
Have you tried folder/name.ext?

Always use forward slashes when dealing with GZDoom stuff - backslashes are not supported in the zip format, nor on Unix filesystems, and forward slashes are forwards-compatible in Windows.

Re: Read text from arbitrary lumps from ZScript

Posted: Sun Oct 29, 2017 5:49 am
by XxMiltenXx
Yeah, I tried e.g. "zscript/mymod/mylump.txt" and also without extension, but it didn't work.

Re: Read text from arbitrary lumps from ZScript

Posted: Sun Oct 29, 2017 5:50 am
by Rachael
That's probably either a bug, then, or simply unimplemented, I am not sure which.