ClaudeMetz
Get the test scenario loading on 2.0.
The testing scenario hadn't been updated for 2.0, and didn't work at all (i.e. was crashing).
This change gets it technically working again, though it avoids the problem of creating factory fixtures. Instead, it shortcuts that process by using a raw export string.
Don't get too excited, this really isn't much. But it's an improvement. A potential negative is that it does technically change the mod code itself, which I was trying to avoid - removing interfaces/commands before adding them - but that strikes me as a pretty safe operation (though redundant in ideal circumstances.) That's caused by this approach needing to re-require control.lua.
I haven't yet convinced myself that this approach is the way forward (as you mentioned yourself on discord, it has some Issues), but at least this leaves it in a better place than it was.
Devlog
2024-10-24
GOAL: Set up devenv.
Cloned repo to mod directory.
PROBLEM: Mod doesn't load when launching debug. modfiles subdirectory needs to
be at the root level. Renamed repo directory to something else and made a
windows shortcut. Didn't work. Copy+pasted directory to verify it should work.
Found how to create "proper" symlinks on windows:
New-Item -Path factoryplanner -ItemType SymbolicLink -Value .\factoryplannerrepo\modfiles
Works.
PROBLEM: Scenarios don't show up.
Symlinked scenarios directory into modfiles. Probably would be cleaner to
symlink into user directory. Reference:
https://wiki.factorio.com/Tutorial:Mod_structure
PROBLEM: misc crashes loading testing scenario. Liberal commenting out and
updating to 2.0 (e.g. global to storage) got the scenario booting, though
not doing anything.
2024-10-25
PROBLEM: Need test suite to actually do something. Start uncommenting and actually figure out what's going on.
Need to make Factory constant available in tests.lua.
local Factory = require("__factoryplanner__.backend.data.Factory")
require works, but has picket up the init and unpack functions. get
doesn't exist anymore, but looking at usage plausible that unpack is the
replacement function ... but has a different API.
Hrmm maybe not, looking at type of import_factory.
process_export_string is returning nil, breakpointing to step through it.
We're getting a migration failure.
So: the test fixture data is in an old format. 1.1.42. This is before 1.1.60 which is first migratable version. So: we need new fixture data. Can we export from mod? Or simply construct by looking at data constructors?
The fixture data is created in parts.lua, which hard codes version strings.
Confirmed can export a string from mod proper, so let's use that and try to reverse engineer.
Ok it loads now, but solving fails because factory is not in a district. (Line:get_surface_compatibility)
Let's try regening with a district? Feel like it might still fail coz we're in a testenv and no surfaces? Actually maybe just looking for compat between district and machines/recipes.
So factory export from ingame mod is specific just to factory and doesn't include district. So we need another way to rehydrate that data.
For now will comment out in Line and see if we can make progress.
Found one more line trying to find pollution type, commented that out also.
Altered test body to locate an item in the factory as a proof-of-concept.
Messy, but this is technically testing something now.
The default District initialiser contains a default location, so adding one of those to the test subfactory lets us remove hacks.
Added print to control.lua so that results are printed to console as well as file. Pretty sure the code to dump errors to results.txt is broken, but don't care at this point.
PROBLEM: Still have some commented code in the main modfiles that need to be reverted before merge is possible.
Files are being double-required. First by the scenario control.lua, second by
the mod control.lua. This causes problems when e.g. adding an interface in
screenshotter.lua
Really wanted to avoid changing main modfiles, but think need to make them idempotent by removing commands first. Otherwise need to do a lot of work in test harness to sort out requires.
Thanks again for this, I'll have a look at it once I'm less inundated with bug reports!
Okay finally had a look, sorry for taking forever, should have done this sooner for such a low-risk change. I'm terrible with PRs lol.
Anyways, appreciate the log, interesting to read! The changes to the commands are fine, although it probably makes more sense to check for existance instead of removing then re-adding. I'll change this after merge.
Otherwise, looks good. You already noticed a few issues with all this, and there not being perfect answers. Feel free to take whatever path makes sense to you, I'm not married to any approach in particular. Thanks again.
Edit: This commit https://github.com/ClaudeMetz/FactoryPlanner/commit/f72fa10734f8c5c7f2c7fc3eec5ce5b74d4d4f22 changes the duplicate prevention.