Unfortunately, I haven't been able to get the mockup to run; first, there were some dependencies that needed installing (`PIL`, which is now known as `pillow`, and `regex`; I had to also get `python3-tk` from my repo, which is weird because I thought python already has tkinter).
But even now that I've gotten what seems to be all the dependencies, I'm now getting this error instead:
Traceback (most recent call last):
File "/home/user/Documents/_Projects/DF Modding/DF-Modloader-main/main.py", line 249, in <module>
root.iconbitmap(os.getcwd() + "//icon.ico")
File "/usr/lib/python3.8/tkinter/__init__.py", line 2080, in wm_iconbitmap
return self.tk.call('wm', 'iconbitmap', self._w, bitmap)
_tkinter.TclError: bitmap "/home/user/Documents/_Projects/DF Modding/DF-Modloader-main//icon.ico" not defined
EDIT: commenting out line 249, and replacing all instances of `\\` in the code with `/` allowed me to run it, I'm gonna have a look around at it now.EDIT2: I don't see the "update syntax" button anywhere? Or that "multi-step compilation" checkbox for that matter.EDIT3: Now that I think of it, the `main.py` hasn't been updated on Github at all, and the SyntaxUpdater object isn't used anywhere.Info on the syntax is found in comments, as well as in the mod examples. Most of it is also taken from our discussion, so hopefully it should be understandable. I'll be able to answer syntax questions the coming hour, and then tomorrow.
About the mod examples; there seems to only be 1 example mod now, I don't know if that was intentional or if some others you had were accidentally deleted
EDIT3: especially considering how `main.py` failed to be updated as well.As for the comments, are you sure that GO_TO_TAG works that way? The wiki says it goes to after the target tag, not just before it.
What is `reading_mode` NONE for?
How do the SPEC_TAG tokens work? There was a bit of contention about how it would handle the modification of those special tags I think (and the implications for mod loading orders with the likes of GO_TO_TAG and all that), particularly with the question of when each mod actually writes its changes (like, OT_REMOVE_TAG actually removing a tag before the next mod adds it back or what-have-you).
What do you mean on line 456 of `raw_handler.py` about objects being compiled "out of order" and making sure not to count them twice?
Last moment I realized this code isn't capable of EDIT-ing already defined OBJECT_TEMPLATEs, but I figured it was better getting it out instead of trying to fix it and inevitably taking another day (or more). Especially since I remember it being a point of contention.
That's alright; as long as this is mentioned in any suggestions, Tarn will at least know about the issue and hopefully be able to solve it himself (same goes for the thing with body detail plans unique tokens).
I forgot about modpack bundling. I personally think the use cases of modpacks and mod options are mostly overlapping, as a modpack can contain versions of the same mod (or really be a single fragmented mod with parts you can choose to include/exclude). But you are right, they should be higher up in the list. After all, the most important thing here is to not "lose" anything that is possible through the current means of modding, procuring the mods and installing them.
Modpack bundling does have a lot of overlap, the only unique purpose of the bundling was for splitting certain sections so specific key parts of a single mod can be loaded at a later time after other mods; for instance, like Eric Blank mentioned at the beginning of the thread, he could define magic types very early on, but then only
apply the magic to civs at a later point, so that all civs (even those added by other mods) can use his magic.
Mod variations and fragmented mods like we have now, as you say could be done quite well with just options, and in fact at least variations should probably
only be done with options; it would be bad practice probably to have a single package downloaded from the Steam workshop literally have parts of it that overwrite itself; a "modpack bundle" should be able to function fully with all parts/mods enabled at once, so it should only be used for making some parts load later, and
maybe fragmented mods.
One other thing or so that I think is missing since I didn't notice it (it's not a priority to add to the mockup probably, but should at least be mentioned in the suggestion), is this:
As both the arbitrary string searches and the full token argument searches are useful when it comes to CV_CONVERT_TAG (or really CVCT_TARGET), why not split the cases into CVCT_TARGET_STRING for the gila monsters and... probably CVCT_TARGET still for e.g. the BODY conversions, as I think that is the obvious way for it to work.
About things to mention to Tarn though, I can't tell if it's maybe already like that because I haven't been able to run it yet (I suspect not though), but if it's possible technically speaking, hopefully we could abolish the use of `OT_ADD_TAG` and just use the actual tags directly in object templates? It would be far easier for copy-pasting purposes (and also the raw language server). Of course, `OT_ADD_CTAG` would still be necessary, but at least for normal non-conditional tags.
As for nesting of object templates, while COPY_TAGS_FROM (as you mention in the comments) would seem to work mostly, it's possible it may be a good idea to also have a way to input specific arguments there? That is, when having a template in a template, there could be potential problems with `!ARG
n` stuff, you know what I'm getting at?