fixes #20: ensure vanilla_entities are loaded on "Write Entities" file regeneration #21
Conversation
| if include_vanilla_entities: | ||
| game_folder = self.GAME.submodule_name | ||
| # DS1R vanilla_entities are located in PTDE folder | ||
| if game_folder == 'darksouls1r': | ||
| game_folder = 'darksouls1ptde' | ||
| try: | ||
| append_to_module = PACKAGE_PATH( | ||
| f"{game_folder}/events/vanilla_entities/{self.path.stem}_entities.py" | ||
| ).read_text() | ||
| except FileNotFoundError: | ||
| append_to_module = "" | ||
| else: | ||
| append_to_module = "" |
| module_path, | ||
| area_id=game_map.area_id, | ||
| block_id=game_map.block_id, | ||
| include_vanilla_entities=self._project.include_vanila_entities |
There was a problem hiding this comment.
The MSB class doesn't have access to the project configuration, which is why this boolean needs to be passed in. Luckily, editors have access to the project via the _project attribute.
| vanilla_module = "" | ||
| else: | ||
| vanilla_module = "" | ||
| self.include_vanila_entities = True |
There was a problem hiding this comment.
Now the only logic needed here is setting the project configuration value.
Notably, this boolean can't be changed after project initialization (besides manually editing the config json, which will break a lot of things anyway), but I think this limitation really stems from that once an entity has replaced a hard-coded ID within a map script, there isn't a way to reverse this/update the entity without rolling back the script to use the ID again. Until that behavior changes, I think it's appropriate for this to be a one-time set.
fixes #20
Solution
I've added a key to the project configuration (saved in a project's
project_config.json) that remembers the user's choice concerning whether to include the pre-identified "vanilla entities" in the entities python modules generated. This boolean is passed into the baseMSB.write_entities_moduleinstead of theappend_to_modulestring. Now, the logic for generating theappend_to_modulestring is within this base function, ensuring that it happens whenever the modules are regenerated (whether during project initialization or manually via the entities editor's "Write Entities" button).Repeating the steps to reproduce outlined in #20 no longer produces a fatal error during compilation, since the module now still contains the 'Flags' class (whereas previously it would be excluded upon module regeneration).
None of the other games have logic that runs the
write_entities_moduleon MSBs during project initialization, so I assume that the modules are only generated via the entities editor for games besides DS1R. I don't have the other games so I can't test it, but I think this solution should work for the other games as well (too lazy to install Elden Ring on my laptop where I dev since it can't run it ;P).Collaboration
Hi again! I'm super interested in identifying/cataloguing all of the flags that are used in DS1. About a year ago I started making a mod with Soulstruct with the goal of refactoring all flag IDs into imports from a constants class, with docstrings for each flag that explained its usage. I went on hiatus before last summer to focus on other things, and it looks like since the summer emevd has changed a lot within Soulstruct - including Soulstruct's expected syntax. I've been familiarizing myself with the changes so I can restart my development.
One of the changes I've noticed is this addition of a class of pre-identified flags that are included as entities for use in an event script. With this change, it makes more sense to me to include identified flags in Soulstruct itself, rather than in an external 'mod' made with Soulstruct.
I would love to help expand this list and provide more detailed information about each flag if that's in your envisioned scope of this project. If you're interested, I'd like to work together to come up with what that should look like in the code. You can reach out to me by replying here or on Discord (mine is LugeL#2716 ).