Print

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

[Dirst]

the one time i tried to use the started pack merge tool it deleted my raws folder, I have no idea how it works...

I think there was a missing impulse ramp in one of the minecart logic gates...

I've had a hard time getting the Starter Pack mod merge to work as well.  It usually involves performing the steps, closing the Starter Pack, launching again, performing the steps again and this time it works.  And keep in mind that the state of the Pre-Merge Graphics button changes when it wants to change, not when you want it to change.

Things seemed to go smoother after I sacrificed a large gem at the Tribute to Python.

[Muffinator]

Hehehe yup, that sums it up! On another note, I have found out the hard way that awakened stones can become werebeasts... Interesting.

[Dirst]

Out of curiosity, what makes TESB incompatible with First Landing?  I was trying to keep this mod capable of co-existing with other mods.

Lots of stuff. For one thing First Landing lacks some of the layer stones (I forget which ones), most of the basic gems are gone (which would result in "hidden x" being available when "x" does not exist), and the permitted creature tag in the syndromes will obviously cause problems (but that's an easy fix).

It would have been possible to make them compatible (using the @IF_ACTIVE template or something similar) but frankly it would be a fearsome amount of work and the result would be fragile and hard to keep up to date.

There are ways to structure addons so that they can be used with radically different bases like that, but it involves lots of templates, basically you make a "library" of all the raws that do not depend on vanilla content in any way wrapped in templates, then make a different addon that uses these templates to create the actual raws used by the game. It's not really hard to do if you start that way from the begining, but would require a major rewrite now. It would be a good task to combine with a major update like moving to a new DF version, but only if you really want total compatibility with everything really badly

In principle, the mod could be "scripted" for arbitrary stone types if I was willing to sacrifice some detail, but I'd rather have a master list of potential stone types (with associated colors and hidden gems) then include only the ones that exist in the raws as layer stones.  I remember seeing an example script that created a caste of a creature for each type of wood in the game.

That would let me include feldspar without breaking a stand-alone installation, and absorb the deletion of some vanilla layer stones.  It'd still require some coordination to make sure the gem type appears alongside the stone type, but it's simpler than accommodating specific mods by name or building a Rube Goldberg contraption that picks a gem for each type of stone.

[milo christiansen]

I just remembered: There is an "IF" template (I forget it's exact name, @SHARED_OBJECT_EXISTS maybe?) that triggers on existence of a "shared object" (any item that is wrapped with the proper templates, which all the materials in the standard base are). Some simple modification of the existing templates would automatically not generate castes for any stone that does not exist. No scripting required, simple and flexible. Basically if, say SLATE exists it would parse and insert the caste raws for the SLATE caste, else it would insert a message stating slate was missing. If you wanted to support new layer stones that mods may add it would just be a matter of adding the proper template call, Rubble would automatically cull unneeded ones. This would require some changes to the DeRubblizer addon, but nothing complicated.

I can finish templating the creature raws and make the other stuff tolerant of missing materials without making the raws much more complicated. That would make TESB First Landing compatible, which would be really cool.

Expect a patch next time I get to a library that has the needed changes for general compatibility with any base addon.

I am making a concerted effort to avoid scripting or any of the more complicated features of Rubble, I don't want something that you will have trouble working with, plus by using just the core template library this will remain compatible with Rubble versions going into the future. I will need to make some changes to the addon.meta files when Rubble 7 hits because I am changing from scripts-as-data-files to a more generic format that should be simpler to use and maintain. Technically if not for the addon.meta files the addon would be compatible with Rubble versions from... 4.x? I think? Anyway, the way things are now you won't have to worry about Rubble updates breaking anything until Rubble 7 (which is still a ways off), and that should be the only time it is a problem. Ever.

[Dirst]

I just remembered: There is an "IF" template (I forget it's exact name, @SHARED_OBJECT_EXISTS maybe?) that triggers on existence of a "shared object" (any item that is wrapped with the proper templates, which all the materials in the standard base are). Some simple modification of the existing templates would automatically not generate castes for any stone that does not exist. No scripting required, simple and flexible. Basically if, say SLATE exists it would parse and insert the caste raws for the SLATE caste, else it would insert a message stating slate was missing. If you wanted to support new layer stones that mods may add it would just be a matter of adding the proper template call, Rubble would automatically cull unneeded ones. This would require some changes to the DeRubblizer addon, but nothing complicated.

I can finish templating the creature raws and make the other stuff tolerant of missing materials without making the raws much more complicated. That would make TESB First Landing compatible, which would be really cool.

Expect a patch next time I get to a library that has the needed changes for general compatibility with any base addon.

I am making a concerted effort to avoid scripting or any of the more complicated features of Rubble, I don't want something that you will have trouble working with, plus by using just the core template library this will remain compatible with Rubble versions going into the future. I will need to make some changes to the addon.meta files when Rubble 7 hits because I am changing from scripts-as-data-files to a more generic format that should be simpler to use and maintain. Technically if not for the addon.meta files the addon would be compatible with Rubble versions from... 4.x? I think? Anyway, the way things are now you won't have to worry about Rubble updates breaking anything until Rubble 7 (which is still a ways off), and that should be the only time it is a problem. Ever.

An "IF" template would handle this concept nicely, as long as it works in entities, creatures, plants, secrets, reactions, interactions and init files.  The DFHack scripts would need to be hardened, but I should do that anyway.  Hell, I'd be willing to load up the documentation with template tags to help the player know what to expect in that world.

[milo christiansen]

Don't worry about it too much just yet, I'll have everything ready to go in a week or so. For now just use the existing version.

Unless you want to try to fix it yourself of course (but why would you want to when I am volunteering?)

Sadly the documentation does not support dynamic generation , well you could but it would be really, really hard... That would actually be something to look into for Rubble 7.

[Dirst]

Don't worry about it too much just yet, I'll have everything ready to go in a week or so. For now just use the existing version.

Unless you want to try to fix it yourself of course (but why would you want to when I am volunteering?)

Sadly the documentation does not support dynamic generation , well you could but it would be really, really hard... That would actually be something to look into for Rubble 7.

I incorporated the changes to bring it up to 1.35, which was just a cut-and-paste operation, and fixed one typo (the workshop NAME_COLOR was ignored).  It is available in the "backup" download location now.

Haven't actually played it yet, but saw this during setup: "No Variables listed in Meta Data"
I can think of some interesting things to do with that, but it will require a much deeper look at the documentation.

This looks great so far!

[Thuellai]

Released a Dolomite Wyrm.  It promptly killed both my miners (probably because I had them attack it and didn't remember that it was made of steel) and then promptly stopped fighting anyone

Now it's just chilling in my dining room with everyone else, but it's not aggressive.  It does, however, like to knock over buildings from time to time.

[Dirst]

Released a Dolomite Wyrm.  It promptly killed both my miners (probably because I had them attack it and didn't remember that it was made of steel) and then promptly stopped fighting anyone

Now it's just chilling in my dining room with everyone else, but it's not aggressive.  It does, however, like to knock over buildings from time to time.

This is one of the bugs in spawn-unit.  Spawned units are built trait by trait for every trait known to the DFHack devs, and something about the mind just doesn't get made.  The newer create-unit takes a different approach by fooling the game into thinking for a moment that it's creating an Arena Mode test creature.  The unleashed units should behave more naturally once I can get the new tool working.

By the way, their claws and bones are steel, and their hide is stone... But there is some flesh in there, including a heart, brain and lungs for your militia to attempt to hit.

But think of it this way: if you were a Wyrm who just mowed down two armed dwarves, and since then you've been quadrupling in size every week, would you feel threatened by a dining hall full of the bearded buggers?

[Dirst]

An historic day for Dwarf Fortress.  A pet rock was moved to violence!



Although it didn't end well for the poor pet rock.

Maybe it will do better against a smaller foe?



Not really.

[Thuellai]

Am getting the bug reported earlier where the tribute reactions to create gem seeds don't work, and just produce generic, unusable 'seeds'

[Dirst]

I've released v1.36, which fixes the useless seeds issue and the oddly calm creatures issue.

You should be able to drop this on top of an existing save with no ill effects.  If you're merging manually, neither entity_default.txt nor onload.init has changed.  Existing creatures will retain their chilled-out ways, but new ones should act like typical DF creatures... which is to say less friendly.

[Thuellai]

New Awakened Gabbros are popping out and now being listed as 'Friendly', which I guess is technically an improvement on being listed as 'Wild' and acting Friendly.

Haven't re-tested the seed reactions yet.

[Dirst]

New Awakened Gabbros are popping out and now being listed as 'Friendly', which I guess is technically an improvement on being listed as 'Wild' and acting Friendly.

Haven't re-tested the seed reactions yet.

Irritatingly, this didn't happen while I was testing... but I just reproduced the problem in a test fort.  I'll work on this and let you know when I have a fix.

[Dirst]

Continuing to get overly friendly spawned creatures, which is different from overly calm ones.  The issue appears to be the new unit's enemy_status, which seems to not be defined until the creature has existed for a tick.  I'm still working on that.

In other news I found a repeated typo in the reactions file.  Search-and-replace PLAT_ to PLANT_ to fix the fix for gem seed extraction.