Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  
Pages: 1 2 [3]

Author Topic: DF Modloader mockup (and discussion on how to load mods in Steam DF)  (Read 7365 times)

voliol

  • Bay Watcher
    • View Profile
    • Website
Re: DF Modloader mockup (and discussion on how to load mods in Steam DF)
« Reply #30 on: November 22, 2021, 03:00:45 pm »

I did start working on a new version of the mockup to play around with/see how the concepts we had discussed would work, some time after my last comment on this thread. The main part went pretty smoothly, then I got caught in a slog trying to make something to auto-update the syntax of the old raws to use object templates etc. When I last worked on it some month ago, the syntax updater was pretty much done, but I ran into some bug with the main part.

I did watch the BlindIRL interview. Considering how close what I've written is to some usable state (hopefully, if that one bug doesn't cover another ten), I have been wanting to make that spurt the last week, but my schedule hasn't allowed it. I will attempt it this week as some gaps opened up. I feel more unsure about being able to produce a thorough suggestion as well, it's more of an either or thing with the time I have.



That said, these are the main parts I think are needed for a more robust mod system. Without these, using mods will remain cumbersome, and mods will be largely incompatible with each other without manual efforts:
  • easy fetching mods from Steam Workshop, and have a manager for mods in-game, no more digging in folders (for Premium users, at least)
  • have mod descriptions not only in Steam Workshop, but also the in-game mod manager. These can include dependencies etc.
  • enable/disable mods in that in-game manager
  • mods should not only be able to add whole objects, but also remove objects, and edit them (add/remove/convert tokens)
The idea is that Steam Workshop is great for finding mods, but not for managing ones you have downloaded. Non-premium users also can't use Steam Workshop, so that's another reason.

These are secondary things, which would be useful for modders and allow more interesting mods and a higher rate of mod interaction:
  • When removing or editing objects, allow mass selection according to tokens used, object id, or a combination
  • Give all objects a arbitrary value token like CREATURE_CLASS. These could also be criteria for mass selection.
  • Generalize creature variation templates to work with all kinds of objects, not just creatures. Merge them with the other template objects (like body detail plans) while you're at it.
  • allow mod-specific options, which can be set by the player in the in-game options

Mr Crabman

  • Bay Watcher
  • A person with the head and pincers of a crab.
    • View Profile
Re: DF Modloader mockup (and discussion on how to load mods in Steam DF)
« Reply #31 on: November 23, 2021, 03:29:28 am »

I did start working on a new version of the mockup to play around with/see how the concepts we had discussed would work, some time after my last comment on this thread. The main part went pretty smoothly, then I got caught in a slog trying to make something to auto-update the syntax of the old raws to use object templates etc. When I last worked on it some month ago, the syntax updater was pretty much done, but I ran into some bug with the main part.

I did watch the BlindIRL interview. Considering how close what I've written is to some usable state (hopefully, if that one bug doesn't cover another ten), I have been wanting to make that spurt the last week, but my schedule hasn't allowed it. I will attempt it this week as some gaps opened up. I feel more unsure about being able to produce a thorough suggestion as well, it's more of an either or thing with the time I have.

I see; hopefully there will be time for it then, and I look forward to seeing what direction you took with the mockup; our earlier discussions about what would and wouldn't work in terms of loading order ultimately have less substance than actually testing what works and doesn't work.

That said, these are the main parts I think are needed for a more robust mod system. Without these, using mods will remain cumbersome, and mods will be largely incompatible with each other without manual efforts:
  • easy fetching mods from Steam Workshop, and have a manager for mods in-game, no more digging in folders (for Premium users, at least)
  • have mod descriptions not only in Steam Workshop, but also the in-game mod manager. These can include dependencies etc.
  • enable/disable mods in that in-game manager
  • mods should not only be able to add whole objects, but also remove objects, and edit them (add/remove/convert tokens)
The idea is that Steam Workshop is great for finding mods, but not for managing ones you have downloaded. Non-premium users also can't use Steam Workshop, so that's another reason.

These are secondary things, which would be useful for modders and allow more interesting mods and a higher rate of mod interaction:
  • When removing or editing objects, allow mass selection according to tokens used, object id, or a combination
  • Give all objects a arbitrary value token like CREATURE_CLASS. These could also be criteria for mass selection.
  • Generalize creature variation templates to work with all kinds of objects, not just creatures. Merge them with the other template objects (like body detail plans) while you're at it.
  • allow mod-specific options, which can be set by the player in the in-game options

About an ingame mod manager, I've seen many games on Steam that have an ingame mod manager (for managing mods you have subscribed to on Steam), so for sure that's essential and definitely doable, and when the idea of an ingame mod manager is brought up (in FotF, and maybe the interview, I don't recall), Tarn seemed open to it. For non-Steam users, I think dropping a downloaded mod file into a dedicated "mods" folder, and then using the ingame mod manager for doing the rest is be as best as can be done really, and seems okay.

As for options, it's just a matter of opinion I suppose, but I personally see mod-specific options (and modpacks/bundling) as being quite important for mod usability, given that Steam doesn't allow the uploading/hosting of multiple versions of a mod at once (whereas here on Bay12, offering versions of mods with certain differences is quite common).

Ultimately, what seems to be the hardest part out of all of these both technically (I may be mistaken on this), and conceptually, and what most of this thread was spent discussing, is how to allow editing existing objects without it being a complete overwrite; Tarn has seen in FotF and said that overwriting based on a "mod load order" seems doable, but expressed doubts about being able to do merges on a single object, but it's possible he was referring to merges on fully defined objects (like, take dwarves from mod A, and dwarves from mod B, and try to combine their token differences almost like a git merge), rather than merging in "object patch" changes in a manner like creature variations like we've been discussing.

The details of pretty much everything else (especially the "essential" parts) I think are either solved already, or easy enough to figure out; the difficulty really lies in the details of how to achieve the "dream" of patch-based editing of objects, so that multiple mods can make precision changes to an object at the same time; I think this is what the likes of PyDwarf try to do, but with python code instead of an officially supported thing written in the raws themselves.

voliol

  • Bay Watcher
    • View Profile
    • Website
Re: DF Modloader mockup (and discussion on how to load mods in Steam DF)
« Reply #32 on: November 24, 2021, 04:57:03 pm »

Turns out it was more than the one bug. Anyways here is the updated mockup, on github. It's probably far from perfect but it is also a mockup, so putting to much energy towards that would be detrimental to the point. 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.

Before compiling anything containing the Vanilla raws included, they need to have their syntax updated (i.e. mostly turning CREATURE_VARIATION into OBJECT_TEMPLATE) by clicking the "Update mods' syntax" button. This just has to be done once, though if you want to try it with other mods they also need their syntax updated, of course.

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.

Oh, and the "multi-step compilation" checkbox doesn't do anything.


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.

Definitely agree that the patched-based editing is the most difficult part, both conceptually and technically.

Mr Crabman

  • Bay Watcher
  • A person with the head and pincers of a crab.
    • View Profile
Re: DF Modloader mockup (and discussion on how to load mods in Steam DF)
« Reply #33 on: November 25, 2021, 06:29:35 am »

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:

Code: [Select]
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 `!ARGn` stuff, you know what I'm getting at?
« Last Edit: November 25, 2021, 07:19:27 am by Mr_Crabman »
Logged

voliol

  • Bay Watcher
    • View Profile
    • Website
Re: DF Modloader mockup (and discussion on how to load mods in Steam DF)
« Reply #34 on: November 25, 2021, 11:55:57 am »

I apparently botched the github upload :/. It is fixed now. I have no idea about the other errors (other than the dependencies, Python is just like that), if they were not caused by the botched upload.

There are more example mods now!

I remember doing !science! on GO_TO_TOKEN, but I don't remember the conclusion I came to, whether it conflicted with the wiki and I forgot to update it, or the wiki was right and I forgot to update the code.

Reading mode "NONE" is for empty files, so it doesn't attempt to create an object (and fail) when reaching the end of a file where there is one. It could as well be "None" or left undefined in some other programming language.

The "SPEC_TAG" tokens work as I envisioned them, like object template tokens but at an earlier stage, and only for special tokens (like USE_OBJECT_TEMPLATE). I don't remember the details though, it's been a while since I wrote their code.

"out of order" refers to how if you got e.g. TOAD and TOAD_MAN, it has to "compile" TOAD first, for TOAD_MAN to copy its tokens from. There is some recursion code further down that allows this to happen, so if TOAD_MAN appears first in the iteration TOAD can still be prioritized. If this happens, TOAD must then be skipped when its supposed turn comes, or it will ultimately be output twice.
It should be mentioned though that the vanilla objects are all in order, presumably because Toady's code lacks that kind of recursion, so you won't see it without some modded raws (or just putting TOAD_MAN above TOAD in the vanilla raws with a text editor).

Quote from:
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.

Agreed. Another point of modpacks bundles is having modpacks ;) (though actually this is less important than having parts of a mod be loaded later, because both Workshop and zipfile downloads have good support for not-that-connected modpacks. Also depends on the way the modpack is structured, how much the parts interact, I suppose).

The splitting of CVCT_TARGET/OTCT_TARGET is something I forgot about, but will mention in the suggestion. I figure there are more things like that we've both agreed on in this thread, which I will encounter when rereading it for the suggestion.

The "OT_ADD_TAG" bit does happen in the modloader mockup, but at least the current implementation is part of what makes it finicky to edit object templates.

I don't think nesting templates have any issues. I assume you mean that "!ARGn" bits get replaced when they shouldn't? By the time "inner" templates are inserted into "outer" ones, all their "!ARGn" bits should already be gone. Not sure what the point of having arguments when copying from another object, or how you suppose it would work.


I've also started writing on the suggestion now, by the look of it it should be done on time... Depending on what "on time" is, by the end of the week is probably more accurate. Then the discussion can be continued there (and hopefully by some more people, who can contribute with their experiences).

Mr Crabman

  • Bay Watcher
  • A person with the head and pincers of a crab.
    • View Profile
Re: DF Modloader mockup (and discussion on how to load mods in Steam DF)
« Reply #35 on: November 25, 2021, 02:15:27 pm »

Just noting that [APPLY_CURRENT_OBJECT_VARIATION] was left in example_mod_4, presumably left over from before when it was needed.

Also, I'm not sure what you mean by this:

Code: [Select]
These syntaxes currently exist:
APPLY_CREATURE_VARIATION:template name:args
BODY_DETAIL_PLAN:template name:args
USE_TISSUE_TEMPLATE:new id:template name
USE_MATERIAL_TEMPLATE:new id:template name (creatures and plants)
USE_MATERIAL_TEMPLATE:template name        (inorganics)

I don't think nesting templates have any issues. I assume you mean that "!ARGn" bits get replaced when they shouldn't? By the time "inner" templates are inserted into "outer" ones, all their "!ARGn" bits should already be gone. Not sure what the point of having arguments when copying from another object, or how you suppose it would work.

My thinking was something like this:

Code: [Select]
[OBJECT_TEMPLATE:UPPER]
    [OT_ADD_TAG:PETVALUE:!ARG1]
    [COPY_TAGS_FROM:VERTEBRATE_TISSUE_LAYERS]

This is a poor example as nobody would ever make a template with this specific content, but the idea is exemplified here; VERTEBRATE_TISSUE_LAYERS is expecting !ARG1 to be the outermost layer tissue, but somebody using `[USE_OBJECT_TEMPLATE:UPPER]` would ideally be using this template the same way as the VERTEBRATE_TISSUE_LAYERS by itself, but with an extra argument for the PETVALUE at the start instead.

You could use !ARG6 instead for PETVALUE, but while that's okay for this example, I worry whether this lack of control over the argument numbers might be an issue, especially when you start taking CTAG into account, or if you ever copy from 2 different templates that each use !ARG1 for different things.

So my idea would be like:

Code: [Select]
[OBJECT_TEMPLATE:UPPER]
    [OT_ADD_TAG:PETVALUE:!ARG1]
    [USE_OBJECT_TEMPLATE:VERTEBRATE_TISSUE_LAYERS:!ARG2:!ARG3:!ARG4:!ARG5]

I realize that USE_OBJECT_TEMPLATE would be a bad syntax to apply here probably since VERTEBRATE_TISSUE_LAYERS is OBJECT_TEMPLATE:CREATURE:, but you get what I mean?

The "SPEC_TAG" tokens work as I envisioned them, like object template tokens but at an earlier stage, and only for special tokens (like USE_OBJECT_TEMPLATE). I don't remember the details though, it's been a while since I wrote their code.

Do they get added to the object like the other tokens, at the start of the object (like you suggested at one point), or do they exist only inside EDIT itself, apply their changes immediately, and get tossed away by the time the next mod/edit starts being loaded?

And is there a use-case for ADD_SPEC_TAG?

Finally do you see there being a possible issue with GO_TO tokens between multiple mods?, Or how did that work again? I worried at one point about situations where the earliest mods could misuse GO_TO_END in a way that results in some tokens being impossible to re-add by later mods unless they have the foresight to also use GO_TO_END (and even then, some tokens have to go near the start because of others that will depend on them later).

Actually, I think that might have been the OT tokens that I had concerns about with GO_TO.

Agreed. Another point of modpacks bundles is having modpacks ;) (though actually this is less important than having parts of a mod be loaded later, because both Workshop and zipfile downloads have good support for not-that-connected modpacks. Also depends on the way the modpack is structured, how much the parts interact, I suppose).

Out of curiosity, by the Workshop having support, you're talking about the collections right?

FantasticDorf

  • Bay Watcher
    • View Profile
Re: DF Modloader mockup (and discussion on how to load mods in Steam DF)
« Reply #36 on: November 25, 2021, 04:19:16 pm »

Id politely excuse myself from getting into the technical parts of stuff, because you two seem to have a good thing going at the moment with your constructive back-forth, but have you considered the technical capabilities of 'Rubble'? Given a couple of old mods use it to organize and shell run some DFhack scripts if you wanted a additional category to put in there.
  • To my knowledge Rubble isn't maintained anymore, perhaps by a certain extent of redundancy, and even so it'd be very cool if @milo christiansen (rubble creator) could get in the conversation for this new-ver mod load/organizer.
Meanwhile PtW.  :)
Logged

Mr Crabman

  • Bay Watcher
  • A person with the head and pincers of a crab.
    • View Profile
Re: DF Modloader mockup (and discussion on how to load mods in Steam DF)
« Reply #37 on: November 25, 2021, 04:38:05 pm »

I've heard of Rubble and thought it was something like that, but I don't really know much about it at all; PyDwarf I think is a more recent thing with a similar purpose?

Does using @ like that actually summon people on this forum?
« Last Edit: November 25, 2021, 04:53:59 pm by Mr_Crabman »
Logged

voliol

  • Bay Watcher
    • View Profile
    • Website
Re: DF Modloader mockup (and discussion on how to load mods in Steam DF)
« Reply #38 on: November 26, 2021, 07:04:31 am »

Oops! I forgot to remove/accidentally uploaded list_of_changes_to_syntax.txt. It was more of a personal note thing (or at least it never evolved any further to become documentation), that part is on what "templates" exist in current DF raw syntax, to be replaced by object templates. This version only does that to creature variations and partially body detail plans. The other turned out to be trickier.

COPY_TAGS_FROM should not be used inside object templates, indeed, and certainly not to copy from object templates. I imagine it is possible with the current code, but it isn't well advised, and nesting APPLY_OBJECT_TEMPLATE (like the second example) should already be possible and the better way to do it.

ADD_SPEC_TAG doesn't really have a use case, no. I included it to mirror OT_ADD_TAG, which also isn't strictly necessary, at least not in a layer visible to the modder.

I don't think there are problems with GO_TO(_END), though I suggest you try it out, I might be wrong and it is one of the reasons the second version of the mockup was made. I don't quite remember what we have said before on this, so I am uncertain what you mean here, and I believe the discussion can get quite lengthy. I'd rather have it on the (more visible) suggestion thread, so I can focus on getting that out.

Indeed those are collections :)


I've seen Rubble and PyDwarf, though I am new to the modding community enough that I never had the chance to use them when they were new, so I'm not 100% aware of their capabilities. The reason I, in the making of the modloader mockup (the first as well as the second version) chose to do something using modified raw syntax instead of a second language (Python and... DFhack scripts?), is that it makes it easier for those familiar with only modding to get into. Both those tools I also think expected end-users to compose the mods (I think), which I don't view as something optimal, and may have contributed to their not popping off. Though the project is also twofold, it's also an attempt to push an integrated mod manager/loader/whatever to Toady. Not to offload effort, but because he can do more with the underlying code, and an integrated version will be available for every player without having to find a third-party tool.
All that said, it's probably a good idea to look closer at the two to get ideas. Thanks! :)

@ does nothing, you have to PM folks.

Mr Crabman

  • Bay Watcher
  • A person with the head and pincers of a crab.
    • View Profile
Re: DF Modloader mockup (and discussion on how to load mods in Steam DF)
« Reply #40 on: November 26, 2021, 05:48:20 pm »

Looks good so far, though a bit "dense"; maybe there could be a spoilered image just after the description of the mod manager to illustrate the structure a bit?

Also, these paragraphs could do with an extra space in between, they are sort of uncomfortably close and make it look a bit wall-of-texty:

What I suggest, is to have an in-game mod manager. The mod manager would depend on a folder of "all mods". In this folder, the player would place mods as separate sub-folders (or compressed .zip files, if that works better with Steam Workshop) in some unified format, unlike the current downloads. For those using Steam Workshop, the "subscribe" button would place a mod in the folder, and "unsubscribing" would remove it, while those not using Steam would have to find mods elsewhere and place them manually there. This is the extent that the player would have to dig in the files (not at all with Steam Workshop), with the mod manager handling the use cases of installing and uninstalling mods.
I suggest reusing many of the same GUI elements from the the trade screen for the mod manager screen, both to instill understanding through familiarity, and to save time developing (if it does, this is an assumption on my part).

  • I'm not sure when the installing is best done, and where the mod manager is best placed. Perhaps on the main screen, or as a step when creating a new world, as new worlds are the prime targets.
    In either case, at the time of "installing" mods (which could be as soon as the mod manager screen is exited), all the mods in the right list have their folders read, and their combined raws are what is used by a save. Here comes the difficult technical part, how do you merge mods? How do you deal with the aforementioned conflicts? The easier way is probably to do it with "patch-style edits" (rather than to use git-like merges of full files) where some parts of a mod relate to a base file (or base raw object) and have instructions on how to add/remove/change(convert) certain tokens, or remove the whole object.

This first version of the suggestion doesn't end there though, as there is one more integral part for the mod manager to cover the use cases we currently have: mod options and/or mod bundles. The point of both of them is to allow variants of a mod and mods subdivided into optional parts, without separate downloads.
With mod options, the idea is to have options for each mod (presumably set using similar methods to the "main" options, as those will have some in-game solution as well). These can toggle parts of the mod on/off, and set values within the raws. From a technical standpoint I imagine they would work similar to the arguments used in creature variations (this explanation/suggestion might be expanded as well), but for the whole mod.
A mod bundle is something like a bin in the trade screen, it contains several "mods" and you can choose to only include some of them to be installed. In the "all mods" folder, a mod bundle is a folder containing multiple mod folders. Mod bundles cover the same use cases as mod options (the bundle containing all variations of the mod as separate mods, the same thing with optional parts), though they also have a technical function related to the merging of mods (but more on this tomorrow). Mod bundles could also be used for mod packs, though I think the collections on Steam Workshop work pretty well to fulfill that niche.

voliol

  • Bay Watcher
    • View Profile
    • Website
Re: DF Modloader mockup (and discussion on how to load mods in Steam DF)
« Reply #41 on: November 27, 2021, 05:58:41 pm »

It is done. I opted to focus on the use cases rather than the attempts we had at getting them to work, because I had to prioritize some and in the end Mr. Adams (the two of them) may read this thread if they are really intrigued. The suggestion is still pretty daunting, even after including the spacing you suggested (thanks! :) ). An image is a good idea, but I've met my limit for this evening; I'm unusually tired, I might be getting sick.

Mr Crabman

  • Bay Watcher
  • A person with the head and pincers of a crab.
    • View Profile
Re: DF Modloader mockup (and discussion on how to load mods in Steam DF)
« Reply #42 on: November 28, 2021, 07:57:07 am »

That's some good stuff; hope you are alright health wise!

In the meantime, I've added on a bit of my own commentary there, and linked to the thread on Reddit to hopefully get a little bit more attention to it.

I have by the way more or less come to agree with you on the matter of placing REMOVE_TAG in the objects; like your example before:

Code: [Select]
[CREATURE:EDIT:BY_TOKEN:TOAD]
[GO_TO_END]
[OV_REMOVE_TAG:PET_VALUE]

Code: [Select]
[CREATURE:EDIT:BY_TOKEN:TOAD]
[GO_TO_START]
[PET_VALUE:50]
Added to the object:
Code: [Select]
[CREATURE:TOAD]
...
[CREATURE_TILE:249]
[COLOR:2:0:0]
[PET_VALUE:10]
...
[GO_TO_END]
[OV_REMOVE_TAG:PET_VALUE]
[GO_TO_START]
[OV_ADD_TAG:PET_VALUE:50]
End result:
Code: [Select]
[CREATURE:TOAD]
[PET_VALUE:50]
...
[CREATURE_TILE:249]
[COLOR:2:0:0]
...

I think my worry was kind of that [REMOVE_TAG] was going to be added to the end, and then the parser would immediately next find GO_TO_START and the PET_VALUE (skipping over REMOVE_tAG), and then would reach the end, and finally remove the pet value only then. But really, as long as it actually removes the tag there and then based on its original position, and doesn't actually move the tag (no real reason it should need to be able to move it right?), then it should work out.

Same goes for CONVERT_TAG; there's no need to be able to move that anywhere else using GO_TO, so in each mod being successively added to the bottom, each mods CONVERT_TAG and REMOVE_TAG tokens are being applied in the correct order.

And GO_TO_TAG can still work fine for USE_OBJECT_TEMPLATE.

The only funky stuff with the order I can see is that any instance of USE_OBJECT_TEMPLATE being edited must happen before it is applied/processed, and same probably goes for any edits to CONVERT_TAG blocks themselves, if that happens to be something that needs to be done.
« Last Edit: November 28, 2021, 08:17:43 am by Mr_Crabman »
Logged
Pages: 1 2 [3]