Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[milo christiansen]

No, I haven't forgotten about Rubble, I'm just waiting for DF to stabilize a bit before I update.

Also, I haven't played DF for a long time, and lots of stuff needs testing to see if it still works... I'm not sure if said testing will get done, but I would like to do some at least.

Anyway, I probably won't bother updating the addons until DFHack is available. Playing without DFHack is just too painful.

[somebears]

I was thinking about mods quite a bit in the last few days, especially due to the fact that the new version of DF released and most mods are broken.


I've seen three approaches to mod-merging tools in the forums, one is simply merging files line by line, one is to merge things with some tag awareness that avoids most broken raws. Both of those delegate the correctness and compatibility of the raws to the original modders.


Rubble seems to go on a radically different path. Rubble is in charge of creating the structure of raws. This results in more deterministic results, scriptable mods and the ability to write mods that still work even after changes to the base game. This is paid for by having to update rubble itself for new versions, much like dfhack.


But I want more than a mere mod-merging tool. I would love to have some sort of package manager for Dwarf Fortress.


To this end, I have a few questions, if you don't  mind:




1. Rubble seems to be mainly concerned with raws. Do you think rubble is the "right" way to manage third party tools such as Dwarf Therapist?


2. How difficult would you think creating a script that "rubbelizes" a mod would be?


3. similar to above: How difficult would you think creating a script that "rubbelizes" a mod as a rubble base would be? (to use a mod as base or simplify DF updates)


4. is there a way to have rubble manage non-rubble mods? So have a mode that allows rubble to merge mods much like LNP does at the moment (the logic does not have to be in rubble itself, it could be provided with a plugin or script (eg. LUA))


5. I could not find the sourcecode/repository anywhere; this is intentional I assume?

[milo christiansen]

1. Not really. I envision Rubble as a tool for assembling raws, with auto-updating addon packs as a minor side benefit. Launching other utilities is not part of my plans. Basically, Rubble is there to build your perfect set of raws, after that it is up to the user to play the game with whatever other tools and launchers they want. This is also one of the reasons why Rubble addons and addon support APIs go so far to keep changes inside the raw directory. That way you can move a save generated by Rubble without needing to have Rubble installed on the computer you want to play it on (being able to have multiple saves with radically different raws in a single copy of DF is another benefit).

I encourage modders who want to provide a Rubble version of their mod to make the Rubble version first, then use Rubble to generate the vanilla version. For example Dirst's The Earth Strikes Back! mod is made this way. There is a special addon I wrote for him that generates the Rubble version and dumps it in a directory ready to zip up and ship. The main reason to do things this way is that Rubble raws are much, much shorter than vanilla raws, and repeat themselves much less. So Rubble is also a modding tool, not just a mod installer. Even if you don't want to make your users use Rubble, you can still get many of the benefits of templated raws.

Either way, serving as a launcher doesn't enter into my planning at all.

2. Easy, so easy that I already wrote one... "Dev/SO Insert" adds templates to existing raws and dumps the result in a directory. You still need to do some manual tweaking and cleanup, but not much. Tilesets use a different system that is even simpler (check out the tutorials that ship with Rubble).

3. I used "Dev/SO Insert" to generate the original "Base" addon. Since then I have edited in changes with each new version, but if a file has lots of new stuff I'll generate it fresh. Keep in mind, "Dev/SO Insert" is a tool to help with porting existing raws. It's output should not be used without manual cleanup.

4. Not presently. The problem with this is that mod-merging is non-trivial. Also, I feel that Rubble's primary benefit is the way it integrates addons, non-Rubble mods would not be integrated in the same way, and so they would be fragile and prone to creating bugs. For example: What if dwarves are not the playable race? Most Rubble addons will "Just Work ^(TM)", but non-Rubble mods will probably cause problems instead. If you really must do this, then use Rubble to generate the base raws, and use another tool to merge changes on top of that.

5. "other/src" in the download should have all the source code that is not online somewhere. I finally have internet at home, so I'll probably have a proper repository setup sooner or later (sooner).

I really, really need to get off my butt and update the addons for the latest DF.

[somebears]

Thank you very much for your reply![size=78%] [/size]



I feel the same way about 4. The problem is, that there always will be mods not using rubble (be it older mods or people not using rubble) but to have a useful package manager, one needs packages.


The solution that came to my mind was to either support non-rubble addons or automatically convert addons to rubble. This results in a dramatically increased risk, but also in increased numbers of mods supported. Maybe someone else has a better idea, but that is stuff for another post.

[milo christiansen]

Rubble 8.5.2 is now up.

This is a boring minimal-effort update to the new DF, together with a few tweaks that accumulated since the last update.

[somebears]

minimal-effort

Oh dear, and I thought me getting it into a almost usable state with the new df was hard work....


I can finally have my logic gates again! Thank you very much!

[milo christiansen]

Updating is pretty easy, but intensely boring. Knowing that someone else uses my work makes it worth it though

For reference, all I do is the following:

1. Diff the vanilla objects directory from the latest version vs the vanilla objects directory from the version Rubble is using, delete all unchanged files from the latest version.
2. Diff the pruned latest version raws against the Rubble Base addon, merge any changes not related to templates. This can get complicated for entities (requiring a bit of hand editing), but otherwise the process is a lot of pressing alt+down and alt+left over, and over, and over until your hands fall off.

Generally I have the update out very soon after a new version, I was just feeling really lazy this time.

[somebears]

Hey, I ported a few changes, mainly to plant_new_trees
I also added small changes that resulted in raws different from vanilla

diffs are here, if you want them: http://dffd.bay12games.com/file.php?id=13388

[milo christiansen]

Ahh! Damn, I must have deleted a few files too many, also there are a few genuine oversights in there (creature ID changes mostly). Thanks!

There are a few odd changes in your diffs though, for example removing the soap maker from the dwarves (and then hardcoding it back in), and removing wheelbarrows from the humans (in vanilla they have wheelbarrows, but not minecarts).

I'll post a new version with the fixes sometime soon (maybe even tonight).

[milo christiansen]

OK, how about "maybe in 20 minutes"?

8.5.3 is up now with the fixes applied.

[somebears]

oh, yeah, I replaced "[PERMITTED_JOB:ALCHEMIST]" with "[PERMITTED_BUILDING:SOAP_MAKER]" for Dwarves, because it is like this in vanila. I guess I had a double "[PERMITTED_BUILDING:SOAP_MAKER]", so I removed it from the Soap making Workshop :/

About the Wheelbarrows, I wanted to remove ITEM_TOOL_MINECART and ITEM_TOOL_STEPLADDER from Humans, not the Wheelbarrows :/
It seems to work on my end, so I probably screwed up creating the diffs or something like that, sorry!

[milo christiansen]

No, you were right about the wheelbarrow. Looking at the diff again I missed the context change in the middle. (honestly, I'm not sure why those two items were registered to the human entity. The playable humans addon has code to add both to the entity, so when I wrote that I was expecting them not to have those items by default.)

Alchemist being enabled on the dwarves was deliberate. Honestly, I don't remember why I did it that way, but I know a few addons use that skill so it was probably just easier to add it in the entity rather than adding templates to inject it later.

The soapmaker workshop was added where it was deliberately also. Otherwise addons cannot remove it from the entity. Rubble entities are very different from vanilla entities. Frankly, entities probably are more different than any other object.

Anyway, next version will fix humans having stepladders. Every other error you found was integrated in 8.5.3 (I won't be pushing a new version until the next DF, someone finds a major bug, or I get inspired to do some work on the current addons, whichever comes first).

[milo christiansen]

Rubble is now on GitHub! It will take a bit before everything is settled in. Currently import paths and such are all kinds of screwed up.

[milo christiansen]

8.5.4 is now up!

I have all the changes needed for GitHub done, and the one lone raw change from DF 44.4 added.

[milo christiansen]

Specifically, c-shared now works on linux/ppc64le, windows/386, and windows/amd64

Very soon now, it will be possible to build Rubble as a DLL or SO, allowing calling the Rubble engine directly from other programs (not written in Go). I'm not sure if this will be used by anyone, but some time after Go 1.10 is released I will do the necessary work to get this working and documented.

I am undecided between exposing the high level APIs, or just the low level building blocks, we will see when I get there.