Comments - EngineOfDarkness

Sorry for not seeing your comment for a day, I'm currently in the process of moving from windows to linux so I cannot check as I'm in the middle of getting MO2 + Anomaly to work properly - once I got it running I'll take a look if what you want to do works.

----

It might work if the file in question doesn't get cached somehow when starting the game from desktop.

As long as the function ini_file(...) is not called directly in the script (so outside any function like on_game_start) it should in theory work.

My script runs before on_game_start is executed and makes changes to the files.

Anomalies "on_game_start", that most scripts use to register callbacks or run other scripts, runs when the "loading" screen appears - so only once you started a new game or loaded an existing savegame.

A note on the #include - if you edit "items\\settings\\npc_loadouts\\npc_loadouts.ltx", the #includes inside that file get parsed and the file then contains the contents of all files that are normally included via #include

(this is expected for now and working "properly" - this is a sideeffect of me using the vanilla anomaly functions, until I get around to write my own methods to handle the ltx files Github.com ).

This means if you want to change any properties of the included files you can either use the main file "items\\settings\\npc_loadouts\\npc_loadouts.ltx" or you can edit included files like for example "items\\settings\\npc_loadouts\\npc_loadouts_stalker.ltx".

But you should not try to do both at once, as this can have side-effects like changes from included files not applying.

In this case I would suggest modifying the included files, given that you do not need to change any properties like "scope_chance" in "items\\settings\\npc_loadouts\\npc_loadouts.ltx"

> As the loader stands now, I think it's probably ready to be used as a dependency for mods going forward.

You can if you want, but in general I would feel better about this, once I made some improvements to the end-user experience with regards to updating their mods.

Since due to the nature how this Library currently works, if you for example have a mod that edits an LTX directly in addition to a Mod that uses this Library, the End-User has to manually remove the .backup and .temp files each time the Mod that edits the LTX directly is updated.

If this is not done, the End-User won't get the updates of the Mod that edits the LTX directly, since the Library uses the .backup file (that remains unchanged once it has been initially created) as a "source" to write the Modifications to.

For MO2 users that keep their install clean that's easy since they can just nuke their "Overwrite" entry but for everyone else that uses JSGME or Manual install this is a hassle.

Once I've solved that I'd feel better about encouraging the usage of this Library.

Especially because this might become a de-facto standard I want to get this mostly right before it is widely adopted.

Ah yes, for now I've designed it so that it's based on the alphabetical order(or at least it should work that way) - that way mod authors already have a way to somewhat control the load order until I come up with something better.

I made an entry in the Roadmap.md on Github about this. I opened no issue for this yet, though

"Very rudimentary load order system (not dependency management!) so modders can specify in which order their mods should be applied given that other mods exist"

This would be the best way I can come up with for now, since this works with any way to install Mods and not just MO2. I suppose the Mod Author(s) should also know best in which way the mods should load (compared to the End-User).

Further down the line, perhaps there could be some sort of config file where an End-User can overwrite the Load Order (incase a mod author goes missing), if there happens to be a need for it. Not sure how / if MO2 has some sort of Plugin Capabilities, but if so perhaps it could be used to write a Plugin that exports the config which specifies the order aswell.

----

I'm not sure if any updates will come out in the coming weeks. Right now I'm hitting my head against a concrete wall, since I'm trying to find out if I can somehow "update" the gamedata Path (to e.g. gamedata_temp) or add a new path and make the engine read loose files from there.

There are methods for this, but `update_path` doesn't seem to do what it says it does (it just seems to return a "parsed" path and not update the path the engine uses, the few uses I found in vanilla scriptfiles seem to support this, regrettably) and `append_path` just crashes on the spot with some generic windows file error and no actual detail as to where it happens.

Doesn't help that I'm not experienced with C++ or Debugging it either (tried to use WinDbg on the mdmp generated by Anomaly, but that too did not yield anything someone like me could work with, pushing aside the fact that I miss the neccessary Debug Symbols aswell. I suppose I could google around and see if I can somehow "generate" debug symbols myself If I download the Anomaly engine and build it or something along those lines)

Just as a heads-up I've implemented the above solution a little bit differently - there will be a new class (ChangesetCollection) that you can return instead of a Changeset (so you can return either a Changeset or a ChangesetCollection)

local someChangeA = Change("supplies_1", "device_pda_1", nil)
local someChangeB = Change("supplies_1", "device_pda_1", nil)

local a = Changeset({someChangeA}, "Sid", "Sid.ltx")
local b = Changeset({someChangeB}, "Barman", "Barman.ltx")

return ChangesetCollection({a, b})

I like this a bit more than the nesting approach I was going to take originally.

It isn't out yet though, I addressed a Performance Issue that would've reared it's head eventually and the last thing I need to finish before I'll release 0.3.0 is a way for Modders to specify if they want a changeset to still apply, even if a change inside the changeset is faulty (right now a single faulty change out of hundreds could cause the entire changeset to not apply). Probably takes a few days still.

After that I'll probably have to spend some weeks on the bigger issue with making updating / removing / etc easier on the End-User aswell as some badly needed architectural changes (e.g. tests, actual error handling instead of this weird error bubbling approach I implemented)

Not right now - I have something similar in mind (only noted in the Roadmap for now but not yet planned out - something like Autoloading LTX files from mod specific folders and generating the Changesets automatically) Github.com

But that is probably still some time in the future.

I think I could implement it so you can nest Changesets one level, for example

local someChangeA = Change("supplies_1", "device_pda_1", nil)
local someChangeB = Change("supplies_1", "device_pda_1", nil)

local a = Changeset({someChangeA}, "Sid", "Sid.ltx")
local b = Changeset({someChangeB}, "Barman", "Barman.ltx")

return Changeset({a, b}, "Barman & Sid")

Not sure if I like the code but if I'm not mistaken that would be relatively simple to tack on.

I'll take a look at it this weekend - I'm kind of exhausted after 8 hours of trying to wrestle with the *.db files Github.com (been trying to find a solution to make updating / removing other Mods easier on End-Users)

I'd say if you encounter any properties that won't work since I haven't tested all possible properties that LTX files can have. Some might not even be fixable (e.g. if some of the properties get "cached" in some obscure way in the engine) but documentation about that would be helpful.

Otherwise general User Experience (from an End-User / Modders perspective, for example if anything in the Readme is off), Bugs, etc.

Currently I'm working on making the detection of changed vanilla / modded LTX files a bit better (so it requires less End-User interaction) but I don't foresee that being done quickly since I have to explore different solutions. Github.com

Done - on the rchive Readme / Moddb Description aswell as the Github Readme.

The issue with it only working from the Launcher should be fixed

However I would not recommend it for production usage (aka other mods) other than to test and give me feedback yet.

I've edited my first comment to include some detail about that

Edit: Ah and I also removed the `.ltx` from both the backup and temp file - works for me.

> The backup and temp files created in the overwrite directory still have .ltx

Good point - I'll made an Issue for that Github.com.

Not entirely sure if it works with the ini_file_ex() function (and therefore the temp file) - but I'll take a look

> I can foresee issues where an end-user with MO2 installed this loader as a requirement for an addon, and then deletes the addon and loader, but doesn't manually clear the accumulated LTX files in the Overwrite

Yeah that is my gripe with my Library aswell - it's why there is an entire Uninstall Section dedicated to this.

I did try, infact, to delete files when quitting the game (still leaves the Problem when the game Crashes though), but some simply cannot be deleted (perhaps due to pointers not getting cleared or the game simply writing the files again). I'm not entirely sure why.

Currently as it stands, when the game quits it at least installs the "vanilla" file from the backup that exists. But well again, if the game crashes that doesn't happen.

I don't think I can save to the MO2 Mod Directory because the LUA files have no knowledge of the Folderstructure once the game launches (because MO2 uses some sort of Virtual Filesystem). The fact that the files end up in Overwrite is probably because MO2 cannot ascertain which mod they came from.

However played with the thought of at least moving the backup file to another folder. However since the temp file is loaded with ini_file_ex() it errors on ini files that include other ini files - probably because ini_file_ex also parses the files and cannot find the included inis.

Another Idea I have written down in an issue for this: use luas IO functions to write my own "ini handler" which does not parse the files -> Github.com

Then I could move the temp file to a custom folder aswell. Still leaves the issue with the "original" file though. This does make editing the system.ltx more complex though. That is because currently you can just say "change section X" and due to the fact that the "system.ltx" gets parsed (and thus includes all sections of weapons, items, ... aswell) you don't need to specify the ltx you want to edit, unlike for the trader files where you need to specify them.

I wish we had a way to get ahold of the "in-memory" ini instances the game uses, that way one could just do the modifications in memory directly - but I don't think that's possible currently - at least I haven't found anything

I got it I think - I always launch the game via the Launcher (from MO2) if I use one of the EXEs directly I get the same issue. Which I guess is to be expected because the Launcher is one Folder "up" in the file hirarchy.

I'll see what I can do.

Perhaps you can try to verify if this works for you aswell (launching from the launcher, that is)

Edit: Documented this as Issue on Github: Github.com

Thanks. That's odd to say the least. Which Operating System are you on?

The reason it looks in Anomaly\bin\lua\gamedata is because when requiring a module it looks in several different folders (this is controlled by the `package.path` setting in lua)

At first I though your package.path is different but I just intentionally named a FileLoader in the autoloader.script require wrong and we seem to have the virtually the same package.path (well except the Disk and Anomaly Foldername)

In fact the very first "no file" message is the same and it should find the file there (if you remove the extra "r" at the end of my logs), but doesn't

Excerpt from your log for autoloader.script

no file '.\gamedata\scripts\config\FileLoader.lua'

My Logs (extra "r" just to see the package.path errors)

no field package.preload['gamedata\scripts\config\FileLoaderr']
no file '.\gamedata\scripts\config\FileLoaderr.lua'
no file 'N:\Anomaly-1.5.1.2\bin\lua\gamedata\scripts\config\FileLoaderr.lua'
no file 'N:\Anomaly-1.5.1.2\bin\lua\gamedata\scripts\config\FileLoaderr\init.lua'
no file '.\gamedata\scripts\config\FileLoaderr.dll'
no file 'N:\Anomaly-1.5.1.2\bin\gamedata\scripts\config\FileLoaderr.dll'
no file 'N:\Anomaly-1.5.1.2\bin\loadall.dll'

Yet for me it works... that's so odd.

Can you try and replace

local FileLoader = require "gamedata\\scripts\\config\\FileLoader"

with

local FileLoader = require "gamedata.scripts.config.FileLoader"

in the autoloader.script and tell me if it the error message of `autoloader.script` disappears?

In the meantime I'll create an Installation on my C: Drive aswell - I wonder if this is perhaps some sort of file protection issue on Windows (assuming you are on Windows) even if you do run the game in Admin mode.

Edit: Its not - at least on Windows 7 - I moved my installation there and tried with "manual" installation aswell as MO2. Though I am on a non-admin account on my system.

In the worst case I can just move all files back into the script folder itself I think.

I'll change it.

Did you start a new game or did you load a game?

Can you check the logfile and look for messages starting with "LTX-LIBRARY" (or just post a link to the logfile on pastebin or something)?

Well hopefully it works - currently it's a case of "Works for Me" since I haven't heard otherwise.

Technically (I haven't tried) when using the "*_trader_mod.script" to create Changesets you can modify any LTX already - not to say the game will load them ofcourse (depends how and when the ltx is loaded in the engine)

However that is more of a side-effect (since I don't limit the Changesets to the trade folder directly) rather than deliberate - I'll probably rework that at some point to be more generic (because there is no point in running some trader specific code on non trader files)

The New Version which can modify Trader Files is up.

Info for Mod Developers: When switching from 0.1.0 to 0.2.0 - you need to

Rename scriptfiles that end on _ltx.script to _system_mod.script

Change the method in those scriptfiles from registerLtxModifications to registerSystemLtxModifications

-----

I'd recommend reading the Readme on Github for now, it now also contains a Table of Content Github.com

A quick note - this will probably take a bit longer since I'm currently working on ravenascendants (see comment below) request.

You may be happy to hear that this seems indeed possible. I finally managed to force the game to read the modified trader ltx.

Well at least for my hardcoded testcase with sidor.

I don't yet fully understand why I have to do a weird workaround though.

It's still a lot of debugging trash I did, so I need isolate which steps are enough to clean that up in the following days so it becomes actually usable. Not really sure how long that takes, since I have to plan some sort of API for this that isn't to hard to use.

There is a high chance I have to overwrite a vanilla scriptfile (trade_manager.script) though, but again not sure what final solution I will arrive at yet - I just basically got this to work mere minutes ago.

I'll write up a more complete description of what I did in the Github ticket later.

Edit: Ops replied to the wrong comment, oh well...

I've made an Issue for this feature. As I assumed in my previous comment my code can already be used to create "copies" of trader files. It's a bit finicky because I made no proper API for this yet, but theoretically it works.

As predicted however, an issue arises with updating - the call to update the system ltx does not update the trader ltx files (as expected) and as such the modified trader files aren't read (probably because they get read at startup, before the changes are made via my code)

I'll investigate in the following days if one workaround I wrote in the Issue is feasible, or perhaps I'll find another one.

Github.com

> What would it take to point this at LTX that are not part of ini_sys, most notably trade profiles?

Ah I see, those are not loaded in the system ini - dangit.

I did write some of the lua files inside the scripts/config/ folder to be a bit configurable but I haven't tested that part yet.

What I don't know yet is how the game behaves when these files are changed on the fly - the system.ltx has a reload function that the CoC Dev Alundaio introduced a few years back - but I don't know if changes to the Trader files would also be refreshed.

I'm gonna try a few things over the coming days.

> what do you have against else statements?

I assume you mean the part that use luas "goto" statements?

Definitely some horrible parts there. Originally I had goto in some parts to simulate what other languages have as a "continue" statement for loops.

Probably something I'll refactor out in the coming days.

Regarding the question - I generall try to avoid else unless neccessary, I used to work in a bigger Team (PHP Backend Dev) where we had tons of linters running to ensure we had a "codestyle" that was the same for everyone working there (so we could get people onboard of different projects efficiently by having some familiarity)

Update 2017-03-25:

Some smaller Changes, nothing big yet. Disclaimer further below still applies:

- Ability to define Changeset and Changes as optional (see Readme)
- Allow multiple Changesets in one scriptfile, using ChangesetCollection (see Readme)
- Refactored the way systemIni is Reloaded (only done once now)

----

I would not recommend it for production usage (aka other mods) other than to test and give me feedback yet.

Currently for JSGME or Manual Installation (so non MO2) Users the Process for Updating Mods is convoluted - I have an issue open ( Github.com ) where I'll try to remedy this somewhat (this won't be completely alleviated just yet though - also not sure if it will ever be - perhaps once I get around to Github.com )

----

There are no mods that use this Library yet, I do work on something small that serves as an example once I got this Library to an acceptable user-experience for End-Users.

Quick Question, is there a limit to how many Marines can spawn once you enter a level?

Say I have three Marines and I go to the next level - in the next Level only one Marine out of the three I had spawns.

In earlier Brutal Doom Versions pre 20 (I didn't play with Project Brutality back then) I could amass more and more Marines per Level, which was quite a fun change.

Nowadays apparently only one Marine changes Levels with me.

Was this done on purpose, and if so, can I somehow "remove" that feature so all Marines I had will spawn when I change levels (e.g. via console command)?

I use the Maps of Chaos Mappack and already asked over there if this might be a issue with the Maps, but the author said that should not be the case, so I figure I'd ask here next.

Thanks for the great mod aswell, even made my Old man want to play the Old Doom again (that tells you something ;) ).

I didn't mean the amount of Marines I get per map - I meant that I literally loose Marines if I switch levels.

Say I have three Marines in Level x and once I enter the next Level only one Marine spawns instead of the three i had in the level before.

But I guess this is a PB / BD thing which then got introduced in later releases - gonna ask over there if anyone knows anything about that.

It's been quite some time I played Brutal Doom (currently using Project Brutality with MoC) - so I'm not sure if this is "mod" or "mappack" related:

If I have more than 1 friendly marine and go to the next level, I only have 1 marine left in the next level instead of the amount I had before. So If I leave the level with 2 marines I only have 1 left in the next level.

I recall being able to have literal armies (which I enjoyed for a change) - is this map related (e.g. not enough spawnpoints?) or is this something I have to check with the Project Brutality Creator?

If It is map related, could you tell me which Editor you used so I can "fix" the problem for myself?

Thanks a lot, and nice work on the maps.