Thank you for the updates. As a fellow dev I wanted to ask about the change from Enum to StringName. Is it purely for the flexibility with modders adding more types or are their other benefits?
I currently use both enums and StringNames but I prefer enums for types because it can be type enforced. Thank you for your insights and time.
Random thought: Although I wonder can we type enforce StringNames if they are under a class level dictionary?
Yes, exactly! The benefit of StringNames is entirely for modder flexibility, and are much worse when it comes to typing and editor features. I figured out how to jump through some somewhat-cursed hoops in order to keep the dropdowns in the inspector & code autocomplete, seen here, but yeah lost the runtime type safety checks.
The only other marginal benefits I can think of are more readable JSON files when I serialize data, and ability to remove earlier entries without messing up the int -> meaning linkage.
I’m not planning on setting up a separate internal API for modders; they should be able to use the same general services & utils that the base content uses, e.g. there’s a big unit_conditions.gd file that any ability can call into by saying UnitCondition.apply_status(…) to apply Impaired.
The main way an ability can specify working differently than the general rules is by extending and overriding a function from the base class. For example, action_impact_lance.gd from the Vlad overrides func get_self_heat_dice(context:Context) to only gain heat if it’s catching more than one target in its attack.
The drawback to this is that mods will break as I change the internal implementations // function names. But since these usually represent changes in available context, I don’t see a way to maintain an unchanging API that would still work with the old contexts.
Okay that makes sense. I just want to lead with I am not trying to make you work out what could or should be done. I am just expressing some thoughts, and not necessarily a good solution as I may not have thought through enough scenarios. Also I realize it is probably impossible to set up a unchanging API this early since the game is still in active development.
So do you have a way to let mod's know the current version API, or is it just the game version?
I really am not sure how I would want to address mods this early in a game either. But I do feel that an abstract would help me control the interactions, and allow me to provide some guarantees to prevent breaking too often. Though perhaps many modders would see this as limiting their ability to achieve their desired modding goal?
Do you check for mods to break on load, or how are they loaded in general? I have only breifly touched on the topic in Godot and generally I see it done as an additional ".pck" that can be loaded at a specific point to the "res:/" like in the docs here: https://docs.godotengine.org/en/stable/tutorials/export/exporting_pcks.html
Again thank you for your time.
All good, these are good questions & I don’t mind the opportunity to think/talk them out :)
Yes, any API I’d be able to hypothetically provide would likely have to change along with the game as more or less information becomes available for functions which would defeat the purpose of it. For standardized sorts of mods like simple texture packs I think keeping the way that they load stable is feasible & required… but for a game as complicated as Lancer I don’t think I can predict what features modders might need to pull off whatever they’re trying to do once they get their fingers into the scripts.
Figuring out how we’re handling mod loading & pck files this week; previously LT mods used the player-made modloader by Gavstar, but I think for the official support we’ll be using the Godot Mod Loader project.
