Print

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

[Boltgun]

Hello,
Did anyone managed to add interactions with add-syndrome?

I tried adding a syndrome through a script and I can confirm that it worked with show-unit-syndromes.

But once in combat the unit never use the interaction. It's the most obvious with the firey one. If I switch into arena mode and assume control, I can throw fireball but the AI never tries.

I remember we had the same problem in 0.34 no and we fixed that by setting additional timers?

Second problem, LUA_HOOK reactions seems to fire twice.

Thanks

[PeridexisErrant]

Proposal:  make DFHack scripts a seperate repo
(see it on github here)

For script developers, the current system is awkward enough to use that most simply don't. Many maintain git repos for their scripts with no shared history, and more still don't use git at all.

I think it self-evident that script authors working on a fork would be better than our new submodule system, and that encouraging more people to use git for DFHack scripts would be a good thing. I further assume that we would like to know about as much of the script development being done as possible, and prefer to have the option of adopting that work into the standard distribution.

So the proposal is actually pretty simple:

• move the scripts directory to a new repository, and make it a submodule in it's current location
• each author forks the repo, and works in /devel/$name/ if they're not comfortable putting stuff in the main folders
• when ready for publication, scripts are moved to the main directories and pull-requests are made

What are the advantages for users (ie script authors)?

• it's trivial to work in a functioning environment: just grab a DF+DFHack install, cd hack && rm -rf scripts && git clone ...
• the same technique makes getting new stuff easy
• all the linting and testing tools are available
• encourages collaboration, since you fork one repo not many and can fetch from other repos
• no baggage: it doesn't include any of the scary C++/Perl/Lisp/XML/Cmake/whatever that scares people off

Advantages for DFHack core developers?

• shared history
• more people use git for DFHack scripts, meaning better history and more content
• the build systems and merge patterns are more sensible
• management of the scripts could (but need not) be handed off, and just checked when it's time to update the submodule for a release
• less duplication, as a higher proportion of the code is widely known among script authors

Thoughts? I know this is a big step, but the DFHack project is getting big enough that it's hard to manage and this seems like a natural and helpful split to make.

[Warmist]

<...>
each author forks the repo, and works in /devel/$name/
<...>

I'm for it but can't seem to understand why this is needed? Imho it would be more sense to fork and work in same location as the script is intended to be (bonus points to improve other $name scripts ). Also history would be better as having file in same place lets you track changes more easily (e.g. tried figuring out something about tweak but because it was split into files and moved around it was a chore).

[PeridexisErrant]

Right, if you're working directly towards publication the expected file location is the right place to start. I would hope that this becomes more common.

For longer term stuff or experiments though, such as most of the new sibmodules, the devel subdirectory is an alternative to entirely separate repos.  And appropriate use of "git mv" preserves the history of a file even when it's path changes, though splitting and combining files still confuses it.

[Gorobay]

I don’t think git mv means what you think it means.

[PeridexisErrant]

"Appropriate" in this case means you commit between moving and editing the file, so it can be tracked.  There's plenty of magic left for me in git, but I do get the basics 

[lethosor]

Without additional options, there's no difference between "git mv a b" and "mv a b; git add a b". Also, GitHub does not follow renames in its web interface (see https://github.com/DFHack/dfhack/commits/develop/plugins/title-version.cpp for an example), and doesn't deal with them in PRs very well either.

[Roses]

So modtools/add-syndrome, for lack of a better term, needs some work, I'm just not exactly sure what. First off most syndromes are added correctly, you can give a unit an interaction that it will use correctly, change display name/tile, change attributes, and basically anything that is considered a "Special Effect" on http://dwarffortresswiki.org/index.php/DF2014:Syndrome. But any of the base effects will have do nothing. My brief bit of science that I did found the following.

When applying a syndrome via interaction (which is what I figure we should model add-syndrome after, instead of adding a syndrome via attack). There are several additional components that are not correctly set.

1. None of the target_ vectors are populated in the symptoms list.
2. This leads to no wound being generated.
3. If the target_vectors are artificially populated a wound is automatically created, but it's parts vector is empty
4. Filling in the parts vector seems to correctly "apply" the syndrome. Unfortunately using this method means that out of everything in;

Code: [Select]

[CE_NECROSIS:SEV:100:PROB:100:RESISTABLE:BP:BY_TYPE:THOUGHT:ALL:BP:BY_TYPE:NERVOUS:ALL:START:30:PEAK:60:END:1200]the only thing we can really do is apply necrosis to the correct body parts for the correct times. As you have to populate all the values, and there is no easy way to handle SEV or RESISTABLE.
5. Unfortunatelyx2 in 3 of my 5 tests the game crashed. This may be because I was creating entries by copying another units. I am unsure

I am hoping that someone more knowledgeable about the workings of things can come up with a way to add damaging syndromes via add-syndrome. Otherwise I will move back to just adding wounds directly (this suffers from the same Unfortunately as number 4)

[PeridexisErrant]

Update on the next release: effectively negative progress because there's more stuff to do. The documentation is overhauled in terms of formatting and presentation but the content is about the same. I'd like to go over the documentation and add stuff and organize a bit more. I'd also like to go through the big pile of third party scripts we're adding and decide what needs to go in and what would be too cluttered and fix indentation and try and extract out common functionality, etc, etc. I'm working on it a little each day but it will take longer than I expected.

I do still intend to do DFHack 0.40.24-r4 before the next DF release.

It would go a lot quicker if I just took all the 3rd party scripts and stuffed them in but that would clutter the scripts folder a lot and when I do eventually go in and standardize everything it would break backwards compatibility. I'm willing to break it if there's a good reason for the long-term health of the project but I try not to.

Just another ping - is there an ETA for the DFhack release, given that the DF release is expected very soon?

The documentation is I think basically done; https://dfhack.readthedocs.org works and pull #732 deals with all the remaining issues I could see.

Of the third-party scripts, Roses' and dscorbett's are disabled for this release, Lethosor's are IMO fine, and the others are one or two small scripts.  Standardizing and extracting common functionality is great, but at this point the real risk to compatibility is going so long without a release that everything changes!

For modders and users alike, it will be much easier to make the transition across DF versions if there has been a recent DFHack release - otherwise we have to cope with all the feature changes at the same time as the DF changes.

[lethosor]

I'm working on cleaning things up for one soon (I was hoping to do it today, but there are a couple more pull requests to get to).

I can't say I understand the argument for releasing before the next DF release, although I certainly want to - there's nothing preventing us from making a DFHack release before adding support for the new DF version after it's released. I also don't know how much modders will gain from having a DFHack release before the new DF release, given that many remain with the older DF version for a while.

[Jay]

I still don't plug the DF release before December, personally.

You're trying to keep backwards compatibility, so I don't really see the ground that the argument is trying to stand on.
If you had rewritten core parts of the application and broken existing scripts, sure, but...
The benefit isn't there to rush it, as far as I can see.

[PeridexisErrant]

I'm working on cleaning things up for one soon (I was hoping to do it today, but there are a couple more pull requests to get to).

• I can't say I understand the argument for releasing before the next DF release, although I certainly want to.
• There's nothing preventing us from making a DFHack release before adding support for the new DF version after it's released.
• I also don't know how much modders will gain from having a DFHack release before the new DF release, given that many remain with the older DF version for a while.

Awesome, that's sooner than I was expecting (and sorry for continuing to add more pulls!).

Given (2), the only reason for (1) is just that people are going to be more excited about migrating if it's unambiguously the newest and best thing around.  There is a potential trade-off between releasing features and updating for a new version, even if the reality is that it doesn't make much difference.

I'd like as much as possible of the long tail in (3) to be on DFHack r4 as possible, to maximise the ease of updates when they finally come due, and as above I think an earlier release would help with this.

[TheFlame52]

Some gm-editor questions:
1. Where are entity loyalties stored for a creature? Exact location please, I couldn't find it from someone else's instructions.
2. Where is state of matter stored in an object?

[lethosor]

I'd like to point out that nothing in gm-editor is specific to gm-editor - it's just a more friendly interface that shows exactly the same layout of structures that other tools use.
If by "state of matter" you mean solid/liquid/gas, those might be determined by checking the object's temperature against the states stored in its raws. (It's hard for me to check exact layouts at the moment, but I'll check soon.)

[Putnam]

Objects do not have a state of matter, states of matters are object. Most objects are solid, anything in a powder is POWDER_MISC, liquids are LIQUID_MISC or DRINK, globs/pastes/pressed things are GLOB and gasses AFAIK don't have an item at all.