Bay 12 Games Forum

Dwarf Fortress => DF Modding => Utilities and 3rd Party Applications => Topic started by: Roses on August 24, 2015, 08:39:56 am

Title: Roses' Script, System, and Utilities Collection (07/06/2021)
Post by: Roses on August 24, 2015, 08:39:56 am
https://github.com/Pheosics/roses_collection (https://github.com/Pheosics/roses_collection)
Use the master branch for the most recent stable version, and the devel branch for the most recent developments

UPDATE 07/06/2021
Fixed the {ATTRIBUTE} and {SKILL} shortcuts for the enhanced items. Now the attributes/skills are correctly increased/decreased when the item is equipped/unequipped

What is it
This is a collection of scripts, systems, and utilities that can be used with DFHack to modify the DF experience. The two main folders are Scripts (which include scripts and systems) and Utilities. All Utilities are built with Python 3+ and are run outside of the game. The scripts and systems are lua files that are run through DFHack. Scripts are run just like any other DFHack script and can be called from the command line or through any other method used to call the base DFHack scripts. Each script contains a help message which can be accessed by using script-name -help. The systems are called automatically behind the scenes and gather information through the raws (or in the case where there are no corresponding raws, such as the Class System, it uses a fake raw file).

Design philosophy
As many of you know, I have been around on this forum for awhile (over 11 years) and have created many scripts. Unfortunately they often became unusably complex as I added more and more to each script while still trying to maintain each scripts individuality. It eventually got to the point where even I had trouble running my own scripts and so I decided that a fresh start was needed. Instead of trying to make each script a stand alone download I have created a set of functions which act as the powerhouse behind the whole thing. These functions are made available through custom classes where appropriate, and through simple calls otherwise. Since each function serves a specific purpose they are relatively small and their use is shared across many different scripts. Additionally they can be called by other modders scripts if desired. Each script included in the collection (except for the intialization script) is also available to be called as a module through dfhack.reqscript, providing a simpler interface to the functions.

In addition to the scripts and their functions, there are the systems. Systems are a somewhat unique method through which a modder can change the way the game works, without worrying about writing their own scripts or getting the DFHack syntax correct. These also take advantage of the functions, but operate behind the scenes by reading the raw/objects files. Some of what the systems do can already be done with the existing modding tools (e.q. you can put "modtools/outside-only -building SCREW_PRESS -type OUTSIDE_ONLY" in the onLoad init file or you can put {OUTSIDE_ONLY} under the SCREW_PRESS in the building_custom.txt raw file), but other uses are not currently found in other scripts. The advantage to this method of scripting is that it allows modders who want to interface only with the raws the ability to use DFHack still.

How to use it

Update history
UPDATE 10/13/2020
Added Reactions to the Enhanced System. More detail is on the third post

UPDATE 04/06/2020
Massive revamp of all scripts, functions, and systems. See next two posts for included scripts and systems. Utilities are not currently up to date and should not be used. More information coming soon.
Title: Re: Roses' Script, System, and Utilities Collection
Post by: Roses on August 24, 2015, 08:40:24 am
Current Scripts
unit Scripts
Spoiler: unit/attack (click to show/hide)
Spoiler: unit/butcher (click to show/hide)
Spoiler: unit/change-action (click to show/hide)
Spoiler: unit/change-attribute (click to show/hide)
Spoiler: unit/change-body (click to show/hide)
Spoiler: unit/change-personality (click to show/hide)
Spoiler: unit/change-skill (click to show/hide)
Spoiler: unit/propel (click to show/hide)
item Scripts
Spoiler: item/change-material (click to show/hide)
Spoiler: item/change-quality (click to show/hide)
Spoiler: item/change-subtype (click to show/hide)
Spoiler: item/create (click to show/hide)
Spoiler: item/destroy (click to show/hide)
Spoiler: item/projectile (click to show/hide)
entity Scripts
Spoiler: entity/change-resource (click to show/hide)
building Scripts
Spoiler: building/change-subtype (click to show/hide)
Spoiler: building/create (click to show/hide)
map Scripts
Spoiler: map/spawn-flow (click to show/hide)
Spoiler: map/spawn-liquid (click to show/hide)
Title: Re: Roses' Script, System, and Utilities Collection v0.0
Post by: Roses on August 24, 2015, 08:42:22 am
Current Systems
Enhanced System
Purpose: The Enhanced System takes the raws as they are now and adds new token options to them. These additional tokens are declared in curly brackets {} and so are not read by DF itself, but instead by the system.
System Modules: Enhanced Buildings, Enhanced Items, Enhanced Reactions
enhancedBuildings
Raw File Type: Building
Eventful Functions: Custom Events: Accepted Tokens: (in no particular order yet)
Simple Examples:
   [BUILDING_WORKSHOP:FOUNTAIN]
      [NAME:Fountain]
      {DESCRIPTION:A building that continually produces mist}
      ... DF Building Stuff ...
      {REQUIRED_WATER:4}
      {ON_FINISH}
         {REPEATING_SCRIPT:map/spawn-flow -pos [ BUILDING_LOCATION ] -type Mist -density 100:25}
      
   [BUILDING_WORKSHOP:COMPLEX_BUILDING]
      [NAME:Complex Building]
      {DESCRIPTION:A complex building that takes a long time to build}
      ... DF Building Stuff ...
      {CONSTRUCTION_TIME:MECHANICS:1000:10:1} Base construction time is 1000 ticks, lowers by 10 for each skill level, max build speed is 1
      
   [BUILDING_WORKSHOP:WINDMILL]
      [NAME:Windmill]
      {DESCRIPTION:A building that can only be built outside and makes power}
      ... DF Building Stuff ...
      {OUTSIDE_ONLY}
      {MECHANICAL}
         {AUTO_GEARS}
         {POWER_PRODUCED:25}
enhancedItems
Raw File Type: Item
Eventful Functions: Custom Events: Accepted Tokens: (in no particular order yet)
Simple Examples:
   [ITEM_SHIELD:ITEM_SHIELD_EXAMPLE]
      [NAME:Example Shield]
      {DESCRIPTION:Knocks enemy backwards half the time when you block}
      ... DF Item Stuff ...
      {ON_BLOCK}
         {SCRIPT:unit/propel -unit OPPONENT -source BLOCKER -velocity [ 50 50 0 ] -mode Relative:50}

   [ITEM_WEAPON:RAPID_FIRE_CROSSBOW]
      [NAME:Fast Shooting Crossbow]
      {DESCRIPTION:Shoots bolts very fast}
      ... DF Item Stuff ...
      {FIRE_RATE:10:2:1} -- Base fire rate is 10, increases by 2 for each skill level, max shot speed is 1

   [ITEM_WEAPON:BLOOD_SWORD]
      [NAME:Blood Sword]
      {DESCRIPTION:Drains blood from opponent when wounded}
      ... DF Item Stuff ...
      {ON_WOUND}
         {SCRIPT:unit/change-body -unit OPPONENT -blood \-10:100}
         {SCRIPT:unit/change-body -unit HOLDER -blood 10:100}
enhancedReactions
Raw File Type: Reaction
Eventful Functions: Custom Events: Accepted Tokens: (in no particular order yet)
Simple Examples:
   [REACTION:MAKE_WAX_CRAFTS]
      {REACTION_TIME:WAX_WORKING:1:1:1}
      {PRODUCT:100:7:LIQUID:WATER:NONE:NONE}
      {PRODUCT:100:150:FLOW:MATERIALDUST:INORGANIC:SLADE}
      {ON_QUEUE} -- Triggers when the reaction is queued
         {SCRIPT:devel/print-args ON_QUEUE REACTION_NAME WORKER_ID BUILDING_ID [ LOCATION ]:100}
      {ON_START} -- Triggers after the ingredients are gathered
         {SCRIPT:devel/print-args ON_START REACTION_NAME WORKER_ID BUILDING_ID [ LOCATION ]:100}
      {ON_FINISH} -- Triggers when the reaction is finished, no product needed
         {SCRIPT:devel/print-args ON_FINISH REACTION_NAME WORKER_ID BUILDING_ID [ LOCATION ]:100}
      {ON_PRODUCT} -- Triggers when the reaction is finished and a product is produced
         {SCRIPT:devel/print-args ON_PRODUCT REACTION_NAME WORKER_ID BUILDING_ID [ LOCATION ]:100}
      [NAME:make wax crafts]
      [BUILDING:CRAFTSMAN:CUSTOM_SHIFT_W]
      [REAGENT:wax:150:GLOB:NONE:NONE:NONE]
      [REACTION_CLASS:WAX]
      [PRODUCT:100:1:CRAFTS:NONE:GET_MATERIAL_FROM_REAGENT:wax:NONE]
      [SKILL:WAX_WORKING]
Title: Re: Roses' Script, System, and Utilities Collection v0.0
Post by: Roses on August 24, 2015, 03:52:55 pm
Current Utilities (WIP)
Title: Re: Roses' Script, System, and Utilities Collection v0.0
Post by: Meph on August 24, 2015, 04:09:52 pm
Quote from: Roses on August 24, 2015, 03:52:55 pm
Questions about the wrapper script.

1. Does anyone other than myself use the 'wrapper' script?
2. If so, what are your opinions on how the system currently works? There are a couple options to try and improve usability. (For instance instead of having to do -profession required:CARPENTER or -profession immune:MASON I could make a separate rprofession and iprofession).
3. I would like to add more features (including checking for body parts, inventory items, etc...). But I am wondering when it becomes too much. I unfortunately can't think of a better way to allow more custom targeting options.
4. Upper or lowercase? That is to say, currently if you want to require a target to have at least 2000 strength you would say -physical min:STRENGTH:2000. Should that instead be MIN:STRENGTH:2000? Something else entirely?
5. Any other suggestions?
1. I wanted to, but you changed syntax a lot, kept working on it, and then I went away on tour.
2. None yet.
3. Wait till someone requests it? It's complex enough as is; I think.
4. Dont care if low/upper case, just keep it consistent.
5. Probably later. ;)
Title: Re: Roses' Script, System, and Utilities Collection v0.0
Post by: Isngrim on August 24, 2015, 08:25:53 pm
Quote from: Roses on August 24, 2015, 03:52:55 pm
Questions about the wrapper script.

1. Does anyone other than myself use the 'wrapper' script?
2. If so, what are your opinions on how the system currently works? There are a couple options to try and improve usability. (For instance instead of having to do -profession required:CARPENTER or -profession immune:MASON I could make a separate rprofession and iprofession).
3. I would like to add more features (including checking for body parts, inventory items, etc...). But I am wondering when it becomes too much. I unfortunately can't think of a better way to allow more custom targeting options.
4. Upper or lowercase? That is to say, currently if you want to require a target to have at least 2000 strength you would say -physical min:STRENGTH:2000. Should that instead be MIN:STRENGTH:2000? Something else entirely?
5. Any other suggestions?

1: I'm trying to, but the new structuring for using the scripts for modding is throwing me through a loop. Edit* as is my grammar
2: as far as I can tell its great,though i do like the iprofession/rprofession
3, 4, and  5 : I'd have to agree with Meph
Title: Re: Roses' Script, System, and Utilities Collection v0.0
Post by: expwnent on August 24, 2015, 10:29:20 pm
Posting to watch.

Have you switched the !BLAH system over to the \\BLAH system to make it more uniform with modtools stuff?
Title: Re: Roses' Script, System, and Utilities Collection v0.0
Post by: Roses on August 25, 2015, 11:55:33 am
Quote from: expwnent on August 24, 2015, 10:29:20 pm
Posting to watch.

Have you switched the !BLAH system over to the \\BLAH system to make it more uniform with modtools stuff?

Yes, I did have a question about that though, and more specifically about the entire utils.processArgs thing. A couple questions actually;

1. Is processArgs recursive? What I mean is when using something like modtools/interaction-trigger does it read through everything in the -command argument? Or does it just lump it all into one thing?
2. Similarly, if I can't use the same \\BLAH that the other modtools things use correct? Because it would be overwritten?
3. Should it always be two \? Is there ever a time you would only use one \?

EDIT: Thanks for the feedback. My current plan is to rewrite the wrapper script to make it more intelligeble for people who want to see what is going on, and to make it easily addable to in the future. The rewrite shouldn't change the syntax from what it was before, and I am actually going to allow for both upper or lower case (since that is super easy to do). I am currently planning on breaking -profession, -noble, and -entity into a required and immune section (from #2 in the previous post)
Title: Re: Roses' Script, System, and Utilities Collection v0.0
Post by: Meph on August 25, 2015, 12:00:04 pm
Quote
EnchancedItems - similar to EnchancedCreatures, except for items. Will also display an items history.
I've seen a script like this flying around, but it was never finished.
Title: Re: Roses' Script, System, and Utilities Collection v0.0
Post by: Roses on August 25, 2015, 12:01:49 pm
Quote from: Meph on August 25, 2015, 12:00:04 pm
Quote
EnchancedItems - similar to EnchancedCreatures, except for items. Will also display an items history.
I've seen a script like this flying around, but it was never finished.

Yes, I've seen one too, except I am planning on doing more advanced things (like sharpness increasing the more units the item kills, etc...)
Title: Re: Roses' Script, System, and Utilities Collection v0.0
Post by: Meph on August 25, 2015, 12:34:02 pm
Call me boring, but shouldnt the sharpness decrease, the more the weapon is used? (except on magical weapons)
Title: Re: Roses' Script, System, and Utilities Collection v0.0
Post by: Roses on August 25, 2015, 12:45:08 pm
Quote from: Meph on August 25, 2015, 12:34:02 pm
Call me boring, but shouldnt the sharpness decrease, the more the weapon is used? (except on magical weapons)

Yes, and that would be possible too, but I was thinking more for magical weapons and such. Basically just to give items more flavor and options all around.
Title: Re: Roses' Script, System, and Utilities Collection v0.0
Post by: Meph on August 25, 2015, 01:15:22 pm
Can you give artefacts some random effects? For example a file with X effects that are user-defined, and any artefact created in dwarf mode gets a random one from the list?

But I probably should not make suggestions at this point, seeing how full (and unfinished) your todo list is.
Title: Re: Roses' Script, System, and Utilities Collection v0.0
Post by: Roses on August 25, 2015, 01:59:09 pm
Hahaha, yeah that todo list is just staring at me. Wish I could just take a month break from real life and get everything done. But, actually, yes, that was one of the plans. The actual DFHack part of it all is rather simple, but it's going to be figuring out how to make it module and customizable that is more difficult.
Title: Re: Roses' Script, System, and Utilities Collection v0.0
Post by: Max™ on August 25, 2015, 04:03:15 pm
That artifact idea is why I left the artifact critical script just artifacts rather than all attacks.
Title: Re: Roses' Script, System, and Utilities Collection v0.0
Post by: Roses on August 26, 2015, 12:16:18 am
So I have been going through my old scripts to make sure that they all work and everything with the new system and I realized that there are a couple options that are currently missing. The primary being a "dispel" option.

For example,  What I mean is that it's currently easy to add or remove a syndrome which changes a units attribute. But what if you use the script attribute-change to alter the attribute directly? Well then there is currently no way to know how a dispel function would remove that increase. So I am thinking of implementing something using the persistent storage. Right now there is already a duration option in my scripts for resetting stuff like this, but there isn't an override. So it might delay me by a couple days adding this override.

A couple question for expwnent regarding persistent storage;

1. Is there much of an overhead on the storage? My scripts are starting to add a lot to it. Especially the class system and such.
2. Should I continue to prefix all of my tables? For instance, currently everything of mine is persistTable.GlobalTable.roses.blah
3. You once mentioned that I should move from unit id's to historical id's. If a unit leaves the map and comes back to they get assigned a new unit id? I'm hesitant about using historical id's because not all creatures have a historical Id.
Title: Re: Roses' Script, System, and Utilities Collection v0.0
Post by: Isngrim on August 26, 2015, 03:00:56 pm
will EnchancedItems be able to change the items subtype after a certain number of kills as well?
Title: Re: Roses' Script, System, and Utilities Collection v0.0
Post by: expwnent on August 28, 2015, 05:52:03 am
Quote from: Roses on August 25, 2015, 11:55:33 am
Quote from: expwnent on August 24, 2015, 10:29:20 pm
Posting to watch.

Have you switched the !BLAH system over to the \\BLAH system to make it more uniform with modtools stuff?

Yes, I did have a question about that though, and more specifically about the entire utils.processArgs thing. A couple questions actually;

1. Is processArgs recursive? What I mean is when using something like modtools/interaction-trigger does it read through everything in the -command argument? Or does it just lump it all into one thing?
2. Similarly, if I can't use the same \\BLAH that the other modtools things use correct? Because it would be overwritten?
3. Should it always be two \? Is there ever a time you would only use one \?

EDIT: Thanks for the feedback. My current plan is to rewrite the wrapper script to make it more intelligeble for people who want to see what is going on, and to make it easily addable to in the future. The rewrite shouldn't change the syntax from what it was before, and I am actually going to allow for both upper or lower case (since that is super easy to do). I am currently planning on breaking -profession, -noble, and -entity into a required and immune section (from #2 in the previous post)


script1 -arg1 \\THINGAMABOB -arg2 \\\BLAH

processArgs strips off one backslash, then script1 strips off one more so that you can pass special arguments to script1, and you can also pass arguments to script1 that it forwards to script2 as a special argument of script2 using 3 backslashes (one for processArgs, one for script1, and one for script2).

That felt like a confusing explanation so let me know if you have any questions. It should be possible to arbitrarily layer scripts using backslashes. Maybe try looking up "escape sequences" online. That's what they're for.

You also need two backslashes in strings in Lua because Lua strips off one for escape sequences. "\\" -> \, "\\\\" -> \\, etc.

1. Overhead on storage: I think it's a few hundred bytes per "node". Not massive but not tiny either.

2. Prefixing just ensures that nobody else's persistent storage conflicts with yours. Recommended for forward compatibility in case someone else wants to do persistent storage with tables with the same names.

3. I remember saying that but I'm not sure anymore. I don't know if returning units get their old unit ids back. It's a rare event so it's hard to test. Even representatives from the mountainhomes tend to be different every year.
Title: Re: Roses' Script, System, and Utilities Collection v0.0
Post by: Roses on September 01, 2015, 07:57:10 pm
Well I found a way to successfully implement a dispel type system, the only issue is that is adds quite a bit more entries into persistent storage. I will have to do some tests to see how much space they are taking up now. I use it for a crap ton of things.

EDIT: Here is a question, in updating my scripts I noticed I used a lot of things like -radius x,y,z and -offset x,y,z. These were used because I just did a direct translation from the previous system of using SYN_CLASSes. But I could change them to -radius [ x y z ]. So the question is, which one is preferred?

Code: [Select]
-radius x,y,zor
Code: [Select]
-radius [ x y z ]
Title: Re: Roses' Script, System, and Utilities Collection v0.0
Post by: Max™ on September 01, 2015, 10:36:37 pm
I'm used to things like tiletypes and liquids does with range 8 2 1 so I kinda like the second one myself.
Title: Re: Roses' Script, System, and Utilities Collection v0.0
Post by: Askot Bokbondeler on September 01, 2015, 11:57:49 pm
ptw
Title: Re: Roses' Script, System, and Utilities Collection v0.0
Post by: expwnent on September 02, 2015, 08:13:22 am
Quote from: Roses on September 01, 2015, 07:57:10 pm
Well I found a way to successfully implement a dispel type system, the only issue is that is adds quite a bit more entries into persistent storage. I will have to do some tests to see how much space they are taking up now. I use it for a crap ton of things.

EDIT: Here is a question, in updating my scripts I noticed I used a lot of things like -radius x,y,z and -offset x,y,z. These were used because I just did a direct translation from the previous system of using SYN_CLASSes. But I could change them to -radius [ x y z ]. So the question is, which one is preferred?

Code: [Select]
-radius x,y,zor
Code: [Select]
-radius [ x y z ]

The second one is slightly better. It requires less string processing for the script. x = args.radius[1], etc. That was processArgs does all the processing you need for you.
Title: Re: Roses' Script, System, and Utilities Collection v0.0
Post by: Dirst on September 02, 2015, 03:03:25 pm
I'll throw in my vote with the second version as well.  It loads nicely into a single object that many DFHack methods seem to understand without further parsing.
Title: Re: Roses' Script, System, and Utilities Collection v0.0
Post by: expwnent on September 25, 2015, 06:19:39 pm
Roses: I've been integrating the script library into DFHack. What's the difference between the hack/scripts directory and the raw/scripts directory?
Title: Re: Roses' Script, System, and Utilities Collection v0.0
Post by: Rumrusher on September 27, 2015, 09:41:29 am
raw/scripts taps into raws so that they load in a script calling function for eventful or something like that, and the other is stand alone where someone can call on them by typing out their name.
Title: Re: Roses' Script, System, and Utilities Collection v0.0
Post by: Roses on September 27, 2015, 03:05:51 pm
Quote from: Rumrusher on September 27, 2015, 09:41:29 am
raw/scripts taps into raws so that they load in a script calling function for eventful or something like that, and the other is stand alone where someone can call on them by typing out their name.

That was my old way of thinking, but then I learned that even if you type out their name in the command line, it will still check raw/scripts first, so I began to move them all to there.

Quote from: expwnent on September 25, 2015, 06:19:39 pm
Roses: I've been integrating the script library into DFHack. What's the difference between the hack/scripts directory and the raw/scripts directory?

With what is uploaded now, the only difference is I hadn't finished migrating everything to raw/scripts

I saw you submitted a pull request, which I haven't had time to go through yet, but I will. The only problem is, and I am sorry if you spent a lot of time going through all the scripts, I have pretty much re-written all of the scripts, combining functionality of some, and over all moving to a new system. It doesn't affect the end user at all, but it opens up a lot more doors for me in the future, and allows other modders to more easily tap into my scripts. I am almost done with my changes and was planning on uploading the new versions soon. However, I can make sure to go through them all and remove trailing spaces if there are any in the new versions (I have fixed the tab issue in all the new ones). I can also write better documentation for all of them if you would like (it's something I have been wanting to do for awhile now).
Title: Re: Roses' Script, System, and Utilities Collection v0.0
Post by: expwnent on September 27, 2015, 04:17:35 pm
That all sounds good. Let me know when you're done.
Title: Re: Roses' Script, System, and Utilities Collection v0.0
Post by: Roses on September 30, 2015, 01:10:05 pm
I have finished updating my scripts, but now need to test them all to make sure they all work. I would also like to include more documentation with them (and some still don't have help sections). Hopefully in the next couple of days I will release the update.

Question, will the new DFHack version have any changes to syntax or anything that I should be aware of?
Title: Re: Roses' Script, System, and Utilities Collection v0.0
Post by: expwnent on September 30, 2015, 01:12:05 pm
I don't think so. The changes should be here. (https://github.com/DFHack/dfhack/blob/develop/NEWS)
Title: Re: Roses' Script, System, and Utilities Collection v0.0
Post by: Dirst on September 30, 2015, 01:16:31 pm
Quote from: expwnent on September 25, 2015, 06:19:39 pm
Roses: I've been integrating the script library into DFHack. What's the difference between the hack/scripts directory and the raw/scripts directory?
My understanding is that DFHack searches raw/scripts for a named script first then hack/scripts, to allow a mod to overload a specific script's name if desired for some reason.  Though I agree with the logic for this, in a specific case I wanted the exact opposite behavior (include a fallback with the mod but use the probably-more-up-to-date general version if it's installed) and there is no way to explicitly call hack/scripts.
Title: Re: Roses' Script, System, and Utilities Collection v0.0
Post by: expwnent on September 30, 2015, 01:24:48 pm
That's how it's supposed to work but I think I noticed a few scripts that were in both places so I was confused.

I'm not sure there's a simple way to extend the script finding system to do that. You might be able to do it manually by checking for the existence / modify date of hack/scripts/whatever and calling it if it's newer than data/save/adsf/raw/scripts/whatever.
Title: Re: Roses' Script, System, and Utilities Collection v0.0
Post by: Warmist on September 30, 2015, 02:04:21 pm
Quote from: expwnent on September 30, 2015, 01:24:48 pm
That's how it's supposed to work but I think I noticed a few scripts that were in both places so I was confused.

I'm not sure there's a simple way to extend the script finding system to do that. You might be able to do it manually by checking for the existence / modify date of hack/scripts/whatever and calling it if it's newer than data/save/adsf/raw/scripts/whatever.
Seriously: Stop abusing script systems!
What next? Hash each script and then distribute approved hashes??

Why such simple and elegant system needs to be "improved" until there is no logic on what gets to run?
Why do we need 20 places that run scripts?
</rant>
My opinion is that the problem is elsewhere: we need a way to update raw folders and/or scripts with more automation. E.g. i was using this to have light redirect in raws that gets called on load and the rest in the "mods" folder. That way mods can be updated and the saves will be automatically up-to-date. This however is not perfect: it lacks the raws updating functionality (e.g. automatically adding missing creatures and etc...)
Title: Re: Roses' Script, System, and Utilities Collection v0.0
Post by: Roses on October 01, 2015, 03:08:50 pm
Alright, so I figured I would explain my new script organization format before I upload them, just so people can know what to expect, and offer criticism/advice.

The basic idea behind the structure is that scripts that effect specific things should be in specific folders. In addition the different "systems", as I call them, each get their own folder. And finally there is a special folder (called functions) where I store different functions that are shared between multiple scripts, so that a simple script_environment call can be used instead of a copy/pasting them into multiple locations. This new use of "functions" means that almost all of my scripts are much shorter than they were previously, and, additionally, allows for easier creation of more scripts in the future. The current complete list of scripts and organization is;


I am, of course, open to criticism/discussion. At this point I am fine with changing things around if those in the know think it would be better, but after I put out this release I am really hoping to stick to a single convention for all future work.

I do have to decide where best to include "system" files. That is to say, if you want to use the class/civilization/event system you need a corresponding file classes.txt/civilizations.txt/events.txt. I suppose I could have the scripts check in multiple locations for each, but where should they check?
Title: Re: Roses' Script, System, and Utilities Collection v0.0
Post by: expwnent on October 01, 2015, 03:21:16 pm
That all looks good.

I would have it look in the raw/ folder of the current save to help promote savegame mobility.
Title: Re: Roses' Script, System, and Utilities Collection v0.0
Post by: Roses on October 01, 2015, 03:29:49 pm
Currently it actually looks in the raw/objects folder since I created the templates for the systems based on the raws themselves. I think I will continue checking there, but encourage people to place them separately so they can easily be accessed without searching through all the objects files.
Title: Re: Roses' Script, System, and Utilities Collection v0.0
Post by: expwnent on October 01, 2015, 03:33:12 pm
That makes sense.
Title: Re: Roses' Script, System, and Utilities Collection v0.0
Post by: Roses on October 06, 2015, 10:44:34 pm
So a release has been delayed by my discovery that flows (mist, web, dragonfire, fire, trailing dust, etc...) can be confined to a single square http://www.bay12forums.com/smf/index.php?topic=139553.msg6531964#msg6531964 (http://www.bay12forums.com/smf/index.php?topic=139553.msg6531964#msg6531964). There are a couple scripts that I have been rewriting to take advantage of this, and most significantly it has prompted me to rehaul the wrapper script, which will hopefully provide a more robust and complete system that is easy to use. I have almost finished all the adjustments and am now in testing mode.

Right now I am simply making sure that nothing is giving errors when run, then I will release a test run that lets others check (along with me) that the effects are actually happening.
Title: Re: Roses' Script, System, and Utilities Collection v0.0
Post by: expwnent on October 14, 2015, 11:23:53 pm
Any update?
Title: Re: Roses' Script, System, and Utilities Collection v0.0
Post by: Roses on October 17, 2015, 07:10:31 pm
Yes, sorry. I came down with the flu and am now desperately playing catch up with work. But I think that I should be pushing my release this week.

EDIT: So I just sort of made a breakthrough (nothing mind boggling, but substantial for my understanding of lua) in terms of string parsing. This allows for very complex equations which can be referenced in my wrapper script. When I finish coding this up you will be able to create an equation using any number of variables you want for both a target and source in an interaction to generate numbers. It seems a little complex in writing, but I will make sure to include a detailed walkthrough of how it works.
Title: Re: Roses' Script, System, and Utilities Collection v0.0
Post by: Roses on October 22, 2015, 05:59:16 pm
Ok, so I am nearing release and am now just working on some readme and help files. What information do people feel would be relevant and good to know in easy to look up files?
Title: Re: Roses' Script, System, and Utilities Collection v0.0
Post by: Deon on October 27, 2015, 06:39:24 am
Whatever you feel is the most complex stuff to understand without a readme :). I am sure we will be able to ask other questions in this thread. I can't wait to see the new release!
Title: Re: Roses' Script, System, and Utilities Collection v0.1 (10/27/2015)
Post by: Roses on October 27, 2015, 09:02:35 pm
Well, I have finally uploaded all of my changes. The original post has the link to the GitHub. Also included is a ReadMe that should answer most questions.

Now I did do a fair amount of testing, but I am guessing that there are still bugs buried here and there. So please let me know if there is anything you run across that errors out or just doesn't work.

For now I am working on finishing up my extensive examples for the three systems. I am almost done with them, but like usual I keep wanting to add to them.
Title: Re: Roses' Script, System, and Utilities Collection v0.1 (10/27/2015)
Post by: Max™ on October 27, 2015, 10:23:47 pm
That flow stuff looks fascinating, were I not in the middle of a bunch of GIMP-work I'd have to poke around with it more.
Title: Re: Roses' Script, System, and Utilities Collection v0.1 (10/27/2015)
Post by: Roses on October 28, 2015, 03:08:40 pm
Updated the first post so it is easier to see what scripts are included with the package. Will update to include information about the various systems once I finish my examples.
Title: Re: Roses' Script, System, and Utilities Collection v0.1 (10/27/2015)
Post by: Deon on October 31, 2015, 09:59:33 am
Script for item spawning with a duration is just what I needed for my conjuration workshop! I will be sure to use some of your scripts and give you a proper credit, thanks a lot for doing that!
Title: Re: Roses' Script, System, and Utilities Collection v0.1 (10/27/2015)
Post by: Deon on October 31, 2015, 10:00:51 am
Did you dig the structures responsible for souls? Is it possible now to transfer a soul from one unit to another?
Title: Re: Roses' Script, System, and Utilities Collection v0.1 (10/27/2015)
Post by: Roses on October 31, 2015, 04:27:49 pm
I haven't worked much with souls. It's on my list of things to look at, but IndigoFenix has done some good work with them. His post is here (http://www.bay12forums.com/smf/index.php?topic=147763.0).
Title: Re: Roses' Script, System, and Utilities Collection v0.1 (10/27/2015)
Post by: Roses on November 03, 2015, 05:50:22 pm
So here is an update on my progress. I currently have all 67 classes done, including class and leveling bonuses, attribute requirements, skills, and very rudimentary descriptions (I will work on those more over time). I have also added the ability for different races to have different names for the same class (just for some flavor). For instance, I don't think Squire and Knight works too well for Dwarfs, so there version is Hammerer and Legionnaire.

Now I need to work on the 700+ skills for the classes. I have been doing about 50 a day on average so it will still take me some time (I'm hoping to bust a bunch out this weekend). Unfortunately I am sure the numbers are unbalanced, but I am doing my best. Then there will be a testing phase of the skills, just to make sure they at least work and don't have any errors. Then I will release the class and spell files.

That's the current update.

Here is a list of current classes (without the name changes for different races)
Code: [Select]
Squire
Knight
Guardian
Fighter
Warrior
Slayer
Thief
Rogue
Stalker
Archer
Marksman
Sniper
Assassin
Warden
Gladiator
Ranger
Mage
Arch-Mage
Elementalist
Adept
Mystic
Arcanist
Cleric
Priest
Bishop
Necromancer
Occultist
Ovate
Druid
High Druid
Shaman
Sage
Geomancer
Disciple
Erudite
Psion
Rune Smith
Holy Mage
Archon
Earth Master
Artificer
Alchemist
Seer
Warlock
Oracle
Defiler
Keeper
Corrupter
Beast Master
Eldritch Knight
Arcane Warrior
Paladin
Death Knight
Monk
Warshaper
Avenger
Mind Blade
Berserker
Magic Arrow
Eldritch Shadow
Trickster
Spellslayer
Vigilante
Demon Hunter
Bard
Strider
Mind Hunter
Title: Re: Roses' Script, System, and Utilities Collection v0.1 (10/27/2015)
Post by: Max™ on November 03, 2015, 08:30:39 pm
I like the mix of D&D-feel and other sorts of games in there.
Title: Re: Roses' Script, System, and Utilities Collection v0.1 (10/27/2015)
Post by: Roses on November 03, 2015, 08:48:26 pm
Quote from: Max™ on November 03, 2015, 08:30:39 pm
I like the mix of D&D-feel and other sorts of games in there.

It's hard to come up with names for some of these classes. I know the roll I want each one to fill (in terms of skills and stats) but actually coming up with names is a huge pain.
Title: Re: Roses' Script, System, and Utilities Collection v0.1 (10/27/2015)
Post by: Max™ on November 03, 2015, 11:21:20 pm
It turned out neat, doesn't come across with the generic feel you get in a lot of class systems.
Title: Re: Roses' Script, System, and Utilities Collection v0.1 (10/27/2015)
Post by: Roses on January 04, 2016, 02:18:25 pm
Sorry for the lack of updates, I have been busy preparing my thesis and job hunting. But when I have had the time I have still been working on this project. Earlier I had posted a list of the classes I have been working on, and now here is a list of spells I have made for the magic classes (abilities for the physical classes are still being worked on). Note that there are ~600 spells, with about 500 of them working correctly. The next step is testing out numbers. I am translating this all from a D&D-esque game a made, so I know how strong I want each spell to be, but it's not a 1-1 match to DF obviously, so right now I have weak spells that are better than strong spells, and other oddities. When I am ready for general testing and feedback I will post all the necessary files.

Code: [Select]
Arcane Shield
Arcane Weapon
Magic Shell
Protection from Melee
Protection from Range
Airward
Arcane Armor
Earthward
Fireward
Iceward
Metalward
Smokeward
Stormward
Waterward
Arcane Fortification
Arcane Wall
Arcaneward
Divineward
Elementalward
Mentalward
Natureward
Resist Magic
Weapon Immunity
Impenetrable Barrier
Magic Immunity
Arcane Missile
Arcane Surge
Attract
Hold
Repel
Arcane Blast
Arcane Burst
Arcane Explosion
Arcane Fury
Arcane Spear
Arcane Volley
Bend Light
Flip Gravity
Gravity
Levitate
Repulse
Arcane Eruption
Arcane Orb
Crush
Element
Pulsar
Quasar
Shock Wave
Blackhole
Supernova
Disengage
Distort Space
Enlarge
Shrink
Vertigo
Alter Reality
Bend Space
Disenchant
Displace
Limbo
Passwall
Portal
Recall Hero
Summon Familiar
Arcane Elemental
Counter Magic
Displacement Field
Magic Vortex
Tear Space
Unsummon
Void
Warp Reality
Wormhole
Arcane Gate
Bind Elemental
Accelerate Healing
Aging Touch
Blink
Haste
Slow
Youth
Accelerate Syndrome
Age Armor
Age Item
Age Weapon
Aging Breath
Delay Syndrome
Distort Time
Mass Haste
Mass Slow
Teleport
Eternal Youth
Reverse Time
Stop
Time Bubble
Time Stop
Warp
Predict Future
Quick
Reflect
Agony
Curse
Dark
Dark Gaze
Dark Sword
Harm
Bind Undead
Bone Armor
Contagion
Corpse Explosion
Creeping Dark
Death Knell
Drain Life
Enfeeble
Nightmare
Pray
Raise Dead
Bind Demon
Create Undead
Dark Pact
Death Word
Desecrate
Divine Blessing
Enthrall
Necrosis
Shackle
Summon Fiend
Death
Vampirism
Bless
Heal
Holy Weapon
Light
Smite
Ward
Barrier
Blinding Light
Cleanse
Consecrate
Fortify
Holy Armor
Holy Aura
Pray
Regenerate
Renew
Turn Undead
Dispel
Divine Blessing
Esuna
Greater Heal
Holy Word
Mass Heal
Rejuvenate
Sanctify Chaos
Sanctify Undead
Serephic Ally
Holy
Resurrect
Blur
Shadow
Shadow Blade
Shadow Bolt
Shadow Walk
Atone
Darkness
Daylight
Greater Shadow
Shadow Armor
Shadow Decoy
Shadow Steed
Shadowsight
Sleep
Vanish
Vengeance
Grand Shadow
Moonlight
Re-Raise
Sacrifice
Sanctuary
Shade
Shadow Beast
Divine Power
Eternal Shade
Repulse
Void Blade
Void Bolt
Void Sphere
Void Walk
Void Ward
Demi
Destruction
Drain
Hold
Soul Bind
Siphon
Void Armor
Void Barrier
Void Blast
Abyss
Banish
Darkward
Lightward
Scourge
Ultima
Void Beast
Void Storm
Doom
Omega
Air Bubble
Air Dart
Blind
Rushing Wind
Whipping Wind
Binding Winds
Gust
Harden Air
Pressing Air
Ventilate
Wind Blast
Wind Shield
Wind Walk
Air Elemental
Burst of Wind
Deflecting Winds
Displace
Howling Wind
Suffocate
Tempest
Vacuum
Wall of Air
Cyclone
Flight
Tornado
Bind
Earthen Ward
Harden
Stone Daggers
Stone Fist
Stone Weapon
Boulder
Earth Armor
Grasping Earth
Seismic Wave
Stalactite
Stalagmite
Stoneskin
Earth Elemental
Earthen Bulwark
Petrify
Sand Storm
Stone Aegis
Sunder Earth
Wall of Stone
Disintegrate
Earthquake
Rockslide
Shelter
Stone Form
Burn
Fire Dart
Flame Weapon
Scorch
Burning Hands
Combust
Fire Armor
Fire Jet
Flame Blast
Flame Strike
Flame Tongue
Ignite
Scorching Ray
Blaze
Conflagration
Fire Ball
Fire Elemental
Flaming Sphere
Incinerate
Wall of Fire
Dragon Breath
Flare
Inferno
Meteor Storm
Cone of Cold
Frostbite
Ice Darts
Ice Weapon
Slowing Ice
Chains of Ice
Cold Snap
Frostburn
Ice Armor
Ice Lash
Ice Spike
Ray of Frost
Arctic Wind
Freeze
Ice Barrier
Ice Elemental
Iceball
Orb of Cold
Polar Ray
Wall of Ice
Arctic Tempest
Avalanche
Blizzard
Frost Nova
Keen Edge
Magic Sword
Metal Shards
Metal Skin
Temper
Animate Armor
Animate Weapon
Armor Break
Metal Fist
Mighty Guard
Repair Metal
Rust Armor
Rust Weapon
Weaken Armor
Weaken Weapon
Weapon Break
Blade Barrier
Chill Metal
Diamond Shell
Heat Metal
Metal Elemental
Molten Spray
Disintegrate Equipment
Quicken
Shatter
Fog Walk
Smog
Smoke Dart
Smoke Screen
Steam Blast
Stinking Cloud
Choke
Cloak of Smoke
Evaporate
Haze
Jet of Steam
Miasma
Mind Fog
Obscure
Poison Mist
Steam Cloud
Acid Fog
Caustic Smoke
Crushing Fog
Fog Cloud
Smoke Elemental
Smoke Terror
Bewildering Fog
Cloud Kill
Incendiary Cloud
Charge
Flash
Lightning Bolt
Shock
Shocking Touch
Spark
Storm Weapon
Disorient
Lightning
Lightning Spear
Lightning Stab
Storm Armor
Super Charge
Thunder Clap
Ball Lightning
Call Lightning
Chain Lightning
Drain Energy
Infuse
Paralyze
Storm Elemental
Thunderbolt
Lightning Shield
Lightning Storm
Storm Cloud
Clean
Healing Stream
Soak
Surge
Water Bolt
Cleansing Rain
Create Water
Cure Infection
Dehydrate
Extinguish
Hydrate
Tidal Wave
Water Orb
Drown
Healing Mist
Torrent
Typhoon
Wall of Water
Water Elemental
Water Shell
Water Spout
Waterfall
Flood
Maelstrom
Rushing Water
Apathy
Bliss
Calm
Fear
Grief
Hate
Courage
Drain Emotion
Fury
Gloom
Pleasure
Pride
Sadness
Terror
Break
Charm
Depression
Ecstasy
Enrage
Horror
Lust
Vigilance
Despair
Dominate
Tranquility
Decoy
Ghost Sound
Mental Blades
Phantom Dart
Sound Burst
Apparition
Blur
Delusion
Disguise
Hypnotic Pattern
Phantom Spear
Phantom Trap
Simulacrum
True Sight
Color Spray
Death Vision
Destroy Illusion
Illusory Wall
Invisibility
Mass Blur
Mirror Image
Phantom Warriors
Copy Self
Mass Invisibility
Phantom Beast
Blind
Deafen
Mind Slash
Psi Blades
Psionic Bolt
Turmoil
Disable
Empty Mind
Hold Mind
Jumble Mind
Mind Flay
Mind Leech
Psionic Blast
Psionic Gift
Share Mind
Telekinesis
Hive Mind
Mental Duel
Mind Trap
Shatter Mind
Silence
Steal Mind
Mind Rot
Mind Storm
Stop Mind
Blank
Craze
Daze
Strengthen Will
Thought Lash
Bend Will
Confusion
Guard Thoughts
Hysteria
Read Thoughts
Scour
Sleep
Steel Will
Stun
Thought Eater
Dementia
Devour Thoughts
Drain Will
Greater Stun
Mass Confusion
Thought Prison
Torment
Break Will
Deep Sleep
Insanity
Animal Agility
Animal Endurance
Animal Strength
Animal Toughness
Animal Bane
Animal Ferocity
Animal Physicality
Calm Animals
Charm Animal
Empower Animal
Envenom
Magic Fang
Mend Animal
Purge Animal
Companion
Enrage Animals
Frenzy
Greater Mending
Recall Companion
Savage Maw
Share Soul
Summon Animal
Summon Swarm
Animal Form
Revive Companion
Geomancy
Soften Earth
Stone Spikes
Burrow
Change Terrain
Earth Bind
Geostrike
Pitfall
Stoneskin
Tremor
Call Earth
Cleanse Land
Corrupt Land
Cracks Call
Hungering Earth
Move Earth
Stone Form
Earth Gate
Cure
Natures Eye
Neutralize Poison
Tree Stride
Warp Wood
Antidote
Barkskin
Cloak of Petals
Entangle
Poison
Restoration
Rot
Awaken Trees
Command Plants
Degenerate
Grow Plants
Ironwood
Natures Wrath
Regenerate
Summon Shambler
Toxin
Wall of Thorns
Blight
Create Guardian
Steeloak
Guardian Spirit
Spirit Walk
Spirit Weapon
Strength of Spirits
Ancestral Armor
Awaken
Calm Spirit
Commune with Spirits
Faerie Fire
Heal
Life Link
Spirit Wave
Totem
Bind Spirit
Call Ancestors
Chain Heal
Cleanse Spirits
Meditate
Spirit Drain
Spirit Link
Spirit Shriek
Spirit Tear
Summon Spirit
Reincarnate
Spirit Form

Also note that there are 5 spheres of magic in my game; Arcane, Divine, Elemental, Mental, and Nature. And each sphere has different schools (e.g. Fire is a school in Elemental, Time is a school in Arcane). None of this, however, is necessary for use in other mods or in DF itself (when I actually finally make my mod based on the game world it will be a large part of it, but that will be in the mods thread, and won't be for awhile I am afraid)
Title: Re: Roses' Script, System, and Utilities Collection v0.1 (10/27/2015)
Post by: Putnam on January 11, 2016, 12:18:55 am
Quote
spells[spell] = spell

spells is undefined, line 445 of functions/tables.lua

it's defined 2 lines later

functions/unit.lua, function changeSkill, utils is used but never actually defined

tonumber(spellTable.RequiredLevel) <= currentClassLevel in functions/class.lua function changeClass gives me a compare-string-to-number error; should probably put currentClassLevel in a tonumber as well

persistTable.GlobalTable.roses.SpellTable is never defined

i'll probably try to set up the newest version of fortbent as a testbed for the class system... especially since i'm not altogether aware of any other mods using it

EDIT: Why am i posting here, i'll make a pull request once i get the class system working
Title: Re: Roses' Script, System, and Utilities Collection v0.1 (10/27/2015)
Post by: Roses on January 11, 2016, 04:38:46 pm
Quote from: Putnam on January 11, 2016, 12:18:55 am
Quote
spells[spell] = spell

spells is undefined, line 445 of functions/tables.lua

it's defined 2 lines later

functions/unit.lua, function changeSkill, utils is used but never actually defined

tonumber(spellTable.RequiredLevel) <= currentClassLevel in functions/class.lua function changeClass gives me a compare-string-to-number error; should probably put currentClassLevel in a tonumber as well

persistTable.GlobalTable.roses.SpellTable is never defined

i'll probably try to set up the newest version of fortbent as a testbed for the class system... especially since i'm not altogether aware of any other mods using it

EDIT: Why am i posting here, i'll make a pull request once i get the class system working

Thank you for your work and the pull request. And as far as I know you are the only one that currently uses it. Pull request merged.
Title: Re: Roses' Script, System, and Utilities Collection v0.1 (10/27/2015)
Post by: Putnam on January 11, 2016, 11:42:59 pm
I think the assumptions that the EntityTable is based on are entirely wrong as of 0.42.04, since I can't seem to get it to work no matter what I do. Trying to fix it doesn't seem like a good idea, since I don't know what it's trying to do.
Title: Re: Roses' Script, System, and Utilities Collection v0.1 (10/27/2015)
Post by: Roses on January 12, 2016, 04:17:15 pm
Quote from: Putnam on January 11, 2016, 11:42:59 pm
I think the assumptions that the EntityTable is based on are entirely wrong as of 0.42.04, since I can't seem to get it to work no matter what I do. Trying to fix it doesn't seem like a good idea, since I don't know what it's trying to do.

Interesting, I was wondering if all the changes made would cause trouble with that. For now I suggest just disabling it. I actually haven't looked at the new version at all yet, so I should sit down and go over everything that has changed in both DF and DFHack.
Title: Re: Roses' Script, System, and Utilities Collection v0.1 (10/27/2015)
Post by: Dirst on January 13, 2016, 04:58:03 pm
I know that most of your effort is going toward updating, but have you made any progress on add-attack (or attack-add as it's called in the OP)?  That way I won't need to worry about creatures biting with their tails :)
Title: Re: Roses' Script, System, and Utilities Collection v0.1 (10/27/2015)
Post by: Roses on January 14, 2016, 12:39:38 pm
Quote from: Dirst on January 13, 2016, 04:58:03 pm
I know that most of your effort is going toward updating, but have you made any progress on add-attack (or attack-add as it's called in the OP)?  That way I won't need to worry about creatures biting with their tails :)

I have made some progress with that, but haven't fixed that exact bug yet. But that is on the list.
Title: Re: Roses' Script, System, and Utilities Collection v0.1 (10/27/2015)
Post by: Dirst on January 14, 2016, 12:47:36 pm
Quote from: Roses on January 14, 2016, 12:39:38 pm
Quote from: Dirst on January 13, 2016, 04:58:03 pm
I know that most of your effort is going toward updating, but have you made any progress on add-attack (or attack-add as it's called in the OP)?  That way I won't need to worry about creatures biting with their tails :)

I have made some progress with that, but haven't fixed that exact bug yet. But that is on the list.
Appreciated... the bigger issue is making sure that the creatures get into a proper fight, but even just the one valid attack makes my mod much better than it was before you told me about this script.
Title: Re: Roses' Script, System, and Utilities Collection v0.1 (10/27/2015)
Post by: Roses on January 25, 2016, 06:52:57 pm
Quote from: Dirst on January 14, 2016, 12:47:36 pm
Quote from: Roses on January 14, 2016, 12:39:38 pm
Quote from: Dirst on January 13, 2016, 04:58:03 pm
I know that most of your effort is going toward updating, but have you made any progress on add-attack (or attack-add as it's called in the OP)?  That way I won't need to worry about creatures biting with their tails :)

I have made some progress with that, but haven't fixed that exact bug yet. But that is on the list.
Appreciated... the bigger issue is making sure that the creatures get into a proper fight, but even just the one valid attack makes my mod much better than it was before you told me about this script.

So I am going to fix this issue this week and came up with a couple different solutions.

1. Add another token you can call, something like -attack BITE, it will then look at the attacking unit and see if it has a declared BITE attack, and if so use that attack (regardless of what body part you declared the attack with).

2. Look at what body part you declared, then look at the unit and see if it has an attack associated with the body part, then use that one.

3. A combination of the above, where if -attack isn't declared it looks at the body part, and if it is it ignores the body part.

2 and 3 are definitely the most work, but maybe are the best moving forward. The question for all three becomes, what if the unit doesn't have the desired attack. Does the script just not add an attack? Or does it pick a random attack the unit does have? Thoughts?
Title: Re: Roses' Script, System, and Utilities Collection v0.1 (10/27/2015)
Post by: Dirst on January 25, 2016, 08:36:03 pm
First, it should be able to pick an attack and bodypart at random so you can just sic one unit on another.  Main attacks are 100x more likely than secondary iirc.  Just need to handle the case of disabled attacks (no teeth = no BITE, only checked if the BITE was rolled), where you drop that attack from contention and roll again, ultimately defaulting to a PUSH attack.  I hope that isn't too much work.

Then, a -strict flag can direct "use the parameters I gave if valid, otherwise do nothing."  Without that tag, a bad suggestion defaults to the above random attack.

Maybe a -force flag as well just in case you really did want to BITE with the TAIL for the giggles.
Title: Re: Roses' Script, System, and Utilities Collection v0.1 (10/27/2015)
Post by: expwnent on January 26, 2016, 02:28:23 am
I find that loud error messages by default are a better policy than guessing at what the calling script meant. It helps debugging.
Title: Re: Roses' Script, System, and Utilities Collection v0.1 (10/27/2015)
Post by: Dirst on January 26, 2016, 08:18:16 am
Quote from: expwnent on January 26, 2016, 02:28:23 am
I find that loud error messages by default are a better policy than guessing at what the calling script meant. It helps debugging.
In that case, make it pick a random attack only when told to do so, perhaps a -random flag.  If -random is present with an explicit directive, it fills in the parameters not specified by the calling script.  For example, a SCRATCH attack with didn't specify a particular limb.
Title: Re: Roses' Script, System, and Utilities Collection v0.1 (10/27/2015)
Post by: Roses on January 26, 2016, 01:25:46 pm
Hmmm. Choices, choices, choices.

How about this;

Start off with a simple script, just
Code: [Select]
unit/attack -attacker \\UNIT_ID -defender \\UNIT_ID
This will make the attacking unit attack the defending unit, picking the attack at random (weighted to pick a main attack over a secondary) and picking the body part target at random (with weights based off body part size). So that it functions as similar to the in-game attack decision as possible.

Then you start adding options. Things like
Code: [Select]
-target BP_CATEGORY (body part to target e.g. -target UPPERBODY)
Code: [Select]
-attack ATTACK (type of attack e.g. -attack BITE)
Code: [Select]
-velocity # (velocity of the attack e.g. -velocity 1000)
Code: [Select]
-hitchance # (hit chance of the attack e.g. -hitchance 100)
That handles the basic options for one unit attacking another. Then you can get to the more advanced options. Like
Code: [Select]
-weapon Equipped (uses equipped weapon to attack with)
Code: [Select]
-weapon Fake -material MAT_ID -quality # (this will create a fake weapon that lasts for a small duration, long enough for the attack to be carried out, and then disappears e.g. -weapon Fake -material INORGANIC:STEEL -quality 1. Note, this works because the game doesn't actually check where the weapon is or who is holding it when performing an attack)
Code: [Select]
-delay # (how many ticks to wait before the attack is made e.g. -delay 5. Defaults to 1)
Code: [Select]
-number # (how many attacks to make e.g. -number 5. Defaults to 1)
Now the only problem I foresee for this method is the hit chance. Velocity can be calculated (thanks to Urist DaVinci's work) for any given weapon/body part attack, so leaving that blank is fine (i.e. there is a default). But we don't know the formula that the game uses to calculate the hit chance. My gut feeling is to just default the hit chance to 100, so that the attack always hits, but I am open to suggestions.

Thoughts?
Title: Re: Roses' Script, System, and Utilities Collection v0.1 (10/27/2015)
Post by: Dirst on January 26, 2016, 01:44:36 pm
I like the system you have there.  Does this completely bypass dodging, or fit normally within the combat system?

I've never seen an attack with the current script get dodged.
Title: Re: Roses' Script, System, and Utilities Collection v0.1 (10/27/2015)
Post by: Roses on January 26, 2016, 01:47:36 pm
Quote from: Dirst on January 26, 2016, 01:44:36 pm
I like the system you have there.  Does this completely bypass dodging, or fit normally within the combat system?

I've never seen an attack with the current script get dodged.

Good questions, and I don't know. I think the hit chance plays into dodging. Meaning that setting hit chance = 100 completely bypasses dodging. But I will test it to see if dodging is taking into account before or after hit chance is defined.
Title: Re: Roses' Script, System, and Utilities Collection v0.1 (10/27/2015)
Post by: Dirst on January 26, 2016, 02:16:43 pm
Quote from: Roses on January 26, 2016, 01:47:36 pm
Quote from: Dirst on January 26, 2016, 01:44:36 pm
I like the system you have there.  Does this completely bypass dodging, or fit normally within the combat system?

I've never seen an attack with the current script get dodged.

Good questions, and I don't know. I think the hit chance plays into dodging. Meaning that setting hit chance = 100 completely bypasses dodging. But I will test it to see if dodging is taking into account before or after hit chance is defined.
Keep in mind, I've only ever used the current script to start a fight between units that aren't in combat.  It might be hard (or impossible) to dodge that kind of "sneak attack."
Title: Re: Roses' Script, System, and Utilities Collection v0.1 (10/27/2015)
Post by: Roses on January 26, 2016, 02:35:59 pm
Quote from: Dirst on January 26, 2016, 02:16:43 pm
Quote from: Roses on January 26, 2016, 01:47:36 pm
Quote from: Dirst on January 26, 2016, 01:44:36 pm
I like the system you have there.  Does this completely bypass dodging, or fit normally within the combat system?

I've never seen an attack with the current script get dodged.

Good questions, and I don't know. I think the hit chance plays into dodging. Meaning that setting hit chance = 100 completely bypasses dodging. But I will test it to see if dodging is taking into account before or after hit chance is defined.
Keep in mind, I've only ever used the current script to start a fight between units that aren't in combat.  It might be hard (or impossible) to dodge that kind of "sneak attack."

Very true. I think I can test that out too.

EDIT: Alright, it's working now, I am still doing some testing though, but I should at least put out this attack script tomorrow. There will be two versions, a stand alone that I will post here, and then a version that will be included with my pack (the reason there will be a different version in my pack is because I use a lot of dfhack.script_environment calls, for the stand alone version I have just copied those functions into the script itself)
Title: Re: Roses' Script, System, and Utilities Collection v0.1 (10/27/2015)
Post by: Roses on January 29, 2016, 09:12:06 pm
Alright, here you go. Tested to work just fine in the arena, all of the options that I mentioned in the above post work except for the creating of a fake item for an attack. You also currently can't use an attack with the incorrect body part (PUNCH attack can't be with your feet). Eventually I will add that option, but for now its not there.

Code: (unit/attack.lua) [Select]
local utils = require 'utils'

validArgs = validArgs or utils.invert({
 'help',
 'defender',
 'attacker',
 'target',
 'attack',
 'velocity',
 'hitchance',
 'weapon',
 'delay',
 'number',
})
local args = utils.processArgs({...}, validArgs)

if args.defender and tonumber(args.defender) then
 defender = df.unit.find(tonumber(args.defender))
else
 print('No defender selected')
 return
end
if args.attacker and tonumber(args.attacker) then
 attacker = df.unit.find(tonumber(args.attacker))
else
 print('No attacker selected')
 return
end

attack = nil
target = nil

if not args.target then
 local rand = dfhack.random.new()
 local totwght = 0
 local weights = {}
 weights[0] = 0
 local n = 1
 for _,targets in pairs(defender.body.body_plan.body_parts) do
  totwght = totwght + targets.relsize
  weights[n] = weights[n-1] + targets.relsize
  n = n + 1 
 end
 while not target do
  pick = rand:random(totwght)
  for i = 1,n do
   if pick >= weights[i-1] and pick < weights[i] then
    target = i-1
    break
   end
  end
  if defender.body.components.body_part_status[target].missing then target = nil end
 end
else
 for i,targets in pairs(defender.body.body_plan.body_parts) do
  if targets.token == args.target then
   target = i
   break
  end
 end
end
 
if not target then
 print('No appropriate target found')
 return
end
delay = args.delay or 1
number = args.number or 1
hitchance = args.hitchance or 100
 
if args.weapon then
 local item = nil
 if args.weapon == 'Equipped' then
  for _,items in pairs(attacker.inventory) do
   if items.mode == 1 then
    item = items.item
    break
   end
  end
  if not item then
   print('No Equipped Weapon')
   return
  end
 end
 if not args.attack then
  local rand = dfhack.random.new()
  local totwght = 0
  local weights = {}
  weights[0] = 0
  local n = 1
  for _,attacks in pairs(item.subtype.attacks) do
   totwght = totwght + 1
   weights[n] = weights[n-1] + 1
   n = n + 1 
  end
  pick = rand:random(totwght)
  for i = 1,n do
   if pick >= weights[i-1] and pick < weights[i] then
    attack = i-1
    vel_mod = item.subtype.attacks[attack].velocity_mult
    break
   end
  end
 else
  for i,attacks in pairs(item.subtype.attacks) do
   if attacks.verb_2nd == args.attack or attacks.verb_3rd == args.attack then
    attack = i
    vel_mod = item.subtype.attacks[attack].velocity_mult
    break
   end
  end
 end

 if not attack then
  print('No appropriate attack found')
  return
 end

 if args.velocity then
  velocity = tonumber(args.velocity)
 else
  material = dfhack.matinfo.decode(item.mat_type,item.mat_index).material
  weight = math.floor(item.subtype.size*material.solid_density/100000)
  weight_fraction = item.subtype.size*material.solid_density*10 - weight*1000000
  effweight=attacker.body.size_info.size_cur/100+weight*100+weight_fraction/10000
  velocity = attacker.body.size_info.size_base * dfhack.units.getPhysicalAttrValue(attacker,0) * vel_mod/1000/effweight/1000
  if velocity == 0 then velocity = 1 end
 end

 j = 0
 while j < number do
 action = df.unit_action:new()
 action.id = attacker.next_action_id
 attacker.next_action_id = attacker.next_action_id + 1

 action.type = 1
 attack_action = action.data.attack
 attack_action.target_unit_id = defender.id
 attack_action.attack_item_id = item.id
 attack_action.target_body_part_id = target
 attack_action.attack_body_part_id = -1
 attack_action.unk_30 = velocity
 attack_action.attack_id = attack
 attack_action.flags = 7

 attack_action.unk_28 = hitchance
 attack_action.unk_2c = 100
 attack_action.unk_38 = 100
 attack_action.unk_3c = 100
 attack_action.timer1 = delay
 attack_action.timer2 = delay
 for i,x in pairs(attack_action.unk_4) do
  attack_action.unk_4[i] = 7
 end
 attack_action.unk_4.wrestle_type = -1
 attacker.actions:insert('#',action)
 j = j + 1
 end
else
 if not args.attack then
  local rand = dfhack.random.new()
  local totwght = 0
  local weights = {}
  weights[0] = 0
  local n = 1
  for _,attacks in pairs(attacker.body.body_plan.attacks) do
   if attacks.flags.main then
    totwght = totwght + 100
    weights[n] = weights[n-1] + 100
   else
    totwght = totwght + 1
    weights[n] = weights[n-1] + 1
   end
   n = n + 1 
  end
  while not attack do
   pick = rand:random(totwght)
   for i = 1,n do
    if pick >= weights[i-1] and pick < weights[i] then
     attack = i-1
     vel_mod = attacker.body.body_plan.attacks[attack].velocity_modifier
     break
    end
   end
   if attacker.body.components.body_part_status[attacker.body.body_plan.attacks[attack].body_part_idx[0]].missing then attack = nil end
  end
 else
  for i,attacks in pairs(attacker.body.body_plan.attacks) do
   if attacks.name == args.attack then
    attack = i
    vel_mod = attacker.body.body_plan.attacks[attack].velocity_modifier
    break
   end
  end
 end

 if not attack then
  print('No appropriate attack found')
  return
 end
 
 if args.velocity then
  velocity = tonumber(args.velocity)
 else
  velocity = 100 * dfhack.units.getPhysicalAttrValue(attacker,0) / 1000 * vel_mod / 1000
 end

 j = 0
 while j < number do
 action = df.unit_action:new()
 action.id = attacker.next_action_id
 attacker.next_action_id = attacker.next_action_id + 1

 action.type = 1
 attack_action = action.data.attack
 attack_action.target_unit_id = defender.id
 attack_action.attack_item_id = -1
 attack_action.target_body_part_id = target
 attack_action.attack_body_part_id = attacker.body.body_plan.attacks[attack].body_part_idx[0]
 attack_action.unk_30 = velocity
 attack_action.attack_id = attack
 attack_action.flags = 7

 attack_action.unk_28 = hitchance
 attack_action.unk_2c = 100
 attack_action.unk_38 = 100
 attack_action.unk_3c = 100
 attack_action.timer1 = delay
 attack_action.timer2 = delay
 for i,x in pairs(attack_action.unk_4) do
  attack_action.unk_4[i] = 7
 end
 attack_action.unk_4.wrestle_type = -1
 attacker.actions:insert('#',action)
 j = j + 1
 end
end
Example uses
Code: [Select]
unit/attack -attacker 0 -defender 1
unit/attack -attacker 0 -defender 1 -target UB
unit/attack -attacker 0 -defender 1 -attack PUNCH
unit/attack -attacker 0 -defender 1 -target RH -weapon Equipped
I also tested the hit chance calculations. Even with hitchance = 100 you can both still miss and be dodged. The higher your skill in the weapon the less likely you are to miss, the higher the defenders dodge skill the more likely they are to dodge. With Legendary dodging and a hitchance of 100 around 80 to 90 of 1000 attacks were dodged and another 100 or so were missed.
Title: Re: Roses' Script, System, and Utilities Collection v0.1 (10/27/2015)
Post by: Dirst on February 02, 2016, 09:51:56 am
Thanks Roses!

Disturbing creatures hidden in the stone should get considerably more dangerous now.
Title: Re: Roses' Script, System, and Utilities Collection v0.1 (10/27/2015)
Post by: Dirst on February 11, 2016, 09:36:53 am
A couple small updates for the attack script due to the naming of unknown attributes:

attack_action.unk_30 -> attack_action.attack_velocity
attack_action.unk_3c -> attack_action.attack_accuracy

(My guess is that these were named based on your work.)
Title: Re: Roses' Script, System, and Utilities Collection v0.1 (10/27/2015)
Post by: Putnam on February 11, 2016, 12:07:02 pm
The former based on mine, the latter based on Roses', I think. I didn't even know about attack_accuracy, but I was using unk_30 for Sparking for a while as attack velocity.

attack_accuracy is actually going to be very helpful...
Title: Re: Roses' Script, System, and Utilities Collection v0.1 (10/27/2015)
Post by: Roses on February 11, 2016, 04:54:34 pm
Quote from: Dirst on February 11, 2016, 09:36:53 am
A couple small updates for the attack script due to the naming of unknown attributes:

attack_action.unk_30 -> attack_action.attack_velocity
attack_action.unk_3c -> attack_action.attack_accuracy

(My guess is that these were named based on your work.)

Thanks for the update, I also noticed in error in the script, I have unk_28 = hitchance, it should be unk_3c = hitchance.
Title: Re: Roses' Script, System, and Utilities Collection v0.1 (10/27/2015)
Post by: Dirst on February 11, 2016, 05:42:17 pm
In my particular case I run it with the defaults for accuracy and velocity, but more flexibility is always better.
Title: Re: Roses' Script, System, and Utilities Collection v0.1 (10/27/2015)
Post by: Roses on February 11, 2016, 09:01:59 pm
So I finally decided to dust off the random creature creation script that I had created before. I have added a GUI and many other features. See the GUI below, and read how the script works. It is almost ready for release, with just a few more options that need to be moved from the black box of the code into easily configurable options. Let me know what you think!

Spoiler (click to show/hide)

Types of Templates:
Code: [Select]
ATTACK
BIOME
CASTE
EXTRACT
INTERACTION
MATERIAL
TYPE
SUBTYPE
HEAD
TORSO
LEG
ARM
HAND
FOOT
EYE
EAR
NOSE
MOUTH
ORGANS
SKELETAL
ATTACHMENT_HEAD
ATTACHMENT_TORSO
ATTACHMENT_LIMBS
ATTACHMENT_MISC
Template Template:
Code: [Select]
[TEMPLATE:-type-:-ID-]
 {DESCRIPTION:-desc-}
 {NAME:-names-}
 {ATTACKS:-attacks-}
 {ARGS:-args-}
 {TOKENS:-tokens-}
 {LINK:-tokens-}
 {EXCEPT:-tokens-}
 {PERCENT:-tokens-}
 {BODY:-body parts-}
 -raws-
Each template can have as many or as few of the above entries.

-type- is one of the above types
-ID- is the designation you give the template, must be unique
-desc- is a string which may be used in the creatures description (more below)
-names- complex behavior, see below
-attacks- is a list of attacks that is associated with the template, all attacks associated with templates will be added to the creature (seperated by commas)
-tokens- a list of self declared tokens which are added to the creature (more below)
-body parts- a list of body parts which are added to the [BODY:--] token of the creature
-raws- any additional raws that are added to the creature, the additions are done in a specific order (more below)

Example Template:
Code: [Select]
[TEMPLATE:EXTRACT:VENOM_1]
{DESCRIPTION:It has a painful venom.}
{ARGS:SEV,END}
    {TOKENS:TOXIC_CREATURE}
{PERCENT:VENOM}
    {LINK:VENOM}
    {EXCEPT:TOXIC_CREATURE}
[USE_MATERIAL_TEMPLATE:VENOM:CREATURE_EXTRACT_TEMPLATE]
[STATE_NAME:ALL_SOLID:frozen #NAME venom]
[STATE_ADJ:ALL_SOLID:frozen #NAME venom]
[STATE_NAME:LIQUID:#NAME venom]
[STATE_ADJ:LIQUID:#NAME venom]
[STATE_NAME:GAS:boiling #NAME venom]
[STATE_ADJ:GAS:boiling #NAME venom]
[PREFIX:NONE]
[ENTERS_BLOOD]
[REACTION_CLASS:VENOM]
[SYNDROME]
[SYN_NAME:#NAME venom]
[SYN_INJECTED]
[SYN_CONTACT]
[CE_PAIN:SEV:#ARG1:PROB:100:RESISTABLE:SIZE_DILUTES:LOCALIZED:VASCULAR_ONLY:START:0:PEAK:10:END:#ARG2]
[EXTRACT:LOCAL_CREATURE_MAT:VENOM]TOKENS vs. LINK vs. EXCEPT vs. PERCENT
-tokens- specified in {TOKENS} are added to the creature when the template is selected
-tokens- specified in {LINK} are checked against when a template is considered, if the LINK tokens are present the template is selected, if not the template is passed
-tokens- specified in {EXCEPT} work exactly the opposite of {LINK}, if present the template is passed, if not the template is selected
-tokens- specified in {PERCENT} are assigned at the onset of creature creation depending on values that the user defines in the creature creation GUI

Note that there are specific special tokens used internally, these tokens are precedded with an '#' and are;
Code: [Select]
#VERMIN - Checks if the creature is the correct size for vermin (defined by Size: Vermin)
#TINY - Checks if the creature is the correct size for tiny vermin (defined by Size: Tiny)
#TRADER - Checks if the creature is the correct size for a trading animal (defined by Size: Trade)
#MALE - Used for defining male castes in TEMPLATE:CASTE - LINK
#FEMALE - Used for defining female castes in TEMPLATE:CASTE - LINK
#DESC - Used to fill in the creature description when creating raws, very little use for this as the script currently creates a description for each caste already
#NAME - Used to fill the the creatue name when creating raws, very useful, allows for naming of things directly in the templates
#ARG1, #ARG2, #ARG3, etc... - Used to fill in the arguments provided in TEMPLATE - ARGS
#SWIMMING_GAITS - If this tag is present in a creature (no matter which template the creature recieved it from) will alter the gaits, flipping the WALK and SWIM gaits
#ONLY_SWIMMING - Same effect as above, but removes all other gaits (WALK, CLIMB, CRAWL, FLY)
#FLYING_GAITS - If this tag is present in a creature (no matter which template the creature recieved it from) will alter the gaits, moving WALK to FLY and CRAWL to WALK
#ONLY_FLYING - Same effect as above, but removes all other gaits (WALK, CLIMB, CRAWL, SWIM)
#NOARMS - Removes the CLIMB gait
#NOLEGS - Removes the WALK gait
Creation Process:
Step 1: Generate all numbers based on user input. This includes argument numbers, size, age, population numbers, attributes, and any other number based entries.
Step 2: Calculate {PERCENT} tokens based on random number generation (e.g. if randint(1,100) < PERCENT add -tokens-)
Step 3: Select the TYPE template to be used for the creature. This is the first template to be selected
Step 4: Select the BIOME template
Step 5: Begin selecting body templates.
 Start by selecting 1 TORSO, 1 HEAD, 1 LEG, 1 ARM, 1 HAND, and 1 FOOT template
 Then select 1 ORGANS and 1 SKELETAL template
 Next select 1 EYE, 1 EAR, 1 MOUTH, and 1 NOSE template
 Finally select a number of ATTACHMENT_TORSO, ATTACHMENT_HEAD, ATTACHMENT_LIMBS, and ATTACHMENT_MISC templates based on a user defined limit
 Note that each of these templates is checked against the {LINK} and {EXCEPT} and the -tokens- of the creature. The order is specific, so a   HEAD template can not forbid a TORSO template, but a TORSO template can forbid a HEAD template
Step 6: Select the MATERIAL template
Step 7: Select the CASTE templates, by default a single template with {LINK:#MALE} and a single template with {LINK:#FEMALE} will be selected. This is configurable by changing the number of female, male and neutral castes in the GUI
Step 8: Select the SUBTYPE templates. The number of SUBTYPE templates chosen is between 0 and Max Subtypes which is configurable in the GUI
Step 9: Select and EXTRACT templates. These templates are chosen differently than others. Instead of randomly picking one, all templates that meet the {LINK} and {EXCEPT} criteria are added to the creature
Step 10: Select the INTERACTION templates. In the gui the maximum number of interactions a single creature can have is specifiable. In addition you can specify the percent chance that each individual INTERACTION template has for being added.
Step 11: Get all of the {ATTACKS} from each template that has been selected for the creature
Step 12: Now all of the templates have been selected, the actual creation of the creature begins. The format of the creation is (entries with an '#' are generated as described below)

Code: [Select]
[CREATURE:--]
 [NAME:#NAME]
 [CREATURE_TILE:--]
 [COLOR:--:--:--]

=> TYPE template -raws- go here

=> SUBTYPE templates -raws- go here

=> BIOME template -raws- go here

=> all numbers generated in Step 1: go here (e.g. [MAX_AGE:--:--], [BODY_SIZE:--:--:--], [CHILD:--], etc...)

 [APPLY_CREATURE_VARIATION:#SPEED]

 [BODY:#BODY]

=> MATERIAL template -raws- go here

=> EXTRACT templates -raws- go here

=> INTERACTION templates -raws- go here

=> ATTACK templates -raws- go here

=> CASTE template -raws- go here, additionally [DESCRIPTION:#DESC] and [CASTE_NAME:#CASTE_NAME] are added here as well
#DESC is generated by using the various -desc- provided in the templates. The actual method for how they are added is
 body_dc = torso_dc + ' ' + torsoa_dc + ', ' + head_dc + ' ' + heada_dc
 limb_dc = arm_dc + ' ' + hand_dc + ' and ' + leg_dc + ' ' + foot_dc
 face_dc = eye_dc + ', ' + nose_dc + ', ' + mouth_dc + ', and ' + ear_dc
 description = type_dc + subtype_dc + '. ' + material_dc + ' with ' + body_dc + ' and ' + face_dc + '. It has ' + limb_dc + '. It ' + biome_dc + '. ' + extract_dc + '. ' + interaction_dc
Note that, while not perfect, it does generate reasonable descriptions, for example;
"A ferocious animal found only in the most savage of landscapes. A scaled creature with a four part body, three heads and eight eyes, a large trunk, no visible mouth, and one ear. It has four upper tentacles with claws and four legs and feet with four toes each. It Is only found underground."

#BODY is generated by combining the {BODY} -body parts- from each template. They are added together TORSO -> HEAD,ARM,LEG -> HAND,FOOT,EYE,EAR,NOSE,MOUTH -> ORGANS,SKELETAL -> all others

#SPEED is calculated for each GAIT (WALK, CLIMB, CRAWL, SWIM, and FLY) based on the numbers provided in the GUI. The speeds are then altered depending on the special tokens present on the creature. This allows for you to generate land and water animals in the same group by switching the WALK/SWIM gaits depending on which they are.

#NAME and #CASTE_NAME are generated in one of two ways. Either randomly by a chosen DF language file. Or based on the templates {NAME}. Currently the {NAME} feature is bugged, but I am hoping to have it working soon.
Title: Re: Roses' Script, System, and Utilities Collection v0.1 (10/27/2015)
Post by: Abadrausar on February 12, 2016, 07:38:17 am
Quote from: Roses on February 11, 2016, 09:01:59 pm
So I finally decided to dust off the random creature creation script that I had created before. I have added a GUI and many other features. See the GUI below, and read how the script works. It is almost ready for release, with just a few more options that need to be moved from the black box of the code into easily configurable options. Let me know what you think!
Roses: the middleware that you are building with the Civilization, Class, Spells and Event Systems have in my opinion the touch of genius.
Spoiler (click to show/hide)
Why I think so:
- Dwarf Fortress (DF) raws are a declarative language where the modder describe what he intend to be done by the simulation, but where all the complexity of the HOW is somewhat hidden from him.
- DFHACK has tried from its inception to expand the universe of things (mechanisms) that can be expressed with DF raws, to this end the DF team have tried many different approaches to be able of communicating to the simulation that more functionalities were required within the limits actually implemented.
- Then an army of admiring DF followers have taken all the disparate weapons disponibles to them (Lisp, Perl, C++, c# ,Go , java, AutoHotKey ,Python, Ruby, Lua, ...) to fight their way to this noble end: Expand the unique content in DF.
- Like a modern Tower of Babel these army of peasants, without discipline, with humble equipment, abilities and skills, even if barely able of communicate and understand each other, all of them can feel that their hearts are broken by the love to this game, all those hearts singing the same love song!!!
- Like warriors and poets of old time, against impossible odds they battle, each time they lose, but their will is like stone and strong are their hearts, their faith will never abandon them.

What you have done with these four files: civilizations.txt, classes.txt, spell.txt and events.txt is not new, I know, you could do the same before with moddtools and some other scripts.
So where is the genius? For me it is in using exactly the same format of DF raws to expand what can be declared and autolimiting yourself to the tiny 146 Kb of lua.dll;  you have removed the principal limitation of the workers in the Babel Tower, they all can now communicate and expand new original content in the most basic language of the DF universe, the DF raw language!

In order of being absolutely mimetic with native DF raws, at the beginning of each one of those 4 files it could be added
Spoiler (click to show/hide)
And then even enable to separate each one of these 4 new expanded categories in different files like the native DF raws do as a way of encapsulating contents.

The innovation is using  or mimicking what is there from the very beginning (DF declarative Lang-like) to do new and wonderful things, could your hard and masterful work, into these new mechanisms and abstractions to approach the hard earned results of the dwarven SCIENCE to the basic modder, inspire others to give birth to a new era in this community.

We all thanks your silent hard work and dedication! We are so lucky to have so much people like you in our community...

Putnam has already started playtesting your middleware in his forbent mod, he is maybe the first pioneer but soon there will be others striking the uncharted earth of the frontiers of DF modding
Title: Re: Roses' Script, System, and Utilities Collection v0.1 (10/27/2015)
Post by: Putnam on February 12, 2016, 07:44:16 pm
the funny part is that i've thought about moving the whole fortbent class system to one of my own design just so that I don't have to rely on any dependencies, since I'm fully capable of that; main thing stopping is that it mostly work at this point (though it has errors every single time anything dies) and there's just a ridiculously huge amount of classes I made, which may be why the game hitches for something like 300-700 milliseconds for every class that I assign.

Like, tbh, I'm by far the worst example of the greatness of the raws system, I basically just ignore it entirely this point except for the very most basic of things. I made an entire mouse UI in the new SCP mod before even considering whether I could've done it with reactions (I can now, since descriptions and categories were added, but at the time it was infeasible), for example.
Title: Re: Roses' Script, System, and Utilities Collection v0.1 (10/27/2015)
Post by: Roses on February 12, 2016, 09:42:35 pm
Quote from: Abadrausar on February 12, 2016, 07:38:17 am
-snip-
Thank you for the kind words. I had originally thought of making the systems in a more intuitive language, but since they are explicitly for DF I decided to go with the raw templates. Currently you can actually have as many class/civilization/events files as you want. It looks for all files labeled classes_*.txt etc... And reads them in. You are right that if I wanted to make it more like the raws I should put an [OBJECT:] header and such, but I always found that that is the most unfriendly part of the raws.

Quote from: Putnam on February 12, 2016, 07:44:16 pm
the funny part is that i've thought about moving the whole fortbent class system to one of my own design just so that I don't have to rely on any dependencies, since I'm fully capable of that; main thing stopping is that it mostly work at this point (though it has errors every single time anything dies) and there's just a ridiculously huge amount of classes I made, which may be why the game hitches for something like 300-700 milliseconds for every class that I assign.

Like, tbh, I'm by far the worst example of the greatness of the raws system, I basically just ignore it entirely this point except for the very most basic of things. I made an entire mouse UI in the new SCP mod before even considering whether I could've done it with reactions (I can now, since descriptions and categories were added, but at the time it was infeasible), for example.

What errors are you getting when something dies? I think I might already know the error. Death tracking is used in all the systems, but if you are just using the class system it will probably give errors. It was set up this way because I thought you could only have one onUnitDeath event declared and everything had to go in there. I have since learned that that is not the case and the new version will have it separated so that if you are only using one system you shouldn't get any errors.

I have also sped up the system dramatically by no longer filling in the entire table for a unit when a class is assigned. The current released version will make a table for each attribute, skill, trait, class, and all combinations there of. The new version will only populate those tables when they are needed. This dramatically cuts down on space and time usage since you are rarely going to be using all of the attributes and skills and traits for each class. There are also some extra speed up additions that are just from making the code more efficient which should help the slowdown. Basically I split the class system into basic and advanced, for the end user there is no difference, but all the advanced features that take up space and time to run don't need to be active if you aren't using them, so they only become active the first time they are called.


Finally, I have fixed the #NAME problems I was having with my random creature creation script. You are now able to specify as many adjectives, prefixes, suffixes, and main words as you would like in each template. The script then picks between 0 and 2 adjectives, between 0 and 1 prefixes, between 1 and 2 main words, and between 0 and 1 suffixes. It then assembles them all into a name. One of the more earth like names I have gotten was Large Arctic Terratox Centipede (a 100 legged creature that lives in arctic biomes underground and toxic). Unfortunately some names are silly like Fire Sightless Ambibeast, and others are just ridiculous, Chitinous Soft Bug. But that's what you get when you randomly assemble words I guess.
Title: Re: Roses' Script, System, and Utilities Collection v0.1 (10/27/2015)
Post by: Abadrausar on February 13, 2016, 08:34:57 am
Quote from: Putnam on February 12, 2016, 07:44:16 pm
the funny part is that i've thought about moving the whole fortbent class system to one of my own design just so that I don't have to rely on any dependencies, since I'm fully capable of that; main thing stopping is that it mostly work at this point (though it has errors every single time anything dies) and there's just a ridiculously huge amount of classes I made, which may be why the game hitches for something like 300-700 milliseconds for every class that I assign.
Putnam you are one of the most capable Lua modders in our community next to Roses, IndigoFenix, Expwnent, Lethosor, Warmists,Milo Christiansen, Quietust or many others.
As a group you are like the spearhead of the community and we all gain when some of you find the ways to collaborate; (git or other SCM) as individuals all of you are able of impressive feats that are however dwarfed by the things that you have done as a group. Ideas and breakthroughs lands randomly and inter pollinate.
Quote from: Roses on February 12, 2016, 09:42:35 pm
... I had originally thought of making the systems in a more intuitive language, but since they are explicitly for DF I decided to go with the raw templates...
That almost every DF modder out there is able to use in some way, using the familiar "lingua franca" of DF raws to give access to the new functionalities and systems (civilizations, classes, spells, events, ...) you have democratized and uniformized the access to everybody. You are removing the entry barriers.
Quote from: Roses on February 12, 2016, 09:42:35 pm
...Currently you can actually have as many class/civilization/events files as you want. It looks for all files labeled classes_*.txt etc... And reads them in....
Nice. :) Docs are in need of some love then?
Quote from: Roses on February 12, 2016, 09:42:35 pm
...You are right that if I wanted to make it more like the raws I should put an [OBJECT:] header and such, but I always found that that is the most unfriendly part of the raws...
Sure! Your system does not need that, you could even ignore [OBJECT:] things as decorators. But adding them is a way to evite confusion and make your DF raw extensions indistinguishable from those of vanilla. Because the casual modder does not need to know that some raw files needs [OBJECT:] and others no... ;D Best to relieve people of the burden of something that only can be at the origine of problems.


Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: Roses on February 16, 2016, 01:54:33 pm
Updated first post, and included the Random Creature Creation Gui in my github collection. Let me know if you try it out! And please post any and all templates you wish to share.

Also added classes_example.txt and spells_example.txt for an example of what you can do with the Class System. Next up will be examples for the Event and Civilization Systems.
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: Roses on February 24, 2016, 09:35:35 pm
Alright, so, because one of my future ideas requires simulating combat, I think it's about time to come up with a reasonable "to hit" calculator. But in order to do this I would like some feedback from anyone that is interested in contributing. To start off we should be able to answer these questions;


Now obviously the ideal would be to get the actual in game hit chance calculations, but I am not well experienced with looking at disassembles of code (such as done here (http://www.bay12forums.com/smf/index.php?topic=142372.0) for velocity and other attack components). If anyone else with experience would like to try to find out, or if anyone knows a way to find out how worldgen battles are calculated that would be amazing.
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: expwnent on February 24, 2016, 11:52:01 pm
The only thing I know about worldgen battles is that they work by choosing a "champion" from each side, then the champions fight until one dies then the losing side picks a new champion. That's why worldgen non-vampire histfigs sometimes get hundreds of kills.
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: Roses on February 25, 2016, 01:56:33 pm
Interesting. Not the best way to handle group combat, but not terrible either. The question is, how is the champions fight handled? Is it fully realized, like with arena combat, or is it just a string of equations which is deterministic? I suppose I could ask Toady directly. See if he would give me any insight into his hitchance calculations.
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: Putnam on February 25, 2016, 03:29:56 pm
It's not arena level but not perfectly deterministic AFAIK. Dice rolls have been mentioned in relation to that; probably uses the history seed for all that.
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: Roses on February 26, 2016, 05:23:32 pm
I did a small amount of research into attacks. Posted my results here (http://www.bay12forums.com/smf/index.php?topic=154798.msg6836619#msg6836619). I think the next step is to create a script that outputs large amounts of data at every time step and copies it into a single file, this should speed up the process and give me better statistics instead of just individually going through the attack values.
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: Roses on March 07, 2016, 07:00:35 pm
So I dusted off my detailed unit viewer gui that I had been working on before, with the reasoning that there needs to be an in-game way to see Class information if you are using my Class System, it also allows you to see active syndromes on units, basic health information, skill information, and anything you would see in the normal description screen. There are sub-pages that will give you even more information, including exact syndrome details, exact attribute numbers, and more.

Spoiler (click to show/hide)
Spoiler (click to show/hide)
Spoiler (click to show/hide)

Note that I am not done with putting all of the class information in there, but you can scroll through different classes, it will tell you if you are eligible for that class, and then will allow you to change to that class (if allowed by the modder, since I know some modders might like to limit certain class changes to reactions of some sort).

Note2, the layout is easily configurable. and can store more information than is currently shown. But for now this is what I have.

Thoughts?
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: expwnent on March 08, 2016, 02:55:39 am
Wow, that looks awesome!
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: Max™ on March 08, 2016, 05:09:14 pm
Holy crap that just makes the default presentation look even more painful.
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: Bumber on March 09, 2016, 04:32:30 am
What happens when the Thoughts and Feelings (or any other) category starts to stretch past the end of the page? Does it get truncated or does it scroll?
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: expwnent on March 09, 2016, 04:58:33 am
PSA: the most recent (beta) DFHack release, DFHack 0.42.06-alpha1, has a crash bug that will affect many of these scripts. Anything that uses persistent data will likely make the game crash when commissioning something related to a historical figure. Running this script before doing that should fix the problem temporarily:

Code: [Select]
--fix-histfigs.lua
local figs = df.global.world.history.figures

for i=0,#figs-1,1 do
   local v = figs[i]
   if v.id<0 then
      --print(v.id..' '..v.name.first_name..' '..v.name.language)
      v.name.language = 0
   end
end
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: Roses on March 09, 2016, 01:15:24 pm
Quote from: Bumber on March 09, 2016, 04:32:30 am
What happens when the Thoughts and Feelings (or any other) category starts to stretch past the end of the page? Does it get truncated or does it scroll?

Right now it just keeps going, so if your screen is bigger you can see more, if it's smaller you see less. I haven't figured out how to get the custom gui to change sizes depending on screen size yet, but I would like to do that and allow for scrolling. I play windowed full screen, but I realize others play in smaller frames and I want to be able to accommodate that, just haven't figured out the best way to do that.

Quote from: expwnent on March 09, 2016, 04:58:33 am
PSA: the most recent (beta) DFHack release, DFHack 0.42.06-alpha1, has a crash bug that will affect many of these scripts. Anything that uses persistent data will likely make the game crash when commissioning something related to a historical figure. Running this script before doing that should fix the problem temporarily:

I actually haven't done anything yet with DFHack in 42+. Still running everything on the previous DF version since there are still so many things on my to-do and wish lists that I didn't want to add the possibilities of fiddling with any of the new stuff into options.
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: Roses on March 16, 2016, 03:22:17 pm
What you get when you open up the unit viewer with the currently provided classes_example.txt and spells_example.txt

Spoiler (click to show/hide)

Now I just need to figure out how to alphabetize it.
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: expwnent on March 16, 2016, 03:47:21 pm
Awesome!
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: Max™ on March 16, 2016, 08:38:10 pm
How does df alphabetize stuff? There must be a native routine we could drag up for that somewhere.
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: Warmist on March 17, 2016, 03:40:09 am
Quote from: Roses on March 16, 2016, 03:22:17 pm
Now I just need to figure out how to alphabetize it.
You mean sorting?
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: Dirst on March 17, 2016, 12:01:30 pm
Quote from: Warmist on March 17, 2016, 03:40:09 am
Quote from: Roses on March 16, 2016, 03:22:17 pm
Now I just need to figure out how to alphabetize it.
You mean sorting?
Or get it acquired by Google's parent company?
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: expwnent on March 17, 2016, 12:19:12 pm
Google has a parent company?
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: Max™ on March 17, 2016, 12:21:42 pm
Spoiler (click to show/hide)
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: Roses on March 17, 2016, 01:11:50 pm
Spoiler (click to show/hide)
Quote from: Warmist on March 17, 2016, 03:40:09 am
Quote from: Roses on March 16, 2016, 03:22:17 pm
Now I just need to figure out how to alphabetize it.
You mean sorting?

Yes, the issue is the name displayed is a reference in a table of a table. Still not that hard to do, would just need to make a separate array and copy the corresponding values, then sort.
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: Meph on March 20, 2016, 07:23:07 am
Quote from: Roses on March 16, 2016, 03:22:17 pm
What you get when you open up the unit viewer with the currently provided classes_example.txt and spells_example.txt

Spoiler (click to show/hide)

Now I just need to figure out how to alphabetize it.
OMG. I love that you are still working on this, and this looks fantastic for players. :)
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: Roses on March 23, 2016, 02:21:41 pm
Quote from: Meph on March 20, 2016, 07:23:07 am
Quote from: Roses on March 16, 2016, 03:22:17 pm
What you get when you open up the unit viewer with the currently provided classes_example.txt and spells_example.txt

Spoiler (click to show/hide)

Now I just need to figure out how to alphabetize it.
OMG. I love that you are still working on this, and this looks fantastic for players. :)

Indeed, I am trying at least. In the process of writing my Thesis right now so my free time has been stretched very thin. But I enjoy writing utilities for DF that I one day hope to include in a mod. At this point I am up to about 40 scripts and over 10k lines of code. But I am trying to prune a little, there are just so many features I want that require writing large pieces of new code.
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: Roses on April 04, 2016, 05:20:06 pm
Alright, I had a new idea for a script/system. Tentatively called TrueCreature it fixes some major problems I have with modding, namely the caps that are present on raw values that aren't shared in game.

For those of you who don't know, 5000 is not the in-game cap for any of the attributes, and yet you can only use up to 5000 in the raws themselves, this typically results in dragons (or other very large creatures) just getting 5000 strength. But is a dragon only 5 times stronger than an average human? Seems unlikely. Similarly, the size of a creature is capped in the raws, but can go much larger in-game.

So what does/will TrueCreature do? Simply put it will scan all creatures every so often, and will adjust values based on an external file that you configure (if I can figure it out it will also work in world generation, but that will be another project all together). This will also tie into the Class and Civilization system (which is where the idea originates from) so that enemy entities and creatures can have classes randomly chosen for them based on the inputs you provide.

Now this is all in the brainstorming phase so far (don't have much time for anything besides thesis writing right now), so let me know if any of you have any suggestions or comments.
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: Dirst on April 04, 2016, 08:10:52 pm
Quote from: Roses on April 04, 2016, 05:20:06 pm
Now this is all in the brainstorming phase so far (don't have much time for anything besides thesis writing right now), so let me know if any of you have any suggestions or comments.
I suggest making it a chapter of your thesis :)

Have the actual limits being scienced yet?  I imagine that intermediate steps of some formulas could overflow if size or a stat was too high.  And that would all change when DF goes 64-bit.
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: expwnent on April 04, 2016, 08:11:59 pm
I remember Putnam (I think) saying that 5000 is the cap on the minimum, not the cap on the maximum.
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: Putnam on April 04, 2016, 09:04:07 pm
Quote from: Dirst on April 04, 2016, 08:10:52 pm
Have the actual limits being scienced yet?  I imagine that intermediate steps of some formulas could overflow if size or a stat was too high.  And that would all change when DF goes 64-bit.

1. Yes.

2. Yeah, 0.40.01 gave a sort of soft cap on strength dependent on unit size and carry weight; for example, having more than ~2,000,000 strength on a human-sized creature will make it so that that creature will immediately become as slow as possible upon picking anything up. Other than that, stuff just tends to work.

3. I don't think it will. DF going 64-bit doesn't mean all the uint_32s that make up attributes are going to magically become 64-bit. AFAIK even if he just uses "int" it still won't do that, "long" is the 64-bit integer type IIRC.
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: Dirst on April 04, 2016, 09:07:52 pm
Quote from: Putnam on April 04, 2016, 09:04:07 pm
Quote from: Dirst on April 04, 2016, 08:10:52 pm
Have the actual limits being scienced yet?  I imagine that intermediate steps of some formulas could overflow if size or a stat was too high.  And that would all change when DF goes 64-bit.

1. Yes.

2. Yeah, 0.40.01 gave a sort of soft cap on strength dependent on unit size and carry weight; for example, having more than ~2,000,000 strength on a human-sized creature will make it so that that creature will immediately become as slow as possible upon picking anything up. Other than that, stuff just tends to work.

3. I don't think it will. DF going 64-bit doesn't mean all the uint_32s that make up attributes are going to magically become 64-bit. AFAIK even if he just uses "int" it still won't do that, "long" is the 64-bit integer type IIRC.
I didn't mean the stats' hard caps would change from 64-bit, but that the intermediate-result-overflow constraints might vanish.  But there's already a lot more science on this topic than I realized, so it might be trivial to test those chokepoints when a 64-bit build comes out.
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: Bumber on April 04, 2016, 09:20:17 pm
Quote from: Putnam on April 04, 2016, 09:04:07 pm
AFAIK even if he just uses "int" it still won't do that, "long" is the 64-bit integer type IIRC.
It's compiler and OS dependent. The only standard requirement is that short ≤ int ≤ long.
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: expwnent on April 04, 2016, 09:22:13 pm
No, he said somewhere he uses int32_t/etc everywhere.
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: Roses on April 04, 2016, 11:51:24 pm
I personally know of size and attribute values not translating directly from raws -> game (i.e. if you say strength should be 6000 it will just default to 5000). There may be other things as well that are raw capped but not game capped. I think I remember someone saying that materials may also be raw capped, but I'm not sure that can be changed since those values aren't stored in individual items but are just referenced directly from the raws.

Putnam brings up a good point though, there may be other soft caps which cause unintended behavior (I think the strength one might be from the tissue token [THICKENS_ON_STRENGTH] but maybe it's something else). Right now most of my scripts just check for the integer type and set the maximum according to that.
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: Putnam on April 04, 2016, 11:59:11 pm
Wait, I made the unbreakable katana in fortbent the maximum possible value for everything (trial and error). Yes, indeedy, the cap for strength values is 100,000,000. Adamantine's 5,000,000, so that's pretty good. Didn't check the cap on strain_at_yield, mostly because strain_at_yield is a really weird measurement to use. It's in percentage*1000, so TENSILE_STRAIN_AT_YIELD:100000 means that the material, once it reaches its TENSILE_YIELD point under tension, will have deformed elastically such that it's twice as long as it was before deformation began. This means, notably, that it's very difficult to define the stretchiness of an object as a function of the force applied to it; rather, it's a function of its strength divided by the force applied to it. Multiplying an item's strength by ten will divide its elasticity by ten unless STRAIN_AT_YIELD is changed to accompany it.

The cap of max_edge is 2147483647, or 231-1.
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: Roses on April 06, 2016, 10:04:51 am
That's good to know, and also fairly weird.
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: Putnam on April 17, 2016, 05:27:14 am
class.lua:191: attempt to index field 'Physical' (a nil value)

EDIT: I have no idea why this is happening.
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: Roses on April 17, 2016, 04:33:49 pm
Quote from: Putnam on April 17, 2016, 05:27:14 am
class.lua:191: attempt to index field 'Physical' (a nil value)

EDIT: I have no idea why this is happening.

I do, poor coding on my part, class.LevelBonus is always defined by default, but class.LevelBonus.Physical (or .Mental, .Skill, .Trait) is only defined if the class actually has those bonuses. To fix it for the version you have now replace (starting at line 191)

Code: [Select]
--Add/Subtract permanent level bonuses
 for _,attr in pairs(class.LevelBonus.Physical._children) do
  local amount = class.LevelBonus.Physical[attr]
  dfhack.script_environment('functions/unit').changeAttribute(unit,attr,amount,0,'track')
 end
 for _,attr in pairs(class.LevelBonus.Mental._children) do
  local amount = class.LevelBonus.Mental[attr]
  dfhack.script_environment('functions/unit').changeAttribute(unit,attr,amount,0,'track')
 end
 for _,skill in pairs(class.LevelBonus.Skill._children) do
  local amount = class.LevelBonus.Skill[skill]
  dfhack.script_environment('functions/unit').changeSkill(unit,skill,amount,0,'track')
 end
 for _,trait in pairs(class.LevelBonus.Trait._children) do
  local amount = class.LevelBonus.Trait[trait]
  dfhack.script_environment('functions/unit').changeTrait(unit,trait,amount,0,'track')
 end
with

Code: [Select]
--Add/Subtract permanent level bonuses
 if class.LevelBonus.Physical then
  for _,attr in pairs(class.LevelBonus.Physical._children) do
   local amount = class.LevelBonus.Physical[attr]
   dfhack.script_environment('functions/unit').changeAttribute(unit,attr,amount,0,'track')
  end
 end
 if class.LevelBonus.Mental then
  for _,attr in pairs(class.LevelBonus.Mental._children) do
   local amount = class.LevelBonus.Mental[attr]
   dfhack.script_environment('functions/unit').changeAttribute(unit,attr,amount,0,'track')
  end
 end
 if class.LevelBonus.Skill then
  for _,skill in pairs(class.LevelBonus.Skill._children) do
   local amount = class.LevelBonus.Skill[skill]
   dfhack.script_environment('functions/unit').changeSkill(unit,skill,amount,0,'track')
  end
 end
 if class.LevelBonus.Trait then
  for _,trait in pairs(class.LevelBonus.Trait._children) do
   local amount = class.LevelBonus.Trait[trait]
   dfhack.script_environment('functions/unit').changeTrait(unit,trait,amount,0,'track')
  end
 end
In the future release this will be fixed more elegantly.
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: Putnam on April 17, 2016, 04:47:51 pm
class.LevelBonus,Physical
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: Roses on April 17, 2016, 04:59:44 pm
thanks, edited original
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: Roses on May 05, 2016, 02:49:12 pm
So I really didn't feel this deserved another post anywhere, and I didn't want to clutter up anyone elses threads. Does anyone know of a utility that allows for easily taking sprites from multiple different sheets and creating a new sheet out of them? I have found tools that let combine entire sheets together, but I was hoping to be able to pick and choose individual sprites from a given sheet.
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: Dirst on May 06, 2016, 07:39:08 am
Quote from: Roses on May 05, 2016, 02:49:12 pm
So I really didn't feel this deserved another post anywhere, and I didn't want to clutter up anyone elses threads. Does anyone know of a utility that allows for easily taking sprites from multiple different sheets and creating a new sheet out of them? I have found tools that let combine entire sheets together, but I was hoping to be able to pick and choose individual sprites from a given sheet.
Not sure if Quiet-Sun's Tool (http://www.bay12forums.com/smf/index.php?topic=156151.0) does what you are looking for, but it's the only thing I know of that's close (other than straight-up image tools).
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: Meph on May 06, 2016, 08:07:15 am
I think you are looking for this: http://www.bay12forums.com/smf/index.php?topic=77724
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: Roses on May 09, 2016, 10:34:39 pm
Well I got really annoyed with writing so I took a short break to brainstorm a road map for where I am planning on going with DF and DFHack. I have updated the first post with this information (removing my outdated todo list) so that you can see what my current plans are. Hopefully the first couple of releases will be quick and will happen in the beginning of June.
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: Putnam on May 16, 2016, 05:29:09 pm
I rewrote it to use json instead of persist-table. It's loads faster now. Main problem I can find is that I can't get it to save on quicksaves.
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: Max™ on May 16, 2016, 05:42:54 pm
Quote from: Dirst on May 06, 2016, 07:39:08 am
Quote from: Roses on May 05, 2016, 02:49:12 pm
So I really didn't feel this deserved another post anywhere, and I didn't want to clutter up anyone elses threads. Does anyone know of a utility that allows for easily taking sprites from multiple different sheets and creating a new sheet out of them? I have found tools that let combine entire sheets together, but I was hoping to be able to pick and choose individual sprites from a given sheet.
Not sure if Quiet-Sun's Tool (http://www.bay12forums.com/smf/index.php?topic=156151.0) does what you are looking for, but it's the only thing I know of that's close (other than straight-up image tools).
It's easy enough with GIMP by just opening them as layers and removing the pieces you don't want.
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: expwnent on May 16, 2016, 10:12:14 pm
Quote from: Putnam on May 16, 2016, 05:29:09 pm
I rewrote it to use json instead of persist-table. It's loads faster now. Main problem I can find is that I can't get it to save on quicksaves.

I hate to break it to you but I'm 99% done with replacing all histfig persistent data with json in a way that's even backwards-compatible with persist-table. It automatically converts to json and uses the same persist-table interface and works for (almost all) plugins too.
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: Putnam on May 16, 2016, 11:14:33 pm
That's very fine, because I couldn't figure out quicksaves lol. It was about 5 hours work anyway.
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: Roses on May 17, 2016, 08:30:01 am
Quote from: expwnent on May 16, 2016, 10:12:14 pm
Quote from: Putnam on May 16, 2016, 05:29:09 pm
I rewrote it to use json instead of persist-table. It's loads faster now. Main problem I can find is that I can't get it to save on quicksaves.

I hate to break it to you but I'm 99% done with replacing all histfig persistent data with json in a way that's even backwards-compatible with persist-table. It automatically converts to json and uses the same persist-table interface and works for (almost all) plugins too.

@Putnam, the new version of my class system should load faster for you as well as I have changed my philosophy from "load absolutely everything into persist-table and then pick what you need" to "only load what you need". This basically means that unless you use it in a script somewhere, there's no reason to be storing every skill and attribute for every unit.

@expwnent, Should I plan on changing anything in my scripts for the persist-table changes?
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: Putnam on May 17, 2016, 05:18:37 pm
Skill and attribute and class? I noticed that issue. Each unit was 34 kb and i'm willing to bet that nothing I would do could've increased or decrease that number (except maybe add/remove classes, obv). Thought it was real weird that it stored all 144 classes in every single unit regardless of whether the unit was going to switch. My json conversion is complete except for the quick/autosave issue, but that's big enough that I won't bother releasing.

Example:

Code: (119.json) [Select]
{
"Attributes": {
"AGILITY": {
"Base": "817",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"ANALYTICAL_ABILITY": {
"Base": "1472",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"CREATIVITY": {
"Base": "2126",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"DISEASE_RESISTANCE": {
"Base": "1945",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"EMPATHY": {
"Base": "1192",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"ENDURANCE": {
"Base": "1060",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"FOCUS": {
"Base": "4649",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"INTUITION": {
"Base": "757",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"KINESTHETIC_SENSE": {
"Base": "1314",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"LINGUISTIC_ABILITY": {
"Base": "804",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"MEMORY": {
"Base": "796",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"MUSICALITY": {
"Base": "817",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"PATIENCE": {
"Base": "1240",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"RECUPERATION": {
"Base": "1111",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"SOCIAL_AWARENESS": {
"Base": "1663",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"SPATIAL_SENSE": {
"Base": "1373",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"STRENGTH": {
"Base": "1161",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"TOUGHNESS": {
"Base": "472",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"WILLPOWER": {
"Base": "1523",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
}
},
"Classes": {
"BARD_OF_BLOOD": {
"Experience": "0",
"Level": "0"
},
"BARD_OF_BREATH": {
"Experience": "0",
"Level": "0"
},
"BARD_OF_DOOM": {
"Experience": "0",
"Level": "0"
},
"BARD_OF_HEART": {
"Experience": "0",
"Level": "0"
},
"BARD_OF_HOPE": {
"Experience": "0",
"Level": "0"
},
"BARD_OF_LIFE": {
"Experience": "0",
"Level": "0"
},
"BARD_OF_LIGHT": {
"Experience": "0",
"Level": "0"
},
"BARD_OF_MIND": {
"Experience": "0",
"Level": "0"
},
"BARD_OF_RAGE": {
"Experience": "0",
"Level": "0"
},
"BARD_OF_SPACE": {
"Experience": "0",
"Level": "0"
},
"BARD_OF_TIME": {
"Experience": "0",
"Level": "0"
},
"BARD_OF_VOID": {
"Experience": "0",
"Level": "0"
},
"Current": {
"Name": "PRINCE_OF_DOOM",
"SkillExp": "0",
"TotalExp": "0"
},
"HEIR_OF_BLOOD": {
"Experience": "0",
"Level": "0"
},
"HEIR_OF_BREATH": {
"Experience": "0",
"Level": "0"
},
"HEIR_OF_DOOM": {
"Experience": "0",
"Level": "0"
},
"HEIR_OF_HEART": {
"Experience": "0",
"Level": "0"
},
"HEIR_OF_HOPE": {
"Experience": "0",
"Level": "0"
},
"HEIR_OF_LIFE": {
"Experience": "0",
"Level": "0"
},
"HEIR_OF_LIGHT": {
"Experience": "0",
"Level": "0"
},
"HEIR_OF_MIND": {
"Experience": "0",
"Level": "0"
},
"HEIR_OF_RAGE": {
"Experience": "0",
"Level": "0"
},
"HEIR_OF_SPACE": {
"Experience": "0",
"Level": "0"
},
"HEIR_OF_TIME": {
"Experience": "0",
"Level": "0"
},
"HEIR_OF_VOID": {
"Experience": "0",
"Level": "0"
},
"KNIGHT_OF_BLOOD": {
"Experience": "0",
"Level": "0"
},
"KNIGHT_OF_BREATH": {
"Experience": "0",
"Level": "0"
},
"KNIGHT_OF_DOOM": {
"Experience": "0",
"Level": "0"
},
"KNIGHT_OF_HEART": {
"Experience": "0",
"Level": "0"
},
"KNIGHT_OF_HOPE": {
"Experience": "0",
"Level": "0"
},
"KNIGHT_OF_LIFE": {
"Experience": "0",
"Level": "0"
},
"KNIGHT_OF_LIGHT": {
"Experience": "0",
"Level": "0"
},
"KNIGHT_OF_MIND": {
"Experience": "0",
"Level": "0"
},
"KNIGHT_OF_RAGE": {
"Experience": "0",
"Level": "0"
},
"KNIGHT_OF_SPACE": {
"Experience": "0",
"Level": "0"
},
"KNIGHT_OF_TIME": {
"Experience": "0",
"Level": "0"
},
"KNIGHT_OF_VOID": {
"Experience": "0",
"Level": "0"
},
"MAGE_OF_BLOOD": {
"Experience": "0",
"Level": "0"
},
"MAGE_OF_BREATH": {
"Experience": "0",
"Level": "0"
},
"MAGE_OF_DOOM": {
"Experience": "0",
"Level": "0"
},
"MAGE_OF_HEART": {
"Experience": "0",
"Level": "0"
},
"MAGE_OF_HOPE": {
"Experience": "0",
"Level": "0"
},
"MAGE_OF_LIFE": {
"Experience": "0",
"Level": "0"
},
"MAGE_OF_LIGHT": {
"Experience": "0",
"Level": "0"
},
"MAGE_OF_MIND": {
"Experience": "0",
"Level": "0"
},
"MAGE_OF_RAGE": {
"Experience": "0",
"Level": "0"
},
"MAGE_OF_SPACE": {
"Experience": "0",
"Level": "0"
},
"MAGE_OF_TIME": {
"Experience": "0",
"Level": "0"
},
"MAGE_OF_VOID": {
"Experience": "0",
"Level": "0"
},
"MAID_OF_BLOOD": {
"Experience": "0",
"Level": "0"
},
"MAID_OF_BREATH": {
"Experience": "0",
"Level": "0"
},
"MAID_OF_DOOM": {
"Experience": "0",
"Level": "0"
},
"MAID_OF_HEART": {
"Experience": "0",
"Level": "0"
},
"MAID_OF_HOPE": {
"Experience": "0",
"Level": "0"
},
"MAID_OF_LIFE": {
"Experience": "0",
"Level": "0"
},
"MAID_OF_LIGHT": {
"Experience": "0",
"Level": "0"
},
"MAID_OF_MIND": {
"Experience": "0",
"Level": "0"
},
"MAID_OF_RAGE": {
"Experience": "0",
"Level": "0"
},
"MAID_OF_SPACE": {
"Experience": "0",
"Level": "0"
},
"MAID_OF_TIME": {
"Experience": "0",
"Level": "0"
},
"MAID_OF_VOID": {
"Experience": "0",
"Level": "0"
},
"PAGE_OF_BLOOD": {
"Experience": "0",
"Level": "0"
},
"PAGE_OF_BREATH": {
"Experience": "0",
"Level": "0"
},
"PAGE_OF_DOOM": {
"Experience": "0",
"Level": "0"
},
"PAGE_OF_HEART": {
"Experience": "0",
"Level": "0"
},
"PAGE_OF_HOPE": {
"Experience": "0",
"Level": "0"
},
"PAGE_OF_LIFE": {
"Experience": "0",
"Level": "0"
},
"PAGE_OF_LIGHT": {
"Experience": "0",
"Level": "0"
},
"PAGE_OF_MIND": {
"Experience": "0",
"Level": "0"
},
"PAGE_OF_RAGE": {
"Experience": "0",
"Level": "0"
},
"PAGE_OF_SPACE": {
"Experience": "0",
"Level": "0"
},
"PAGE_OF_TIME": {
"Experience": "0",
"Level": "0"
},
"PAGE_OF_VOID": {
"Experience": "0",
"Level": "0"
},
"PRINCE_OF_BLOOD": {
"Experience": "0",
"Level": "0"
},
"PRINCE_OF_BREATH": {
"Experience": "0",
"Level": "0"
},
"PRINCE_OF_DOOM": {
"Experience": "0",
"Level": "0"
},
"PRINCE_OF_HEART": {
"Experience": "0",
"Level": "0"
},
"PRINCE_OF_HOPE": {
"Experience": "0",
"Level": "0"
},
"PRINCE_OF_LIFE": {
"Experience": "0",
"Level": "0"
},
"PRINCE_OF_LIGHT": {
"Experience": "0",
"Level": "0"
},
"PRINCE_OF_MIND": {
"Experience": "0",
"Level": "0"
},
"PRINCE_OF_RAGE": {
"Experience": "0",
"Level": "0"
},
"PRINCE_OF_SPACE": {
"Experience": "0",
"Level": "0"
},
"PRINCE_OF_TIME": {
"Experience": "0",
"Level": "0"
},
"PRINCE_OF_VOID": {
"Experience": "0",
"Level": "0"
},
"ROGUE_OF_BLOOD": {
"Experience": "0",
"Level": "0"
},
"ROGUE_OF_BREATH": {
"Experience": "0",
"Level": "0"
},
"ROGUE_OF_DOOM": {
"Experience": "0",
"Level": "0"
},
"ROGUE_OF_HEART": {
"Experience": "0",
"Level": "0"
},
"ROGUE_OF_HOPE": {
"Experience": "0",
"Level": "0"
},
"ROGUE_OF_LIFE": {
"Experience": "0",
"Level": "0"
},
"ROGUE_OF_LIGHT": {
"Experience": "0",
"Level": "0"
},
"ROGUE_OF_MIND": {
"Experience": "0",
"Level": "0"
},
"ROGUE_OF_RAGE": {
"Experience": "0",
"Level": "0"
},
"ROGUE_OF_SPACE": {
"Experience": "0",
"Level": "0"
},
"ROGUE_OF_TIME": {
"Experience": "0",
"Level": "0"
},
"ROGUE_OF_VOID": {
"Experience": "0",
"Level": "0"
},
"SEER_OF_BLOOD": {
"Experience": "0",
"Level": "0"
},
"SEER_OF_BREATH": {
"Experience": "0",
"Level": "0"
},
"SEER_OF_DOOM": {
"Experience": "0",
"Level": "0"
},
"SEER_OF_HEART": {
"Experience": "0",
"Level": "0"
},
"SEER_OF_HOPE": {
"Experience": "0",
"Level": "0"
},
"SEER_OF_LIFE": {
"Experience": "0",
"Level": "0"
},
"SEER_OF_LIGHT": {
"Experience": "0",
"Level": "0"
},
"SEER_OF_MIND": {
"Experience": "0",
"Level": "0"
},
"SEER_OF_RAGE": {
"Experience": "0",
"Level": "0"
},
"SEER_OF_SPACE": {
"Experience": "0",
"Level": "0"
},
"SEER_OF_TIME": {
"Experience": "0",
"Level": "0"
},
"SEER_OF_VOID": {
"Experience": "0",
"Level": "0"
},
"SYLPH_OF_BLOOD": {
"Experience": "0",
"Level": "0"
},
"SYLPH_OF_BREATH": {
"Experience": "0",
"Level": "0"
},
"SYLPH_OF_DOOM": {
"Experience": "0",
"Level": "0"
},
"SYLPH_OF_HEART": {
"Experience": "0",
"Level": "0"
},
"SYLPH_OF_HOPE": {
"Experience": "0",
"Level": "0"
},
"SYLPH_OF_LIFE": {
"Experience": "0",
"Level": "0"
},
"SYLPH_OF_LIGHT": {
"Experience": "0",
"Level": "0"
},
"SYLPH_OF_MIND": {
"Experience": "0",
"Level": "0"
},
"SYLPH_OF_RAGE": {
"Experience": "0",
"Level": "0"
},
"SYLPH_OF_SPACE": {
"Experience": "0",
"Level": "0"
},
"SYLPH_OF_TIME": {
"Experience": "0",
"Level": "0"
},
"SYLPH_OF_VOID": {
"Experience": "0",
"Level": "0"
},
"THIEF_OF_BLOOD": {
"Experience": "0",
"Level": "0"
},
"THIEF_OF_BREATH": {
"Experience": "0",
"Level": "0"
},
"THIEF_OF_DOOM": {
"Experience": "0",
"Level": "0"
},
"THIEF_OF_HEART": {
"Experience": "0",
"Level": "0"
},
"THIEF_OF_HOPE": {
"Experience": "0",
"Level": "0"
},
"THIEF_OF_LIFE": {
"Experience": "0",
"Level": "0"
},
"THIEF_OF_LIGHT": {
"Experience": "0",
"Level": "0"
},
"THIEF_OF_MIND": {
"Experience": "0",
"Level": "0"
},
"THIEF_OF_RAGE": {
"Experience": "0",
"Level": "0"
},
"THIEF_OF_SPACE": {
"Experience": "0",
"Level": "0"
},
"THIEF_OF_TIME": {
"Experience": "0",
"Level": "0"
},
"THIEF_OF_VOID": {
"Experience": "0",
"Level": "0"
},
"WITCH_OF_BLOOD": {
"Experience": "0",
"Level": "0"
},
"WITCH_OF_BREATH": {
"Experience": "0",
"Level": "0"
},
"WITCH_OF_DOOM": {
"Experience": "0",
"Level": "0"
},
"WITCH_OF_HEART": {
"Experience": "0",
"Level": "0"
},
"WITCH_OF_HOPE": {
"Experience": "0",
"Level": "0"
},
"WITCH_OF_LIFE": {
"Experience": "0",
"Level": "0"
},
"WITCH_OF_LIGHT": {
"Experience": "0",
"Level": "0"
},
"WITCH_OF_MIND": {
"Experience": "0",
"Level": "0"
},
"WITCH_OF_RAGE": {
"Experience": "0",
"Level": "0"
},
"WITCH_OF_SPACE": {
"Experience": "0",
"Level": "0"
},
"WITCH_OF_TIME": {
"Experience": "0",
"Level": "0"
},
"WITCH_OF_VOID": {
"Experience": "0",
"Level": "0"
}
},
"Skills": {
"ALCHEMY": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"ANIMALCARE": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"ANIMALTRAIN": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"APPRAISAL": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"ARMOR": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"ASTRONOMY": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"AXE": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"BALANCE": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"BEEKEEPING": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"BITE": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"BLOWGUN": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"BONECARVE": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"BOOKBINDING": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"BOW": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"BOWYER": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"BREWING": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"BUTCHER": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"CARPENTRY": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"CHEESEMAKING": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"CHEMISTRY": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"CLIMBING": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"CLOTHESMAKING": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"COMEDY": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"CONCENTRATION": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"CONSOLE": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"CONVERSATION": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"COOK": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"COORDINATION": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"CRITICAL_THINKING": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"CROSSBOW": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"CRUTCH_WALK": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"CUTGEM": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"DAGGER": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"DANCE": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"DESIGNBUILDING": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"DETAILSTONE": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"DIAGNOSE": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"DISCIPLINE": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"DISSECT_FISH": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"DISSECT_VERMIN": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"DODGING": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"DRESS_WOUNDS": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"DYER": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"ENCRUSTGEM": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"EXTRACT_STRAND": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"FISH": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"FLATTERY": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"FLUID_ENGINEER": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"FORGE_ARMOR": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"FORGE_FURNITURE": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"FORGE_WEAPON": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"GELD": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"GEOGRAPHY": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"GLASSMAKER": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"GLAZING": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"GRASP_STRIKE": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"HAMMER": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"HERBALISM": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"INTIMIDATION": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"JUDGING_INTENT": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"KNAPPING": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"KNOWLEDGE_ACQUISITION": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"LEADERSHIP": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"LEATHERWORK": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"LOGIC": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"LYE_MAKING": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"LYING": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"MACE": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"MAGIC_NATURE": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"MAKE_MUSIC": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"MASONRY": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"MATHEMATICS": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"MECHANICS": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"MELEE_COMBAT": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"METALCRAFT": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"MILITARY_TACTICS": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"MILK": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"MILLING": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"MINING": {
"Base": "2",
"Change": "0",
"Class": "0",
"Current": "2",
"Item": "0",
"StatusEffects": []
},
"MISC_WEAPON": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"NEGOTIATION": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"OPERATE_PUMP": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"OPTICS_ENGINEER": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"ORGANIZATION": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"PACIFY": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"PAPERMAKING": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"PERSUASION": {
"Base": "0",
"Change": "0",
"Class": "0",
"Current": "0",
"Item": "0",
"StatusEffects": []
},
"PIKE": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"PLANT": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"PLAY_KEYBOARD_INSTRUMENT": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"PLAY_PERCUSSION_INSTRUMENT": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"PLAY_STRINGED_INSTRUMENT": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"PLAY_WIND_INSTRUMENT": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"POETRY": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"POTASH_MAKING": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"POTTERY": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"PRESSING": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"PROCESSFISH": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"PROCESSPLANTS": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"PROSE": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"RANGED_COMBAT": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"READING": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"RECORD_KEEPING": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"SET_BONE": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"SHEARING": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"SHIELD": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"SIEGECRAFT": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"SIEGEOPERATE": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"SING_MUSIC": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"SITUATIONAL_AWARENESS": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"SMELT": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"SNEAK": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"SOAP_MAKING": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"SPEAKING": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"SPEAR": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"SPINNING": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"STANCE_STRIKE": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"STONECRAFT": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"SURGERY": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"SUTURE": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"SWIMMING": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"SWORD": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"TANNER": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"TEACHING": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"THROW": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"TRACKING": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"TRAPPING": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"WAX_WORKING": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"WEAVING": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"WHIP": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"WOODCRAFT": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"WOODCUTTING": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"WOOD_BURNING": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"WRESTLING": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
},
"WRITING": {
"Base": "0",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
}
},
"Spells": {
"Active": []
},
"Stats": {
"Deaths": "0",
"Kills": "0"
},
"Traits": {
"ABSTRACT_INCLINED": {
"Base": "57",
"Change": "0",
"Class": "0",
"Item": "0",
"StatusEffects": []
And then it goes on to describe every other trait much the same way. It didn't even fit into the post.
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: Roses on May 17, 2016, 07:41:37 pm
Quote from: Putnam on May 17, 2016, 05:18:37 pm
Skill and attribute and class? I noticed that issue. Each unit was 34 kb and i'm willing to bet that nothing I would do could've increased or decrease that number (except maybe add/remove classes, obv). Thought it was real weird that it stored all 144 classes in every single unit regardless of whether the unit was going to switch. My json conversion is complete except for the quick/autosave issue, but that's big enough that I won't bother releasing.

Example:
<snipped>
And then it goes on to describe every other trait much the same way. It didn't even fit into the post.

Yep, now it only stores it if the unit uses it. Shrinks that overhead way down. Although that is cool to see all of the persist-table "trees".
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: Putnam on May 17, 2016, 08:52:44 pm
Yeah, I found it fascinating. Then it turned out I had to actually cut the persist-table into multiple files to get it to work correctly lol

ClassTable.json is 399 KB alone, each unit is 34 KB
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: Roses on May 17, 2016, 10:13:57 pm
Quote from: Putnam on May 17, 2016, 08:52:44 pm
Yeah, I found it fascinating. Then it turned out I had to actually cut the persist-table into multiple files to get it to work correctly lol

ClassTable.json is 399 KB alone, each unit is 34 KB

Hahaha, yeah. I kept adding and adding without really thinking about it.
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: expwnent on May 18, 2016, 01:29:50 am
You shouldn't need to change anything once the new system is in place. It'll just be faster.
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: Roses on May 25, 2016, 05:32:07 pm
So I am starting to go through all my scripts for bug checking and the like and am looking at some of my older scripts (particularly the attribute-change, skill-change, trait-change scripts) and was wondering if anyone would hate me if I changed the syntax slightly. Right now they require a -fixed, -percent, or -set input with a given number. I would like to change that to a simple -mode and -amount input. So that, for instance

Code: [Select]
   unit/attribute-change -unit \\UNIT_ID -fixed 100 -attribute STRENGTH
   unit/attribute-change -unit \\UNIT_ID -percent [ 10 10 10 ] -attribute [ ENDURANCE TOUGHNESS WILLPOWER ] -dur 3600
   unit/attribute-change -unit \\UNIT_ID -set 5000 -attribute WILLPOWER -dur 1000would become
Code: [Select]
   unit/attribute-change -unit \\UNIT_ID -mode fixed -amount 100 -attribute STRENGTH
   unit/attribute-change -unit \\UNIT_ID -mode percent -amount [ 10 10 10 ] -attribute [ ENDURANCE TOUGHNESS WILLPOWER ] -dur 3600
   unit/attribute-change -unit \\UNIT_ID -mode set -amount 5000 -attribute WILLPOWER -dur 1000
Thoughts?
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: Putnam on May 25, 2016, 08:20:37 pm
I use script-environment and call the functions directly, usually, so I have no opinion.
Title: Re: Roses' Script, System, and Utilities Collection v0.2 (2/16/2016)
Post by: Roses on May 26, 2016, 05:57:59 pm
Progress Update:

Today I finished going trough all 18 unit based scripts. They are all working with no errors (for the combinations I tested), although all combinations have not been tested.

By this weekend I plan on finishing testing and updating all the other scripts and pushing out a release.

EDIT: All scripts and their corresponding functions have been updated to DFHack 42.06. I have temporarily pulled down the Class, Civilization, and Event systems and will re-upload them as I finish updating them.
Title: Re: Roses' Script, System, and Utilities Collection (05/31/2016)
Post by: Roses on June 02, 2016, 03:41:20 pm
Working on the Class System I have stripped out most of the complexity of the system and separated it into two systems (Class and Spell). There is no change for the modder or end user, but it loads much faster and has a much smaller memory footprint. The biggest change is that the system only uses something if it needs to (before it was loading everything and the kitchen sink into memory). Current list of changes:

1. The spell upgrade wasn't working like it was supposed to, it now works correctly.
2. Skill experience is now tracked by class instead of total, this means if a spell costs something to learn you will need skill experience from the class itself.
3. Many small changes that should improve performance.

Additions that are being implemented;

1. A feat system similar to D&D that will provide further upgrade options. You will gain feat points at defined total experience levels that you can spend on custom defined feats. For example you might have a complex feat like Improved Casting which lowers the cool down of all interactions, or simple feats that give straight attribute bonuses. The purpose of adding these in is to make units with the same class more distinct from each other and to add more progress levels.

2. The spell system is getting an upgrade. While it will be entirely optional from the Class System you will be able to tie your class spells into this system which will provide you with a couple neat options;
2a. Casting time: Make certain spells take longer to cast than others. This works by adding an action to the unit with a defined time delay which will prevent the unit from doing any other actions. This also means you will be vulnerable to attack during this time since you will be unable to dodge, block, or parry, and you won't be able to attack or use other interactions either.
2b. Casting fatigue: Make spell casting fatigue the unit. This simply adds to the exhaustion counter a certain amount.
2c. Casting experience: Make spell casting give the unit experience. This will help your healers to level up.

3. You will be able to add custom skills with custom profession names and custom attributes. This is more of a feature that will get heavily used in the Enhanced and Expedition Systems, but I figured I would start it off by including it here. Unfortunately these skills/attributes won't show up in the in-game unit viewer, but they will be visible in my enhanced unit viewer gui (when that gets released). And will tie into the spell system and be usable in the wrapper script. As an example you might have a skill Spell Casting and attributes like Faith, Wisdom, and Intelligence.

Now you might think these additions would add a lot of time to my expected release dates, but actually most of the code is already written and just needs to be linked together (of course testing is another thing). I am currently testing the basic class system using Putnam's Fortbent classes

Depending on how my testing goes this weekend I am hoping to have the next release up by Monday with sample classes, spells, and feats and a rough ReadMe.

@Putnam, do you mind if I include your Fortbent classes as another example file (with appropriate reference of course)? I like how simple and yet detailed they are.
Title: Re: Roses' Script, System, and Utilities Collection (05/31/2016)
Post by: Teneb on June 02, 2016, 04:21:11 pm
Nice to see the work going on the classes.I am pretty sure I'll be making use of them.
Title: Re: Roses' Script, System, and Utilities Collection (05/31/2016)
Post by: expwnent on June 04, 2016, 09:09:11 am
Awesome stuff!
Title: Re: Roses' Script, System, and Utilities Collection (05/31/2016)
Post by: Roses on June 23, 2016, 06:02:28 pm
Sorry for the lack of updates. There should be the first stage 2 release this weekend. The release will include the updated Class System, with the Spell and Feat SubSystems also included. A ReadMe will also be included detailing all of the uses and capabilities of these systems.

As an example there will also be a set of files included with 5 classes, 15 spells/abilities, and 12 feats. The example classes are (warrior, priest, mage, rogue, and archer) and each class has three unique spells/abilities while the feats are shared across multiple classes.

I may be forced to rearrange some of the release schedule since the wrapper script plays such a crucial role in the Spell SubSystem, and it is currently in a practically unusable state.
Title: Re: Roses' Script, System, and Utilities Collection (07/05/2016)
Post by: Roses on July 05, 2016, 02:49:21 pm
A couple weeks behind schedule, but the update is out. The Class System along with Spell and Feat SubSystems is now included in my collection. Note that the ReadMe is still being worked on and will be included at a later time, but working examples of the entire system and subsystems are included. If you have any questions please feel free to ask.
Title: Re: Roses' Script, System, and Utilities Collection (07/05/2016)
Post by: Teneb on July 06, 2016, 11:23:29 am
Quote from: Roses on July 05, 2016, 02:49:21 pm
A couple weeks behind schedule, but the update is out. The Class System along with Spell and Feat SubSystems is now included in my collection. Note that the ReadMe is still being worked on and will be included at a later time, but working examples of the entire system and subsystems are included. If you have any questions please feel free to ask.
Nice. I'll check it out later.
Title: Re: Roses' Script, System, and Utilities Collection (07/05/2016)
Post by: Roses on July 13, 2016, 07:02:48 pm
Alright, so wrapping up my next release (which will also have a couple extra scripts that I created for Meph to use) and I am following up from the discussion from this (http://www.bay12forums.com/smf/index.php?topic=159320.0) thread. Basically how to go about adding more customization options to entities. My old entity/resource-change script was very narrow in that it checked a very strict list of requirements, want to add something to the INORGANIC:METAL resource? It has to have the [IS_METAL] flag. Now I have removed all of those checks (just commented out so they can be easily placed back in if needed), this means you could theoretically add DWARF:BONE to the INORGANIC:METAL table, now I have no idea what affect this would have on the game, but I figured if people wanted they could play around with it (you can even add INORGANIC:GRANITE to the food table, haven't tested if they will eat granite then, or maybe use it in cooking, I somehow doubt it, but maybe?

Also following that thread, I have added the ability to determine specific products materials. You can have a civ that only makes weapons out of steel, ammo out of silver, and armor out of iron or whatever you want. Similar with crafts, barrels, flasks, quivers, backpacks, and cages. Again, I have no idea what affects these changes will have in game since I haven't been able to test them, but the changes are correctly being made to the correct tables.
Title: Re: Roses' Script, System, and Utilities Collection (07/05/2016)
Post by: Meph on July 14, 2016, 06:46:57 am
If you make MEAT:NONE:INORGANIC:GRANITE it will rot and act like meat. If you make DRINK:NONE:INORGANIC:NONE you get magma in a barrel, and dwarves will treat it as booze and drink it. It wont even kill them.

Quote
Alright, so wrapping up my next release (which will also have a couple extra scripts that I created for Meph to use)
:D Thank you
Title: Re: Roses' Script, System, and Utilities Collection (07/05/2016)
Post by: Teneb on July 18, 2016, 02:46:57 pm
Hey, how exactly do I install your scripts? As in, where do I put each folder? Does the scripts folder go inside /raw , for instance?

EDIT: I think I figured it out.

EDIT 2: If I might make a request, could you allow for classes to also do personality, transformations and size changes?

EDIT 3: What is the correct syntax for AUTO_UPGRADE? [AUTO_UPGRADE:CLASSNAME]? [AUTO_UPGRADE:CLASSNAME:LEVEL]? Also, do feats work? I hope I am not being a bother, but this is not covered in the read me file.
Title: Re: Roses' Script, System, and Utilities Collection (07/05/2016)
Post by: Teneb on July 19, 2016, 11:16:15 am
Roses, your ReadMe file says that to set up the classes system, I need to run classes_setup.py ... but there is no such file in your download.
Title: Re: Roses' Script, System, and Utilities Collection (07/05/2016)
Post by: Roses on July 19, 2016, 01:38:37 pm
Yes, sorry. That ReadMe is out of date. l shouldn't have included it with the package. Everything you need for the class system is in the following files


To use the system all you need are the above files, and then put
Code: [Select]
base/roses-init -classSystem [ Feats Spells ]In our onLoad.init file. You can then use the following scripts to utilize the system

Sorry I have yet to make a proper ReadMe. I hope this at least helps a little. Now to answer your questions

Quote from: Teneb on July 18, 2016, 02:46:57 pm
Hey, how exactly do I install your scripts? As in, where do I put each folder? Does the scripts folder go inside /raw , for instance?

EDIT: I think I figured it out.
Yes, the scripts folder goes inside the /raw folder.

Quote from: Teneb on July 18, 2016, 02:46:57 pm
EDIT 2: If I might make a request, could you allow for classes to also do personality, transformations and size changes?
I can add that to the system, but it is sort of already possible. In the file inorganic_class_names.txt, along with the [CE_DISPLAY_NAME] syndrome effect you can add any other syndrome effects you want. For example, instead of
Code: [Select]
[SYNDROME]
  [SYN_NAME:WARRIOR]
  [SYN_CLASS:CLASS_NAME]
  [CE_DISPLAY_NAME:NAME:warrior:warriors:warrior:START:0]You can put
Code: [Select]
[SYNDROME]
  [SYN_NAME:WARRIOR]
  [SYN_CLASS:CLASS_NAME]
  [CE_DISPLAY_NAME:NAME:warrior:warriors:warrior:START:0]
  [CE_BODY_APPEARANCE_MODIFIER:HEIGHT:200]
Quote from: Teneb on July 18, 2016, 02:46:57 pm
EDIT 3: What is the correct syntax for AUTO_UPGRADE? [AUTO_UPGRADE:CLASSNAME]? [AUTO_UPGRADE:CLASSNAME:LEVEL]? Also, do feats work? I hope I am not being a bother, but this is not covered in the read me file.
You are not being a bother at all, it is my fault for not making an updated ReadMe. Yes feats work, and the correct syntax is [AUTO_UPGRADE:CLASSNAME], one your class reaches the max level of that class it will automatically change classes to the auto upgrade one.

Please feel free to ask as many questions as you want. It will drive me to get this ReadMe done with (and to get the next release out, which I really should have done already!)
Title: Re: Roses' Script, System, and Utilities Collection (07/05/2016)
Post by: Teneb on July 28, 2016, 04:45:02 pm
I don't know how possible, or practical, this is so disregard if that's the case, but could you make it so that there's an option to use creature materials when it comes to the names and spells? The reason for this is that any inorganic, regardless if it has [SPECIAL] or any other token, can be picked as the material for a worldgen slab, resulting in weird stuff like "warrior name slab".

I thought of a workaround this (namely, making the inorganic a copy of a vanilla one minus the environment), but the would avoid some trouble.
Title: Re: Roses' Script, System, and Utilities Collection (07/05/2016)
Post by: Meph on July 28, 2016, 05:02:13 pm
Quote from: Teneb on July 28, 2016, 04:45:02 pm
I don't know how possible, or practical, this is so disregard if that's the case, but could you make it so that there's an option to use creature materials when it comes to the names and spells? The reason for this is that any inorganic, regardless if it has [SPECIAL] or any other token, can be picked as the material for a worldgen slab, resulting in weird stuff like "warrior name slab".

I thought of a workaround this (namely, making the inorganic a copy of a vanilla one minus the environment), but the would avoid some trouble.
Any STONE_TEMPLATE using inorganic is being used for slabs as far as I know.
Title: Re: Roses' Script, System, and Utilities Collection (07/05/2016)
Post by: Teneb on July 28, 2016, 05:15:10 pm
Quote from: Meph on July 28, 2016, 05:02:13 pm
Quote from: Teneb on July 28, 2016, 04:45:02 pm
I don't know how possible, or practical, this is so disregard if that's the case, but could you make it so that there's an option to use creature materials when it comes to the names and spells? The reason for this is that any inorganic, regardless if it has [SPECIAL] or any other token, can be picked as the material for a worldgen slab, resulting in weird stuff like "warrior name slab".

I thought of a workaround this (namely, making the inorganic a copy of a vanilla one minus the environment), but the would avoid some trouble.
Any STONE_TEMPLATE using inorganic is being used for slabs as far as I know.
If that's the case, it makes things far easier. Ignore my request then.
Title: Re: Roses' Script, System, and Utilities Collection (07/05/2016)
Post by: Roses on July 29, 2016, 03:33:41 pm
Technically the class names and spells and things are all based on syndrome names. This means you can theoretically put all of the syndromes on a single inorganic or even a creatures materials (as far as I know modtools/add-syndrome doesn't have a problem with that).
Title: Re: Roses' Script, System, and Utilities Collection (07/05/2016)
Post by: Teneb on August 02, 2016, 02:17:29 pm
Is it possible to restrict classes to specific creature classes? Or to prevent creatures with specific syn classes from having them, like with regular interactions?

If not, could you add that possibility? I want specific castes of a creature (representing their nobles) to rise through tiers of knighthood (which will use your system), but prevent other castes (peasants) or creatures from doing the same.
Title: Re: Roses' Script, System, and Utilities Collection (07/05/2016)
Post by: Roses on August 02, 2016, 06:37:19 pm
Quote from: Teneb on August 02, 2016, 02:17:29 pm
Is it possible to restrict classes to specific creature classes? Or to prevent creatures with specific syn classes from having them, like with regular interactions?

If not, could you add that possibility? I want specific castes of a creature (representing their nobles) to rise through tiers of knighthood (which will use your system), but prevent other castes (peasants) or creatures from doing the same.

[REQUIREMENT_CREATURE:CREATURE_NAME:CASTE_NAME] can be used to restrict it to a specific caste of a creature. I can add the ability to restrict it to certain creature classes and syndrome classes.
Title: Re: Roses' Script, System, and Utilities Collection (07/05/2016)
Post by: Teneb on August 03, 2016, 02:20:56 pm
Quote from: Roses on August 02, 2016, 06:37:19 pm
Quote from: Teneb on August 02, 2016, 02:17:29 pm
Is it possible to restrict classes to specific creature classes? Or to prevent creatures with specific syn classes from having them, like with regular interactions?

If not, could you add that possibility? I want specific castes of a creature (representing their nobles) to rise through tiers of knighthood (which will use your system), but prevent other castes (peasants) or creatures from doing the same.

[REQUIREMENT_CREATURE:CREATURE_NAME:CASTE_NAME] can be used to restrict it to a specific caste of a creature. I can add the ability to restrict it to certain creature classes and syndrome classes.
While caste restriction works for me, it would be nice if you could add creature classes and syndrome classes if you have the time.
Title: Re: Roses' Script, System, and Utilities Collection (07/05/2016)
Post by: Roses on August 13, 2016, 01:19:18 pm
Sorry for my horrible update schedule. I am done with the Event system (it's actually working pretty neat, can have buildings change by season/month/week, random weather occur based on season, run scripts based on wealth/population/deaths/progress triggers/and many more. A complete list will be included in the ReadMe) and am now starting on the Civilization System (I want to get both working before a proper release since they tie into each other a lot).

Now previously I had each entity get it's own unique civilization that was tracked independently of the others, but I am now wondering if it would be better to have all of the same entities get grouped together. Does anyone know how the game itself treats entities? For instance if there are three MOUNTAIN entities and two EVIL entities, can MOUNTAIN A be at war with EVIL A but not EVIL B? If MOUNTAIN A is at war will MOUNTAIN B and MOUNTAIN C be too? I know resources (i.e. available weapons, materials, animals, etc...) are stored on a per-entity basis, but are they actually just shared in the game? If someone from MOUNTAIN A learns to tame a specific creature, will MOUNTAIN B and MOUNTAIN C have access to them as well?

The whole reason for asking is because there are certain things that would be made much easier if I just treated all of the MOUNTAIN entities as a single civilization. It's not impossible to make each entity unique and independent, but it will complicate some things.
Title: Re: Roses' Script, System, and Utilities Collection (07/05/2016)
Post by: vjmdhzgr on August 13, 2016, 04:30:19 pm
The way you asked that question is a bit confusing, but I think I know what you mean. Once a world is generated civilizations are separate from the entity file. They are all their own individual civilization that tames their own creatures, has its own entity positions (in vanilla they can actually vary between civilizations. Humans don't start out with law givers they make them at some point, and I think there can be some varying names) and any editing of the entity files does not affect them. Which is why I've been trying to always use entity to refer to the files and civilization for civilizations.

Now just in case my current interpretation is wrong and my initial one is actually correct, then having multiple MOUNTAIN entities is duplicating raws which is not a viable option for a mod that makes any sense.
Title: Re: Roses' Script, System, and Utilities Collection (07/05/2016)
Post by: Dirst on August 13, 2016, 04:50:02 pm
Quote from: vjmdhzgr on August 13, 2016, 04:30:19 pm
The way you asked that question is a bit confusing, but I think I know what you mean. Once a world is generated civilizations are separate from the entity file. They are all their own individual civilization that tames their own creatures, has its own entity positions (in vanilla they can actually vary between civilizations. Humans don't start out with law givers they make them at some point, and I think there can be some varying names) and any editing of the entity files does not affect them. Which is why I've been trying to always use entity to refer to the files and civilization for civilizations.

Now just in case my current interpretation is wrong and my initial one is actually correct, then having multiple MOUNTAIN entities is duplicating raws which is not a viable option for a mod that makes any sense.
I can confirm that civilizations have distinct identities beyond the entity definition, much the same way units have distinct identities beyond their creature definition.
Title: Re: Roses' Script, System, and Utilities Collection (07/05/2016)
Post by: Roses on August 13, 2016, 05:26:19 pm
Yes, I agree the wording with entities, civilizations, and Civilizations (from my system) is confusing to discuss. I will refer to them as entities (the things in the raw files), civilizations (the civilizations in game), and Civilizations (which are assigned through my system). The way the "Civilization System" currently works is this,

Create a seperate file with
Code: [Select]
[CIVILIZATION:MOUNTAIN]
...
...
...I then assign that Civilization to all populations from the matching entity, but each civilization gets it's own unique Civilization. This is done by basically making several copies of the same Civilization and applying them across each civilization . This means that each civilization advances separately from the others. But I could change it so that each civilization that belongs to a given entity all belong to the same Civilization, so that if you give one them access to steel, they all get it.

Honestly I thought the first one was the best way to do it, but you really only interact with a single civilization of an entity while playing fort mode (and my systems are all designed around fort mode). I don't know, I suppose I can add the option for both, but it's a lot more coding. I'm guessing the feature really won't be used by many people other than myself for my mod, and I only generate one civilization (with a high number of different populations) of each entity so that isn't a big deal for me.

I guess the question becomes, how often do you interact with different civilizations of the same entity in fort mode?
Title: Re: Roses' Script, System, and Utilities Collection (07/05/2016)
Post by: Dirst on August 13, 2016, 07:27:17 pm
Maybe use the word Nation instead of doubling up on Civilization?
Title: Re: Roses' Script, System, and Utilities Collection (07/05/2016)
Post by: Roses on August 14, 2016, 04:32:37 pm
Hmm, that's a good idea. But the question remains, should each civ have its own nation, or should each civ that belongs to a single entity be apart of the same nation? I keep going back and forth in my head. But I think I'm going to make it joined nations instead of individual nations.
Title: Re: Roses' Script, System, and Utilities Collection (07/05/2016)
Post by: vjmdhzgr on August 14, 2016, 05:16:14 pm
I like the idea of different civilizations having varying levels of technology so there's more to distinguish them, but I don't really care too much either way, and the mod you're planning already seem to be a lot of work so I'd go with what's easiest.

Also Dirst there's a bit of a difference between the relation of entities and civilizations and creatures and units. Civilizations are completely separate from the entity after world generation, but most ways you can edit a creature after world generation will still affect any units. Though I think the ways that don't will just cause crashes rather than do nothing, which is still an effect I suppose.
Title: Re: Roses' Script, System, and Utilities Collection (08/27/2016)
Post by: Roses on August 27, 2016, 04:23:58 pm
Well I have really been failing at my updates this summer, but here finally is another one. It includes a ReadMe for all three systems (Class, Civilization, and Event) as well as examples for both Class and Event Systems. The Civilization System doesn't include an example yet because I'm not sure how well it actually works. That is to say, it works without errors or things like that, but all it currently does is add and remove access to materials and items to entities, and I'm not sure if that is actually respected in game or not. So if someone would like to play around with it and let me know, I won't have a chance to fully test it out for awhile.

Up next is the wrapper script. Probably one of the most complex scripts for DF there is, it is currently usable, but can be greatly improved and (hopefully) simplified a bit. This next update should be faster than the others since it doesn't involve an entire system, although technically the wrapper script and functions is as large as one of the systems.

EDIT: I also updated the third post to include information about all three currently included systems.

EDIT2: Just noticed a fairly large issue with how I was reading in certain information from external files. I have just now uploaded a fixed version.
Title: Re: Roses' Script, System, and Utilities Collection (08/27/2016)
Post by: Roses on September 21, 2016, 05:07:56 pm
Alright, I am wrapping up the wrapper script (pardon the pun). I have added the ability to target units based off of their pathfinding and station (https://github.com/DFHack/df-structures/blob/master/df.pathfinding.xml). Both for required and immune. This allows for targeting units that are fleeing and other such things.

Before I finalize the script, are there any other targeting features that people would like to see as options the current list is
Code: [Select]
creature class
syndrome class
syndrome name
race
caste
body part
flag (i.e. skeleton, ambusher_hidden, etc...)
token (i.e. MEGABEAST, FLIER, etc...)
noble position
profession
skill level
attribute level
traits
speed
age
entity
pathfinding
stationI am also planning on adding targeting configuration for a units inventory, but if there is anything else people would like to see just let me know and I will see if I can add it in.
Title: Re: Roses' Script, System, and Utilities Collection (08/27/2016)
Post by: Roses on October 26, 2016, 01:19:57 am
So I know I haven't been updating this as much as I said I would, or as I would have liked. But I am nearing a new release for the improved wrapper system. And then I plan on working on the detailed unit viewer gui along with an in-game bestiary. This bestiary will tell you all the relevant information about the creatures of the world AND it will have pictures! See below for a proof of concept. Note that I am actually hoping on tying this in with Japa's Dwarf Portrait project so that by default you get a portrait like he has, and then if you have external images you would like to show instead those are overlayed. If/when Japa includes wounds on his paper doll models those could be included in the detailed unit viewer as well.

Spoiler (click to show/hide)
Title: Re: Roses' Script, System, and Utilities Collection (08/27/2016)
Post by: Mr. Orange on October 27, 2016, 04:20:53 am
Just want to say that it's awesome what you're doing Roses. Looking forward to the new stuff!
Title: Re: Roses' Script, System, and Utilities Collection (08/27/2016)
Post by: Roses on November 18, 2016, 01:09:56 am
I wanted to apologize for my lack of updates and my general absence from the boards lately. I have been dealing a lot with familial and personal issues this summer and have not gotten to invest as much time as I would like in this endeavor. That being said, I will be pushing my next update to github this weekend, and that is the wrapper script update. I am hoping that the update will make it more intuitive and easier to use as it provides a lot of targeting and logic options that are not available in DF or DFHack.

That being said, I am apologizing again for my limited appearance in the last few months. I know several people have messaged me and I am only now just responding. I am hoping to be more involved in the community moving forward so I hope those that were interested in my work here will keep posting and messaging me. I have thought a lot recently about what I would like to see from a mod and how the main reason I started writing all of these scripts is so I could create the mod that I have always wanted. I think that is closer than ever now, but unfortunately there are still several things that are missing from a scripting stand point before I would feel comfortable releasing a mod of my own. That being said I feel like over the course of the next month I will have a fairly decent chunk of time to put towards coding and I hope that I will be able to push the rest of my planned DFHack scripts and systems through so that I will finally be able to show case the power of these scripts.

I won't lie, the fact that very few people, if any, use these scripts I write has made it difficult to continue working, but I know that that is largely my fault in making the whole system more complicated and harder to understand. I am hoping that in the next month or so I will be able to tie everything together and show the community the power of the things I have envisioned. Again, sorry for my absence, and I hope I can make it up to you all in the coming weeks!
Title: Re: Roses' Script, System, and Utilities Collection (08/27/2016)
Post by: Meph on November 18, 2016, 06:16:01 am
Quote
I won't lie, the fact that very few people, if any, use these scripts I write has made it difficult to continue working, but I know that that is largely my fault in making the whole system more complicated and harder to understand.
Its not a fault to be a perfectionist. ;)

It would help a lot of you make small examples and release them as small mods, to show what people can do. The scripts are of course arcane if no one has used them yet.

I'd certainly still be interested... there are more races to be made with unique playstyles. ;)
Title: Re: Roses' Script, System, and Utilities Collection (08/27/2016)
Post by: Putnam on November 18, 2016, 06:28:31 am
I use the class system in Fortbent, and that's hopefully going to be the most extreme use case around (or else I'd feel real bad for whoever outdoes me), so that's an example of what it can do.
Title: Re: Roses' Script, System, and Utilities Collection (08/27/2016)
Post by: Roses on November 24, 2016, 12:56:07 am
The first pass as the wrapper script is now up. Hopefully it is more streamlined and easier to use. Below you will find a brief walkthrough. I will be creating a more in depth one soon that will include all of the options and what they do.

The wrapper script is, as it sounds, a script that wraps around your other scripts in order to provide much more complex options than can currently be found in game. The reason for it's development is two fold;
1. It allows any script writer to provide complex targeting options for their scripts without the need to write all of the code themselves.
2. It allows modders to create more meaningful interactions with custom targeting options and unit based outcomes.

The way the script works is as follows;
Starting with a standard script which adds 500 skill experience to the masonry skill to unit 0
Code: [Select]
modtools/skill-change -skill MASONRY -mode add -granularity experience -unit 0 -value 500
We can then place this script inside of the wrapper script, at the very basic level you will have
Code: [Select]
wrapper -sourceUnit 0 -checkUnit -script [ modtools/skill-change -skill MASONRY -mode add -granularity experience -unit SOURCE_UNIT_ID -value 500 ]
As it stands this gives us no extra advantages, however we can now begin adding in the options. The full list of targeting options are as follows
Code: [Select]
'requiredClass',
 'requiredCreature',
 'requiredSyndrome',
 'requiredToken',
 'requiredNoble',
 'requiredProfession',
 'requiredEntity',
 'immuneClass',
 'immuneCreature',
 'immuneSyndrome',
 'immuneToken',
 'immuneNoble',
 'immuneProfession',
 'immuneEntity',
 'maxAttribute',
 'minAttribute',
 'gtAttribute',
 'ltAttribute',
 'maxSkill',
 'minSkill',
 'gtSkill',
 'ltSkill',
 'maxTrait',
 'minTrait',
 'gtTrait',
 'ltTrait',
 'maxAge',
 'minAge',
 'gtAge',
 'ltAge',
 'maxSpeed',
 'minSpeed',
 'gtSpeed',
 'ltSpeed',
So if you wanted your script to only add experience to the unit if they were between masonry levels 1 and 5 you could add
Code: [Select]
wrapper -sourceUnit 0 -checkUnit -minSkill MASONRY:1 -maxSkill MASONRY:5 -script [ modtools/skill-change -skill MASONRY -mode add -granularity experience -unit SOURCE_UNIT_ID -value 500 ]
You can add as many or as few of the targeting options as you want into a single wrapper. But you aren't just limited for checking a single unit. Say you wanted to add the experience to all of your units within a given distance of the source unit
Code: [Select]
wrapper -sourceUnit 0 -checkUnit -radius [ 10 10 2 ] -script [ modtools/skill-change -skill MASONRY -mode add -granularity experience -unit SOURCE_UNIT_ID -value 500 ]
Only 5 units in the radius?
Code: [Select]
wrapper -sourceUnit 0 -checkUnit -radius [ 10 10 2 ] -maxTargets 5 -script [ modtools/skill-change -skill MASONRY -mode add -granularity experience -unit SOURCE_UNIT_ID -value 500 ]
Only friendly units in the radius?
Code: [Select]
wrapper -sourceUnit 0 -checkUnit Friendly -radius [ 10 10 2 ] -script [ modtools/skill-change -skill MASONRY -mode add -granularity experience -unit SOURCE_UNIT_ID -value 500 ]
In addition to the many many different targeting options you can come up with, you can also alter the actual scripts being run. For example, say you wanted to add masonry experience to a unit, but you wanted to do it based on how much strength that unit has? It's simple!
Code: [Select]
wrapper -sourceUnit 0 -checkUnit -value [ source.attribute.strength ] -script [ modtools/skill-change -skill MASONRY -mode add -granularity experience -unit SOURCE_UNIT_ID -value VALUE_1 ]
Average of their strength and toughness?
Code: [Select]
wrapper -sourceUnit 0 -checkUnit -value [ (source.attribute.strength+source.attribute.toughness)/2 ] -script [ modtools/skill-change -skill MASONRY -mode add -granularity experience -unit SOURCE_UNIT_ID -value VALUE_1 ]
And so on, and so on...

Now, because of the large number of different options I am sure you are bound to find some problems, whether it be that it's not doing anything or it's crashing. There is the option to add -verbose into your wrapper script, this will give you a little bit more information on what is going on.

Lastly, if you look at the script you will see several options that I haven't touched on here. For now consider those options not working (most of them are, but there are still some bugs). Currently the wrapper script only supports checking for units and their relations to other units. The next step will be checking locations, items, projectiles, and more. With these additional checks you will be able to;
1. Have a script that only targets tiles with trees around a unit
2. Have a script that only targets items, or weapons, or silver weapons, or silver short swords
3. Have a script to target corpses
4. Have a script to target projectiles
etc...

Any questions please let me know. And if the targeting options aren't working please let me know that as well. I did test nearly all of them in the arena.
Title: Re: Roses' Script, System, and Utilities Collection (08/27/2016)
Post by: Teneb on November 26, 2016, 11:18:12 am
I got a question about some of those targeting options, actually: what does the gt and lt in 'gtSkill' and 'ltSkill' and other stand for? greater/less than? If so, does it always compare to the unit running the interaction?

And if I may make a request, could you add an option to the class system for an attribute boost to only happen at a specific level instead of all levels? So, say, class A gets +5 strength at level 3 and only level 3.
Title: Re: Roses' Script, System, and Utilities Collection (08/27/2016)
Post by: Roses on November 27, 2016, 02:37:46 pm
Yes, gt and lt do mean greater/less than. The format is -gtAttribute STRENGTH:2, this means that the targeted unit has to have a strength more than twice that of the source unit.

Do you mean the LEVELING_BONUS or the temporary BONUS? (Class posted below for reference)
Code: [Select]
[CLASS:WARRIOR]
 [NAME:warrior:warriors]
 [LEVELS:5]
 [EXP:50:100:175:275:400]
 [LEVELING_BONUS:PHYSICAL:STRENGTH:10]
 [LEVELING_BONUS:PHYSICAL:TOUGHNESS:10]
 [BONUS_PHYS:STRENGTH:25:50:75:100:150]
 [BONUS_PHYS:TOUGHNESS:25:50:75:100:150]
 [SPELL:RALLY:1]
  [SPELL_AUTO_LEARN]
 [SPELL:BATTLE_SHOUT:3]
  [SPELL_AUTO_LEARN]
 [SPELL:LEADERSHIP:5]
  [SPELL_AUTO_LEARN]
I will assume you mean the leveling bonus since the temporary bonus is already level dependent. Yes, I can make the leveling bonus function the same way the temporary bonus works. If there is just one number it will apply that increase at every level, if you wanted it to only increase at the odd levels you could do
Code: [Select]
[LEVELING_BONUS:PHYSICAL:STRENGTH:10:0:10:0:10]I'll put it on my list of changes to make.
Title: Re: Roses' Script, System, and Utilities Collection (08/27/2016)
Post by: Roses on December 05, 2016, 12:59:23 pm
Small update coming out today;

The flow/source script, which previously only allowed you to create a source or sink for water or magma, now allows you to create a source for flows as well. This will create a flow with a given density continuously (at a set interval) until the flow is removed using the same script. Like the water/magma source and sink it will persist over saving and reloading.

I'm almost done with the second half of the wrapper script (location and item targeting) and will be pushing that through soon as well.

EDIT: The wrapper script has been updated to include location and item checking. It will allow you pick nearby trees and plants as well as ground based on your inputs. It can also pick out corpses, any item, and projectiles. All that is left for it now is to polish the value function as it is currently fairly limited in what it can do.
Title: Re: Roses' Script, System, and Utilities Collection (08/27/2016)
Post by: Roses on December 12, 2016, 01:54:52 pm
I don't really know where to ask this so I figured I would just put the question here so as not to clutter up any other threads.

What information would you want to see in a bestiary? Say someone handed you there mod and you encountered a creature you didn't know anything about. If you could push one button to find out all the information, what would that information be? I am thinking the basics, average size, lifespan, any natural skills, interactions and attacks, extracts, maybe prefstrings?, biomes. What else?

Note that this is different than my unit viewer (which I posted a couple pages back), that will include all the information related to the individual unit (i.e. it's actual size, attributes, skills, etc...) This is more just a... well a bestiary. It will allow you to look up creatures by name and by biome so say you are an adventurer and you are heading into a particular biome and you want to know what to expect, or if you want to hunt a griffon and you need to know what biome they are in, stuff like that.

As a bonus modders will be able to include any pictures they want so that you can see a pretty graphical representation of the creature. If there is no picture available I plan on to hook up Japa's Dwarf Portrait to give a visual representation of the creature and it's various body parts and such.

EDIT: Also, how should seperate castes of the same creature be handled? For the standard Male/Female split it's not too hard but what if there are 6 or 7 different castes? How should that information be shown?

EDIT2: To give you an example of what it will look like

Spoiler: The list of creatures, will be configurable to include or not include HFS (click to show/hide)
Spoiler: The caste list and where the information will go (click to show/hide)
Spoiler: The caste list for a creature with an image (click to show/hide)

Obviously sizing needs to be worked on, but overall I think it works well
Title: Re: Roses' Script, System, and Utilities Collection (08/27/2016)
Post by: Teneb on December 13, 2016, 12:43:11 pm
Since you want this bestiary to be more for adventurers, you may also want to add the activity time of the creature (dawn, day, dusk, night, all). Maybe also if (and what) they eat, if they can see and so on.
Title: Re: Roses' Script, System, and Utilities Collection (08/27/2016)
Post by: Nahere on December 13, 2016, 02:55:04 pm
Itemcorpses would be useful to know, given how many mods use them.
Title: Re: Roses' Script, System, and Utilities Collection (08/27/2016)
Post by: Roses on December 15, 2016, 03:11:25 am
Alright, now here's a question. When I am conveying information like NOPAIN and such, should I just use the DF token or should I put in some basic text describing that token, for example;

Code: [Select]
Traits:
                NOPAINvs.
Code: [Select]
Traits:
                Does not feel pain
EDIT: I suppose I could combine them, do something like
Code: [Select]
Traits:
                Does not feel pain [NOPAIN]
Title: Re: Roses' Script, System, and Utilities Collection (08/27/2016)
Post by: vjmdhzgr on December 16, 2016, 01:58:35 am
It looks like you're going to be having plenty of space on the bestiary screen, so just having both seems good.
Title: Re: Roses' Script, System, and Utilities Collection (08/27/2016)
Post by: Roses on December 23, 2016, 11:36:14 pm
Update to the bestiary script, I need to figure out how best to organize the information and display it still, but it's pretty much done.

Spoiler (click to show/hide)

EDIT: Ok, I added the ability to quickly make a compendium of basically anything in the game, including sorting and filtered searches. I just need to decide what information should be presented for each type of compendium. Currently I have;

Creatures - Pretty much everything shown in the above image plus the butcher results and any extra butcher objects or corpse item pieces
Plants - Biomes, seasons, growths, and plant products (drinks, mills, extracts, etc...)
Items - What it can be made of, any attacks it has, material size, armor stats (e.g. coverage), tool use
Inorganics (Metals, Gems, Stones) - Environment, material information (density, specific heat, boiling/melting point, etc...)

Is there anything else people would like to see added to the above lists, and are there any other lists that people would like to see? I was thinking about buildings and reactions lists, not particularly useful for vanilla but they could be very useful for modders. I am also going to make an interaction list, but I think that will be tied in with my spell system.
Title: Re: Roses' Script, System, and Utilities Collection (08/27/2016)
Post by: Roses on January 21, 2017, 09:56:57 pm
Been busy moving across country, but I have had a little time to work on some stuff. Here are some screen shots of the various compendiums. I am still trying to figure out the best way to display the information, and exactly what should be included. I do plan on having a way for you to provide descriptions for items, plants, and inorganics in the same way that there are creature descriptions. I'm also thinking about adding in what reactions things are used for. It's not shown in the below screenshots, but you can also look for specific types of items (like only show Weapons) and specific types of inorganics (only show Gems). I am interested in working on the biome information a little bit, currently, if you have a creature with [BIOME:ANY_LAND] it will show up as having 26 different biomes. It may just be easier to check for certain conditions and then replace the group of biomes with it's corresponding raws token. At the very least they should be grouped.

Spoiler: Bestiary (click to show/hide)
Spoiler: Herbiary (click to show/hide)
Spoiler: Inorganic Compendium (click to show/hide)
Spoiler: Item Compendium (click to show/hide)
Title: Re: Roses' Script, System, and Utilities Collection (08/27/2016)
Post by: Roses on February 02, 2017, 12:53:29 pm
Please note, my script collection repository on GitHub is currently broken, the basic scripts should all work, but the systems likely will not.

Here is a copy of the butcher script that I posted in the DFHack thread
Code: [Select]
local utils=require 'utils'
local gui = require 'gui'
 
validArgs = --[[validArgs or]]utils.invert({
  'help',
  'unit',
  'corpse',
  'location',
  'kill',
 
})

local args = utils.processArgs({...}, validArgs)
if args.help then
  print('')
  return
end

corpse = nil
if args.unit and tonumber(args.unit) then
 unit = df.unit.find(tonumber(args.unit))
 if not unit then return end
 if unit.flags1.dead then
  for _,id in pairs(unit.corpse_parts) do
   item = df.item.find(id)
   if df.item_corpsest:is_instance(item) and not item.body.components.body_part_status[0].missing and item.corpse_flags.unbutchered then
    corpse = item
    break
   end
  end
 else
  if args.kill then
   print('-kill not currently working')
  else
   print('Unit is still alive and has not been ordered -kill')
  end
 end
elseif args.corpse and tonumber(args.corpse) then
 item = df.item.find(tonumber(args.corpse))
 if not item then return end
 if df.item_corpsest:is_instance(item) then
  if not item.body.components.body_part_status[0].missing and item.corpse_flags.unbutchered then
   corpse = item
  end
 end
elseif args.location then
 locx = tonumber(args.location[1])
 locy = tonumber(args.location[2])
 locz = tonumber(args.location[3])
 block = dfhack.maps.ensureTileBlock(locx,locy,locz)
 if block.occupancy[locx%16][locy%16].item then
  for _,id in pairs(block.items) do
   item = df.item.find(id)
   if df.item_corpsest:is_instance(item) then
    if item.pos.x == locx and item.pos.y == locy and item.pos.z == locz then
     if not item.body.components.body_part_status[0].missing and item.corpse_flags.unbutchered then
      corpse = item
      break
     end
    end
   end
  end
 end
end
if not corpse then return end

local view_x = df.global.window_x
local view_y = df.global.window_y
local view_z = df.global.window_z
local curViewscreen = dfhack.gui.getCurViewscreen()
local dwarfmodeScreen = df.viewscreen_dwarfmodest:new()
curViewscreen.child = dwarfmodeScreen
dwarfmodeScreen.parent = curViewscreen
local oldMode = df.global.ui.main.mode
df.global.ui.main.mode = df.ui_sidebar_mode.LookAround
local old_gametype = df.global.gametype
df.global.gametype = df.game_type.DWARF_ARENA

df.global.cursor.x = corpse.pos.x
df.global.cursor.y = corpse.pos.y
df.global.cursor.z = corpse.pos.z
for i,_ in pairs(df.global.ui_look_list.items) do
 df.global.ui_look_cursor = i
 if dfhack.gui.getCurFocus() == 'dwarfmode/LookAround/Item' then
  if corpse.id == dfhack.gui.getSelectedItem().id then
   break
  end
 end
end
gui.simulateInput(dfhack.gui.getCurViewscreen(), 'D_LOOK_ARENA_ADV_MODE')

df.global.gametype = old_gametype
curViewscreen.child = nil
dwarfmodeScreen:delete()
df.global.ui.main.mode = oldMode

df.global.window_x = view_x
df.global.window_y = view_y
df.global.window_z = view_z
Title: Re: Roses' Script, System, and Utilities Collection (08/27/2016)
Post by: Teneb on February 02, 2017, 02:59:10 pm
On the bestiary: I think a neat idea might be a list of what interactions a creature is capable of. Doesn't help much in vanilla, but sure does with mods.
Title: Re: Roses' Script, System, and Utilities Collection (08/27/2016)
Post by: Roses on February 02, 2017, 08:00:20 pm
Quote from: Teneb on February 02, 2017, 02:59:10 pm
On the bestiary: I think a neat idea might be a list of what interactions a creature is capable of. Doesn't help much in vanilla, but sure does with mods.

Yep, that is in there. The bestiary will only show interactions that are innate to the creature, but the unit viewer that is also coming will show all interactions, both innate and learned. The only thing I haven't been able to add that I want to is a list of what you get by butchering the creature. I know the exact amount of things will vary based on the creatures size. But it would be cool if you looked up Dragon, and saw that you would get Dragon Scales from butchering it. Note that extra butcher objects and corpse items are already included, I'm just talking about the vanilla stuff.
Title: Re: Roses' Script, System, and Utilities Collection (08/27/2016)
Post by: zilpin on February 02, 2017, 10:10:57 pm
Nice work, Roses!
Title: Re: Roses' Script, System, and Utilities Collection (08/27/2016)
Post by: Roses on February 09, 2017, 06:17:28 pm
How unreadable is this?
Code: [Select]
[EQUATION:FIRE_DAMAGE_1:(50+10*SOURCE.ATTRIBUTE.PRIMARY/1000-5*TARGET.ATTRIBUTE.PRIMARY/1000)*(100-TARGET.RESISTANCE.!_TDDS+SOURCE.STAT.!_SKILL_PENETRATION)/100*(1+math.max(0,math.floor(math.min(1,EQUATION.MAGICAL_CRIT_CHANCE/math.random(100))))*(EQUATION.MAGICAL_CRIT_BONUS-100)/100)]
I'm experimenting with customizable equations. Basically if you don't like the way my scripts or systems do something, you can easily change it. Don't like how I compute hit chance for script attacks?
Code: [Select]
[EQUATION:PHYSICAL_HIT_CHANCE:STAT.HIT_CHANCE+STAT.!_HIT_CHANCE+5*SKILL.WEAPON]
You can change it! The only problem is some equations (like the first one) can be a bit difficult to read. (Don't worry about what the values actually are, that is all well documented)
Title: Re: Roses' Script, System, and Utilities Collection (08/27/2016)
Post by: Putnam on February 09, 2017, 07:49:10 pm
I would rather just manually write an extra script for that; there comes to be a point where that's easier.
Title: Re: Roses' Script, System, and Utilities Collection (08/27/2016)
Post by: Roses on February 10, 2017, 12:12:59 pm
True, but then if you want to add new functions you will need to go into the script and modify them, some people might not be comfortable editing lua files. But yes, instead of having the whole equation written out I could just link it to a script.
Title: Re: Roses' Script, System, and Utilities Collection (08/27/2016)
Post by: Roses on February 15, 2017, 03:35:49 pm
So since every time I make a change to one of my scripts/functions/systems I usually end up breaking another, and have often put out buggy code I have decided to invest the time in writing a test script. What this script does is check that all systems, scripts and functions are performing correctly. That all required raw entries are found and that everything is in order. When run it will generate a LOT of text and information. It will alter units, entities, and the map so it should only be used in fort mode and only on a save you don't care about. After it is run it will generate a simple list of anything that was found to be not working.

And because I can't do anything simple without adding way more than is needed, I have generalized the test system to work for anyones scripts, they simply need to follow the standard format (i.e. the processArgs format) and one of the arguments needs to be -testRun with the corresponding test code written there. The testing script will then run all scripts it can find with the -testRun command. Note that many scripts need units, locations, buildings, and items. The testing script picks these things randomly and inserts them into the -testRun script. This won't work for all scripts, but it should give some good benchmarks.
Title: Re: Roses' Script, System, and Utilities Collection (08/27/2016)
Post by: Roses on February 24, 2017, 04:56:40 pm
So I am playing a bit with my random creature creator (RCC) and trying to create better templates. Here are some of the creatures. They are pretty messed up, granted this is with all of the options turned on. You will get much more reasonable creatures by only choosing from certain templates (e.g. don't mix and match tentacles and arms/legs, etc...)

This one shows off the body part color naming scheme along with the single body part name (blob) and hairless name (bald). The description isn't too crazy.
Code: [Select]
[NAME:pink skinned bald blob:pink skinned bald blobs:pink skinned bald blob]
[DESCRIPTION:A common animal found in the wilderness., It lives in deep underground places. A hairless leathery creature with a single part body,
a large head and no eyes, a simple nose, a beak, and large ears. It has two tentacles attached to it's upper body with claws and six tentacles attached to it's lower body with clubs.
It Is only found underground. It cleans itself when dirty. Maximum Size: 19kg ]
This one shows off the eye color naming along with feathered naming (both fluffed and fowl come from the feather template). I should restrict words to a single template. The number of fingers in the description might be a little much.
Code: [Select]
[NAME:fluffed purple eyed fowl:fluffed purple eyed fowls:fluffed purple eyed fowl]
[DESCRIPTION:A common animal found in the wilderness. A feathered creature with a single part body, a head a single horn and four eyes, no nose, a beak, and pointed ears.
It has two arms and hands with four fingers each and two legs with hooves. It Is found in hardy places. It often greets other animals by head bumping them. It cleans itself when dirty. Maximum Size: 22kg ]
Here is one with a basic name and a description that doesn't match it at all. The fen comes from the temperate wetland, and the centipede comes from the 100 legs (again number of claws seems overkill). The name should probably mention that it is tusked or it has pincers or some such
Code: [Select]
[NAME:fen centipede:fen centipedes:fen centipede]
[DESCRIPTION:A common animal found in the wilderness. A hairy creature with a two part body, two heads two tusks and two eyes, a snout, a beak, and no ears.
It has four arms with large pincers and one hundred legs and feet with four claws each. It Can be found in any temperate wetland. Maximum Size: 20kg ]
For reference, limiting which templates are chosen from you can get creatures like, which actually doesn't sound too bad.
Code: [Select]
[NAME:tropical claw-fowl:tropical claw-fowls:tropical claw-fowl]
[DESCRIPTION:A common animal found in the wilderness. A feathered creature with a two part body, a head four horns and no eyes, no nose, a beak, and no ears. It has two wings and two legs and feet with four claws each. It Can be found in any dense tropical location. Maximum Size: 4kg ]
What I really need to do now is create more templates and think up more names. Should I branch out from english? Start using prefixes like geo/terra/aqua/aero? I am using names like crustacean, insect, amphibian, reptile, etc... Should I change those to specific creature names? There are a couple templates I do that for (e.g. the single horn template can have the name unicorn, the single eye template can have the name cyclops, etc...) I could also just make names random, or select words from the language files.

EDIT: Alright, I added the ability to link templates, so now you can have a single torso template that's linked to specific other templates to create more complex random creatures. For example, say you wanted to create a host of random scorpions (with six legs, two arms with pinchers, and a stinger and the rest random) you would just need to create the scorpion torso template and link it with the appropriate legs, arms, and attachments. Then the creator will select random biomes, material templates, facial features, extra attachments (wings, spikes, etc...), and other additions to make each scorpion unique.

EDIT2: Another update, I have added the ability to weight templates. before you had to make multiple copies of a template if you wanted it to be more selected than another, now you just change it's weighting.
Title: Re: Roses' Script, System, and Utilities Collection (08/27/2016)
Post by: Kaytavo on March 04, 2017, 09:11:13 pm
Hello I was looking at your scripts, and decided to try it. Since using these scripts/systems is mostly DIY, I was wondering two things:

1. Is there a program to easily make the raws/txt files or should I just use Notepad++?

2. Would it be ok once I finish getting every thing set up to release my .txt's for class/civs/ect. so that others can you them?

Thank you in advance.
Title: Re: Roses' Script, System, and Utilities Collection (08/27/2016)
Post by: Putnam on March 04, 2017, 09:42:35 pm
1. notepad++

2. i've already done that with fortbent, it shouldn't be a problem
Title: Re: Roses' Script, System, and Utilities Collection (08/27/2016)
Post by: Kaytavo on March 04, 2017, 10:06:41 pm
Quote from: Putnam on March 04, 2017, 09:42:35 pm
1. notepad++

2. i've already done that with fortbent, it shouldn't be a problem

Fortbent has this set up? hmm i must of grabbed an old version then, as DFHack did not list any class related commands in that console

EDIT: it seems the rose-init line is commented out
EDIT2: ok i got the command to work... sort of... it always says "no unit declared" i'm in adv mode btw
EDIT3: ok i have gotten it to work mostly needed -unit # and -class name, but it isn't doing much unfortunitly
Title: Re: Roses' Script, System, and Utilities Collection (08/27/2016)
Post by: Roses on March 06, 2017, 11:50:41 am
Sorry, I don't have internet at home currently so I don't get to get on here much on the weekend.

1. Yeah, I use notepad++
2. And like Putnam said, I actually encourage you to share your work. Like you said it's mostly DIY with me just providing the framework so please do share any work you do with it.

Now on to your problems, if you are using Fortbent I can't be of much help since Putnam has his own way of interfacing with my scripts (which is totally fine too and once again encouraged!). If you aren't using Fortbent can you elaborate on what you mean by, "it isn't doing much"?
Title: Re: Roses' Script, System, and Utilities Collection (08/27/2016)
Post by: Kaytavo on March 08, 2017, 05:52:33 pm
well i'll have to figure out how to install it into a clean copy first. I tried putting it in the raws folder but i have the impression that is wrong, should probably put in in the dfhack folder ok appearently there is another raw folder in hack, oops.
Title: Re: Roses' Script, System, and Utilities Collection (08/27/2016)
Post by: Roses on March 08, 2017, 07:04:46 pm
No, it should go in the DF_DIR/raw/ folder not the DF_DIR/hack/raws (or whatever the dfhack one is)
Title: Re: Roses' Script, System, and Utilities Collection (08/27/2016)
Post by: Roses on March 20, 2017, 12:08:45 pm
First I would like to apologize for the lack of updates. No reliable internet for two months is rough, but this week/weekend should be a good one.

So I am getting ready for a major release this week and wanted to give a little heads up on two things that have changed.

1. Previously in all of my systems I made a distinction between physical and mental attributes. For example the Class System would use BONUS:PHYS_ATTRIBUTE and BONUS:MENT_ATTRIBUTE, both of these still work (for backwards compatibility) but they just link to BONUS:ATTRIBUTE, so going forward you can just use BONUS:ATTRIBUTE (and for any of the other systems just get rid of any reference to physical or mental). Note that all changes are backwards compatible, and if you prefer to make the distinction in your files you are free to do so. But it is no longer required.

2. Many of the names of functions in my various functions/x.lua scripts have been "changed". The reason for the parenthesis is that I have linked the old function names with the new one, again for backwards compatibility. The reason for the change is I made the function name more consistent with what the function returns.
  a. All functions that start with check (e.g. checkInventoryType) will return true/false.
  b. All functions that start with get (e.g. getInverntoryType) will return a list of whatever it was trying to get or an empty list if nothing is found.
  c. All functions that start with change (e.g. changeAttribute) will change something in game, if the change is successful it will return true, it will return false if unsuccessful
  d. All functions that start with add/remove (e.g. addAttack) will add/remove to/from an existing table (in the case of addAttack it will add to the unit.actions table). These don't have any return
  e. All functions that start with compute (e.g. computeAttackValues) use functions and whatever inputs are needed to calculate a number(s)
  f. All functions that start with find (e.g. findBuilding) use a specially defined string (more info will be available in the ReadMe) to locate the id/ids of the desired object
  g. All functions that start with queue (e.g. queueCheck) create a persistent delay object which triggers at a latter time (even after a save/reload)
  h. All functions that start with track (e.g. trackAttribute) are used in conjunction with a change function and are for the purpose of advanced interactions
There are a number of other functions named specifically for what they do, but this change helps me better remember what each function does/returns

Right now I am in the process of testing all of the changes and additions I have made over the past month without reliable internet. The big holdup right now is making sure the Detailed Unit Viewer works on all units, and in all modes. The problem is that currently it used view_screen shenanigans to get the various thoughts, preferences, emotions, etc... that you would get in the normal unit viewscreen. But these screens are different for different modes, and again different for various units (tame vs. not-tame animals, civ fort members vs civ non-fort members, etc...). I am thinking it almost might be easier to read all of the details from the unit directly and recreate the text. That would ensure it works in any mode on any unit. Something that is interesting about using the view-screen method is that tame animals will have the same set of entity preferences that their civ does, even if those would normally not be shown in the normal unit viewer.
Title: Re: Roses' Script, System, and Utilities Collection (08/27/2016)
Post by: Amostubal on March 22, 2017, 09:28:52 am
ptw
Title: Re: Roses' Script, System, and Utilities Collection (08/27/2016)
Post by: Amostubal on March 22, 2017, 01:31:48 pm
well I had started following to await any future release information, but I had found an error in one of your scripts when used in dfhack 43.05 beta 1.  so I'll post it for you or anyone else who may be in need of it.

In on-death.lua v1.0 line 43, old line:
Code: [Select]
killer_id = tonumber(target.relations.last_attacker_id)
replace with new line:
Code: [Select]
killer_id = tonumber(target.relationship_ids.LastAttacker)

just a change needed when moving from 43.03 to 43.05.  That line was spamming errors at me over here. I love reading through your scripts, I feel like I've learned something as I move page to page.
Title: Re: Roses' Script, System, and Utilities Collection (08/27/2016)
Post by: Putnam on March 22, 2017, 03:54:37 pm
That's a universal problem, I'm going to have to update all of my scripts to account for the complete removal of the relations struct and moving of everything in it to other places.
Title: Re: Roses' Script, System, and Utilities Collection (08/27/2016)
Post by: Roses on March 22, 2017, 07:02:29 pm
Yeah, I just saw in the DFHack thread that the relations entry was removed and things were moved to other places. Since I am still working in the last version of DFHack I hadn't noticed. I will make sure to make note of each of the places that need to be adjusted. Ideally we could get a bash script or something that goes through all the scripts and makes the adjustments, but I've got enough other stuff to work on that that would be a very low priority

https://i.img.ie/0cO.png
https://i.img.ie/0cH.png
https://i.img.ie/0cd.png
https://i.img.ie/0cG.png
https://i.img.ie/0cW.png
Title: Re: Roses' Script, System, and Utilities Collection (08/27/2016)
Post by: Roses on March 27, 2017, 01:12:06 pm
I promised a release and I hate to dissapoint, so here it is. For simplicity sake I am going to break the release up into parts and release them over the next couple of days. First up is the Journal GUI!

Journal GUI: This GUI allows you to browse all in game buildings, creatures, items, inorganic materials, organic materials, plants, and reactions. It displays the relevant information in a (hopefully) conviniently readable format. Note that the layout and such is easily changed, so any suggestions for moving things around, changing wording, or adding information can easily be handled. Below is a set of screen shots showing how the Journal works, including an example for each of the previously mentioned categories.

Typing gui/journal in the command line will open up a window like this (Food is not currently supported)
Spoiler: Journal (click to show/hide)
Selecting one of the categories (for this example Creatures) will open up another window with some selection options
Spoiler: Selection (click to show/hide)
After selecting the options you want for display (right now the options are fairly limited, but more will be added with time and requests) a list of objects will appear (note that most information for creatures is stored at the caste level)
Spoiler: Objects (Creatures) (click to show/hide)
If available a red message will appear on the top of the right side telling you to press enter for more detailed information (currently only available for Creatures -> Castes)
Spoiler: SubObjects (Castes) (click to show/hide)

Spoiler: Buildings (click to show/hide)
Spoiler: Items (click to show/hide)
Spoiler: Inorganics (click to show/hide)
Spoiler: Organics (click to show/hide)
Spoiler: Plants (click to show/hide)
Spoiler: Reactions (click to show/hide)

In the future I would like to add the ability to include an image in any of the journal entries (for an example see this (http://www.bay12forums.com/smf/index.php?topic=152762.msg7292872#msg7292872) post). Work still needs to be done for the butcher and extra butcher objects for creatures, and better layout control for all of it. Ideally I will be able to link all of the objects together so that if a building needed a specific material you would be able to select that material and it would take you to it's object page so that you would be able to figure out where it is and how to get it.

Up next will be the Detailed Unit Viewer, with Class System support
Title: Re: Roses' Script, System, and Utilities Collection (08/27/2016)
Post by: ragundo on March 27, 2017, 01:21:58 pm
Amazing !!!!
PTW
Title: Re: Roses' Script, System, and Utilities Collection (03/28/2017)
Post by: Roses on March 28, 2017, 12:03:13 pm
Time for release number 2! So here is the Detailed Unit Viewer (DUV), unfortunately trying to link the DUV into the Class System caused some unforeseen errors to appear so I had to roll back a couple of changes. What this means is you can view the class information of a creature, but you can't yet change classes.

Typing gui/detailed-unit will bring up the main screen which shows;
Spoiler: DUV Main (click to show/hide)

On the bottom of the screen you will see different key options, currently the available options are for Attributes, Classes, Syndromes, and Thoughts/Preferences.
Spoiler: Attribute Details (click to show/hide)
Spoiler: Class Details (click to show/hide)
Spoiler: Syndrome Details (click to show/hide)
Spoiler: Thoughts and Preferences (click to show/hide)

In the future I will be adding interaction, health, and relationship information tabs, along with a complete tie-in with the Class System so you will be able to change classes, learn spells and traits, and all other Class System related options.

Up next will be the expanded Random Creature Creator (RCC) along with it's new and improved ReadMe

EDIT: Just realized I forgot to do a final commit to master branch this morning, so hold off on checking out the DUV until I get home and can upload the most recent version.
Title: Re: Roses' Script, System, and Utilities Collection (03/28/2016)
Post by: Roses on March 29, 2017, 04:01:31 pm
Alright, todays release will be the Random Creature Creation (RCC) script. Note that this script required Python 3+

First I would like to give a little preamble, if you are looking for a random creature generator that just works (and works well) I can't recommend Knight Otu's work (http://www.bay12forums.com/smf/index.php?topic=91255.0) enough. It is very good. While both of these scripts have the same end purpose, the generation of random creatures, they have a fundamentally different mode of reaching that purpose. Knight Otu's scripts read your raws and generates creatures based on what you have there. The RCC instead relies on templates that you provide and gives more control over the generation, but also requires a lot more work. For this reason I have dubbed this a creature creator instead of generator since it requires you to actually create the creatures (or in this case the templates that become creatures).

A complete ReadMe is provided with the script, but below is an outline of the RCC;

First up are templates, these are what are read in and then chosen from. The exact method for how templates are chosen is covered in the ReadMe, but basically it will pick one template from each category, and make a creature out of those templates. Here is an example of what some HEAD and MATERIAL templates look like
Spoiler: Templates (click to show/hide)

When you have all of your templates created that you want, running the program generates a GUI for added input. Within the GUI there are several things you can modify. A complete list of what each object is can be found in the ReadMe. Mousing over a field will also give you a brief description of it's purpose in case you forget.
Spoiler: GUI Main Page (click to show/hide)

In addition to the changes that can be made on the front page of the GUI there are also several side menus. These menus let you change things like, which templates are actually available to use, and other more complex changes.
Spoiler: GUI Side Menus (click to show/hide)

Finally selecting Generate Creatures will create a file for the given number of creatures you wish to generate. If instead you select Sample Creature it will create a single creature and output it's raws for you to check that things are working how you expect them to.
Spoiler: Sample Creature (click to show/hide)

The script currently comes with a wide variety of templates and the raws that would be required to actually use the creatures, but these are simple provided for examples. In the future I will include all of the templates and raw files that I am using for the current mod I am working on, but I thought it would be better to get the script out so that others could make their own templates if they wanted.

Up next will be the new and improved wrapper script, unfortunately this change is not backwards compatible, but the parts that need to be changed can easily be done by a Find/Replace command.
Title: Re: Roses' Script, System, and Utilities Collection (03/28/2016)
Post by: Roses on March 31, 2017, 05:14:42 pm
I decided to postpone the wrapper update until this weekend since it relies on tables that have changed in the newest DFHack version. So this weekend I will port all of my scripts to the newest version and release the wrapper update at the same time
Title: Re: Roses' Script, System, and Utilities Collection (03/28/2016)
Post by: Teneb on April 01, 2017, 10:19:48 am
Awesome stuff Roses. Possibly expect PMs pestering you for info.
Title: Re: Roses' Script, System, and Utilities Collection (03/28/2016)
Post by: Roses on April 01, 2017, 06:50:47 pm
Quote from: Teneb on April 01, 2017, 10:19:48 am
Awesome stuff Roses. Possibly expect PMs pestering you for info.

Of course, also feel free to ask questions here, since more than one person might have the same question.
Title: Re: Roses' Script, System, and Utilities Collection (03/28/2016)
Post by: Roses on April 19, 2017, 10:34:34 am
Alright I am going to be pushing a release in the next couple of days. This release will be different than others as it will be DFHack version specific. With the change in the unit data structure several of my scripts stopped working (as some have pointed out). Now I know that an official release of DFHack 43.05 hasn't come out yet, but the beta version is pretty stable, so after this release if you want to use my scripts you will need to be running DF and DFHack 43.05.
Title: Re: Roses' Script, System, and Utilities Collection (03/28/2016)
Post by: Roses on May 04, 2017, 12:41:17 pm
Sorry I haven't uploaded recently. Work got crazy this last week. But I am still chugging along. I've fixed up the test run script so that it will be much easier in the future to find out what scripts need updating, and to make sure all 50+ scripts and 200+ functions are working correctly. I have also added the ability to change classes, learn spells, and gain feats directly to the Detailed Unit Viewer (DUV). Which brings a question to mind;

If you were playing a game and it had a spell book, would you expect the spell book to show you all spells, only spells available to your class, or only spells that are available to your class and you already know? I am trying to figure out the best way to organize all the information and I keep going back and forth. Note that there are two different "Spell Books", one that is accessible from the DUV, and on the is accessible from the Journal. For the Journal version I am just listing every spell so that it acts more like a compendium of information. The DUV version is the one I am having trouble deciding on.

EDIT: Well I have decided to have all three display options available through a simple toggle. You will be able to see all spells, only spells you know, only spells that are active, only spells for your current class, spells you can learn.
Title: Re: Roses' Script, System, and Utilities Collection (03/28/2016)
Post by: Amostubal on May 22, 2017, 07:31:14 am
awesome work Rose.  My only question, is there a central location for documentation?  I've been scanning scripts and I have an "idea" of what is going, but not enough to "know" what's going on.  Its hard to understand how they mesh together. 

one error:  the top of base/roses-init: it states to put it in DFHack.init... but that is outside of the range where persist-tables can operate, so it errors on the first actual line of code.  Shouldn't it be put at the top of onLoad.init, when a map is actually loaded and persist-tables can operate?
Title: Re: Roses' Script, System, and Utilities Collection (03/28/2016)
Post by: Roses on May 22, 2017, 09:12:45 am
Quote from: Amostubal on May 22, 2017, 07:31:14 am
awesome work Rose.  My only question, is there a central location for documentation?  I've been scanning scripts and I have an "idea" of what is going, but not enough to "know" what's going on.  Its hard to understand how they mesh together.

Unfortunately the documentation writing has not kept up with the script writing, I was working on more detailed information, the start of which can be found here (https://docs.google.com/document/d/1eKR1yTFdPJrqWehsshD8nPxhx0O8P33HQkggf_v-t-U/edit?usp=sharing) for scripts and here for functions (https://docs.google.com/document/d/1d84xpc5DcKlytZSS829Lga_llns7DR4mxiYJ2P5ET7c/edit?usp=sharing), but some information is out of date and some is just missing (I'm really hoping to work on better documentation, but it's sooo boring...). The ReadMes in the Git repo should be the most up to date versions for the Class, Civilization, and Event Systems. Please feel free to ask as many questions as you want in this thread, I am happy to answer them, it will also probably help me write documentation since it will give me an idea of where questions are, what needs to be better documented (or documented at all), and eventually what I can improve on.

Note that most of my scripts and such are not as plug and play friendly as other modders/script writers. Not only is there a certain lack of polish, but most have way more functionality than a standard user would ever use, with options that are really only there for my own use. For example you can use syndromes to track changes made by certain scripts so that you can remove those changes with other scripts, i.e. If you have a script that gives a unit +2000 strength for 600 ticks, you can have a "dispell" script that removes the buff, but also knows to correctly remove the callback for reverting the unit's strength. These types of options and such are for when I get my act together and actually publish my "spell" repository I am working on.

Quote from: Amostubal on May 22, 2017, 07:31:14 am
one error:  the top of base/roses-init: it states to put it in DFHack.init... but that is outside of the range where persist-tables can operate, so it errors on the first actual line of code.  Shouldn't it be put at the top of onLoad.init, when a map is actually loaded and persist-tables can operate?

You are indeed correct, that line was placed there before I really understood the differences between the various init files and what DFHack was really doing. It just has never been changed. I will get that updated ASAP.
Title: Re: Roses' Script, System, and Utilities Collection (03/28/2016)
Post by: Amostubal on May 22, 2017, 09:52:32 am
well I forked your github to my pc, this morning... decided to update all the scripts in MDF to the most recent version... now chasing down the few errors i know exist because of the data-structural change from 43.03 to 43.05. I can send some pull requests on things I spot as I go through here, possibly even pass it through a DFHack version check so that both codes can exist side by side without error, so its forward/backward compatible.  Its not many errors, at the moment, but I'm sure I will find more as I test out the script region.

Additionally, I type as fast as I read, so I could start creating usage blocks at the start of the scripts, based on what I see in them; then you can just suggest corrections. I read lua code and dfhack structure fairly well and it would be a learning experience.  adding such documentation, may assist people in understanding what is going on inside the script and what they need called for different things.  Dealing with MDF... I've discovered inter-dependencies that I didn't know existed.  I could do it in my downtime around my other projects (you got to take breaks, lol).
Title: Re: Roses' Script, System, and Utilities Collection (03/28/2016)
Post by: Roses on May 22, 2017, 10:11:34 am
Quote from: Amostubal on May 22, 2017, 09:52:32 am
well I forked your github to my pc, this morning... decided to update all the scripts in MDF to the most recent version... now chasing down the few errors i know exist because of the data-structural change from 43.03 to 43.05. I can send some pull requests on things I spot as I go through here, possibly even pass it through a DFHack version check so that both codes can exist side by side without error, so its forward/backward compatible.  Its not many errors, at the moment, but I'm sure I will find more as I test out the script region.

Additionally, I type as fast as I read, so I could start creating usage blocks at the start of the scripts, based on what I see in them; then you can just suggest corrections. I read lua code and dfhack structure fairly well and it would be a learning experience.  adding such documentation, may assist people in understanding what is going on inside the script and what they need called for different things.  Dealing with MDF... I've discovered inter-dependencies that I didn't know existed.  I could do it in my downtime around my other projects (you got to take breaks, lol).

If you want to add some comments and know how to use Git I don't mind at all looking through pull requests. Right now I'm not using great Git practice since I am updating dozens of files at a time with a single commit message, but oh well.

I actually have been working on updating to 43.05 myself (mainly the removal of the unit.relations struct). I should say that I have already updated on my local machine, I'm just working on getting this run-test script to work flawlessly so in the future if any changes are made (either to DFHack or to DF's inner working itself) I can quickly find them and correct/account for them. I suppose now that the official DFHack version has been updated to 43.05 I should just push the necessary changes to make it work. I'm not too concerned about backwards compatibility, I suppose if someone feels super strong about it I can offer it, but personally my plan was always to keep my scripts up to date with the most recent non-beta version of DFHack.

EDIT: Also wanted to say that I have gotten class changing, spell learning, and feat adding put into the Detailed Unit Viewer. Screenshots will be coming soon, but currently when you look at a unit and select Class Details you will see a list of available classes, colored green if the unit has experience with the class, yellow if they don't, you can also toggle all classes, or just classes that are available to your civ (if using the Civilization System), the classes that the unit can not become will be colored red. Hitting enter on a class will give you a prompt asking if you want to change, and will then switch the units class.

Spells are similar, with the view toggalable between all spells, known spells, and class available spells. You can then toggle these on and off. For most mods I expect all known/available spells will want to be toggled so when changing classes that is the default. But you can also specify that a class can only have a certain number of spells active at one time (default to infinity). This will allow a spell system that functions more like D&D Mages where you can only have a certain number active, in the future it would be interesting to make a D&D Sorcerer like system where instead of a certain number of spells active you have a certain number of uses per time period, but that is much more complicated.

Feats function basically the same except that they cost "Feat Points" to learn, and are permanent once learned (No Respeccing!) The current number of feat points available are displayed on the feat page so you can see what that unit has.

Like I said, screenshots to better illustrate all of these changes will be coming "soon", I am basically just playing with layout and positioning. (it's hard to create a custom GUI placement when everyone has different monitor sizes, resolutions, and some play in windowed vs fullscreen)
Title: Re: Roses' Script, System, and Utilities Collection (03/28/2016)
Post by: Amostubal on May 22, 2017, 11:37:26 am
Great! well I got to churn through a few errors real quick and drop an update (I broke MDF, accidentally, somewhat)...  but I'm getting back on track, I will look at it latter today/the week;  see where I can pitch in some assistance, in between everything else on my plate ;)
Title: Re: Roses' Script, System, and Utilities Collection (03/28/2016)
Post by: Roses on June 08, 2017, 11:17:29 am
So, in addition to providing an updated release for the new DFHack version this weekend, I am also re-releasing the utility Modding with Excel (MWE). Basically it is a python script that will read in raw txt files and convert them to csv. Or it will read in a csv file and convert it to a raw file. Below you will find an example for inorganics;

The conversion process from raw -> csv -> raw
Spoiler (click to show/hide)

A larger look at what the csv file looks like (large image)
Spoiler (click to show/hide)

Currently the program handles buildings, inorganics, items, plants, and reactions. I am working on getting it set up to handle creatures, but they are much more complicated than anything of the other raws. Interactions and templates should be easy enough to handle, just haven't gotten around to it yet. Expect an update this Saturday or Sunday.
Title: Re: Roses' Script, System, and Utilities Collection (06/12/2016)
Post by: Roses on June 12, 2017, 05:47:06 pm
All scripts have been updated to the newest DFHack version (43.05), the run_test script is working (sort of), and the MWE utility is released. I'm sure there's a bug or two, but hopefully not that many.
Title: Re: Roses' Script, System, and Utilities Collection (06/12/2016)
Post by: Roses on September 06, 2017, 02:06:26 pm
Sorry I have been away so much, work has really been piling it on lately. Here is a small proof of concept update for the journal I have been working on. Note that the artwork isn't necessary, but it does give it a little more flair (although it poses a big problem with different sized screens and monitors because of the way it is put in, so I will probably just change it to not have that, mostly just wanted to see how it would look.

Spoiler: Main Journal/Compendium (click to show/hide)

Spoiler: Main Bestiary/Creature Compendium (click to show/hide)

Spoiler: Creature List (click to show/hide)

Spoiler: Creature/Caste List (click to show/hide)

One major improvement I have made to the journal is that all journal entries will now be linked. That means that when you select on a butcher object (once they are implemented) you will be taken either to that item or that material (depending on what it is). For a toad this isn't very interesting, but say you have a custom creature that drops a special gem, you could click the gem, be taken to that items journal entry and see it's information as well as all the reactions it is used in and, if using the Enhanced System, any description you provided. You can then select any of the reactions and you will see the buildings and descriptions for the reactions, etc... Hitting escape is like hitting the back button on your browser. Think of the journal as a wikipedia for your world. Eventually I will add the option to make some things hideable, like if you don't want a player to know about a certain creature, or if you have a bunch of different materials or items that are added just for dfhack purposes that shouldn't be mentioned. In the late future I would also like to have the option to only have journal entries updated when you encounter the creature/item/material/building/etc...

I'm still fine tuning the sizing and spacing, but hopefully I'll be able to share this updated version of the journal soon.
Title: Re: Roses' Script, System, and Utilities Collection (06/12/2016)
Post by: Roses on September 09, 2017, 12:06:21 am
So I am picking up from where I left off and just now realizing that I left several of my scripts in a quasi-unplayable state (actually the scripts are fine it's the systems that suffer) which is probably why Putnam (the main user of the Class System) was forced to create his own system for Fortbent (also my Class System provided a lot more bells and whistles than Fortbent needed which make Putnam's decision to make his own even more underdstandable). I apologize that I've been absent and that my work was left in a subpar state. Over the next couple of weeks I plan on making sure everything I have release is working correctly, and also building on the infrastructure I already have to make my next release(s) more substantial. I'll be updating my first post as well over the next week or so, but I wanted to illustrate some of the advantages that a modder would get from using some of my scripts over others that are already provided. So here is a little PR piece.

Many scripts (and even some builtin functions of DFHack) provide options for changing a units attributes. So why would I include a script for changing attributes in my collection? The main problem I had with the current scripts is that they all simple added or removed a set amount of an attribute. My scripts allow adding and removing, as well as multiplying/dividing and even setting to a specific value. In addition, the modification of an attribute can be associated with a specific persistent value. This means that you can have multiple attribute increasing effects (e.g. effect A that increases Strength and effect B that increases Agility) and have them be removed by the same script. This "dispel" option is a big reason that I decided to duplicate many of the functions that current scripts provide as I wanted there to be "dispel" spells that could remove ANY attribute/skill increase in an effective and efficient way.

This tracking system is currently already working, but is so closely tied to my Class System that it makes it practically unusable by any other modder. That is why, over the next few weeks, I am playing on decoupling my various scripts from my various systems. A modder should be able to use any individual part of my work, without worrying that the parts they don't want will interfere. In addition, over the next month, I will be releasing my current mod with 9+ playable races, 40+ classes and 1000+ spells that will utilize all of my scripts and systems to their fullest so that other modders can get an idea of the power of some of what I have done (I've been really bad at showcasing exactly what I have done offers modders).

On a side note, I really want to thank Putnam and Meph, both of who have used a lot of what I have done in their own work, and who have adapted what I have done to make it actually usable. They have given me a lot of ideas to process over the next chunk of time about features vs usability and providing a product that doesn't fail 90% of the time.
Title: Re: Roses' Script, System, and Utilities Collection (06/12/2016)
Post by: Putnam on September 09, 2017, 02:06:51 am
my decision was more future-proofing and accountability than anything; i wanted to be able to quickly remember exactly what does what and where so that i could fix things if a problem shows up. I still use some of the other stuff, like the select-all-units-in-circle and makeprojectile things.

Weirdly enough, I think I wrote my own persist-timeout even though I'm not sure that that was ever necessary. I'm not entirely sure why I did.
Title: Re: Roses' Script, System, and Utilities Collection (06/12/2016)
Post by: Roses on September 09, 2017, 03:57:45 am
Quote from: Putnam on September 09, 2017, 02:06:51 am
my decision was more future-proofing and accountability than anything; i wanted to be able to quickly remember exactly what does what and where so that i could fix things if a problem shows up. I still use some of the other stuff, like the select-all-units-in-circle and makeprojectile things.

Weirdly enough, I think I wrote my own persist-timeout even though I'm not sure that that was ever necessary. I'm not entirely sure why I did.

Totally understandable. I was looking at your persist-timeout and I think I liked the way you handled some stuff better than the way I did it.
Title: Re: Roses' Script, System, and Utilities Collection (06/12/2016)
Post by: Elowin on September 15, 2017, 09:27:51 am
Quote from: Roses on September 09, 2017, 12:06:21 am
So I am picking up from where I left off and just now realizing that I left several of my scripts in a quasi-unplayable state (actually the scripts are fine it's the systems that suffer) which is probably why Putnam (the main user of the Class System) was forced to create his own system for Fortbent (also my Class System provided a lot more bells and whistles than Fortbent needed which make Putnam's decision to make his own even more underdstandable). I apologize that I've been absent and that my work was left in a subpar state. Over the next couple of weeks I plan on making sure everything I have release is working correctly, and also building on the infrastructure I already have to make my next release(s) more substantial. I'll be updating my first post as well over the next week or so, but I wanted to illustrate some of the advantages that a modder would get from using some of my scripts over others that are already provided. So here is a little PR piece.

Many scripts (and even some builtin functions of DFHack) provide options for changing a units attributes. So why would I include a script for changing attributes in my collection? The main problem I had with the current scripts is that they all simple added or removed a set amount of an attribute. My scripts allow adding and removing, as well as multiplying/dividing and even setting to a specific value. In addition, the modification of an attribute can be associated with a specific persistent value. This means that you can have multiple attribute increasing effects (e.g. effect A that increases Strength and effect B that increases Agility) and have them be removed by the same script. This "dispel" option is a big reason that I decided to duplicate many of the functions that current scripts provide as I wanted there to be "dispel" spells that could remove ANY attribute/skill increase in an effective and efficient way.

This tracking system is currently already working, but is so closely tied to my Class System that it makes it practically unusable by any other modder. That is why, over the next few weeks, I am playing on decoupling my various scripts from my various systems. A modder should be able to use any individual part of my work, without worrying that the parts they don't want will interfere. In addition, over the next month, I will be releasing my current mod with 9+ playable races, 40+ classes and 1000+ spells that will utilize all of my scripts and systems to their fullest so that other modders can get an idea of the power of some of what I have done (I've been really bad at showcasing exactly what I have done offers modders).

On a side note, I really want to thank Putnam and Meph, both of who have used a lot of what I have done in their own work, and who have adapted what I have done to make it actually usable. They have given me a lot of ideas to process over the next chunk of time about features vs usability and providing a product that doesn't fail 90% of the time.

Wow, that's pretty ridiculously huge. I'll look forward to diving into it when it's ready.

I've always wanted a magic system in Dwarf Fortress. I've tried to build a few basic interaction based spells using some of your scripts in the past, but I'm pretty awful with DFHack and could never get the interaction trigger script to work for me.
Title: Re: Roses' Script, System, and Utilities Collection (06/12/2016)
Post by: Roses on September 22, 2017, 03:33:03 pm
Update: Apparently the last commit I made to github broke more than I realized. It took awhile but I finally got the run-test script to function properly. It now runs through each of my scripts and systems and does a variety of checks and then tells you if the script/system passed or failed. Almost all of the scripts are currently being checked (I still need to enable a couple, and figure out how to properly test a couple others). This will allow me to keep up on dfhack changes as well as make sure that any changes I make in the future don't break something.

My current plan is to have a release at the end of next week with all scripts and systems working correctly. If I have the time I am also planning on releasing an update to the Journal and Detailed Unit Viewer GUI's

EDIT: Update 2: I've decided to re-write the way the Detailed Unit Viewer works. Currently it copies the text that the in-game unit viewer creates when you inspect a unit (i.e. all the attribute information, thoughts, emotions, likes, dislikes, etc...). But I found that lots of that information isn't very useful, so I will be reading the values and creating my own sentences (in the same way the game does it currently, but instead of, for example, any unit with over X strength gets Y description, it will instead give Y description depending on the unit's X strength in relation to the creatures average strength). I will also add an extra button that will allow you to see the current information as well, but it won't be the default.
Title: Re: Roses' Script, System, and Utilities Collection (06/12/2016)
Post by: Fleeting Frames on September 28, 2017, 08:43:01 am
Hm, detailed unit info viewer?

The screenshot was pretty cool, well lets try it...Hm, don't see a thread, nor helptext

*attempts to get it to work*
Spoiler (click to show/hide)
oh ok, a dependency, lets add it...
Spoiler (click to show/hide)
Ah, it's using df.global.world.history.figures[unit.hist_figure_id] instead of df.historical_figure.find(unit.hist_figure_id)
Spoiler (click to show/hide)
Line 2805: local classTable = persistTable.GlobalTable.roses.ClassTable

Uh

hm. Going to need a class system on vanilla save.

Yeah, I'm starting to see why you said things are pretty closely tied to class system and why you'd recommend downloading everything. Slightly worried/wondering about conflicts (more than I'm curious, anyway), though, given many examples of your great work has already been integrated in dfhack core.

Any present that you can think of?
Title: Re: Roses' Script, System, and Utilities Collection (06/12/2016)
Post by: Roses on September 28, 2017, 10:17:49 am
The viewer was never really updated to DF 0.43.X properly, so I'm not surprised there are many issues. Sorry about that! I'll get to work on that ASAP.

You shouldn't need the Class System, it's just currently it's not working correctly. When I upload the new version it should work without the Class System. Unfortunately it does rely on many different functions, but all you should really need is the scripts/gui folder and the scripts/functions folder. There shouldn't be any conflicts between any of my scripts and those included in DFHack (and, as far as I know, none of the other currently active scripters work). Most of my work that has been included/used by the DFHack team and other scripts have been renamed and/or used in different ways (which is actually very nice since it does avoid conflicts while still disseminating the work).

I think there was an effort several DFHack versions ago to include all of my work in the base DFHack, but I think everyone agreed that it would be better not to try to incorporate them as I hadn't written them with that in mind.

EDIT: Just as a clarification. The basic structure of all my scripts is reliant on the scripts/functions folder. To use any of the scripts included in my repository all you SHOULD need is the script and the functions folder (the Systems will need the entire systems folder, not just individual scripts). Hopefully I have managed to keep this true as I've continued to create new scripts and modify old ones.
Title: Re: Roses' Script, System, and Utilities Collection (06/12/2016)
Post by: Fleeting Frames on September 28, 2017, 10:27:22 pm
No need for ASAP - like I said, it was more of a curiosity, and also a case study on "how does one get it to work" anyway. Good to know about conflicts.

To continue it along the same vein, there's the matter of getting the scripts/functions folder (I know I didn't get to tables.lua above, for instance) - if you know how, the simplest way would be to create a github account and pull the whole repo - otherwise, the end user has to open up 15 files in raw mode in github, copy every one, and for every one create a new text file and save them in it. Of course, there's many large advantages to using modules, to put it lightly, but I think there's gotta be a better way to get the folder and all its contents.
Title: Re: Roses' Script, System, and Utilities Collection (06/12/2016)
Post by: Roses on September 29, 2017, 08:14:14 am
I'm a big supporter of git, so I don't see any trouble with GitHub, but if people have ideas for other options I am open to suggestions.
Title: Re: Roses' Script, System, and Utilities Collection (06/12/2016)
Post by: Fleeting Frames on September 29, 2017, 09:50:48 am
It's something that really only shows up when you move beyond single files to multiple libraries.

I can think of few options:
 - Compressed folder with all the scripts. 3 clicks and it's downloading.
 - Small script or maximally simple instructions for those who just want to try out the scripts and don't have a preexisting reason to use github beyond this.
Title: Re: Roses' Script, System, and Utilities Collection (06/12/2016)
Post by: Roses on September 29, 2017, 10:12:05 am
Actually, even without a github account you can just download the entire package as a zipped archive by clicking the Clone or download button (it's green) on the top level page.
Title: Re: Roses' Script, System, and Utilities Collection (06/12/2016)
Post by: Fleeting Frames on September 29, 2017, 10:17:59 am
...

...How did I miss that?

...

...I probably know how. I read clone and disregarded everything after that.

>_> (Didn't RTFM.)
Title: Re: Roses' Script, System, and Utilities Collection (06/12/2016)
Post by: Roses on October 03, 2017, 12:58:48 pm
Yeah, I always thought they should decouple the Clone and Download button. To me they do two fundamentally different functions, so it's odd that they use the same button.

Well, things were going really well in terms of progress, and then I got sidetracked with the idea of storing all the custom skills/attributes/resistances/stats/etc... in the actual df.global.world.units.active.X table. Easy enough for skills, not so much for the others. So now that I have that idea out of my head things are back to progressing nicely. All currently tested scripts are working and performing well, and the list of untested scripts is growing smaller. The currently untested scripts are
Code: [Select]
item/equip
item/unequip
unit/create
unit/destroy
unit/emotion-change
unit/wound-change
The Systems are in a similar state, with most being tested and working, the following are still untested
Code: [Select]
Class System - Spell SubSystem
Enhanced System - Buildings
Enhanced System - Reactions
In addition the GUIs (both gui/journal and gui/detailed-unit-viewer) are not currently working (as Fleeting Frames found out).

I've already got new ideas for scripts and Systems I want to implement so I am going to do my best to finish the above items up quickly and not get sidetracked. For the most part the changes and checking should be fairly simple for scripts. System checks are much more detailed (a difference ~15 lines of code to test a script and 500-1000 lines to test a System).
Title: Re: Roses' Script, System, and Utilities Collection (10/15/2017)
Post by: Roses on October 15, 2017, 08:06:37 pm
Alright, so first release in a while. The github has been updated. All scripts in the repository should be working and updated to 43.05. That being said I'm sure there will be some problem I didn't foresee, also in process of updating they won't be backwards compatible. The detailed unit viewer is also working even if you don't use the Class System, although the spacing is still a little strange. The journal hasn't been updated to include the links, but it does work for all the in game information, just takes some more time to find what you might need.

There will be more updates coming soon, as I work on individual scripts and create new ones.
Title: Re: Roses' Script, System, and Utilities Collection (10/15/2017)
Post by: Roses on November 27, 2017, 02:46:17 pm
In preparation for DFHack moving to the new DF version I have been going through my scripts/systems and the run_test script to make sure everything is working correctly and apparently my most recent git push broke a couple things, I have sensed fixed most of them, and added script tests for the previously missing scripts. I just need to add tests to the remaining untested systems and then I will do another push.

Also, I have started working on a couple new scripts and additions to previous scripts;

1. unit/attack - Currently this script creates an attack action with various user inputs. However this limits it to just working for basic attacks (i.e. an attack between two units right next to eachother). But what about creating an attack spell that you want to hit further away (e.g. Flame Whip)? So I am adding the ability to trigger the attack at range. Unfortunately there is nothing built-in to DF to handle this, so it involves a lot of DFHack chicanery, but I think I have a method that will work.

2. item/animate - This is a tricky one. I've always thought it would be cool if you could animate a certain item/object. However, to make this work correctly you would need to make a creature corresponding to each item/material combo, making it unrealistic. Instead I have created a "template" creature with 25 castes (note that the 25 is because I assumed you would never have more than 25 different item/material combos animated at the same time, if you think you will have more/less you can add/remove the extra castes). When you run the animate script it will find one of the castes that is not being used and modify the caste raws to mimic the item that is being animated. This involves changing names, materials, attacks (if applicable), etc... For those of you wondering why it has to be so complicated, when you change a castes raws you change all units tied to that caste, so you can't just use on creature/caste for all your animations.

3. tile/geomancy - This script will read the tile material at a specified location, and perform a specific command depending on that tiles material. I am still ironing out exactly how the user will specify what commands to trigger on what tile materials, but other than that it is a pretty straight forward script. (Thank to Milo Christianson's work on finding tile material with lua)

4, action-trigger - This will be an extension of the current modtools/item-trigger (with a couple non-item required extras). Currently item-trigger allows for triggering scripts on equipping/unequipping an item or striking with one. What this script will do is allow script triggering on any action (dodge, parry, block, attack, move, etc...), You will be able to specify that the effect occurs only when a certain item is equipped/used, only if a certain creature performs the action, only if a certain syndrome class is present on the unit, or some combination there of. Now you will be able to make a shield that, if blocked with, will send the attacker flying backwards.

I've also been working on adding more options to the Enhanced System, namely for buildings. Currently it allows for creating multi-story buildings, buildings with walls and roofs, outside/inside only (currently this feature is also available straight from DFHack), building only near water/magma, building only on specific materials, requiring both water and magma, and specifying certain criteria are met before building (e.g. >X population/kills/deaths/wealth/etc..., other buildings being built, other buildings not being built, and more). What I am adding to it is allowing buildings some more automation and features for the buildings themselves (e.g. buildings that trigger scripts every X ticks, buildings that provide/consume power, which is already possible with DFHack, buildings that trigger a script if a unit walks by, and more). Note, for those of you unfamiliar with my "Systems" all of this is achieved by reading in external files, which I have decided to create in the DF raw format, that the user provides. I will provide a couple of examples, but largely these are just systems (get it!) that a modder can use to provide extra features.

Also, I have decided to put my Expedition System on hold until I get a good grasp on what the new version of DF can do in terms of raids and such.
Title: Re: Roses' Script, System, and Utilities Collection (10/15/2017)
Post by: Amostubal on November 27, 2017, 07:33:31 pm
I found an issue in flow/source.lua

basically if you ever remove any source or sink in any way... you destroy the table length.  so your process of selecting a key for the table causes a critical failure where the removed key reduces the table length by one... so here's the math.

source 1 is created, key is "0", because the table length is 0.
source 2 is created, key is "1", because the table length is 1 ("0").
source 1 is removed, so key "0" disappears completely.
source 3 is created, key is "1", because the table length is 1 ("1"). <- critical error.
after this point any source created is just going to rewrite key "1" repeatedly until the entire table is deleted.

the error is due to how persist-table works when a key is set to nil... it completely removes the key making it no longer available to the table length.

my fix was to change the key to a system that doesn't rely on the table length at all.  so all the parts that say:
number tostring(#liquidTable._children)
I replaced with:
number = tostring(df.global.cur_year).."."..tostring(df.global.cur_year_tick)..".0"..tostring(x)..tostring(y)..tostring(z)

to be exact there is like 5 of those lines in the script and since this new format didn't require reliance on the table choice (flow or liquid) I just replaced the first instance that occurs before all of it, and removed the other 4.

basically even if someone sets up a reaction to make multiple calls to source in the same tick... they most likely wouldn't use the same X.Y.Z So this has the wonderful effect of creating keys that look like this:
5.30972.095.069.0172.0 <-I like how for some reason x,y,z had a .0 after them making the location read 095, 069, 0172 thats why I add the ".0"
a completely unique non repeatable key creation, as soon as the next game tick occurs, that key generation is completely gone.  I considered doing a random between 0 and 1,000,000,000,000,000,000,000,000 but I figured it would eventually find a way to repeat.

there is other errors in the script also, besides that.

like here in line 52:
 if not args.removeAll or not args.removeAllSource or not args.removeAllSink then

so what you was wanting was that if any of those args are true to not do the next code block. the problem is the logic doesn't work that way. the line is seeking a true answer to do the following block so say you had args.removeAll and not the others:
if not (true) or not (false) or not (false) then
...
if false or true or true then <-  this is true by lua logic so the line does the next code block, which is not what you wanted the line to do.

replacement line 52:
 if not ( args.removeAll or args.removeAllSource or args.removeAllSink ) then

not ( true or false or false ) = not ( true ) = false <- which is the result you wanted.

I also wrote a report list that spit out the liquidTable info int DFHack specifically for figuring out what was going on.

If you want I can send over to your github the fixes I made to that script.
Title: Re: Roses' Script, System, and Utilities Collection (10/15/2017)
Post by: Roses on November 27, 2017, 07:39:28 pm
Quote from: Amostubal on November 27, 2017, 07:33:31 pm
I found an issue in flow/source.lua

snipped

Great to know, I guess my test of the script would never have found that since all I do is try to place them, check that they were placed, then try and remove them and check that they were removed, don't think I ever tried adding again after one was removed. I'll make this change. Thank you very much
Title: Re: Roses' Script, System, and Utilities Collection (10/15/2017)
Post by: Amostubal on November 27, 2017, 07:58:18 pm
Quote from: Roses on November 27, 2017, 07:39:28 pm
Quote from: Amostubal on November 27, 2017, 07:33:31 pm
I found an issue in flow/source.lua

snipped

Great to know, I guess my test of the script would never have found that since all I do is try to place them, check that they were placed, then try and remove them and check that they were removed, don't think I ever tried adding again after one was removed. I'll make this change. Thank you very much

not a problem, I never really noticed it before and have used this script hundreds of thousands of times through reactions in MDF and MMDF and never noticed this weirdness.  Generally I used it exactly as you stated, turning some sources on then turning them off... most times turning all of them off long before trying to turn another on.

If it wasn't for me messing with a copy of this script that I'm modifying for other purposes ... I wouldn't have noticed this at all, but I was playing with turning on and off several things do to the nature of modifying when I started noticing that certain sinks and sources would suddenly disappear.

it was really interesting, because my sources are being placed in channels that drop 2z into a pool that is being used to test sinks that has an overflow exit tunnel to one side on the in between z level.  all this to test a few workshops and additional stuff.

So when I turned one off mid way through and then turned another one on... and then a third stopped, I thought I had set bad reaction triggers, something that has happened before. that wasn't it. that led me to investigate the source and sink functions, and the update functions and then finally give up and write a report option into source to print the liquidTable into something legible.   Its funny how we think something is true and it isn't true and we suddenly have our mind blown.
Title: Re: Roses' Script, System, and Utilities Collection (10/15/2017)
Post by: Roses on December 05, 2017, 01:21:52 pm
For some reason I just noticed your last line of your previous message. If you are familiar with Git and want to submit a pull request that would be great! Would save me having to go through the same fixes
Title: Re: Roses' Script, System, and Utilities Collection (10/15/2017)
Post by: Meph on December 08, 2017, 08:42:10 pm
Good to see you are still around. :)
Title: Re: Roses' Script, System, and Utilities Collection (10/15/2017)
Post by: Amostubal on December 08, 2017, 09:55:57 pm
Quote from: Roses on December 05, 2017, 01:21:52 pm
For some reason I just noticed your last line of your previous message. If you are familiar with Git and want to submit a pull request that would be great! Would save me having to go through the same fixes

sorry I missed this line, I'll look into this week... since I did the changes in my own version of the code, I'll have to remake it in the original roses script.

I used it to make a pipe-dreams hack script system that's in my newest pack.  basically I used your liquid sinks/sources on one side, with the other side maintaining lists of pipes and machines on the network, and how they connect.  Currently its working fairly well and I plan to separate it out and release it as a module once the next dfHack is stable and I've tested it on it.
Title: Re: Roses' Script, System, and Utilities Collection (10/15/2017)
Post by: Roses on December 09, 2017, 04:51:59 pm
If it's a big hassle you don't need to worry about it. I think you gave me enough information to make it pretty quick (I know it can be difficult to navigate some of my stuff)
Title: Re: Roses' Script, System, and Utilities Collection (10/15/2017)
Post by: Amostubal on December 10, 2017, 11:16:06 am
Quote from: Roses on December 09, 2017, 04:51:59 pm
If it's a big hassle you don't need to worry about it. I think you gave me enough information to make it pretty quick (I know it can be difficult to navigate some of my stuff)

I believe I sent it, but I wasn't on my test computer, so I didn't test it, there may be typos, regretfully.
Title: Re: Roses' Script, System, and Utilities Collection (10/15/2017)
Post by: Urist Sonuvagimli on December 11, 2017, 02:33:30 am
One of the curses of DF adventurer mode is inability to manually create titles (earned after 5 significant kills). Is there such a functionality in this plugin?
Title: Re: Roses' Script, System, and Utilities Collection (10/15/2017)
Post by: Meph on December 15, 2017, 03:54:51 pm
Just wanted to let you know that the building subtype-change script still works in dfhack-alpha for 44.02 without any issues. :)
Title: Re: Roses' Script, System, and Utilities Collection (10/15/2017)
Post by: Roses on December 18, 2017, 12:44:09 pm
Quote from: Meph on December 15, 2017, 03:54:51 pm
Just wanted to let you know that the building subtype-change script still works in dfhack-alpha for 44.02 without any issues. :)

That's good to know. I'm guessing that pretty much all my scripts will work with the 44.02 alpha, but I was going to wait until after the holidays to actually confirm that. If there are any changes that need to be made to make it compatible I will probably move the current master branch into a 43 version  branch and continue 44 work in the master branch.
Title: Re: Roses' Script, System, and Utilities Collection (10/15/2017)
Post by: Roses on December 19, 2017, 02:33:03 pm
So since I will be going to the land of slow internet and no people for the holidays I will have a lot of time to do other stuff. One thing I really want to do is get working on this mod I keep mentioning (for those that don't know I have a D&D-esque world I have created that I play with my friends that I have been meaning to translate to DF for years, and is actually the reason I started all of my scripts and systems since they were needed to properly translate it), but I will also have time for scripting.

Now I have a list of things I want to get done, but since it's the holidays and all, I thought I would ask people if there was any scripts they have been wanting but might not have the time/knowledge necessary to create it and I will add it to my to do list.

Quote from: Urist Sonuvagimli on December 11, 2017, 02:33:30 am
One of the curses of DF adventurer mode is inability to manually create titles (earned after 5 significant kills). Is there such a functionality in this plugin?
Sorry for the late reply. I'm actually not sure about that, I've never really played adventure mode, so I don't even know how most of my scripts would fair, let alone how the title information is stored. But, as per my above message, I will look into it over the holidays and have a script for you in the new year that lets you create titles
Title: Re: Roses' Script, System, and Utilities Collection (10/15/2017)
Post by: Roses on December 29, 2017, 08:42:40 pm
Getting some decent work done on my various scripts/systems. I have now made it easier to create your own "magical" items. For example;

A shield that increases your shield skill by 5 and everytime you block with it there is a 50% chance that the attacker will get flung away from you
Code: [Select]
[ITEM:FORCE_SHIELD]
 [ON_EQUIP]
  [SKILL_CHANGE:SHIELD:5]
 [ON_BLOCK]
  [CHANCE:50]
  [SCRIPT:unit/propel -unitSource ATTACKER_ID -unitTarget DEFENDER_ID -velocity [ 25 25 0 ] -mode relative]
Our a cloak that gives you a speed boost each time you dodge
Code: [Select]
[ITEM:CLOAK_OF_SPEED]
 [ON_DODGE]
  [CHANCE:100]
  [DEFENDER_SYNDROME_ADD:SPEED_UP]

These would go in a seperate file that is read by the game at start up and can either be automatically applied to certain items in the game (i.e. if you had a shield with FORCE_SHIELD as it's ID in your raws, then the game would automatically apply the effects to those shields, or be manually applied via the command line (or reactions/interactions/syndromes/etc...)

The above are examples of items with magical properties, but you can also create materials with magical properties. The system is basically the same except instead of having a magical shield item you could create a magical material that if you made a shield out of it, any time you blocked with that shield something would happen. Or if you made a sword out of it something else would happen.
Title: Re: Roses' Script, System, and Utilities Collection (10/15/2017)
Post by: Meph on December 29, 2017, 09:03:39 pm
These sound fantastic for adventure mode. :)
Title: Re: Roses' Script, System, and Utilities Collection (10/15/2017)
Post by: Roses on December 30, 2017, 03:22:11 pm
Quote from: Meph on December 29, 2017, 09:03:39 pm
These sound fantastic for adventure mode. :)

I hope it all works in adventure mode. I really need to set up a test script for trying them all out. I've got them all running in Fort mode, any they just use things like modtools/item-trigger, which I am pretty sure work just fine in adventure mode.

I also, got the Enhanced Buildings working. So now you can have working multi-story buildings (it's kind of a cludgy work around, but seems to work fine). You can also require a certain size in the z direction be available in order to build a building. As an example a multi-story cathedral can be designated like this.
Code: [Select]
[BUILDING:MULTI_STORY_CATHEDRAL]
 [OUTSIDE_ONLY]
 [WALLS:BUILDING_MAT:STONE]
 [ROOF:BUILDING_MAT:STONE]
 [FLOORS:BUILDING_MAT:STONE]
 [LEVELS:5]
 [PILLAR:1:1]
 [LEVEL:1:MULTI_STORY_CATHEDRAL]
 [LEVEL:2:CATHEDRAL_LEVEL_2]
 [LEVEL:3:CATHEDRAL_LEVEL_3]
 [LEVEL:4:CATHEDRAL_LEVEL_4]
 [LEVEL:5:CATHEDRAL_TOP_LEVEL]When you start construction of the MULTI_STORY_CATHEDRAL building it will check to make sure there is enough room for all five levels and that it is outside. It will then construct floors, a roof, and walls out of whatever stone material is being used in the base construction of the building (if the building material being used isn't stone it will default to a local stone material). Walls and roof are optional, the PILLAR argument states which position you want to act as a pillar that holds the whole thing up. If you are using walls it is not necessary. Each level needs to have it's own BUILDING_WORKSHOP raw entry, as it is basically just constructing buildings on buildings. I'm hoping to tie the construction of different levels to the build stages of the base building, but right now it just completes all of them at once. I haven't tested out building destroyers and multistory buildings yet, but I'm guessing it will fail miserably, as I barely have deconstruction working.

In addition to multi-story buildings, it is now easy to set up buildings with continuous effects. For example a building that continually produces mist every 10 ticks
Code: [Select]
[BUILDING:MIST_GENERATOR_BASE]
 [SPAWN_FLOW:MIST:100:10]Which is really just a shortcut for a building that runs a script
Code: [Select]
[BUILDING:MIST_GENERATOR_SCRIPT]
 [SCRIPT:flow/random-pos -location BUILDING_LOC -flow MIST -density 100:10]
To go along with Enhanced Buildings, Enhanced Reactions is coming along nicely. These reactions will basically allow you to specify a much wider range of reagents and products for a reaction. I will also be adding the ability to change reaction times, so you can make a reaction take as long as you want. The idea behind this addition was to be able to create things like quarries, where you assign a unit to perform the reaction with a certain amount of food and drink, then the unit goes to the quarry disappears for a couple days and then finishes the reaction with a certain amount of stone produced based on the units skill and what local stones are available. You will also be able to create stage like workshops where you can have a unit or group of units "perform" for a certain amount of time in order to give nearby units buffs and such.

Two notes;
1. I haven't played with the new version at all, so I don't know if anything that I am doing now will conflict with that. From what I can tell, no, but we shall see.
2. Like most of the scripting I do, these are all just tools for modders and players to use to add features to their game. Eventually there will be a mod of my own that uses all of these features, but for now the scripts come with just very basic examples. So if you want to know more about what they can do just ask!

Hope everyone is having a good holidays and happy new year (tomorrow). I should be pushing a big update on the 3rd or 4th of January when I get back to non dial-up internet.

EDIT: So something I did with the building triggers is now causing an intermittent crash. I'm trying to work it out before I push all the new stuff. If I can't figure it out in the next couple of days I'll probably just disable the Enhanced Buildings and Enhanced Reactions.
Title: Re: Roses' Script, System, and Utilities Collection (10/15/2017)
Post by: Roses on January 26, 2018, 06:18:45 pm
So a small update on progress. I meant to get changes pushed through by now but as usual I am fairly delayed. But fear not! Progress does continue, so here we go, green is done, yellow is in the testing stage, and red is in the planning stage;

1. modtools/action-trigger: A new script has been written to handle the "magical" items mentioned from a previous post. The reason I created this new script is because, while it was working fine before, it was limited to only work with my entire framework. This new script, which I will be submitting for inclusion in dfhack, does not rely on anything from my other scripts and systems. Of course my Enhanced Items and Enhanced Materials systems will add more functionality to the script and automate the components, any modder should now be able to set up action triggers in the same vein as item-trigger and interaction-trigger.

2. modtools/building-trigger: Following the same reasoning as above, this script essentially takes the current modtools/outside-only script and adds additional checks. For now you can check for a certain amount of height available, water and magma being available within 1 square of the buildings perimeter, other buildings already being built (as both a requirement and forbidden), and the outside/inside checks from the modtools/outside-only script. My Enhanced Buildings system will allow for much more (as outlined in the previous post), but splitting this script off into it's own thing allows other modders to benefit without the need for everything else.

3. modtools/reaction-trigger: This is more of a rewrite/rework of the existing modtools/reaction-trigger and modtools/reaction-product-trigger. This script combines the two together and allows for some more advanced options. It will probably need a new name because I'm not entirely sure it should replace the existing modtools/reaction-trigger, but for now I'll keep it what it is. The main reason for the creation of this script is to tie it into my Enhanced Reaction system, which needs more control than the current scripts have. Whether or not this should be included in default dfhack will be a decision for another time.

4. Civilization System - Diplomacy SubSystem: With mifki creating a script that can reliably force a siege, and the new DF features of sending out parties and such I figured it was time to actually make the Diplomacy SubSystem useful. Your standing with other civilizations will influence many different factors including, but not limited to, sieges, merchants, prices, immigration, and sending units to help you against other sieges.

5. Civilization System - Soldiers SubSystem: In conjunction with the Diplomacy SubSystem changes I am adding more configurable options for specifying a civilizations armies. Currently the Civilization System allows you to specify what materials and items are available to them (and Classes if using the Class System), but this leads to relatively random equipment of their units. The Soldiers SubSystem will allow you to set uniforms and other features. For instance, if you want to have a civilization that only ever sends its best soldiers you could set the Soldiers SubSystem to give all (or a percentage of all) units in a siege steel plate armor with steel weapons and enhanced skills and attributes, then when units from the civilization enter your map their inventories, skills, and attributes (and Classes if using the Class System) will be changed, Or another civilization might send lots and lots of poorly armed weak units and just a handful of extremely strong units, this will change the necessary things to achieve the preset stats of the armies. You will also be able to specify "Hero" units with a chance to show up on occasion.

6. Expedition System: This has been on my back burner for a long time now, with a lot of uncertainty about how I would even do it, but with the newest DF version and the ability to send out units I feel like now is a great time to take what is there and build on it. Originally this system was planned out to allow users to send units to raid, explore, quest, trade, steal, hunt, and more. I still need to figure out what features this system will have with respect to the new DF version and also which of those features are even remotely possible.

Once the reaction-trigger and Enhanced Reaction system is fully tested I will push a new release for the previous DF version. Once that is done I will migrate all of my scripts to the new DF version (shouldn't be too bad, especially since I spent an inordinate amount of time creating testing scripts), and then continue the work on expanding the Civilization System.

EDIT: reaction-trigger is coming along nicely. I just figured out how to increase the length of reactions to an arbitrary length so I am pretty pumped about that, it was the last major change I wanted to make to the script so after a little more testing it should be ready to go.
Title: Re: Roses' Script, System, and Utilities Collection (02/07/2018)
Post by: Roses on February 07, 2018, 12:25:15 pm
Warning: Long Post Incoming!

Good news everyone! I just (last night) pushed an update through! This update mainly focuses on minor bug fixes and fine tuning but there are a couple changes I would like to highlight.

First is the inclusion of three new scripts trigger/action, trigger/building, and trigger/reaction. These scripts (discussed in detail below) are stand alone scripts. What that means is that you can take them from my repository and use them as is. You can move and rename them anyway you want (I would suggest renaming them and putting them in modtools/action-trigger etc... since I will, hopefully, be getting them included in the main DFHack repo). Now what do they do? There is a brief description of them in the post above, but I'll go into more detail here. As with all trigger type scripts these commands need to be placed into the onLoad.init file.

1. trigger/action - This script is an extension of modtools/item-trigger. It allows you to trigger scripts when a unit does certain actions based on specific criteria. The exact options are;
Code: (trigger/action -help) [Select]
[[trigger/action.lua usage
arguments:
    -help
        print this help message
    -clear
        clear all registered triggers
    -actionType
        trigger the command when this action takes place
        valid values:
            Attack              -- This triggers whenever a unit makes an attack, whether or not the attack hits or misses
            Block               -- This triggers whenever a unit blocks an attack
            Dodge               -- DOES NOT CURRENTLY WORK, DODGES AREN'T ACTIONS
            Equip               -- Stolen from modtools/item-trigger, triggers when a unit equips an item
            Move                -- This triggers whenever a unit moves
            Parry               -- This triggers whenever a unit parries an attack
            Unequip             -- Stolen from modtools/item-trigger, triggers when a unit unequips an item
            Wound               -- Stolen from modtools/item-trigger, triggers when a unit wounds another unit
    ANNOUNCEMENT_TYPE   -- NOT CURRENTLY IMPLEMENTED
    -item type
        trigger the command for items of this type
        examples:
            ITEM_WEAPON_PICK
    -material mat
        trigger the commmand on items with the given material
        examples
            INORGANIC:IRON
            CREATURE:DWARF:BRAIN
            PLANT:MUSHROOM_HELMET_PLUMP:DRINK
    -contaminant mat
        trigger the command on items with a given material contaminant
        examples
            INORGANIC:IRON
            CREATURE:DWARF:BRAIN
            PLANT:MUSHROOM_HELMET_PLUMP:DRINK
    -creature creature
        trigger the command on creature performing the action
        examples:
            DWARF:ALL
            ELF:FEMALE
    -attack type
        trigger the command when a certain attack is performed
        obviously only works for the attack actionType
    -command [ commandStrs ]
        specify the command to be executed
        commandStrs
            UNIT_ID
            ATTACKER_ID
            BLOCKER_ID
            PARRIER_ID
            DEFENDER_ID
            BLOCKED_UNIT_ID
            PARRIED_UNIT_ID
            ITEM_MATERIAL
            ITEM_TOKEN
            ITEM_ID
            CONTAMINANT_MATERIAL
            anything -> anything
]])Unlike item-trigger this script checks that all three requirements are met before triggering a script. This means you could make an action trigger which only works if a male elf attacks with a mithril short sword coated in dwarf brain
Code: (All requirements Example) [Select]
trigger/action -actionType Attack -creature ELF:MALE -item ITEM_WEAPON_SWORD_SHORT -material INORGANIC:MITHRIL -contaminant CREATURE:DWARF:BRAIN -command [ blah ]You can also trigger a script any time a specific unit moves
Code: (-actionType Move Example) [Select]
trigger/action -actionType Move -creature DRAGON:ALL -command [ shake the ground or something ]Note that -actionType Dodge doesn't currently work because the game doesn't actually register the dodge as an action even though there is a dodge action type. The work around for this is allowing triggers off of combat reports as well. This will open up many new action types (list below), right now this is disabled but I do have a prototype version working, just need to find a full proof way to get the required information from the reports
Code: (Combat Report Types) [Select]
        <enum-item name='COMBAT_TWIST_WEAPON'/>
        <enum-item name='COMBAT_LET_ITEM_DROP'/>
        <enum-item name='COMBAT_START_CHARGE'/>
        <enum-item name='COMBAT_SURPRISE_CHARGE'/>
        <enum-item name='COMBAT_JUMP_DODGE_PROJ'/>
        <enum-item name='COMBAT_JUMP_DODGE_STRIKE'/>
        <enum-item name='COMBAT_DODGE'/>
        <enum-item name='COMBAT_COUNTERSTRIKE'/>
        <enum-item name='COMBAT_BLOCK'/>
        <enum-item name='COMBAT_PARRY'/>
        <enum-item name='COMBAT_CHARGE_COLLISION'/>
        <enum-item name='COMBAT_CHARGE_DEFENDER_TUMBLES'/>
        <enum-item name='COMBAT_CHARGE_DEFENDER_KNOCKED_OVER'/>
        <enum-item name='COMBAT_CHARGE_ATTACKER_TUMBLES'/>
        <enum-item name='COMBAT_CHARGE_ATTACKER_BOUNCE_BACK'/>
        <enum-item name='COMBAT_CHARGE_TANGLE_TOGETHER'/>
        <enum-item name='COMBAT_CHARGE_TANGLE_TUMBLE'/>
        <enum-item name='COMBAT_CHARGE_RUSH_BY'/>
        <enum-item name='COMBAT_CHARGE_MANAGE_STOP'/>
        <enum-item name='COMBAT_CHARGE_OBSTACLE_SLAM'/>
        <enum-item name='COMBAT_WRESTLE_LOCK'/>
        <enum-item name='COMBAT_WRESTLE_CHOKEHOLD'/>
        <enum-item name='COMBAT_WRESTLE_TAKEDOWN'/>
        <enum-item name='COMBAT_WRESTLE_THROW'/>
        <enum-item name='COMBAT_WRESTLE_RELEASE_LOCK'/>
        <enum-item name='COMBAT_WRESTLE_RELEASE_CHOKE'/>
        <enum-item name='COMBAT_WRESTLE_RELEASE_GRIP'/>
        <enum-item name='COMBAT_WRESTLE_STRUGGLE'/>
        <enum-item name='COMBAT_WRESTLE_RELEASE_LATCH'/>
        <enum-item name='COMBAT_WRESTLE_STRANGLE_KO'/>
        <enum-item name='COMBAT_WRESTLE_ADJUST_GRIP'/>
        <enum-item name='COMBAT_GRAB_TEAR'/>
        <enum-item name='COMBAT_STRIKE_DETAILS'/>
        <enum-item name='COMBAT_STRIKE_DETAILS_2'/>
        <enum-item name='COMBAT_EVENT_ENRAGED'/>
        <enum-item name='COMBAT_EVENT_STUCKIN'/>
        <enum-item name='COMBAT_EVENT_LATCH_BP'/>
        <enum-item name='COMBAT_EVENT_LATCH_GENERAL'/>
        <enum-item name='COMBAT_EVENT_PROPELLED_AWAY'/>
        <enum-item name='COMBAT_EVENT_KNOCKED_OUT'/>
        <enum-item name='COMBAT_EVENT_STUNNED'/>
        <enum-item name='COMBAT_EVENT_WINDED'/>


2. trigger/building - This is an extension of modtools/outside-only, basically it takes that script and adds extra checks to it. The exact options are;
Code: [Select]
Arguments::
    -clear
        clears the list of registered buildings
    -building BUILDING_TOKEN
        specify the id of the building
    -location OUTSIDE or INSIDE
        state whether the building needs to be built outside or inside
    -zLevels #
        the number of z levels needed for the building
    -requiredBuilding [ ID:# ]
        the id and number of a building(s) that needs to already be built to continue
    -forbiddenBuilding [ ID:# ]
        the id and number of a building(s) that cannot be already built to continue
    -maxNumber #
        the maximum number of this type of building
    -requiredWater #
        the amount of water next to the building that is required to build
        it will check every tile between x1-1->x2+1, y1-1->y2+1, and z-1->z
    -requiredMagma #
        the amount of water next to the building that is required to build
        it will check every tile between x1-1->x2+1, y1-1->y2+1, and z-1->z
    -command [ commandStrs ]
        specify the command to be executed if the building passes the checks
        commandStrs
            BUILDING_ID
            BUILDING_TOKEN
            BUILDING_LOCATION
            anything -> anythingThis script is fairly self explanatory, be careful with using the zLevel check as it is very specific, there must be that much open space above the building, if even a small tree branch is there it will abort the building.


3. trigger/reaction - This script is a combination of modtools/reaction-trigger and modtools/reaction-product-trigger with some new added features. The exact options are;
Code: [Select]
Arguments::
    -clear
        unregister all reaction hooks
    -reactionName name
        specify the name of the reaction
    -trigger Trigger Type
        specify when to trigger the script
        Valid Values:
            onStart
            onFinish
            onProduct
    -delay #
        how long to make the reaction take
        only works on -trigger onStart
    -requiredWater #
        amount of water the reaction needs, will cancel reaction if the water isn't present
        removes this amount of water from the surrounding tiles
    -requiredMagma #
        same as -requiredWater except for with magma
    -syndrome name
        specify the name of the syndrome to be applied to the targets
    -allowNonworkerTargets
        allow other units in the same building to be targetted by
        either the script or the syndrome
    -allowMultipleTargets
        allow multiple targets to the script or syndrome
        if absent:
            if running a script, only one target will be used
            if applying a syndrome, then only one target will be infected
    -resetPolicy policy
        the policy in the case that the syndrome is already present
        policy
            NewInstance (default)
            DoNothing
            ResetDuration
            AddDuration
    -command [ commandStrs ]
        specify the command to be run on the target(s)
        special args
            WORKER_ID
            TARGET_ID
            BUILDING_ID
            LOCATION
            REACTION_NAME
            JOB_ID
            INPUT_ITEMS
            OUTPUT_ITEMS
            anything -> anythingWith the inclusion of the -trigger option this script mimics the behavior of the combined scripts. Use -trigger onFinish to replicate modtools/reaction-trigger and use -trigger onProduct to replicate modtools/reaction-product-trigger. The major additions from this script is the onStart trigger and delay and requiredWater/Magma. A couple examples for illustration. First, a reaction that takes a full day, regardless of skill, to complete. Note that the timer for this starts as soon as the unit begins the work so it includes the amount of time spent fetching items needed for the reaction, at a later time I will make it only start the timer once the unit stops fetching and starts working.
Code: (-delay Example) [Select]
trigger/reaction -reaction SOME_REACTION_YOU_WANT_TO_TAKE_A_WHOLE_DAY -delay 3200 -command [ you don't need a command if you don't want one ]Next up is a reaction that requires 1 water and 1 magma to run and makes steam. Note the water and magma will be removed from the surrounding tiles.
Code: (-requiredWater/Magma Example) [Select]
trigger/reaction -reaction MAKE_STEAM -requiredWater 1 -requiredMagma 1 -command [ flow/random-pos -flow STEAM -location LOCATION ]Other than the above examples the script should work the same as the two modtools equivalents.


Alright! Now that I have covered the new scripts, let's talk about how they interact with my other scripts and systems! As with all my systems they use an external "raw" file written by the user. Examples will be provided below for each of the subsystems. These scripts were basically written to be the power horse of the Enhanced System. So let's discuss that.

1. Enhanced System - Buildings SubSystem (Note that for the time being I have disabled the construction of multi story buildings as the deconstruction of them can cause crashes)
    This subsystem is designed to; a) streamline the trigger/building script and b) add additional utility. The structure of the subsystem raws are;
Code: [Select]
[BUILDING:TEST_BUILDING_1]
    [NAME:Test Building]    < Name and Description are only for the journal-gui scripts
    [DESCRIPTION:Testing all the things]
    [INSIDE_ONLY]
    [MAX_AMOUNT:4]
    [REQUIRED_WATER:7]
    [REQUIRED_MAGMA:3]
    [REQUIRED_BUILDING:TEST_BUILDING_2:1]
    [FORBIDDEN_BUILDING:TEST_BUILDING_3:2]
    [MULTI_STORY:4]
    [SCRIPT:devel/print-args [ BUILDING_ID BUILDING_TOKEN BUILDING_LOCATION ]:500]    < This script will be run every 500 ticks for as long as the building remains constructedYou will see that most of the the options correspond directly to what is in the trigger/building script. This allows you to write out what each building is supposed to do/require and not have to worry about placing script calls in onLoad.init

2. Enhanced System - Creatures SubSystem
    This subsystem is designed to allow automatic manipulation of creatures. This gets around the current raw cap on things like attributes as well as making the acquisition of interactions more random. It can also be tied into the Class System to assign classes. The structure of the subsystem raws are;
Code: [Select]
[CREATURE:ELF:MALE]
  [NAME:Test Enhanced Creature (ELF:MALE)]
  [DESCRIPTION:This is a test enhanced creature, checks that all tokens are processed correctly]
  [BODY_SIZE:1000:10000:100000:200000:1000]                 < Will change the size of the creature based on age, BABY:CHILD:ADULT:MAX:VARIANCE
  [ATTRIBUTE:AGILITY:5000:5500:6000:6500:7000:7500:8000]    < Will set agility to between 5000 and 8000 using the same weighting as the standard raws
  [NATURAL_SKILL:AXE:2:5]                                   < Will set units natural axe skill to between 2 and 5
  [STAT:SPELL_CASTING:50:75]                                < Stats and resistances are used in my other scripts, they work just like skills and attributes
  [RESISTANCE:MAGICAL:25:50]
  [CLASS:TEST_CLASS_1:2:50]                                 < Will assign TEST_CLASS_1 at level 2 with 50% of it's spells chosen randomly, note that multiple CLASS tokens will be chosen from randomly
  [INTERACTION:TEST_SPELL_2:50]                             < 50% chance the unit will learn TEST_SPELL_2
  [INTERACTION:TEST_SPELL_3:50]                             < 50% chance the unit will learn TEST_SPELL_3This entry will update any male elf on the map every 100 ticks. Once they are "enhanced" they won't be enhanced again so you don't have to worry about multiple enhancements for the same unit (note MALE could be replaced with ALL to handle all elf units).

3. Enhanced System - Items SubSystem and Materials SubSystem
    Both of these subsystems serve the same purpose but are triggered on different things (items and material respectively). They both heavily use trigger/action. The structure of the subsystem raws are;
Code: [Select]
[ITEM:ITEM_WEAPON_SWORD_SHORT]
  [NAME:Test Enhanced Item (ITEM_WEAPON_SWORD_SHORT)]
  [DESCRIPTION:This is a test enhanced item, checks that all tokens are processed correctly]
  [ON_EQUIP]    < This means the following effects occur when the item is equipped (and are reveresed when unequipped)
    [ATTRIBUTE_CHANGE:STRENGTH:-250]    < Subtracts 250 strength from the unit
    [SKILL_CHANGE:SWORD:10]    < Adds 10 levels to the units sword skill
    [TRAIT_CHANGE:ANGER:50]    < Adds 50 to the units anger trait
    [STAT_CHANGE:PHYSICAL_HIT_CHANCE:-10]    < Stats and resistances are used in other scripts, they work the same as skills and attributes
    [RESISTANCE_CHANGE:FIRE:-25]
    [INTERACTION_ADD:TEST_SPELL_2]    < Adds the TEST_SPELL_2 interaction to the unit
    [SYNDROME_ADD:TEST_SYNDROME_1]    < Adds the syndrome TEST_SYNDROME_1
  [ON_ATTACK:25]    < This means the following effects occur on an attack with the item 25% of the time. Effects are the same as ON_EQUIP but are prefaced by ATTACKER_ or DEFENDER_
    [ATTACKER_ATTRIBUTE_CHANGE:STRENGTH:25]
    [ATTACKER_SKILL_CHANGE:SWORD:-1]
    [ATTACKER_TRAIT_CHANGE:ANGER:-5]
    [ATTACKER_STAT_CHANGE:PHYSICAL_HIT_CHANCE:1]
    [ATTACKER_RESISTANCE_CHANGE:FIRE:5]
    [ATTACKER_INTERACTION_ADD:TEST_SPELL_3]
    [ATTACKER_SYNDROME_ADD:TEST_SYNDROME_2]
    [ATTACKER_CHANGE_DUR:100]    < The length of time for the changes to last. Note that in this particular case multple stacks of these changes can and will be applied to the attacker
  [ON_BLOCK:5]    < This means the following effects occur on a block with the item 5% of the time. Effects are the same as ON_EQUIP but are prefaced by ATTACKER_ or DEFENDER_
    [DEFENDER_ATTRIBUTE_CHANGE:AGILITY:25]
    [DEFENDER_SKILL_CHANGE:DODGE:-1]
    [DEFENDER_TRAIT_CHANGE:ANGER:5]
    [DEFENDER_STAT_CHANGE:PHYSICAL_CRIT_CHANCE:5]
    [DEFENDER_RESISTANCE_CHANGE:WATER:-5]
    [DEFENDER_INTERACTION_ADD:TEST_SPELL_1]
    [DEFENDER_SYNDROME_ADD:TEST_SYNDROME_3]
    [DEFENDER_CHANGE_DUR:100]
    [SCRIPT:devel/print-args [ SOURCE_ID TARGET_ID ITEM_ID ITEM_TOKEN ]:50]    < This script will be run 50% of the time the ON_BLOCK is triggered (so 50% of 5% of the blocks)
  [ON_PARRY:100]    < This means the following effects occur on a parry with the item 100% of the time. Effects are the same as ON_EQUIP but are prefaced by ATTACKER_ or DEFENDER_
    [ATTACKER_ATTRIBUTE_CHANGE:STRENGTH:-25]
    [ATTACKER_SKILL_CHANGE:SWORD:1]
    [ATTACKER_TRAIT_CHANGE:ANGER:5]
    [ATTACKER_STAT_CHANGE:PHYSICAL_HIT_CHANCE:-1]
    [ATTACKER_RESISTANCE_CHANGE:FIRE:-5]
    [ATTACKER_INTERACTION_ADD:TEST_SPELL_3]
    [ATTACKER_SYNDROME_ADD:TEST_SYNDROME_2]
    [ATTACKER_CHANGE_DUR:100]The Materials SubSystem has the exact same format exept [ITEM:ITEM_WEAPON_SWORD_SHORT] gets changed to [MATERIAL:INORGANIC:STEEL], [MATERIAL:CREATURE:DRAGON:BONE], or [MATERIAL:PLANT:SINGLE-GRAIN_WHEAT:DRINK] etc...

4. Enhanced System - Reactions SubSystem
    This subsytem takes advantage of the trigger/reaction script, and allows for some extra goodies. The structure of the subsystem raws are;
Code: [Select]
[REACTION:TEST_REACTION_1]
    [NAME:Test Reaction 1]
    [DESCRIPTION:Testing various Enhanced Reaction triggers]
    [ON_START]
[SKILL:MINING]                < Skill associated with this reaction
[BASE_DURATION:1000]          < Base duration (or delay in the trigger/reaction script) for the reaction to last
[DURATION_REDUCTION:50:10]    < Reduction in the base duration based on skill. This means for each 1 level of MINING the duration of the reaction decreases by 50 ticks down to a minimum of 10 ticks
        [SCRIPT:devel/print-args [ UNIT_ID TARGET_ID BUILDING_ID LOCATION INPUT_ITEMS OUTPUT_ITEMS REACTION_NAME ]]    < This script will be run on the start of the reaction, note that INPUT_ITEMS and OUTPUT_ITEMS will not be populated since they aren't available to onStart reaction triggers
    [ON_PRODUCT]
        [SCRIPT:devel/print-args [ UNIT_ID TARGET_ID BUILDING_ID LOCATION INPUT_ITEMS OUTPUT_ITEMS REACTION_NAME ]]
    [ON_FINISH]
        [SCRIPT:devel/print-args [ UNIT_ID TARGET_ID BUILDING_ID LOCATION INPUT_ITEMS OUTPUT_ITEMS REACTION_NAME ]]Currently there aren't as many fun features for this subsystem as there with the others. But that will change with time.

NOTE: For all of the above Enhanced System examples you DO NOT need to place anything in the onLoad.init (like you do if using the trigger scripts by themselves). The Enhanced System will take care of all of that for you!

I will be testing all scripts and systems on DF 44.05 this afternoon and if there are no issues I will update the master branch of my GitHub to 44.X compliant and create a 43.X branch for those still using the old DF. All future development will be done in the current DF version however.
Title: Re: Roses' Script, System, and Utilities Collection (02/07/2018)
Post by: Roses on February 07, 2018, 06:06:08 pm
More good news. All tests came back as passing for the new DF/DFHack version (44.05). No changes needed! So feel free to download and use to your hearts content. Hopefully the inclusion of my tests means there will be less errors going forward, but with over 10000 lines of combined code there is always going to be something wrong somewhere.

One request, if anyone decided to use the Enhanced System (or any of the Systems actually) would you please post your files here so that others can see, take inspiration from, and possibly even use them?
Title: Re: Roses' Script, System, and Utilities Collection (02/07/2018)
Post by: Roses on April 15, 2018, 06:16:54 pm
I've made a small upgrade to the Enhanced Item system, now in addition to ON_EQUIP, ON_ATTACK, ON_WOUND, ON_BLOCK, ON_PARRY, and ON_MOVE triggers there is now ON_FIRED, ON_PROJECTILE_MOVE, and ON_PROJECTILE_HIT. Both the moving and the hit were already possible with an eventful trigger, this is just a different method for calling them without having to mess with the onload.init. The ON_FIRED allows you to trigger a script when a projectile is fired. Some neat examples are a "cannon shot" that knocks the firer backwards and a "semi auto shot" which every time you shoot a projectile it fires an extra 4 shots. I will add some extra examples soon
Title: Re: Roses' Script, System, and Utilities Collection (04/16/2018)
Post by: Roses on April 18, 2018, 01:17:48 pm
At a conference this week so I won't have time to add examples and updates for the new Enhanced Item and Enhanced Material projectile triggering, but here is a sneak peak that I tested before I left. This will change any ITEM_AMMO_ARROW_SPLITSHOT ammo fired from 1 into 3 projectiles. I still need to add options for branching shots and other unique features, but it works pretty well so far. You can also add the ability to a bow so that any ammo shot from the bow will split into 3 shots (or whatever else you want)

Code: [Select]
[ITEM:ITEM_AMMO_ARROW_SPLITSHOT]
 [NAME:Split Shot Arrow]
 [Description:An arrow that splits into multiple when fired]
 [ON_PROJECTILE_FIRED]
  [SCRIPT:item/projectile -unitSource UNIT_ID -unitTarget TARGET_ID -item ITEM_TOKEN -material MATERIAL_TOKEN -number 2 -velocity PROJECTILE_VELOCITY -hitchance PROJECTILE_HITCHANCE]
Title: Re: Roses' Script, System, and Utilities Collection (04/16/2018)
Post by: Roses on April 23, 2018, 03:16:13 pm
Question for possible users. For the systems, is it better to have separate files or to include the information directly into the DF raws. For example;

2 Files
Code: (objects/item_ammo.txt) [Select]
[ITEM_AMMO:ITEM_AMMO_ARROWS_SPLITSHOT]
[NAME:split shot arrow:split shot arrows]
[CLASS:ARROW]
[SIZE:150]
[ATTACK:EDGE:5:1000:stab:stabs:NO_SUB:1000]
        [ATTACK_PREPARE_AND_RECOVER:3:3]
Code: (system/Eitems.txt) [Select]
[ITEM:ITEM_AMMO_ARROWS_SPLITSHOT]
 [NAME:Split Shot Arrow]
 [Description:An arrow that splits into multiple when fired]
 [ON_PROJECTILE_FIRED]
  [SCRIPT:item/projectile -unitSource UNIT_ID -unitTarget TARGET_ID -item ITEM_TOKEN -material MATERIAL_TOKEN -number 2 -velocity PROJECTILE_VELOCITY -hitchance PROJECTILE_HITCHANCE]

Or 1 single file with the normal raws with [] and the enhanced item raws with {}
Code: (objects/item_ammo.txt) [Select]
[ITEM_AMMO:ITEM_AMMO_ARROWS_SPLITSHOT]
[NAME:split shot arrow:split shot arrows]
{Description:An arrow that splits into multiple when fired}
[CLASS:ARROW]
[SIZE:150]
[ATTACK:EDGE:5:1000:stab:stabs:NO_SUB:1000]
        [ATTACK_PREPARE_AND_RECOVER:3:3]
{ON_PROJECTILE_FIRED}
        {SCRIPT:item/projectile -unitSource UNIT_ID -unitTarget TARGET_ID -item ITEM_TOKEN -material MATERIAL_TOKEN -number 2 -velocity PROJECTILE_VELOCITY -hitchance PROJECTILE_HITCHANCE}

The reason they are currently separate is because the classes and civilization systems that I started with didn't have corresponding DF raws. But items, buildings, reactions, and materials all do. Just not sure which is easier
Title: Re: Roses' Script, System, and Utilities Collection (04/16/2018)
Post by: Atomic Chicken on April 24, 2018, 04:12:12 pm
Not much of a modder myself, but having everything integrated into a single raw file sounds much more convenient from the user friendliness perspective.
Title: Re: Roses' Script, System, and Utilities Collection (04/16/2018)
Post by: zilpin on April 27, 2018, 09:44:03 am
Ditto.
I vote 1 file with the default language (english).
Separate files for content should only be considered when you have verbose text, complex markup, or multimedia.
If wanted, a languages folder could later be used, the way software typically is done.

@Roses, are you fully parsing all raw files and validating them, or are you just scanning through them looking for your extensions and replacing them with the appropriate RAW text?
Title: Re: Roses' Script, System, and Utilities Collection (04/16/2018)
Post by: Roses on April 27, 2018, 12:56:44 pm
Currently the scripts will read all correctly named files in the raw/systems/ folder. Since this is outside of the normal raw/objects structure the files can be made to match the default raws, namely using [ ] to specify a raw token. For example, for testing the Enhanced Item system I use this file
Code: (Eitems_test.txt) [Select]
Eitems_test

[OBJECT:ENHANCED_ITEM]

[ITEM:ITEM_WEAPON_PICK]
  [NAME:Test Enhanced Item 1 (ITEM_WEAPON_PICK)]
  [DESCRIPTION:This is a test enhanced item, check ON_EQUIP SKILL_CHANGE]
  [ON_EQUIP]
    [SKILL_CHANGE:AXE:15]
  [ON_ATTACK:25]
    [SCRIPT:devel/print-args [ SOURCE_ID TARGET_ID ITEM_ID ITEM_TOKEN ]:50]
   
[ITEM:ITEM_WEAPON_AXE_BATTLE]
  [NAME:Test Enhanced Item 2 (ITEM_WEAPON_AXE_BATTLE)]
  [DESCRIPTION:This is a test enhanced item, checks ON_EQUIP INTERACTION_ADD]
  [ON_EQUIP]
    [INTERACTION_ADD:TEST_SPELL_1]
    Now the first group of lines is only included to match with default raws, the lua parser doesn't start reading until it finds [ITEM: on line 5. By using the same names as the default raws (namely ITEM_WEAPON_PICK and ITEM_WEAPON_AXE_BATTLE) the system knows to link create a link between the two.

If I were to add it all to the default raws I would no longer be able to use the [ ] convention (DF would spit out a lot of errors of unrecognized tokens) so I would have to switch to something like { }, and then I would need to parse all files in the raw/objects folder. Luckily this only needs to be done at the first setup so it wouldn't cause a slow down during gameplay. I wouldn't validate any raws with [ ], but instead just validate { } raws. I suppose I could leave it set up to try both methods as well
Title: Re: Roses' Script, System, and Utilities Collection (04/16/2018)
Post by: Roses on June 05, 2018, 10:18:31 am
Sorry for my recent lack of updates. I have been doing some DF stuff, but mostly RL has invaded my time. As for updates, heres a small list

1. As per recent discussions I have combined my Systems Raws with the game raws, this flows a lot better I think, and it means all the information is stored in one place. For an example I have included a building and an item. Note the Enhanced System information is placed in { } as opposed to [ ]

The building can only be built outside, requires at least 4 water within 1 tile of it, and creates a source of mist (this uses my flow/source script, but you could also spawn a specific amount of mist each X ticks with the spawn-flow script)
Code: [Select]
[BUILDING_WORKSHOP:FOUNTAIN]
        [NAME:Fountain]
        [NAME_COLOR:7:0:1]
        [DIM:1:1]
        [WORK_LOCATION:1:1]
        [BUILD_LABOR:MECHANIC]
        [BUILD_KEY:CUSTOM_P]
        [BLOCK:1:0]
        [TILE:0:1:207]
        [COLOR:0:1:0:7:0]
        [TILE:1:1:207]
        [COLOR:1:1:MAT]
        {OUTSIDE_ONLY}
        {REQUIRED_WATER:4}
        {SCRIPT:flow/source -location BUILDING_LOCATION -source 200 -flow MIST -check 10:0}
        [BUILD_ITEM:2:TRAPPARTS:NONE:NONE:NONE][CAN_USE_ARTIFACT]
The item is a standard spear with some extra information that is used in my scripts and systems. You could also add ON_EQUIP or ON_ATTACK or any of the other Enhanced Items options
Code: [Select]
[ITEM_WEAPON:ITEM_WEAPON_SPEAR]
        [NAME:spear:spears]
        {DESCRIPTION:A standard spear}
        [SIZE:400]
        [SKILL:SPEAR]
        [TWO_HANDED:47500]
        [MINIMUM_SIZE:5000]
        [MATERIAL_SIZE:3]
        {CRIT_CHANCE:10}
        {CRIT_BONUS:150}
        {DAMAGE_TYPE:PIERCING}
        {WEAPON_CLASS:SPEAR}
        [ATTACK:EDGE:20:10000:stab:stabs:NO_SUB:1000]
                [ATTACK_PREPARE_AND_RECOVER:3:3]
        [ATTACK:BLUNT:10000:6000:bash:bashes:shaft:1250]
                [ATTACK_PREPARE_AND_RECOVER:3:3]

2. Multi Story buildings continue to cause issues with deconstructing them and building destroyers. I'm not sure if they will end up being useful at all, but I'm still trying.

3. With the recent DF additions the Civilization System needs to be reworked a bit. Particularly the Diplomacy Sub-System which handles civilizations interactions with each other.

That's pretty much it for now, I'm still working on creating my mod, but it is slow going as it is essentially a total conversion and I am trying to translate D&D like rules into DF which hasn't been as easy as I thought it would!
Title: Re: Roses' Script, System, and Utilities Collection
Post by: Roses on August 13, 2018, 11:06:26 am
Wow, 2 months since the last post. Time sure does fly.... I'm trying to get back into DF modding and coding since I miss doing it, but I've been going through everything that's already there and I've realized it is kind of a mess! Reading through it all it seems like I was trying to do to many things at once and never finished a task before leaping onto the next one.

So over the next couple of weeks I am going to be going through all my stuff. And essentially "starting from scratch" (but it will actually be mostly just copying and pasting) and going through a list of tasks. Only adding needed code, and making the code as simple and straight forward as possible. I think one of the big problems is that I added features on to already completed scripts in kind of crappy ways instead of rewritting the scripts to account for the new features. This resulted in some functions and scripts needing way to many variable inputs and the persistent data tables being a complete mess. Looking at everything as a whole should make it all much more streamlined and hopefully more usable by others.

Work plan

I should be able to reasonably get through the scripts and functions in the next two weeks. I am going to try and be more aggressive and get through the Class and Enhanced systems as well, but those are both very large codes that it may take a while to fully sketch out and implement.
Title: Re: Roses' Script, System, and Utilities Collection (Rework Underway!)
Post by: Meph on August 13, 2018, 11:56:14 am
Roses! Glad to see you around. :-)
Title: Re: Roses' Script, System, and Utilities Collection (Rework Underway!)
Post by: Roses on August 22, 2018, 12:50:20 pm
Thanks! Now I just hope that I can keep a good balance between RL and DF. I really want to get back in to modding, script writing, and eventually playing.

Updated previous post with progress, working on scripts now.
Title: Re: Roses' Script, System, and Utilities Collection (Rework Underway!)
Post by: Roses on August 25, 2018, 03:20:16 pm
So I've been going through everything and realized that one of the reasons it's so complicated is because I was trying to make the scripts work both inside my framework and as standalone scripts. This made things needlessly complicated so I've decided to just make all my scripts work inside my framework since without it they really don't do anything more than already published scripts do.
Title: Re: Roses' Script, System, and Utilities Collection (Rework Underway!)
Post by: Roses on September 05, 2018, 02:12:13 pm
As is probably not surprising, things have been moving much slower than I had hoped. As something to help show that I am still working on it and to help illustrate what I am working on, I have decided to do a set of Feature Notes (e.g. explaining the features of the various scripts, what they do, and how they can be used). So today will be the first of a series of notes.

Tracking
Description:
Tracking is used by nearly every script that makes a change to an item, unit, or building. It stores all changes made (i.e. changing a unit's strength with unit/attribute-change) in persistent tables that last between save/reload. This allows for a number of interesting uses.

Uses:
Examples:
Summary:
Tracking allows for increased control over the behavior, effects, and duration of changes made with scripts. It offers things akin to "dispelling", "banishing", "purging", and other typical D&D like spell interactions.
Title: Re: Roses' Script, System, and Utilities Collection (Rework Underway!)
Post by: Roses on September 19, 2018, 01:10:07 pm
I continue to make slow but steady progress. Have gone through all the base scripts and functions. Now I need to go through the systems. Updated the previous post to show progress.

Now it is time for another Feature post. This time we are talking about the wrapper feature. I know the Examples section for these feature things are pretty poor right now. I will be adding actual usable examples in the future.

Wrapper
Description:
The wrapper script is a unique script that allows for providing other scripts with more information, better targeting, and a whole host of other things. In essence it "wraps" around other scripts to improve on their uses without needing to modify the wrapped script.

Uses:
Examples:
Summary:
By using the wrapper script with the modtools/interaction-trigger script (or any other trigger script) you can dramatically increase the options for both targeting and effects of scripts without having to modify the scripts themselves.
Title: Re: Roses' Script, System, and Utilities Collection (Rework Underway!)
Post by: Roses on October 31, 2018, 10:59:26 am
Continuing to make slow (very slow) but steady progress towards a complete code revamp. I have added a new pdf to github which details the persistent tables used by the various systems and scripts in case anyone is interested in how things work in the background, or how the information can be accessed for other purposes.
Title: Re: Roses' Script, System, and Utilities Collection (Rework Underway!)
Post by: Roses on November 08, 2018, 06:29:32 pm
Alright, I've finally gotten through all of the scripts, functions, and systems. Scripts have been tested and are working, functions are 75% tested and working, and the systems will be tested this weekend. Assuming all goes to plan (which it never does, but hey, you've gotta start somewhere) everything should be up and running by next week. I've also included much more thorough help documentation for everything, as well as information about the systems (not currently on git, will push with the final tests). I will also need to stress test the systems, currently information is only read from persistent tables when it is needed, but in a big fort even that might be too often and have a negative impact on fps. If that's the case I will switch to using global non-persistent tables that are loaded from persistent tables at the start and are pushed back when saving.

As a reminder, I've changed the Enhanced and Civilization systems to read directly from the raws so there is no more need for multiple files and trying to link things. I've included an example for a building and an item. I didn't include an entity or creature example because those raws are big, but it works the same. Anything in the {} is read by the systems. For now any ON_ATTACK in an item will be applied to every attack from the item, in the future it will just be applied to the attack it is under.

Code: [Select]
[BUILDING_WORKSHOP:TEST_BUILDING_1]
  [NAME:Test Building 1]
  {DESCRIPTION:Testing various Enhanced Building triggers}
  [NAME_COLOR:7:0:1]
  [DIM:1:1]
  [WORK_LOCATION:1:1]
  [BUILD_LABOR:MECHANIC]
  [BLOCK:1:0]
  [TILE:0:1:207]
  [COLOR:0:1:0:7:0]
  [TILE:1:1:207]
  [COLOR:0:1:0:7:0]
  [BUILD_ITEM:1:NONE:NONE:NONE:NONE][BUILDMAT]
  {OUTSIDE_ONLY}
  {SCRIPT:devel/print-args [ BUILDING_ID BUILDING_TOKEN BUILDING_LOCATION ]:500}
Code: [Select]
[ITEM_WEAPON:ITEM_WEAPON_PICK]
  [NAME:Enhanced Pick]
  {DESCRIPTION:This is a test enhanced pick}
  [SIZE:500]
  [SKILL:MINING]
  [TWO_HANDED:47500]
  [MINIMUM_SIZE:42500]
  [MATERIAL_SIZE:4]
  [ATTACK:EDGE:100:4000:strike:strikes:NO_SUB:2000]
    [ATTACK_PREPARE_AND_RECOVER:3:3]
  {ON_EQUIP}
    {SKILL_CHANGE:MINING:15}
  {ON_ATTACK:25}
    {SCRIPT:devel/print-args [ SOURCE_ID TARGET_ID ITEM_ID ITEM_TOKEN ]:50}
Looking forward I would like to revisit the gui's I had been working on, specifically the detailed unit viewer (http://www.bay12forums.com/smf/index.php?topic=152762.msg7405507#msg7405507) and the journal (http://www.bay12forums.com/smf/index.php?topic=152762.msg7404330#msg7404330). I never really finished these even though I put a bunch of work into figuring out custom view screens and how to get the information into them. There have also been several nice custom screens from other modders that I have seen on the forums lately and I think it would be cool to make it easy to tie various custom view screens together.
Title: Re: Roses' Script, System, and Utilities Collection (Rework Underway!)
Post by: Roses on November 13, 2018, 12:43:24 pm
Alright! All scripts and systems (except for the Enhanced Materials) are updated and passing the tests! There are very basic examples in the raw/systems/Test/ folder. I will get better examples put together this week (things like a fountain that makes mist, reactions that take a long time, weapons that increase attributes, creatures with sizes/attributes outside the raw limitations, etc...).

As for the gui stuff, I am going to start with the detailed unit viewer (DUV) Looking through my old stuff I used a fairly complicated system in an effort to try and link things together. With the changes I just made to the various scripts and systems I should be able to simplify it greatly. So I am going to start from scratch (with a lot of copy and pasting probably) and use my previous work as a road map. Is there anything in particular people would like to see in a DUV?
Title: Re: Roses' Script, System, and Utilities Collection (11/13/2018)
Post by: Roses on November 19, 2018, 12:21:33 pm
So apparently multiple new versions of DF and DFHack were released since I last updated my download (man I've been slow lately). The scripts and systems are all working on version 44.05, there are a couple things that changed between then and the new version (e.g. unit_flags1.dead -> unit_flags1.inactive) so I will upload a new fix tonight with everything working for the the current (44.12) version.

The Detailed Unit Viewer is also almost done, it is all set up, there are just a couple bits of information that are just place holders for now that need to be updated, and the layout (widths/heights/colors/etc...) could probably use some fine tuning, but those are easy. I'll get some screen shots up of the new layout and information stuff tonight. I also made it easy to tie in other authors scripts so the DUV (and journal when I re-release that) can look for another script and add an extra button to call.

EDIT: I also have a set of examples for the various systems that I will upload tonight as well. And as a teaser here is an Enhanced Reaction which an entity that doesn't have diggers could use to create a "mine shaft" type job that takes an amount of time to complete based on the units skill.
Code: [Select]
[REACTION:BASIC_MINING]
  [NAME:shallow mining]
  {DESCRIPTION:dig up rocks from the mine shaft}
  [BUILDING:MINE_SHAFT:NONE]
  [SKILL:MINING]
  [PRODUCT:100:1:BOULDER:NONE:INORGANIC:NONE]
  {ON_START}
    {BASE_DURATION:1000} -- In-game ticks the reaction takes for someone with 0 skill
    {DURATION_REDUCTION:50:10} -- Lowers duration by 50 in-game ticks per skill level down to a minimum of 10
Title: Re: Roses' Script, System, and Utilities Collection (11/13/2018)
Post by: Roses on November 19, 2018, 07:37:55 pm
Alright, scripts/systems are updated to the correct version, and below are two screen shots for the detailed unit viewer. The main view and the detailed view, as mentioned above there's still some work to do, but it's coming along

Spoiler: Main View (click to show/hide)

Spoiler: Details View (click to show/hide)
Title: Re: Roses' Script, System, and Utilities Collection (11/13/2018)
Post by: Roses on December 08, 2018, 06:18:31 pm
So I've still got some more to do on the detailed unit viewer, but it is coming along, and with the inclusion of the work done by Patrik Lundell the thoughts, preferences, values, etc... should be a lot better than what they were previously. I still need to get my string splitting routine to properly respect words but it should be simple enough. So far I've built it to be very modular, with all of the screens being made of sets of panels that can easily be reordered or even moved to entirely new pages with only changing a few lines of code. Below are some screen shots of the current set up, items marked with [X] are just place holders.

Spoiler: Main View (click to show/hide)
Spoiler: Details View (click to show/hide)
Spoiler: Classes View (click to show/hide)
Spoiler: Personality View (text) (click to show/hide)
Spoiler: Personality View (numbers) (click to show/hide)

Thoughts?
Title: Re: Roses' Script, System, and Utilities Collection (11/13/2018)
Post by: Bumber on December 08, 2018, 09:45:18 pm
Why does Urist, Female Dwarf, have a male appearance? Is that the placeholder at work?
Title: Re: Roses' Script, System, and Utilities Collection (11/13/2018)
Post by: Roses on December 11, 2018, 09:31:13 pm
Quote from: Bumber on December 08, 2018, 09:45:18 pm
Why does Urist, Female Dwarf, have a male appearance? Is that the placeholder at work?

Yes it is!
Title: Re: Roses' Script, System, and Utilities Collection (11/13/2018)
Post by: Roses on December 20, 2018, 06:14:46 pm
So I've got the appearances working mostly. It gets all of the information and parses it correctly but there seems to be some extra processing done when displaying information on the unit description screen. Two units with the same amount of CURLY in their hair can have different descriptions (one that mentions the curliness and one that doesn't). So it looks like the descriptions generated for the detailed unit viewer will always be much more in depth than the default ones. I've decided to make a seperate tab to list the entire unit description and then just put the most important descriptors on the main view. That way you don't get overwhelmed by just looking at the main view, but you can still get a basic sense of the unit. So far it works well for all of the default creatures in the game, but I will need to try a custom creature with lots of different appearance and tissue modifiers and see if it still works.

Here's an example string for a units hair
Code: [Select]
Her hair is copper with a touch of gray. It is very long, wavy, quite dense, and is tied in a pony tail. compared to the default string
Code: [Select]
Her quite dense hair is wavy. Her very long hair is tied in a pony tail. Her hair is copper with a touch of gray.
Still not sure I like the way I'm piecing together the information, but that is easy enough to change once I get all the information in there (currently there are placeholder strings for a lot of the descriptions because I haven't seen them in game yet)
Title: Re: Roses' Script, System, and Utilities Collection (11/13/2018)
Post by: Roses on January 08, 2019, 07:32:27 pm
New update
Spoiler (click to show/hide)
Title: Re: Roses' Script, System, and Utilities Collection (11/13/2018)
Post by: Putnam on January 09, 2019, 01:13:05 am
Kinda feel like that screen should have orientation on it.
Title: Re: Roses' Script, System, and Utilities Collection (11/13/2018)
Post by: Roses on January 09, 2019, 05:14:16 pm
Quote from: Putnam on January 09, 2019, 01:13:05 am
Kinda feel like that screen should have orientation on it.

Good call
Title: Re: Roses' Script, System, and Utilities Collection (11/13/2018)
Post by: Roses on January 11, 2019, 02:18:32 pm
New update, added orientation and more relationship info to the main page, and added a whole relationship page that provides more details (think the default relationship page, but more information). Here is the updated main page, and also the newest version of the personality page. Note that I am not entirely happy with the current appearance thing on the main page, but I haven't finished setting up the logic to create sentences out of the information, so for now it is just there to remind me to do that.

Spoiler: Main Page (click to show/hide)
Spoiler: Personality Page (click to show/hide)

Is there any other information people would like seeing on the main page or any of the others? I've set up the UI so that it is super easy to add information and move it around by using tables like
Code: [Select]
               ['main']             = {
                        num_cols = 3,
                        num_rows = 3,
col_pads = 4,
row_pads = 1,
widths   = {{40,40,40},
            {40,40,40},
    {40,40,40}},
heights  = {{6, 10,60},
            {10,10, 0},
    {10,10, 0}},
fill     = {'BaseInfo','Description','AppearanceBasic',
    'WorshipBasic','HealthBasic',nil,
    'RelationshipsBasic','AttributesBasic',nil}},
Title: Re: Roses' Script, System, and Utilities Collection (11/13/2018)
Post by: Bumber on January 11, 2019, 06:51:02 pm
Once you get around to adding skills, could there be an indicator whether or not the associated labor is active? Might be kind of useful, IDK.
Title: Re: Roses' Script, System, and Utilities Collection (11/13/2018)
Post by: Roses on January 11, 2019, 08:06:38 pm
Quote from: Bumber on January 11, 2019, 06:51:02 pm
Once you get around to adding skills, could there be an indicator whether or not the associated labor is active? Might be kind of useful, IDK.

There are a list of current skills in the details screen  shown here (http://www.bay12forums.com/smf/index.php?topic=152762.msg7898298#msg7898298). But I can easily add a mark next to each skill that is currently active
Title: Re: Roses' Script, System, and Utilities Collection (11/13/2018)
Post by: Roses on January 14, 2019, 04:15:00 pm
So I just realized I have been providing updates here, but not actually updating my git repo... that's not very useful. So I just updated the git repo, to use the detailed unit viewer just select a unit and type gui/duv. You can also test out the first iterations of the new journal feature by using gui/journal.
Title: Re: Roses' Script, System, and Utilities Collection (01/14/2019)
Post by: Roses on January 16, 2019, 12:49:45 pm
I made a slight change to the main screen of the DUV, instead of having the subscreens listed on the bottom, the keys needed to access them are a part of the header. For instance, to access the detailed attributes screen you would press 'SHIFT_A' (the A in Attributes is highlighted). In addition I added the ability to add extra scripts on the bottom (where the subscreens used to be). As seen in the picture you can press 1 to access the gui/gm-editor for the unit you have selected. Additional extra scripts can be called and will have numbers 2-9
Spoiler: DUV Main (click to show/hide)

I've also started working on the Journal/Compendium, it uses all the same features as the DUV just access different information (mostly df.global.world.raws). All the currently listed entries are working, but I haven't written the needed information to turn the raws they generate in to usable text. Luckily I already had a version running before with most of the information needed so it shouldn't be too hard to get it working (minus the picture, I've given up on that for now)
Spoiler: Journal (click to show/hide)
Spoiler: Previous Bestiary (click to show/hide)
Title: Re: Roses' Script, System, and Utilities Collection (01/14/2019)
Post by: Roses on January 23, 2019, 03:06:57 pm
So I am getting close to finished with the detailed unit viewer (at least as a first pass). Below is a basic walkthrough of the viewer and what the various screens look like. (Note the Health entry on the main screen and the detailed Health view are both giving some troubles at the moment)

Selecting a unit and running gui/duv will give you the main view screen
Spoiler: Main View (click to show/hide)
This has most of the information the is visible in the default unit view screen, with a couple additions and a couple subtractions. Each header has a corresponding detailed view screen.

Hitting 'p' on the main screen takes you to the detailed appearance screen. This screen is currently set up as a list of body parts and their modifiers.
Spoiler: Appearance Details (click to show/hide)
By default the string values of the modifiers are displayed. You can also display the actual in game number value and the bin it fits in based on the creature raws.

Hitting 'A' or 'S' on the main screen takes you to the detailed attributes and skills view screen. Attributes are split into Physical and Mental (and Custom if you are using my other scripts and tracking custom attributes). Skills are broken into multiple parts. The top level are the labors, these display even if the unit has 0 experience in the skill. Then it will display skills broken into Crafting, Farming, Gathering, Social, Military, Performance, Science/Magic, and Other. The exact skills in each category are defined in functions/text. These categories will only display skills that the unit actually has experience in. (The screen also displays Stats and Resistances if you are using them from my other scripts)
Spoiler: Attributes/Skills Details (click to show/hide)

Hitting 'P' on the main screen gives you the personality screen. This displays the Thoughts, Preferences, Values, Traits, and Focus of the unit.
Spoiler: Personality Details (click to show/hide)
By default the strings associated with each are displayed, but you can also look at the individual numbers and details
Spoiler: Personality Details (numbers) (click to show/hide)
Note that almost all of this information is from Patrik Lundell's thoughts script and I haven't fully ported the functions needed to accurately fill out the thoughts, hence the [] in the thoughts section.

Hitting 'R' on the main screen gives you the detailed relationship screen. Currently the display is very lacking, but I plan on breaking it into sections including ones for family, friends, grudges, master/apprentices, and possibly more.
Spoiler: Relationship Details (click to show/hide)

Lastly, hitting 'D' on the main screen takes you to the Journal entry for the creature (Journal is currently empty, but it does take you to the correct page, just doesn't display anything).

All of the strings in the viewer are easily editable and all found in functions/text (e.g. If you want someone with a large strength to have 'herculean strength' instead of being 'unbelievably strong' you just need to change the corresponding string entry). The color profile is also easily editable with Tab cycling through any available color profiles found in functions/gui (currently there are only two DEFAULT, the one shown, and WHITE, where everything is just white).

Title: Re: Roses' Script, System, and Utilities Collection (01/14/2019)
Post by: Bumber on January 23, 2019, 07:46:52 pm
Are you going to add color coding to the Values and Traits (numbers) based on which range they're in? (Or rather, is it possible to setup using the UI config?)

Is there a view that has labor selection, so you don't have to [v]iew the unit or find them in Dwarf Therapist / Manipulator?
Title: Re: Roses' Script, System, and Utilities Collection (01/14/2019)
Post by: Roses on January 23, 2019, 08:21:58 pm
Quote from: Bumber on January 23, 2019, 07:46:52 pm
Are you going to add color coding to the Values and Traits (numbers) based on which range they're in? (Or rather, is it possible to setup using the UI config?)

Is there a view that has labor selection, so you don't have to [v]iew the unit or find them in Dwarf Therapist / Manipulator?

Yes, color coding by ranges is basically implemented, just haven't picked the colors for the different ranges yet (they are all set to COLOR_LIGHTGREEN right now, once I change that they will show up correctly)

The labors are listed in two places, the Skills subsection on the main view has the current list of enabled labors just by name, the Skills subsection on the detailed Attribute/Skill view has the current list of enabled labors and the level/experience of the particular labor. I should say that these are the labors associated with skills, maybe I should put a separate list on the main page that has all currently enabled labors, not just the skill based ones. That would probably be more helpful. Then you could see if they have hauling enabled and such
Title: Re: Roses' Script, System, and Utilities Collection (01/14/2019)
Post by: Bumber on January 23, 2019, 10:26:53 pm
But can you toggle the labors somewhere convenient?
Title: Re: Roses' Script, System, and Utilities Collection (01/14/2019)
Post by: Roses on January 24, 2019, 12:30:17 pm
Quote from: Bumber on January 23, 2019, 10:26:53 pm
But can you toggle the labors somewhere convenient?

Ah, you want to be able to edit which labors are active, I misunderstood. Currently this is a viewer only. I do plan on making it possible to make edits to the unit down the road. The easiest way to change them in the current version is to hit '1' to enter the gui/gm-editor and go to status.labors.
Title: Re: Roses' Script, System, and Utilities Collection (01/14/2019)
Post by: Roses on January 27, 2019, 04:33:50 pm
So I have an initial pass of the wound information now working. It tracks the damage from the body_part_status but doesn't currently use the layer information to determine if the skin is bruised vs dented vs etc... So it just reads, "the skin is damaged"
Spoiler: Main View (click to show/hide)

The detailed view currently just tracks some of the numbers of the wound, I still need to play around with what information is best for this.
Spoiler: Health View (click to show/hide)
Title: Re: Roses' Script, System, and Utilities Collection (01/29/2019)
Post by: Roses on January 29, 2019, 09:21:41 am
Uploaded a new version to github with the recent unit viewer changes as well as a preliminary changes to the journal. Is there any more information people would like to see from the unit viewer? I realized I should put a 'measurements' section on the main screen that gives you height, weight, speed, etc... And I should also make an inventory screen. Other than that I think I will be pretty much done with the unit viewer for now as I want to get the journal up to the same level, after that I can go back to both to polish them off more. Unfortunately right now the unit viewer and journal are not stand alone as they use functions in other scripts I have written, but please feel free to try it out.

Speaking of the journal, what sort of information do people expect to see for things like a creature or item compendium? Right now for creatures I have things like Biomes, Habitats (e.g. AMPHIBIOUS and SAVAGE), Active times (e.g. NOCTURNAL), Products (e.g. silk, cow's milk, venom, etc...), Attacks, Interactions, and some numbers (e.g. max age, gait speed, frequency, size information, etc...).
Title: Re: Roses' Script, System, and Utilities Collection (01/29/2019)
Post by: Roses on February 02, 2019, 05:02:26 pm
Update on the journal, got it working fairly well with the vanilla raws, so I decided to test it out on Masterwork DF. Below you can see the main page and three of the subpages, still need to figure out the exact organization I am going to use for everything and which information should be displayed but it's a start. And even with the thousands of creatures and reactions and materials it still only takes about a second to load, which is pretty good I think.

Spoiler: Main (click to show/hide)
Spoiler: Buildings (click to show/hide)
Spoiler: Creatures (click to show/hide)
Spoiler: Items (click to show/hide)
Title: Re: Roses' Script, System, and Utilities Collection (01/29/2019)
Post by: Roses on February 09, 2019, 05:17:14 pm
Continuing to work on the journal and compendium gui

I've added a list of reactions to each building
Spoiler: Buildings (click to show/hide)

Creatures still need a lot of work (there is a lot of information to display) creature name and caste name are now colored according to the raws
Spoiler: Creatures (click to show/hide)

Inorganics are pretty much done, you can tell which environment it is from, if it from a specific ore, if it has ore concentrations, and if it is created through an alloying reaction. If the inorganic material has a syndrome attached to it that will also show up
Spoiler: Inorganics (click to show/hide)

Plants show materials, products and growths. As well as biome and grow information, not sure all those numbers for trees are actually useful, but for now they are there.
Spoiler: Plants (click to show/hide)

Products show the basic material information, it's uses, and where it is from. The organic materials tab shows the same thing, except it also includes the material strengths as those are important for wood and leather and such, but not really that important for cheese, dyes, etc...
Spoiler: Products (click to show/hide)
Title: Re: Roses' Script, System, and Utilities Collection (01/29/2019)
Post by: Roses on February 16, 2019, 09:43:48 pm
Two bits of good news
1) I was able to get an image of the building itself into the Journal as you can see here
Spoiler: Journal-Buildings (click to show/hide)

2) What you also see is that this particular building is a multistory building. In this case there are 10 levels. All of which are accessible, with working stairs and floors. Here are four of the 10 floors with units moving around on them. You can even give each floor it's own reactions and everything. Then all you do is build the ground building and it constructs all the other buildings. (At least it will once I figure out why my onBuildingCreatedDestroyed eventful trigger stopped working). There are some limitations with what it can do right now, like stairs need to be stacked on top of eachother (they are all in the center for this building), buildings are stacked through the center so cool shapes aren't implemented yet, and to ensure no trees or anything get in the way everything in the building cube is erased (the tiles, not creatures or items).
Spoiler: MultiStory Building (click to show/hide)
Title: Re: Roses' Script, System, and Utilities Collection (01/29/2019)
Post by: bloop_bleep on March 06, 2019, 12:17:15 am
PTW
Title: Re: Roses' Script, System, and Utilities Collection (03/15/2019)
Post by: Roses on March 15, 2019, 03:27:43 pm
Updated the journal to include a search functionality and a help screen.

Spoiler: Search example (click to show/hide)

Updated github repo
Title: Re: Roses' Script, System, and Utilities Collection (03/15/2019)
Post by: Roses on April 04, 2019, 02:10:13 pm
I continue to make progress on the Encyclopedia, although it has slowed down a bit recently, I've got sorting in by different parameters now (e.g. sort inorganic by their shear value, sort shields by their block value, etc...), pretty much any number associated with a particular raw can now be sorted by. I still need to implement complex sortings (e.g. sort by best material for edge weapon) that are based on more than one value, but that should be a fairly easy extension. I've also implemented a couple more options for hiding information, such as only viewing things that your civ knows about, as well as making any raw entry with a special character (!,$,#,*,=) in either the name or the token (e.g. [CREATURE:==THIS_CREATURE_SHOULD_BE_HIDDEN==]) be automatically hidden. This doesn't impact the vanilla raws, but several modders use such entries to make in game menus prettier. This allows those to remain, while not cluttering up the encyclopedia

Additionally I'm experimenting a little bit with generating random raws by modifying a random world D&D-like creator I wrote a while back. The random world creator makes creatures, plants, metals, spells, items, and all sorts of other stuff. The trick so far has been to write a "translation" script that takes the D&D-like information and puts it into raws. Below is a copy of two randomly generated plant. Basically the DESCRIPTION is what is generated by the random world creator, and the raws below that are what my script generates. The names still need a bit of work, as I basically used random words to generate names before.
Code: [Select]
{DESCRIPTION:a grand ovate magenta fungus, with light blue cap. it grows in the summer, autumn, and winter in desert badlands. it has short spreading dark magenta daises. the daises smell pungent. the daises can be used to mill a dark magenta dye}

[NAME:grand ovate magenta desert fungus]
[NAME_PLURAL:grand ovate magenta desert fungi]
[ADJ:grand ovate magenta desert fungus]
[PICKED_TILE:58][PICKED_COLOR:5:0:0][SHRUB_COLOR:5:0:0]
[VALUE:2]
[FREQUENCY:50]
[CLUSTERSIZE:5]
[SUMMER][FALL][WINTER]
[WET]
[BIOME:DESERT_BADLAND]
[PREFSTRING:light blue cap]
[PREFSTRING:short spreading dark magenta daises]
[PREFSTRING:white petals]
[PREFSTRING:silver stigma]
[PREFSTRING:dark magenta dye]

# Structure Details
[USE_MATERIAL_TEMPLATE:STRUCTURAL:STRUCTURAL_PLANT_TEMPLATE]
        [MATERIAL_REACTION_PRODUCT:SEED_MAT:LOCAL_PLANT_MAT:SEED]
        [MATERIAL_REACTION_PRODUCT:POWDER_MAT:LOCAL_PLANT_MAT:MILL]
[BASIC_MAT:LOCAL_PLANT_MAT:STRUCTURAL]

# Seed Details
[USE_MATERIAL_TEMPLATE:SEED:SEED_TEMPLATE]
        [MATERIAL_VALUE:1]
        [EDIBLE_VERMIN]
[SEED:grand ovate magenta desert fungus seed:0:0:0:LOCAL_PLANT_MAT:SEED]

# Growth Details
[USE_MATERIAL_TEMPLATE:FLOWER:FLOWER_TEMPLATE]
        [STATE_COLOR:ALL:#COLOR_STATE_GROWTH_FLOWER]
        [DISPLAY_COLOR:5:0:0]
        [EDIBLE_VERMIN]
        [MATERIAL_REACTION_PRODUCT:POWDER_MAT:LOCAL_PLANT_MAT:MILL]
[GROWTH:FLOWER]
        [GROWTH_NAME:short spreading dark magenta daises]
        [GROWTH_ITEM:PLANT_GROWTH:NONE:LOCAL_PLANT_MAT:FLOWER]
        [GROWTH_TIMING:60000:119999]
        [GROWTH_PRINT:5:5:5:0:0:60000:119999:2]

# Product Details
[USE_MATERIAL_TEMPLATE:MILL:PLANT_POWDER_TEMPLATE]
        [STATE_NAME_ADJ:ALL_SOLID:dark magenta dye]
        [STATE_COLOR:#COLOR_STATE_PRODUCT_MILL]
        [DISPLAY_COLOR:5:0:0]
        [REACTION_CLASS:PLANT_MILL]
[MILL:LOCAL_PLANT_MAT:MILL]
Code: [Select]
{DESCRIPTION:a crawling scaly ivory algae. it grows in the spring and summer in sandy deserts. it has giant square saffron soft fruit, and short whorled gold leaves. the soft fruit smell musky and taste sweet and have round and tiny seeds. the leaves smell pleasant and have pungent edges. the soft fruit can be used to mill a saffron dye. the soft fruit can be used to brew a sweet spirit}
[NAME:crawling scaly ivory desert algae]
[NAME_PLURAL:crawling scaly ivory desert algae]
[ADJ:crawling scaly ivory desert algae]
[PICKED_TILE:58][PICKED_COLOR:7:0:1][SHRUB_COLOR:7:0:1]
[VALUE:2]
[FREQUENCY:50]
[CLUSTERSIZE:5]
[SPRING][SUMMER]
[WET]
[BIOME:DESERT_SAND]
[PREFSTRING:giant square saffron soft fruit]
[PREFSTRING:short whorled gold leaves]
[PREFSTRING:red veins]
[PREFSTRING:saffron dye]
[PREFSTRING:sweet spirit]

# Structure Details
[USE_MATERIAL_TEMPLATE:STRUCTURAL:STRUCTURAL_PLANT_TEMPLATE]
        [MATERIAL_REACTION_PRODUCT:SEED_MAT:LOCAL_PLANT_MAT:SEED]
        [MATERIAL_REACTION_PRODUCT:POWDER_MAT:LOCAL_PLANT_MAT:MILL]
        [MATERIAL_REACTION_PRODUCT:DRINK_MAT:LOCAL_PLANT_MAT:DRINK]
[BASIC_MAT:LOCAL_PLANT_MAT:STRUCTURAL]

# Seed Details
[USE_MATERIAL_TEMPLATE:SEED:SEED_TEMPLATE]
        [MATERIAL_VALUE:1]
        [EDIBLE_VERMIN]
[SEED:crawling scaly ivory desert algae seed:0:0:0:LOCAL_PLANT_MAT:SEED]

# Growth Details
[USE_MATERIAL_TEMPLATE:SOFT_SHELL:FRUIT_TEMPLATE]
        [EDIBLE_VERMIN]
        [EDIBLE_RAW]
        [EDIBLE_COOKED]
        [STOCKPILE_PLANT_GROWTH]
        [MATERIAL_REACTION_PRODUCT:SEED_MAT:LOCAL_PLANT_MAT:SEED]
        [MATERIAL_REACTION_PRODUCT:POWDER_MAT:LOCAL_PLANT_MAT:MILL]
        [MATERIAL_REACTION_PRODUCT:DRINK_MAT:LOCAL_PLANT_MAT:DRINK]
[USE_MATERIAL_TEMPLATE:LEAF:LEAF_TEMPLATE]
        [STATE_COLOR:ALL:#COLOR_STATE_GROWTH_LEAF]
        [DISPLAY_COLOR:6:0:1]
        [EDIBLE_VERMIN]
[GROWTH:SOFT_SHELL]
        [GROWTH_NAME:giant square saffron soft fruit]
        [GROWTH_ITEM:PLANT_GROWTH:NONE:LOCAL_PLANT_MAT:SOFT_SHELL]
        [GROWTH_TIMING:120000:200000]
        [GROWTH_DROPS_OFF]
        [GROWTH_PRINT:'%':'%':6:0:1:120000:200000:3]
        [GROWTH_HAS_SEED]
[GROWTH:LEAF]
        [GROWTH_NAME:short whorled gold leaves]
        [GROWTH_ITEM:PLANT_GROWTH:NONE:LOCAL_PLANT_MAT:LEAF]
        [GROWTH_PRINT:0:6:6:0:1:ALL:1]

# Product Details
[USE_MATERIAL_TEMPLATE:MILL:PLANT_POWDER_TEMPLATE]
        [STATE_NAME_ADJ:ALL_SOLID:saffron dye]
        [STATE_COLOR:#COLOR_STATE_PRODUCT_MILL]
        [DISPLAY_COLOR:6:0:1]
        [REACTION_CLASS:PLANT_MILL]
[USE_MATERIAL_TEMPLATE:DRINK:PLANT_ALCOHOL_TEMPLATE]
        [STATE_NAME_ADJ:ALL_SOLID:frozen sweet spirit]
        [STATE_NAME_ADJ:LIQUID:sweet spirit]
        [STATE_NAME_ADJ:GAS:boiling sweet spirit]
        [DISPLAY_COLOR:6:0:1]
        [REACTION_CLASS:PLANT_BREW]
        [EDIBLE_VERMIN]
        [EDIBLE_RAW]
        [EDIBLE_COOKED]
[MILL:LOCAL_PLANT_MAT:MILL]
[DRINK:LOCAL_PLANT_MAT:DRINK]
My ultimate goal for this little side project is to be able to generate a completely random world with however many creatures, plants, etc... you want. Then, combined with the Encyclopedia you can "discover" a whole new world each time you play.
Title: Re: Roses' Script, System, and Utilities Collection (03/15/2019)
Post by: Roses on April 07, 2019, 04:16:13 pm
Code: [Select]
Created 9907 plants out of 10000 in 65.0 seconds
category 2
        MUNDANE     :   98.9%
        MAGICAL     :   1.1%
type 7
        SAVAGE      :   36.0%
        WILD        :   33.2%
        DOMESTIC    :   29.7%
        ARCANE      :   0.3%
        NATURE      :   0.3%
        ELEMENTAL   :   0.3%
        DIVINE      :   0.2%
subtype 6
        TREE        :   21.7%
        BUSH        :   20.5%
        GRASS       :   18.9%
        VINE        :   16.0%
        FUNGUS      :   12.5%
        MOSS        :   10.4%
growths 8
        LEAF        :   26.0%
        HERB        :   21.0%
        FLOWER      :   18.6%
        POD         :   18.2%
        SOFT_SHELL  :   16.9%
        GRAIN       :   16.2%
        HARD_SHELL  :   14.4%
        UNDERGROUND :   11.2%
products 5
        MILL        :   68.4%
        BREW        :   68.0%
        THRESH      :   16.5%
        EXTRACT     :   16.0%
        PULP        :   10.7%
biomes 51
        SHRUBLAND_TROPICAL              :       341     3.4%
        DESERT_ROCK                     :       335     3.4%
        MOUNTAIN                        :       327     3.3%
        SUBTERRANEAN_CHASM              :       326     3.3%
        MARSH_TEMPERATE_FRESHWATER      :       326     3.3%
        GLACIER                         :       322     3.3%
        SAVANNA_TEMPERATE               :       317     3.2%
        SWAMP_TEMPERATE_FRESHWATER      :       313     3.2%
        SWAMP_TROPICAL_FRESHWATER       :       312     3.1%
        FOREST_TAIGA                    :       309     3.1%
        DESERT_BADLAND                  :       309     3.1%
        FOREST_TEMPERATE_BROADLEAF      :       306     3.1%
        MARSH_TROPICAL_FRESHWATER       :       305     3.1%
        SUBTERRANEAN_LAVA               :       304     3.1%
        SWAMP_TEMPERATE_SALTWATER       :       303     3.1%
        MARSH_TEMPERATE_SALTWATER       :       302     3.0%
        FOREST_TROPICAL_DRY_BROADLEAF   :       300     3.0%
        SAVANNA_TROPICAL                :       298     3.0%
        FOREST_TEMPERATE_CONIFER        :       298     3.0%
        GRASSLAND_TROPICAL              :       293     3.0%
        TUNDRA                          :       291     2.9%
        DESERT_SAND                     :       290     2.9%
        MARSH_TROPICAL_SALTWATER        :       287     2.9%
        FOREST_TROPICAL_MOIST_BROADLEAF :       286     2.9%
        SWAMP_TROPICAL_SALTWATER        :       284     2.9%
        SHRUBLAND_TEMPERATE             :       284     2.9%
        GRASSLAND_TEMPERATE             :       280     2.8%
        SWAMP_MANGROVE                  :       275     2.8%
        SUBTERRANEAN_WATER              :       275     2.8%
        FOREST_TROPICAL_CONIFER         :       251     2.5%
        POOL_TEMPERATE_BRACKISHWATER    :       52      0.5%
        POOL_TROPICAL_FRESHWATER        :       48      0.5%
        LAKE_TEMPERATE_BRACKISHWATER    :       48      0.5%
        RIVER_TEMPERATE_BRACKISHWATER   :       47      0.5%
        OCEAN_TEMPERATE                 :       46      0.5%
        RIVER_TROPICAL_BRACKISHWATER    :       45      0.5%
        OCEAN_TROPICAL                  :       44      0.4%
        RIVER_TROPICAL_FRESHWATER       :       43      0.4%
        RIVER_TEMPERATE_SALTWATER       :       42      0.4%
        LAKE_TEMPERATE_SALTWATER        :       42      0.4%
        RIVER_TEMPERATE_FRESHWATER      :       41      0.4%
        OCEAN_ARCTIC                    :       41      0.4%
        LAKE_TROPICAL_SALTWATER         :       40      0.4%
        LAKE_TROPICAL_FRESHWATER        :       40      0.4%
        LAKE_TROPICAL_BRACKISHWATER     :       40      0.4%
        POOL_TEMPERATE_SALTWATER        :       38      0.4%
        POOL_TEMPERATE_FRESHWATER       :       35      0.4%
        RIVER_TROPICAL_SALTWATER        :       31      0.3%
        POOL_TROPICAL_SALTWATER         :       31      0.3%
        POOL_TROPICAL_BRACKISHWATER     :       31      0.3%
        LAKE_TEMPERATE_FRESHWATER       :       31      0.3%
Title: Re: Roses' Script, System, and Utilities Collection (03/15/2019)
Post by: Roses on August 20, 2019, 04:52:24 pm
I have been working on and off on a new set of scripts that reads in a set of templates and generates an entirely random world, everything from the plants and creatures to the metals and soils. Essentially a randomized total conversion. The templates are written in json format and read in with a python script that puts them together to create objects for DF. The original purpose of these scripts was to create random D&D worlds to play through, and I've been working on getting it working with DF raws. Why? Because I thought it would be fun to start a single human adventurer in a totally unknown world, where creatures, materials, items, everything has unfamiliar names and properties and, using my Encyclopedia utility, catalogue everything and try to survive. Below is an example template for a creatures arm, just to give an idea of what the templates look like.

Code: [Select]
"6PART_ARM":    {"__comment": "shoulder, upper arm, elbow, lower arm, wrist, hand (2,4,6)",
"TYPE":     "ARM_BASIC",
"WEIGHT":   100,
"MATERIAL": ["SURFACE","INSULATION","MEAT","STRUCTURE"],
"DIGITS":   {"MIN": 1, "REQUIRED": ["FINGERS"]},
"ATTACK":   ["PUNCH"],
"REPEAT": {
"2": [1.0,
["L","left","[LEFT]"],["R","right","[RIGHT]"]],
"4": [0.5,
["UL","upper left","[LEFT]"],["UR","upper right","[RIGHT]"],
["LL","lower left","[LEFT]"],["LR","lower right","[RIGHT]"]],
"6": [0.1,
["TL","top left","[LEFT]"],   ["TR","top right","[RIGHT]"],
["ML","mid left","[LEFT]"],   ["MR","mid right","[RIGHT]"],
["BL","bottom left","[LEFT]"],["BR","bottom right","[RIGHT]"]]
},
"EXTERNAL": {
"BODY": [
"[BP:^1UA_J:^2 shoulder:STP] [CATEGORY:ARM_JOINT]^3 [JOINT][SMALL][INTERNAL][DEFAULT_RELSIZE:100][CONTYPE:UPPERBODY]",
"[BP:^1UA:^2 upper arm:STP]  [CATEGORY:ARM_UPPER]^3 [LIMB]                  [DEFAULT_RELSIZE:200][CON:^1UA_J]",
"[BP:^1LA_J:^2 elbow:STP]    [CATEGORY:ARM_JOINT]^3 [JOINT][SMALL][INTERNAL][DEFAULT_RELSIZE:20] [CON:^1UA]",
"[BP:^1LA:^2 lower arm:STP]  [CATEGORY:ARM_LOWER]^3 [LIMB]                  [DEFAULT_RELSIZE:200][CON:^1LA_J]",
"[BP:^1H_J:^2 wrist:STP]     [CATEGORY:ARM_JOINT]^3 [JOINT][SMALL][INTERNAL][DEFAULT_RELSIZE:20] [CON:^1LA]",
"[BP:^1HAND:^2 hand:STP]     [CATEGORY:HAND]     ^3 [GRASP]                 [DEFAULT_RELSIZE:80] [CON:^1H_J]"],
"BODY_DETAIL_PLAN": [
"[BP_LAYERS:BY_CATEGORY:ARM_JOINT:STRUCTURE:4:MEAT:1]",
"[BP_LAYERS:BY_CATEGORY:ARM_UPPER:STRUCTURE:25:MEAT:25:INSULATION:5:SURFACE:1]",
"[BP_LAYERS:BY_CATEGORY:ARM_LOWER:STRUCTURE:25:MEAT:25:INSULATION:5:SURFACE:1]",
"[BP_LAYERS:BY_CATEGORY:HAND:STRUCTURE:25:MEAT:25:INSULATION:5:SURFACE:1]"]
},
"RAWS": {
"BODY": ["{#KEY}"],
"BDP":  ["[BODY_DETAIL_PLAN:#KEY]"]
}
}
I'm finally at a point where everything is working as intended and generating nearly everything (some work still needs to be done on entities and their buildings), but now I need to come up with a large amount of template entries in order to get some proper good randomization.

If anyone is interested in helping out, what I would like are any custom creatures (either entire ones or just their bodies), plants, items, inorganics, materials, entities, syndromes (e.g. poisons), etc... that you are particularly proud of. I won't bother asking you to put it in a template format, just the relevant raws so that I can parse them into templates that can be randomized.

For those of you interested in the python scripts and the currently created templates you can find them in the Utilities section of my github collection, and if you are very interested and would like to learn exactly what each of the entries in a template does and make your own templates just let me know and I can put together a little ReadMe
Title: Re: Roses' Script, System, and Utilities Collection (03/15/2019)
Post by: Roses on August 30, 2019, 03:03:21 pm
The Random World Creator (RWC) continues to make progress. With the current set of templates there are about ~1 million combinations of plants that can be created and ~20 million creatures. Of course the more combinations the longer it takes to generate the random raws, which is why creatures take longer than plants which take longer than syndromes (also the shear complexity of creature contributes to the time needed to create). Below is a run with 1000 of each of the currently enabled templates. (More than 1000 inorganics are created, because some of the templates require a companion inorganic, like ores that require metals)

Code: [Select]
RANDOM WORLD CREATOR STARTING

Reading templates/raws.json
Created 1000 syndromes     out of 1000 in 5.3 seconds
Created 1000 environments  out of 1000 in 4.1 seconds
Created 1000 materials     out of 1000 in 2.6 seconds
Created 1159 inorganics    out of 1000 in 6.1 seconds
Created 1000 plants        out of 1000 in 10.5 seconds
No weapons created
Created 1000 creatures     out of 1000 in 48.8 seconds
No buildings created
No reactions created
No entities created
Writing EXTERNAL raws
Title: Re: Roses' Script, System, and Utilities Collection (03/15/2019)
Post by: Roses on January 16, 2020, 12:00:39 pm
In anticipation of the new upcoming release I have put the RWC on hold and have begun a massive rewrite on my set of scripts. I will post more updates when the new release (and cooresponding DFHack) comes out, but for now if you want to look at the newest work being done, you can check out the devel branch of my github
Title: Re: Roses' Script, System, and Utilities Collection (03/15/2019)
Post by: FantasticDorf on February 13, 2020, 12:59:16 pm
Hiya, i've mainly come to ask a question regarding the wrapping script, i wouldn't particularly call it a suggestion for a plugin or command but rather just a check-up on the archaic form of yoinking to summon creatures to your desired location which has been used on numerous DFhack things in the past.

Since the new interactions for 47.xx creates brand new entities that don't rely on a nessecity to exist but only to be defined (a body required with [DOES_NOT_EXIST]) and few other perfunctory arguement rules like length of persistency of the summon & whether the unit has historical relevance, do you think wrapper would be a appropriate rubyscript tool for these kind of desired DFhack triggers?

Your 'Stone Mine' proof of concept design was very interesting. If i might add in accordance with [SKILL_ROLL_RANGE] which would allow units to use workshops such as pseudo gyms for a longer amount of time until the job is completed or suspended with extra-experience or attribute outcome. The future of the scripts shown here will be definitely PTW.
Title: Re: Roses' Script, System, and Utilities Collection (03/15/2019)
Post by: Roses on February 14, 2020, 10:53:38 am
Quote from: FantasticDorf on February 13, 2020, 12:59:16 pm
Hiya, i've mainly come to ask a question regarding the wrapping script, i wouldn't particularly call it a suggestion for a plugin or command but rather just a check-up on the archaic form of yoinking to summon creatures to your desired location which has been used on numerous DFhack things in the past.

Since the new interactions for 47.xx creates brand new entities that don't rely on a nessecity to exist but only to be defined (a body required with [DOES_NOT_EXIST]) and few other perfunctory arguement rules like length of persistency of the summon & whether the unit has historical relevance, do you think wrapper would be a appropriate rubyscript tool for these kind of desired DFhack triggers?

Your 'Stone Mine' proof of concept design was very interesting. If i might add in accordance with [SKILL_ROLL_RANGE] which would allow units to use workshops such as pseudo gyms for a longer amount of time until the job is completed or suspended with extra-experience or attribute outcome. The future of the scripts shown here will be definitely PTW.

Thanks for the comments, the new stuff included with 47 definitely have me thinking about all the things I can do. I've actually started keeping a list of new features and ideas for how they can be used. The main thing to work out is how dfhack can interface with these new things. Once a relatively stable dfhack version is released I will start poking around in there and seeing what I can figure out.

I'm also updating all my scripts so that they are a little simpler. And have a more consistent layout and help information. Almost all the scripts are done, but I'm starting the systems from scratch. I've axed the class and civilization systems for now because I think they will be heavily influenced by the new stuff, but the enhanced system, which basically adds new tokens for the raws (like buildings that can only be built outside or changing the amount of time it takes to complete reactions) will be in my first release for the 47 version. I've also set it up so that it is relatively simple to add new tokens to the enhanced system, you will only need to modify a single file instead of before which needed 4 separate files to be updated!
Title: Re: Roses' Script, System, and Utilities Collection (04/06/2020)
Post by: Roses on April 06, 2020, 02:50:39 pm
First major update in some time. I have made sure that all my scripts are working on DF/Hack version 47.04. The currently available scripts and systems is a much smaller subset of my previous scripts/systems, but I am working on getting everything converted to the new setup that I am using. The first four posts contain information (or will soon contain information) on what is currently included in the package
Title: Re: Roses' Script, System, and Utilities Collection (04/06/2020)
Post by: Roses on April 08, 2020, 12:03:08 pm
Alright, so I have pushed all the updates to the devel branch of my github, and updated the first three posts for what is currently included in the repo. Now I am looking for testers, especially the Enhanced Building and Enhanced Item systems (the scripts all have built in testing, the systems have minimal testing as they are more complicated). If anyone wants to try them out feel free and let me know how they work out/if you have any questions. There are very simple examples in scripts/tests/raw_files that you can use as a basic guide.
Title: Re: Roses' Script, System, and Utilities Collection (04/06/2020)
Post by: Roses on April 14, 2020, 01:23:39 pm
Added a new token to the Enhanced Item system, you can no specify the fire rate of ranged weapons. It works by putting
Code: [Select]
{FIRE_RATE:base rate:skill increase:max rate}in the ranged items raws (currently can only be specified in the actual ranged item, not the ammo), where

base rate = number of ticks until the next shot with no weapon skill (in vanilla DF this is ~80)
skill increase = number of ticks the base rate is decreased per weapon skill (in vanilla DF this is ~2)
max rate = fastest the weapon can fire regardless of skill (in vanilla DF this is ~40)

so if you wanted a weapon that fires once every tick regardless of skill
Code: [Select]
{FIRE_RATE:1:0:1}or a weapon that is really slow to fire unless you have skill with it
Code: [Select]
{FIRE_RATE:500:50:1}
Note that this only changes the time between shots, the unit will still act between shots just like they do now. Also worth noting, firing every tick will drain ammo like mad. Since most times the game is playing at >20 frames (frame = tick) per second, it will empty a quiver quite quickly. I am planning on creating the option for one ammo item to be used multiple times (think, instead of carrying 20 "bullets" you carry 20 "clips" in your quiver) so that the ammo will last a little longer. Also I am working on implementing burst fire
Title: Re: Roses' Script, System, and Utilities Collection (04/06/2020)
Post by: Warmist on April 15, 2020, 08:19:17 am
Quote from: Roses on April 14, 2020, 01:23:39 pm
<...>
Note that this only changes the time between shots, the unit will still act between shots just like they do now. Also worth noting, firing every tick will drain ammo like mad. Since most times the game is playing at >20 frames (frame = tick) per second, it will empty a quiver quite quickly. <...>

Gif material right there :D
Title: Re: Roses' Script, System, and Utilities Collection (04/06/2020)
Post by: Roses on April 17, 2020, 12:04:33 pm
It's no gif, but it is a picture of a unit firing a crossbow at 1 bolt per tick

(https://imgur.com/IRcTO2X.png)
Title: Re: Roses' Script, System, and Utilities Collection (04/06/2020)
Post by: Roses on April 21, 2020, 12:48:03 pm
I've added two new fire modes to projectile weapons, a spread shot mode and a burst fire mode.

The spread shot mode functions like a shotgun and changes the projectile fired to multiple projectiles.
Code: [Select]
{SPREAD_SHOT:# of projectiles:spread distance:per target distance}So if you were to put
Code: [Select]
{SPREAD_SHOT:5:1:4}onto a crossbow, every time you fired a crossbow bolt, it would create 5 bolts (but only costing a single bolt) with a target offset of 1 tile for every 4 tiles away the target is from the shooter. If you set the spread distance to 0 all created projectiles will have the exact same target position.

The burst fire mode functions pretty much how you would imagine
Code: [Select]
{BURST_FIRE:# of shots}So if you were to put
Code: [Select]
{BURST_FIRE:4}onto a crossbow, the unit would fire four projectiles in four ticks, and then wait the normal fire rate delay to fire again. If you also use the FIRE_RATE command the normal delay will be replaced with the FIRE_RATE delay.

I've also begun adding short cuts to some of the other triggers, so instead of needing to provide scripts you can just use built in commands. For instance, instead of
Code: [Select]
{ON_EQUIP}
    {SCRIPT:unit/change-attribute -unit HOLDER -attribute [ STRENGTH +200 ]:50}you use
Code: [Select]
{ON_EQUIP}
    {ATTRIBUTE_CHANGE:STRENGTH:200:50}Again, these are identical, but the later is easier to read and understand in my opinion
Title: Re: Roses' Script, System, and Utilities Collection (04/06/2020)
Post by: Atomic Chicken on April 22, 2020, 05:13:53 am
Looking good! I imagine that many modders would be interested in this if they were aware of its existence and understood how to use it; I sometimes wonder whether the sequestration of utilities into this subforum has decreased their general visibility as compared to when everything was mixed together in the 'Modding' section. It would probably help to have a couple of eyecatching usage examples in the first few posts to draw interest.

With regards to {ON_EQUIP} in the enhancedItems system, I haven't checked your code, but if it works like modtools/item-trigger you need to be aware that this script used to have a problem of triggering the 'onEquip' effect regardless of whether the target item was being hauled, worn, wielded, stabbed into a unit, etc (so a sword intended to transform wielders into giants would also have a transform units hauling it to the stockpile or opponents in the middle of a battle, for example). This may or may not be intended behaviour in your system, but I had added the option to specify the desired equipment mode(s) to give item-trigger users more control.

Does enhancedItems not include {ON_UNEQUIP} or is it assumed that unequipping an item removes the {ON_EQUIP} effect? If the latter is correct, allowing users to make {ON_EQUIP} effects permanent may be useful in some cases. A separate {ON_UNEQUIP} option would be useful for effects unique to unequipping (a cursed sock which kills the wearer when removed, for example).
Title: Re: Roses' Script, System, and Utilities Collection (04/06/2020)
Post by: Roses on April 22, 2020, 01:28:14 pm
Quote from: Atomic Chicken on April 22, 2020, 05:13:53 am
Looking good! I imagine that many modders would be interested in this if they were aware of its existence and understood how to use it; I sometimes wonder whether the sequestration of utilities into this subforum has decreased their general visibility as compared to when everything was mixed together in the 'Modding' section. It would probably help to have a couple of eyecatching usage examples in the first few posts to draw interest.
Yes I agree, examples are definitely required. I just keep adding more features instead of writing them! I will work on getting some good ones together

Quote from: Atomic Chicken on April 22, 2020, 05:13:53 am
With regards to {ON_EQUIP} in the enhancedItems system, I haven't checked your code, but if it works like modtools/item-trigger you need to be aware that this script used to have a problem of triggering the 'onEquip' effect regardless of whether the target item was being hauled, worn, wielded, stabbed into a unit, etc (so a sword intended to transform wielders into giants would also have a transform units hauling it to the stockpile or opponents in the middle of a battle, for example). This may or may not be intended behaviour in your system, but I had added the option to specify the desired equipment mode(s) to give item-trigger users more control.
Good point, I remember that was an issue the last time I worked on this system. ON_EQUIP should definitely only work when the unit is wearing or wielding the item. I will add a mode check for that. Similarly I should add a ON_HAULED and ON_STUCKIN (or something) so that you can trigger those effects as well.
The only trouble with that will be when a unit goes from having an item equipped to hauling the item.

Quote from: Atomic Chicken on April 22, 2020, 05:13:53 am
Does enhancedItems not include {ON_UNEQUIP} or is it assumed that unequipping an item removes the {ON_EQUIP} effect? If the latter is correct, allowing users to make {ON_EQUIP} effects permanent may be useful in some cases. A separate {ON_UNEQUIP} option would be useful for effects unique to unequipping (a cursed sock which kills the wearer when removed, for example).
Another good point. Originally I had the idea that all ON_EQUIP effects would simply be removed when the unit unequipped the item, but in the latest update I have added an ON_UNEQUIP so that the the effects are indeed seperate. It also makes the coding easier as I know longer have to figure out what the opposite of everything is.
Title: Re: Roses' Script, System, and Utilities Collection (04/06/2020)
Post by: Roses on May 04, 2020, 02:27:48 pm
I've been recently slammed with work and so haven't had much time to work on this, but I am continuing with adding short cuts to the Enhanced Buildings and Enhanced Items for easier readability and use (for instance, instead of specifying a script to create mist for a enhanced building, you can now just make it produce mist with {MIST:density:frequency}). I'm almost done with the first set of short cuts, so that should be coming sometime this week. I will also be releasing examples along with the short cuts so that people can have an idea of how to use the systems.

Looking forward, I am planning on implementing Enhanced Reactions next, this will essentially do everything you can already do with modtools/reaction-trigger. Additionally it will have some new features that can't be done currently, including adjusting the time the reaction takes (you could have a reaction take days if you want), adjusting the minimum skill needed to perform the reaction (warning, this will just cancel the job if the unit doesn't meet the requirements, which is not the best solution), and extra control over products.

Looking forward x2, Enhanced Units will most likely be next. This is a more complex system as it needs to handle castes and creatures separately to truly be useful, but it will add some useful features, like creatures that excrete miasma, or even just letting creatures have more than 5000 of a specific stat
Title: Re: Roses' Script, System, and Utilities Collection (04/06/2020)
Post by: Warmist on May 05, 2020, 03:06:34 am
Quote from: Atomic Chicken on April 22, 2020, 05:13:53 am
Looking good! I imagine that many modders would be interested in this if they were aware of its existence and understood how to use it; I sometimes wonder whether the sequestration of utilities into this subforum has decreased their general visibility as compared to when everything was mixed together in the 'Modding' section. It would probably help to have a couple of eyecatching usage examples in the first few posts to draw interest.
<...>

Yeah i was naive thinking that modders would use straight lua (as it's IMHO easier to learn than df raws) for modding instead of any hacks on top of modding system. That being said i think dfhack and RSS (i.e. this) has limited visibility and needs a some sort community showcase or a way to show off features in general. I had an idea to make a sort-of newspaper with each release but lately DF is way down in the list of thing i have time and patience for.
Title: Re: Roses' Script, System, and Utilities Collection (04/06/2020)
Post by: Roses on May 05, 2020, 02:31:43 pm
Quote from: Warmist on May 05, 2020, 03:06:34 am
Quote from: Atomic Chicken on April 22, 2020, 05:13:53 am
Looking good! I imagine that many modders would be interested in this if they were aware of its existence and understood how to use it; I sometimes wonder whether the sequestration of utilities into this subforum has decreased their general visibility as compared to when everything was mixed together in the 'Modding' section. It would probably help to have a couple of eyecatching usage examples in the first few posts to draw interest.
<...>

Yeah i was naive thinking that modders would use straight lua (as it's IMHO easier to learn than df raws) for modding instead of any hacks on top of modding system. That being said i think dfhack and RSS (i.e. this) has limited visibility and needs a some sort community showcase or a way to show off features in general. I had an idea to make a sort-of newspaper with each release but lately DF is way down in the list of thing i have time and patience for.

Yeah, I agree, I thought more people would take up using lua since it's a fairly easy language to learn, but it seems the stigma of coding keeps people away from it, which is why I decided to move to this raw framework where the heavy lifting is done behind the scenes. I agree that there is very limited visibility for dfhack and various tools. I think the newspaper like idea is a good one, but I agree that DF stuff is rather low on my list as well. I was thinking that once I had a better set of examples and use cases that I could advertise in more public places, and maybe start answering some questions in the modding forums that aren't possible without tools like these.
Title: Re: Roses' Script, System, and Utilities Collection (04/06/2020)
Post by: Roses on May 21, 2020, 09:48:45 am
Some fun new stuff I'm working with;

1. Reactions that create miasma and smoke when completed
2. Reactions that take variable amounts of time and produce variable amounts of output
3. Reactions that remove a unit from play for an amount of time
4. Multistory buildings

Still not quite ready for a release, but hopefully within the next week I'll have the Enhanced Buildings and Items fleshed out, and the initial Enhanced Reactions system in place, along with some cool examples.

EDIT: While I'm thinking about it, are there certain things people would like to see in the Enhanced Buildings, Items, and Reactions systems? Things that I can build in before a release. Feel free to request anything you think might fit, if it seems to out of scope or to much work I'll just put it aside for now. (An example might be wanting a trigger for Enhanced Items ON_DODGE, this would be a great suggestion, however, triggering something on a dodge is much more complicated than triggering on other actions due to the way DF handles it, which is why this isn't included yet)
Title: Re: Roses' Script, System, and Utilities Collection (04/06/2020)
Post by: Warmist on May 22, 2020, 12:06:55 pm
Quote from: Roses on May 21, 2020, 09:48:45 am
Some fun new stuff I'm working with;

1. Reactions that create miasma and smoke when completed
2. Reactions that take variable amounts of time and produce variable amounts of output
3. Reactions that remove a unit from play for an amount of time
4. Multistory buildings

Still not quite ready for a release, but hopefully within the next week I'll have the Enhanced Buildings and Items fleshed out, and the initial Enhanced Reactions system in place, along with some cool examples.

EDIT: While I'm thinking about it, are there certain things people would like to see in the Enhanced Buildings, Items, and Reactions systems? Things that I can build in before a release. Feel free to request anything you think might fit, if it seems to out of scope or to much work I'll just put it aside for now. (An example might be wanting a trigger for Enhanced Items ON_DODGE, this would be a great suggestion, however, triggering something on a dodge is much more complicated than triggering on other actions due to the way DF handles it, which is why this isn't included yet)

This reminds me of an old idea: make golems. Why? Because most of the fun stuff makes very bad fumes. Thus have fort with two parts, fuming and not. Also there would be mandatory maintenance and support part as anything that does not eat/sleep/bleed is boring and must have drawbacks
Title: Re: Roses' Script, System, and Utilities Collection (04/06/2020)
Post by: Roses on June 18, 2020, 12:55:04 pm
Added some simple examples to the system list, Enhanced Reactions are almost ready to go. I will post more detailed and complex examples once they are ready.
Title: Re: Roses' Script, System, and Utilities Collection (04/06/2020)
Post by: Rumrusher on June 18, 2020, 11:39:52 pm
Quote from: Warmist on May 22, 2020, 12:06:55 pm
-snip- Also there would be mandatory maintenance and support part as anything that does not eat/sleep/bleed is boring and must have drawbacks

Feel like the big issue with golems is if you give them emotions or not, if you don't they probably work fine until one goes extremely distracted and crafting with them might get shoddy I heard, if you do give them emotions then they act like an immortal fort citizen that is affected by corpses and stress can cause them to go mad so you end up having to find a way to de-stress the golems.
which already feels like maintenance.
Title: Re: Roses' Script, System, and Utilities Collection (04/06/2020)
Post by: Roses on June 19, 2020, 10:50:11 am
Quote from: Rumrusher on June 18, 2020, 11:39:52 pm
Quote from: Warmist on May 22, 2020, 12:06:55 pm
-snip- Also there would be mandatory maintenance and support part as anything that does not eat/sleep/bleed is boring and must have drawbacks

Feel like the big issue with golems is if you give them emotions or not, if you don't they probably work fine until one goes extremely distracted and crafting with them might get shoddy I heard, if you do give them emotions then they act like an immortal fort citizen that is affected by corpses and stress can cause them to go mad so you end up having to find a way to de-stress the golems.
which already feels like maintenance.

You could set up "pylon" buildings that periodically de-stress golems automatically when they walk by them. For even more flavor you could make them naturally super weak and slow, then have the pylons give them a massive strength and speed boost which lasts a certain amount of time, so you would need them to almost always be close to the building
Title: Re: Roses' Script, System, and Utilities Collection (04/06/2020)
Post by: Bumber on June 19, 2020, 11:23:03 am
You could periodically set their stress/needs to neutral.
Title: Re: Roses' Script, System, and Utilities Collection (04/06/2020)
Post by: FantasticDorf on June 20, 2020, 10:53:00 am
Quote from: Roses on June 19, 2020, 10:50:11 am
Quote from: Rumrusher on June 18, 2020, 11:39:52 pm
Quote from: Warmist on May 22, 2020, 12:06:55 pm
-snip- Also there would be mandatory maintenance and support part as anything that does not eat/sleep/bleed is boring and must have drawbacks

Feel like the big issue with golems is if you give them emotions or not, if you don't they probably work fine until one goes extremely distracted and crafting with them might get shoddy I heard, if you do give them emotions then they act like an immortal fort citizen that is affected by corpses and stress can cause them to go mad so you end up having to find a way to de-stress the golems.
which already feels like maintenance.

You could set up "pylon" buildings that periodically de-stress golems automatically when they walk by them. For even more flavor you could make them naturally super weak and slow, then have the pylons give them a massive strength and speed boost which lasts a certain amount of time, so you would need them to almost always be close to the building

Wouldn't it be like alcohol dependency? Dwarf golems drinking without aperture, and getting eventual decline of neglect for not standing near pylons, or visiting a tavern for a mechanical refill even if they can't party (can't choke because no lungs, also easiest way to get served drinks until full least in current version is to be unable to speak and take part in socialising)

Plumphelmet-men visitors just stand in the corner sipping their drinks, its not really known how they're supposed to have fun.
Title: Re: Roses' Script, System, and Utilities Collection (04/06/2020)
Post by: Roses on June 22, 2020, 08:55:52 pm
Quote from: FantasticDorf on June 20, 2020, 10:53:00 am
Quote from: Roses on June 19, 2020, 10:50:11 am
Quote from: Rumrusher on June 18, 2020, 11:39:52 pm
Quote from: Warmist on May 22, 2020, 12:06:55 pm
-snip- Also there would be mandatory maintenance and support part as anything that does not eat/sleep/bleed is boring and must have drawbacks

Feel like the big issue with golems is if you give them emotions or not, if you don't they probably work fine until one goes extremely distracted and crafting with them might get shoddy I heard, if you do give them emotions then they act like an immortal fort citizen that is affected by corpses and stress can cause them to go mad so you end up having to find a way to de-stress the golems.
which already feels like maintenance.

You could set up "pylon" buildings that periodically de-stress golems automatically when they walk by them. For even more flavor you could make them naturally super weak and slow, then have the pylons give them a massive strength and speed boost which lasts a certain amount of time, so you would need them to almost always be close to the building

Wouldn't it be like alcohol dependency? Dwarf golems drinking without aperture, and getting eventual decline of neglect for not standing near pylons, or visiting a tavern for a mechanical refill even if they can't party (can't choke because no lungs, also easiest way to get served drinks until full least in current version is to be unable to speak and take part in socialising)

Plumphelmet-men visitors just stand in the corner sipping their drinks, its not really known how they're supposed to have fun.

That's actually a pretty interesting thought train. You could fairly easily set up a race that suffers the positives and negatives of ALCOHOL_DEPENDENT but attaching it to a separate building/object. For example, you could have playable elves that suffer negative thoughts and speed reductions if they haven't passed by a tree lately. Or humans that need a "church" building.

EDIT: Is there any modder(s) that would like to partner with me to come up with some good examples and use cases? I honestly haven't played DF for awhile and have spent most of my time writing lua and c++ code for it instead (a job hazard, as writing code is what I do for a living) and could use a modder to help me understand the sorts of stuff that is actually wanted. As an incentive I am willing to offer my services as a script writer.
Title: Re: Roses' Script, System, and Utilities Collection (04/06/2020)
Post by: Rumrusher on June 24, 2020, 05:12:20 am
so I just got an adv mode idea given how stealth works and how it's invisible to the player but not to everyone else. is it possible to make Dfhack npcs that spawn in and hide out of site to do stuff you can't just force with dfhack yet.
like making an unit named Aimed Shot that hits like a space station and sets up aimed attacks that pierce and probably sticks into the person you told Aim to hit.
you could even set up how much force and damage the attacks are you could even assign the same historical figure to Aimed Shot so any kills they get would transfer over to the player.

this script idea would only work as long as the whole sneaking thing isn't fixed and probably break if someone uses any reveal any hidden units scripts.
Title: Re: Roses' Script, System, and Utilities Collection (04/06/2020)
Post by: Rose on June 24, 2020, 10:17:49 am
Give humans a TV set.

I don't actually have any good ideas, I just think we should team up on a mod purely for name confusion.
Title: Re: Roses' Script, System, and Utilities Collection (04/06/2020)
Post by: Roses on June 24, 2020, 12:20:07 pm
Quote from: Rumrusher on June 24, 2020, 05:12:20 am
so I just got an adv mode idea given how stealth works and how it's invisible to the player but not to everyone else. is it possible to make Dfhack npcs that spawn in and hide out of site to do stuff you can't just force with dfhack yet.
like making an unit named Aimed Shot that hits like a space station and sets up aimed attacks that pierce and probably sticks into the person you told Aim to hit.
you could even set up how much force and damage the attacks are you could even assign the same historical figure to Aimed Shot so any kills they get would transfer over to the player.

this script idea would only work as long as the whole sneaking thing isn't fixed and probably break if someone uses any reveal any hidden units scripts.

Theoretically I think it would be possible, but spawning units with DFHack can be problematic, so I'm not sure you would want to do that too much. I also don't think there are too many things that a hidden npc could do that you couldn't do without it. For instance, in your example, you can already make an attack and add it to a unit and modify it's attack values
Title: Re: Roses' Script, System, and Utilities Collection (04/06/2020)
Post by: Rumrusher on June 27, 2020, 04:50:45 am
so you're saying one could slap an attack on the unit modify it and have it target themselves?
well then that's one work around to get control of which body part you want to shoot.
Title: Re: Roses' Script, System, and Utilities Collection (04/06/2020)
Post by: Roses on June 27, 2020, 02:18:22 pm
Quote from: Rumrusher on June 27, 2020, 04:50:45 am
so you're saying one could slap an attack on the unit modify it and have it target themselves?
well then that's one work around to get control of which body part you want to shoot.

Hmmm, normally I would say no because projectile attacks don't function the same as normal attacks and self targeted attacks usually don't work, but if your goal is to be able to target specific body parts in adventure mode (or say a special ammo that always targets the head or legs or something) it may actually be possible by modifying the projectile right before it hits the target. I'll have to explore how the game handles projectile attacks.

For reference, I was referring to melee attacks, which can easily be added and modified such that you can change the velocity, hit chance, and target body part of an attack.
Title: Re: Roses' Script, System, and Utilities Collection (04/06/2020)
Post by: Roses on July 09, 2020, 01:24:27 am
Alright, I've got the basics of the Enhanced Reactions all up and running. I am still experimenting and testing a bit with how the various triggers are being handled together (onJobCompleted and onReactionComplete) along with my custom triggers, but they seem to all be cooperating together. The trick being making sure that the required information is available regardless of if a product from a reaction is created or not.

Currently script calling is enabled through the system, which lets you do anything you could want, but I am also working on getting shortcuts set up for some of the more obvious uses (miasma/smoke generation, long time reactions, variable reactions, power/water/magma consumption, etc...).

Some of my previous work on the Enhanced Reactions has been invalidated with the 0.47 release as well, which means I still want to go through and make sure I am not duplicating anything that is currently doable with the new reactions.
Title: Re: Roses' Script, System, and Utilities Collection (04/06/2020)
Post by: Roses on October 02, 2020, 04:07:26 pm
So I am finally back working on some DF stuff and getting back into the swing of things. I will be moving my devel branch to the master branch in the next week or two and making an official release of the new system. As a little preview of the type of things that are possible with my new set up, here is the unit metatables

Code: (Works like the df.unit.find(id) function, except it returns a new metatable) [Select]
[lua]# unit = reqscript("functions/unit").getUnit(752)
[lua]# ~unit
table: 000001F81AE9CDA0
id                       = 752
_unit                    = <unit: 000001F81AE7E0C0>        -- The old return of df.unit.find(id)
Flags                    = table: 000001F81AE9CFE0         -- Each of these are metatables that access the desired information
Counters                 = table: 000001F81AE9D060
Attributes               = table: 000001F81AE9CEE0
Skills                   = table: 000001F81AE9CF20

Code: (Access the same information from the df.unit reference the same way) [Select]
[lua]# !unit.name == unit._unit.name
true
[lua]# ~unit.name
<language_name: 000001F81AE7E0C8>
first_name               =
nickname                 =
words                    = <int32_t[]: 000001F81AE7E108>
parts_of_speech          = <part_of_speech[]: 000001F81AE7E124>
language                 = -1
unknown                  = -1
has_name                 = false

Code: (Physical and Mental attributes are all stored together, no more need to look in different spots) [Select]
[lua]# ~unit.Attributes.STRENGTH
table: 000001F81B143420
token                    = STRENGTH
type                     = Physical
_unit                    = <unit: 000001F81AE7E0C0>
_attribute               = <unit_attribute: 000001F81AE7E6A4>
[lua]# ~unit.Attributes.WILLPOWER
table: 000001F81BE4C8A0
token                    = WILLPOWER
type                     = Mental
_unit                    = <unit: 000001F81AE7E0C0>
_attribute               = <unit_attribute: 000001F819EDBB64>

Code: (dfhack functions are linked to the new metatable) [Select]
[lua]# ~unit.getAge()
230.81025793651
[lua]# ~dfhack.units.getAge(unit._unit)
230.81025793651
Title: Re: Roses' Script, System, and Utilities Collection (04/06/2020)
Post by: Roses on October 13, 2020, 03:56:53 pm
Alright! The git repo has been updated and migrated to the master branch. Development will continue in the devel branch so if you want the most up to date stuff check that branch out first.

This release adds the Enhanced Reactions system to what was already there. For now it is just the basics and supports easy running of scripts based on queing up reactions, starting the actual reaction, finishing the reaction, and producing products from a reaction (see the third post for more information). It also allows easy checking for nearby water and magma (cancelling the reaction if there is not enough) and easy production of flows and liquids from reactions. For example, adding
Code: [Select]
{PRODUCT:100:150:FLOW:MIASMA:NONE:NONE}to the reaction means that the reaction will produce a 150 density miasma flow with 100% probability, and
Code: [Select]
{PRODUCT:50:7:LIQUID:WATER:NONE:NONE}will produce a 7 depth tile of water with a 50% probability.

All scripts on the second post and systems on the third post should be working and I have written tests to make sure they keep working in future updates.

Moving forward I still need to implement the Enhanced Creatures and Enhanced Materials systems. Then I will probably work on migrating the Journal, Encyclopedia, and Detailed Unit Viewer gui's from the old repo to the new repo. I also want to re-implement the Class and Civilization Systems from the old repo but it will need to be heavily modified.


Title: Re: Roses' Script, System, and Utilities Collection (10/13/2020)
Post by: Roses on October 14, 2020, 02:26:57 pm
Alright, Enhanced Creatures is on its way! As a little taste you can now put
Code: [Select]
{ON_DEATH}
  {SCRIPT:map/spawn-flow -unit UNIT_ID -type Fire -density 100:100}OR just put
Code: [Select]
{EXPLODES_ON_DEATH}
Into the creatures raws and when that creature dies it will now create a little explosion of fire!
Title: Re: Roses' Script, System, and Utilities Collection (10/13/2020)
Post by: Roses on October 22, 2020, 03:22:28 pm
Another update.

I've got the attributes and sizes for units working correctly now. Essentially you declare the size numbers and attribute numbers the same way they are done now, but instead of capping them, the script assigns the correct numbers to the unit. Note that this doesn't work for world gen mode as it only sets them once they appear on the screen, I might try to tie the setting into the historical figure generation in world gen so that it might work, but that is a stretch goal at this point.

Attack modifications are also in place so for instance if we take a kick attack like
Code: [Select]
[ATTACK:KICK:BODYPART:BY_TYPE:STANCE]
[ATTACK_SKILL:STANCE_STRIKE]
[ATTACK_VERB:kick:kicks]
[ATTACK_CONTACT_PERC:100]
[ATTACK_PREPARE_AND_RECOVER:4:4]
[ATTACK_FLAG_WITH]
[ATTACK_PRIORITY:SECOND]
[ATTACK_FLAG_BAD_MULTIATTACK]we can add some extra tokens to do some fancy things
Code: [Select]
[ATTACK:KICK:BODYPART:BY_TYPE:STANCE]
[ATTACK_SKILL:STANCE_STRIKE]
[ATTACK_VERB:kick:kicks]
[ATTACK_CONTACT_PERC:100]
[ATTACK_PREPARE_AND_RECOVER:4:4]
[ATTACK_FLAG_WITH]
[ATTACK_PRIORITY:SECOND]
[ATTACK_FLAG_BAD_MULTIATTACK]
{ON_ATTACK}
{SCRIPT:do-something}
{ON_HIT}
{SCRIPT:do-something}
{ON_WOUND}
{SCRIPT:do-something}
I am also planning on adding some more features to the attacks that are basically shortcuts, so you could modify the velocity or hit chance of the attack directly, add repeat attacks, or even have targeted attacks (e.g. HEAD_KICK).

Interactions are a little harder due to the fact that they are handled differently than all the other raws I've processed so far, namely, a unit can have several different [CAN_DO_INTERACTION:MATERIAL_EMISSION] in their raws and each one will be different in DF but my current code would just create a single one (since it would just read the MATERIAL_EMISSION). An easy work around for now would be to only allow unique interaction entries read from the [OBJECT:INTERACTION] files, so that you would have multiple copies of the [INTERACTION:MATERIAL_EMISSION] (e.g. [INTERACTION:MATERIAL_EMISSION_DRAINBLOOD]) that has the Enhanced Raws stuff in them. But I'd rather be able to add the Enhanced Raws stuff to both places if the user wanted.

Other triggers that I've added are {ON_DEATH}, {ON_KILL}, {ON_MOVE}, and {ON_STRESSED}. Currently they only accept scripts with the triggers (except for the ON_DEATH shortcut {EXPLODES_ON_DEATH}), but I'll be adding other shortcuts as well.
Title: Re: Roses' Script, System, and Utilities Collection (10/13/2020)
Post by: Fleeting Frames on October 24, 2020, 08:15:49 pm
Encouraging to see the system develop. The advantage of rawified approach in keeping the entire thing in one place is quite nice for compartmentalizing, despite what limits it may hold.

If I were to make a suggestion, {ON_EXISTENCE} (or _LIFE?) i.e. something to run when the unit enters map for the first time (through being born or migrating on-site) for ex. assigning animalmen to player fort and announcing migrants, though I think you currently can do a lot by just self-applied syndrome.
Quote from: Roses on August 24, 2015, 08:39:56 am
How to use it
  • Copy the Scripts/raw/scripts folder into your DF raw folder (hopefully there are no conflicts with any other scripts you have installed there)
  • Copy the Scripts/raw/systems folder into your DF raw folder (directly into the raw folder, not the raw/scripts folder)
  • Put core/initialize in your onLoad init file. If you want more verbose output you can use -v repeatedly (up to -vvvvv)
  • All available systems should now be working, and all scripts should now be callable through any other methods you want
Regarding this list, couldn't the third step (core/initialize) be skipped by adding init.lua (https://docs.dfhack.org/en/latest/docs/Lua%20API.html#save-init-script) into raws for the purpose of sharing existing saves?
Title: Re: Roses' Script, System, and Utilities Collection (10/13/2020)
Post by: Roses on October 26, 2020, 03:04:58 pm
Quote from: Fleeting Frames on October 24, 2020, 08:15:49 pm
Encouraging to see the system develop. The advantage of rawified approach in keeping the entire thing in one place is quite nice for compartmentalizing, despite what limits it may hold.

If I were to make a suggestion, {ON_EXISTENCE} (or _LIFE?) i.e. something to run when the unit enters map for the first time (through being born or migrating on-site) for ex. assigning animalmen to player fort and announcing migrants, though I think you currently can do a lot by just self-applied syndrome.
Quote from: Roses on August 24, 2015, 08:39:56 am
How to use it
  • Copy the Scripts/raw/scripts folder into your DF raw folder (hopefully there are no conflicts with any other scripts you have installed there)
  • Copy the Scripts/raw/systems folder into your DF raw folder (directly into the raw folder, not the raw/scripts folder)
  • Put core/initialize in your onLoad init file. If you want more verbose output you can use -v repeatedly (up to -vvvvv)
  • All available systems should now be working, and all scripts should now be callable through any other methods you want
Regarding this list, couldn't the third step (core/initialize) be skipped by adding init.lua (https://docs.dfhack.org/en/latest/docs/Lua%20API.html#save-init-script) into raws for the purpose of sharing existing saves?

There actually is already a trigger for when a unit is first detected on the map (it's how the attributes and sizes are assigned) but I hadn't exposed it to script calls and such, but that is easy enough to do.

As for the other part, yes you are completely correct. I had meant to do that a while back and it must have slipped my mind.
Title: Re: Roses' Script, System, and Utilities Collection (10/13/2020)
Post by: Luckyowl on November 17, 2020, 02:07:00 am
Hey, got this bug going on. The item_enhanexample name are invisible in the object test arena. Can you tell me how to fix it?
Title: Re: Roses' Script, System, and Utilities Collection (10/13/2020)
Post by: Luckyowl on November 17, 2020, 10:04:07 am
Figured out was the problem. You didn't have a plural name for the example items. It should've been
power digger:power diggers.

But that's honestly a minor thing.
I got a question are the skills and attributes changes attached to the item invisible? Or are they suppose to show up in you the player's stats?
Title: Re: Roses' Script, System, and Utilities Collection (10/13/2020)
Post by: Roses on November 17, 2020, 02:11:33 pm
Thanks for pointing that out. I'll make sure to update the examples.

The changes should be visible in the players stats, but I have only really tested in fortress mode and looked at the stats in DFHack. I'll test out in adventure mode and make sure it is correctly applying and is visible (also looking through the code right now it seems I didn't finish all of the attribute and skill change things, so some of them may not even be working correctly).
Title: Re: Roses' Script, System, and Utilities Collection (10/13/2020)
Post by: Evans on November 22, 2020, 04:09:21 pm
Roses,

I'm trying to bring back old script for cage-thrower that cages target.
So far I've managed to restore projectiles into cages and they do capture targets.

But, the hunter or attackers keep at the target. Apparently there has been a change between then and now on how units store their targets.

After searching through forums I've noticed you have a script for creating an attack and clearing actions from units. Any ideas how to remove current action target from unit? :/
Title: Re: Roses' Script, System, and Utilities Collection (10/13/2020)
Post by: Roses on November 23, 2020, 03:50:49 pm
Quote from: Evans on November 22, 2020, 04:09:21 pm
Roses,

I'm trying to bring back old script for cage-thrower that cages target.
So far I've managed to restore projectiles into cages and they do capture targets.

But, the hunter or attackers keep at the target. Apparently there has been a change between then and now on how units store their targets.

After searching through forums I've noticed you have a script for creating an attack and clearing actions from units. Any ideas how to remove current action target from unit? :/

Just for clarification, what exactly happens? The cage gets thrown correctly, and the target gets put in the cage correctly, but the unit keeps attacking the caged target? More than one attack, or just a single extra attack?
Title: Re: Roses' Script, System, and Utilities Collection (10/13/2020)
Post by: Evans on November 23, 2020, 06:23:44 pm
Quote from: Roses on November 23, 2020, 03:50:49 pm
Just for clarification, what exactly happens? The cage gets thrown correctly, and the target gets put in the cage correctly, but the unit keeps attacking the caged target? More than one attack, or just a single extra attack?
There was once this bug where squads ordered to kill target followed target after it was caught by cage trap.

It's the same - hunter wants to hunt/return kill, squads ordered to kill stay at that order and follow caged target.

Here is the script, I will refactor it a bit later, if I deal with this follow issue :S
Spoiler (click to show/hide)
Title: Re: Roses' Script, System, and Utilities Collection (10/13/2020)
Post by: Roses on November 24, 2020, 01:01:55 pm
Quote from: Luckyowl on November 17, 2020, 10:04:07 am
Figured out was the problem. You didn't have a plural name for the example items. It should've been
power digger:power diggers.

But that's honestly a minor thing.
I got a question are the skills and attributes changes attached to the item invisible? Or are they suppose to show up in you the player's stats?

It looks like several of the hooks for the attribute and skill changes are not working correctly. I was testing using the {SCRIPT} command, so that is my fault. I'll get the hooks correct and upload a new version. Sorry for the inconvenience.

Quote from: Evans on November 23, 2020, 06:23:44 pm
Quote from: Roses on November 23, 2020, 03:50:49 pm
Just for clarification, what exactly happens? The cage gets thrown correctly, and the target gets put in the cage correctly, but the unit keeps attacking the caged target? More than one attack, or just a single extra attack?
There was once this bug where squads ordered to kill target followed target after it was caught by cage trap.

It's the same - hunter wants to hunt/return kill, squads ordered to kill stay at that order and follow caged target.

Here is the script, I will refactor it a bit later, if I deal with this follow issue :S

Looking at the code briefly I see this part, which looks like it's trying to do what you want, but the if statement will never read true because it is comparing an id to a unit struct
Code: [Select]
local allUnits = nil
allUnits = df.global.world.units.all
--make other units stop following it
for i=#allUnits-1,0,-1 do -- search list in reverse
newu = allUnits[i]
if newu.opponent.unit_id == unit then
newu.following = nil
newu.enemy = nil
newu.opponent.unit_id = nil
newu.job.hunt_target = nil
end
end

Try changing if newu.opponent.unit_id == unit then to if newu.opponent.unit_id == unit.id then and see if that works.
Title: Re: Roses' Script, System, and Utilities Collection (10/13/2020)
Post by: Evans on November 24, 2020, 03:32:31 pm
Quote from: Roses on November 24, 2020, 01:01:55 pm
Looking at the code briefly I see this part, which looks like it's trying to do what you want, but the if statement will never read true because it is comparing an id to a unit struct

Try changing if newu.opponent.unit_id == unit then to if newu.opponent.unit_id == unit.id then and see if that works.

Script now looks like that:
Spoiler (click to show/hide)
Log shows no bugs, but nothing really changed. Seems like 'following' is no longer used (I've monitored the engangement with gui/gm-editor) as it is always nil and opponent is only used during the actual attack.

Targeting for hunt/kill job seems to be kept elsewhere :/

I can't seem to find a field tho...

Hmm... Is there maybe a way to peak into job data somewhere?
Title: Re: Roses' Script, System, and Utilities Collection (10/13/2020)
Post by: Roses on November 24, 2020, 06:11:40 pm
Darn, was hoping it would be a simple fix. One other simple thing you could try would be to change the units path goal newu.path.goal = -1, that might reset them. You can also try to remove any jobs they might currently have with
Code: [Select]
newu.job.current_job = nil although I would be a little concerned that that might leave a hanging job on the list and cause issues if it happens to much. But if that does fix it, then it would be simple enough to properly remove the job instead of just unassigning it.
Title: Re: Roses' Script, System, and Utilities Collection (10/13/2020)
Post by: Evans on November 25, 2020, 01:42:57 pm
Quote from: Roses on November 24, 2020, 06:11:40 pm
Darn, was hoping it would be a simple fix. One other simple thing you could try would be to change the units path goal newu.path.goal = -1, that might reset them. You can also try to remove any jobs they might currently have with
Code: [Select]
newu.job.current_job = nil although I would be a little concerned that that might leave a hanging job on the list and cause issues if it happens to much. But if that does fix it, then it would be simple enough to properly remove the job instead of just unassigning it.

There is something odd about all this.
The code:
Spoiler (click to show/hide)
I've added some logging to see what happens, and IF is executed properly. But here is the thing.
The unit seems to be loosing current job, as expected, but only for a split second and then it gets that job back... still following the target :)

I'm actually wondering about stealing some of your code for action cancelling and seeing what happens. You think that maybe '_action.type = -1' could help? :/
Title: Re: Roses' Script, System, and Utilities Collection (10/13/2020)
Post by: Evans on November 25, 2020, 02:02:35 pm
edit:

I think I'm getting somewhere.
The script now looks like this:
Spoiler (click to show/hide)
...aaaand it seems it works. I don't know what happens in the loop we were discussing earlier, but it works.
Nothing can be done about soldiers, it seems, as it is possible to issue kill order for caged animal to a squad.

But now there remains one last thing :(
A lingering hint under the cursor about the creature that persists between save and reload.
(https://i.postimg.cc/T1QV8mDg/lingering-hint.jpg)
Title: Re: Roses' Script, System, and Utilities Collection (10/13/2020)
Post by: Warmist on November 26, 2020, 05:41:27 am
Quote from: Evans on November 25, 2020, 02:02:35 pm
<...>

You need to mark that map tile as empty of creatures- see here: https://github.com/DFHack/scripts/blob/master/teleport.lua#L32
Title: Re: Roses' Script, System, and Utilities Collection (10/13/2020)
Post by: Evans on November 26, 2020, 03:22:10 pm
Quote from: Warmist on November 26, 2020, 05:41:27 am
Quote from: Evans on November 25, 2020, 02:02:35 pm
<...>

You need to mark that map tile as empty of creatures- see here: https://github.com/DFHack/scripts/blob/master/teleport.lua#L32
Wow. Thanks.

Edit:
Ok, here I'm trying this:
Spoiler (click to show/hide)
Both first things do not solve the problem, hint persists.
Last line with either nil or false returns an error.

What should I set in here? What am I missing? :S
Title: Re: Roses' Script, System, and Utilities Collection (10/13/2020)
Post by: Atomic Chicken on November 27, 2020, 01:35:43 pm
Quote from: Evans on November 25, 2020, 02:02:35 pm
...

Code: [Select]
local eventful = require 'plugins.eventful'

function getItemType(item)
  if item:getSubtype() ~= -1 and dfhack.items.getSubtypeDef(item:getType(), item:getSubtype()) then
    return dfhack.items.getSubtypeDef(item:getType(),item:getSubtype()).id
  else
    return df.item_type[item:getType()]
  end
end

function createCage(material, quality)
  local item = df.item_cagest:new()
  item.id = df.global.item_next_id
  df.global.world.items.all:insert('#',item)
  df.global.item_next_id = df.global.item_next_id+1
  item:setMaterial(material.type)
  item:setMaterialIndex(material.index)
  item:setQuality(quality)
  item:categorize(true)
  item.flags.removed = true
  return item
end

function getCaptureProbability(unit)
  local damageFactor = 1
  if unit.counters.winded > 0 then
    damageFactor = damageFactor/1.5
  end
  if unit.counters.stunned > 0 then
    damageFactor = damageFactor/1.5
  end
  if unit.counters.unconscious > 0 then
    damageFactor = damageFactor/2
  end
  if unit.counters.webbed > 0 then
    damageFactor = damageFactor/1.5
  end
  if unit.counters.nausea > 0 then
    damageFactor = damageFactor/1.5
  end

  local bloodFrac = 1
  local bloodMax = unit.body.blood_max
  if bloodMax ~= 0 then
    bloodFrac = unit.body.blood_count/bloodMax
  end

  return 100 - ((unit.body.size_info.size_cur*10 ^ 1/3)*bloodFrac*damageFactor)
end

function cageUnit(cage, unit)
  local containedIn = df.general_ref_contained_in_itemst:new()
  containedIn.item_id = cage.id
  unit.general_refs:insert('#', containedIn)
  unit.flags1.caged = true
  unit.flags1.on_ground = false
  local tileOccupancy = dfhack.maps.getTileBlock(unit.pos).occupancy[unit.pos.x%16][unit.pos.y%16]
  tileOccupancy.unit = false -- would probably be better to check whether there are other units on the same tile before disabling these
  tileOccupancy.unit_grounded = false

  local containsUnit = df.general_ref_contains_unitst:new()
  containsUnit.unit_id = unit.id
  cage.general_refs:insert('#', containsUnit)
  cage.flags.container = true
end

eventful.onProjItemCheckImpact.capture = function(projectile)
  local firedItem = projectile.item
  if not firedItem then
    return
  end

  if string.find(getItemType(firedItem), "_PROJCAGE", 9) then -- replace as necessary
    local material = dfhack.matinfo.decode(firedItem)
    if not material then -- shouldn't happen
      return
    end

    local targetUnit
    for _, u in ipairs(df.global.world.units.active) do
      if u ~= projectile.firer then -- prevent firer from capturing themself
        if same_xyz(u.pos, projectile.cur_pos) then -- find a unit at the same location as the projectile
          targetUnit = u
          break -- only a single unit will be captured
        end
      end
    end
    if not targetUnit then -- nothing to capture at the impact location
      return
    end

    local cage = createCage(material, firedItem.quality)
    dfhack.items.moveToGround(cage, targetUnit.pos)

    if math.random(100) > getCaptureProbability(targetUnit) then -- removing this will guarantee capture
      cageUnit(cage, targetUnit)
    end

    projectile.flags.to_be_deleted = true -- ensures that the fired item doesn't persist

--  make other units stop following the captured unit:
    local allUnits = df.global.world.units.all
    for i = #allUnits-1, 0, -1 do
      local unit = allUnits[i]
      if unit.following == targetUnit then
        unit.following = nil
      end
      if unit.opponent.unit_id == targetUnit.id then
        unit.opponent.unit_id = -1
        unit.path.goal = -1
        unit.job.current_job = nil
        unit.job.hunt_target = nil
      end
    end
  end
end

Tidied up your script whilst looking into the "phantom unit" issue. It also appears to occur with creatures that are captured via regular cage traps, so I'd say that this is a more of a problem with the way DFHack generates the "units under the cursor" display (cursor support isn't a vanilla feature), as opposed to anything specifically wrong with this script.

Looks like the script incorporates a Pokemon-esque mechanic which makes capturing easier the more damaged the target is. I didn't examine it closely, but it might need some fine-tuning as the bulk of my test units were caught on first attempt.

For future reference, enclosing code in a "code" block as opposed to a "spoiler" makes it easier for others to read and copy. Also, this particular thread might not be the most appropriate place to ask for scripting advice; opening a new one or continuing the discussion in the general DFHack thread would make it easier for others to notice your queries whilst preventing accidental derailing.
Title: Re: Roses' Script, System, and Utilities Collection (10/13/2020)
Post by: Evans on November 27, 2020, 04:09:58 pm
Quote from: Atomic Chicken on November 27, 2020, 01:35:43 pm
Tidied up your script whilst looking into the "phantom unit" issue. It also appears to occur with creatures that are captured via regular cage traps, so I'd say that this is a more of a problem with the way DFHack generates the "units under the cursor" display (cursor support isn't a vanilla feature), as opposed to anything specifically wrong with this script.
Whoah. Thanks.
Compared to yours, it's a miracle mine was even working.

Anyway,
Quote
Looks like the script incorporates a Pokemon-esque mechanic which makes capturing easier the more damaged the target is. I didn't examine it closely, but it might need some fine-tuning as the bulk of my test units were caught on first attempt.
True, I think original author (was it IndigoPhoenix) had something like that in mind. I've actually seen capture failed few times, but on bigger animals, so it might just work, somewhat :)

Quote
For future reference, enclosing code in a "code" block as opposed to a "spoiler" makes it easier for others to read and copy. Also, this particular thread might not be the most appropriate place to ask for scripting advice; opening a new one or continuing the discussion in the general DFHack thread would make it easier for others to notice your queries whilst preventing accidental derailing.
I'll keep that in mind. I thought maybe posting large blocks of unclean code wasn't such a smart idea ;)
And my apologies to Roses for hi-jacking this thread. I made a search through available lua scripts and Roses scripts were the only I've found where an action was cancelled.

Seems like this Phantom Menace won't go away any time soon, so cage guns will remain of limited use. But so far it is working, at least to some extend.

Thank you guys for help.
Title: Re: Roses' Script, System, and Utilities Collection (10/13/2020)
Post by: Roses on May 21, 2021, 01:09:20 pm
You know its been a long time when you are getting an old topic warning when posting in your own thread...

So after a very hectic year, I am finally getting back into a point where I can do some DF stuff. It looks like a left off with a few fixes needed for for the EnhancedItems and testing needed for Adventure mode. I also need to investigate if there have been any major changes to DFHack that I should be including. I will probably need some testers in the near future for some other stuff I am planning on implementing, but for now I just need to get back into the feel of DF.
Title: Re: Roses' Script, System, and Utilities Collection (10/13/2020)
Post by: myk on May 25, 2021, 02:12:28 pm
Hi Roses! Welcome back! I've been seeing your name in the code a lot, but we've never met. I've been making a lot of changes recently to quickfort (https://docs.dfhack.org/en/latest/docs/_auto/base.html#quickfort) (there's one in DFHack now, not the external Python one), buildingplan (https://docs.dfhack.org/en/latest/docs/Plugins.html#buildingplan), and blueprint (https://docs.dfhack.org/en/latest/docs/Plugins.html#blueprint).

I'm also working on a few utility plugins that might be useful for you -- dig-dug (https://github.com/DFHack/dfhack/pull/1853) to dig out sections of rock according to dig designations and build-now (https://github.com/DFHack/dfhack/issues/1857) (or something.. I haven't really thought of a name yet) for instantly completing construction jobs. My use case is automated regression testing -- apply a blueprint file with quickfort, use dig-dug and build-now to make things happen without dwarven intervention, create blueprint files from the resulting game map with blueprint, and compare the input and output files -- but you might be able to use them for making general changes to the game map.

There's also a database of building metadata (https://github.com/DFHack/scripts/blob/master/internal/quickfort/build.lua#L237) in quickfort that we might be able to factor out and share.
Title: Re: Roses' Script, System, and Utilities Collection (10/13/2020)
Post by: Roses on May 27, 2021, 11:44:30 am
Quote from: myk on May 25, 2021, 02:12:28 pm
Hi Roses! Welcome back! I've been seeing your name in the code a lot, but we've never met. I've been making a lot of changes recently to quickfort (https://docs.dfhack.org/en/latest/docs/_auto/base.html#quickfort) (there's one in DFHack now, not the external Python one), buildingplan (https://docs.dfhack.org/en/latest/docs/Plugins.html#buildingplan), and blueprint (https://docs.dfhack.org/en/latest/docs/Plugins.html#blueprint).

I'm also working on a few utility plugins that might be useful for you -- dig-dug (https://github.com/DFHack/dfhack/pull/1853) to dig out sections of rock according to dig designations and build-now (https://github.com/DFHack/dfhack/issues/1857) (or something.. I haven't really thought of a name yet) for instantly completing construction jobs. My use case is automated regression testing -- apply a blueprint file with quickfort, use dig-dug and build-now to make things happen without dwarven intervention, create blueprint files from the resulting game map with blueprint, and compare the input and output files -- but you might be able to use them for making general changes to the game map.

There's also a database of building metadata (https://github.com/DFHack/scripts/blob/master/internal/quickfort/build.lua#L237) in quickfort that we might be able to factor out and share.

Those do sound like useful utilities, I have something similar in a script that takes a building name and position and constructs a fully operational building (building/create.lua (https://github.com/Pheosics/roses_collection/blob/master/Scripts/raw/scripts/building/create.lua)), but it isn't as advanced as what I am seeing in your script (I also have a small database of hardcoded buildings (functions/building.lua (https://github.com/Pheosics/roses_collection/blob/master/Scripts/raw/scripts/functions/building.lua)), but again, not as advanced as yours). I will definitely look into your stuff, I am particularly interested in dig-dug since I think it would be really cool to make "geomancy" type magic that manipulates the map and such. I've only played around with very basic map manipulation, mostly just removing trees/bushes (functions/plant.lua (https://github.com/Pheosics/roses_collection/blob/master/Scripts/raw/scripts/functions/plant.lua)), and checking tiletypes and such (functions/map.lua (https://github.com/Pheosics/roses_collection/blob/master/Scripts/raw/scripts/functions/map.lua)), not much actually changing things.
Title: Re: Roses' Script, System, and Utilities Collection (10/13/2020)
Post by: myk on May 29, 2021, 12:27:54 pm
plant.lua looks like exactly what I need to simulate tree chopping. I was worried that I'd just have to ignore trees entirely if I couldn't figure it out! Do you mind if I add that to either dig-dug itself or the dfhack core library?

tiletypes (https://docs.dfhack.org/en/latest/docs/Plugins.html#tiletypes) might also be useful to force a tile into a particular shape/configuration. I'm writing dig-dug because I specifically want the tile tile transformations to follow the rules of "organic" digging.

If you think you could use the quickfort buildings db, I can work on putting it behind an API so it's queryable by multiple indices (e.g. by type,subtype,custom instead of its current "ui keystroke sequence" map key
Title: Re: Roses' Script, System, and Utilities Collection (10/13/2020)
Post by: Bumber on May 29, 2021, 04:05:28 pm
Quote from: myk on May 29, 2021, 12:27:54 pm
plant.lua looks like exactly what I need to simulate tree chopping. I was worried that I'd just have to ignore trees entirely if I couldn't figure it out!

I don't understand everything that's going on in the script, but it doesn't look like it will cause items to fall out of the removed tree, or water to recalculate. In other words, it's equivalent to using a ballista bolt.

dfhack.items.makeProjectile can be used to cause an item to fall, and liquids plugin probably has the proper way to update fluids. Should be simple enough to implement.


I've been preparing to disassemble the exact code for tree chopping by starting with understanding the less complex function for finding a plant at a tile (that the tree chopping function calls.) Knowing I'm probably seeing:
Code: [Select]
y_column = math.floor(base.y/16)
y_column-y_column%3when I'm looking at
Code: [Select]
movsx   r12d, r8w ; y coord into r12
mov     eax, 2AAAAAABh
imul    r12d
mov     edi, r12d
movzx   ecx, r12w
sar     edx, 3
mov     eax, edx
shr     eax, 1Fh
add     edx, eax
lea     eax, [rdx+rdx*2]
shl     eax, 4
sub     edi, eax
sub cx, di
mov     [rsp+30h+arg_8], ediis very helpful!

Edit: Actually, looks like the above assembly calculates math.floor(base.x / 48) * 48 and base.y%48 (which it later uses with dim_y to completely avoid using extent_north, etc.)

The optimized code used by DF is:
Code: [Select]
map_block_column = df.global.world.map.column_index[(math.floor(base.x / 48) * 48) / 16][(math.floor(base.y / 48) * 48) / 16]which avoids %3.
Title: Re: Roses' Script, System, and Utilities Collection (10/13/2020)
Post by: Roses on June 02, 2021, 10:41:28 am
Quote from: myk on May 29, 2021, 12:27:54 pm
plant.lua looks like exactly what I need to simulate tree chopping. I was worried that I'd just have to ignore trees entirely if I couldn't figure it out! Do you mind if I add that to either dig-dug itself or the dfhack core library?

tiletypes (https://docs.dfhack.org/en/latest/docs/Plugins.html#tiletypes) might also be useful to force a tile into a particular shape/configuration. I'm writing dig-dug because I specifically want the tile tile transformations to follow the rules of "organic" digging.

If you think you could use the quickfort buildings db, I can work on putting it behind an API so it's queryable by multiple indices (e.g. by type,subtype,custom instead of its current "ui keystroke sequence" map key

Any of the code I write can be freely used by anyone. I do request that there is some mention of where it comes from (mainly so if there are questions about it in the future it is easier to track down). Before you change any code, let me make sure that I could actually make use of it :)

Quote from: Bumber on May 29, 2021, 04:05:28 pm
Quote from: myk on May 29, 2021, 12:27:54 pm
plant.lua looks like exactly what I need to simulate tree chopping. I was worried that I'd just have to ignore trees entirely if I couldn't figure it out!

I don't understand everything that's going on in the script, but it doesn't look like it will cause items to fall out of the removed tree, or water to recalculate. In other words, it's equivalent to using a ballista bolt.

dfhack.items.makeProjectile can be used to cause an item to fall, and liquids plugin probably has the proper way to update fluids. Should be simple enough to implement.


I've been preparing to disassemble the exact code for tree chopping by starting with understanding the less complex function for finding a plant at a tile (that the tree chopping function calls.) Knowing I'm probably seeing:
Code: [Select]
y_column = math.floor(base.y/16)
y_column-y_column%3when I'm looking at
Code: [Select]
movsx   r12d, r8w ; y coord into r12
mov     eax, 2AAAAAABh
imul    r12d
mov     edi, r12d
movzx   ecx, r12w
sar     edx, 3
mov     eax, edx
shr     eax, 1Fh
add     edx, eax
lea     eax, [rdx+rdx*2]
shl     eax, 4
sub     edi, eax
sub cx, di
mov     [rsp+30h+arg_8], ediis very helpful!

Edit: Actually, looks like the above assembly calculates math.floor(base.x / 48) * 48 and base.y%48 (which it later uses with dim_y to completely avoid using extent_north, etc.)

The optimized code used by DF is:
Code: [Select]
map_block_column = df.global.world.map.column_index[(math.floor(base.x / 48) * 48) / 16][(math.floor(base.y / 48) * 48) / 16]which avoids %3.

That's some interesting stuff, you are correct that the currently removal doesn't cause items to fall or water to recalculate. It also sometimes leaves a few branches way up high, and can mess up if there are multiple trees in overlapping vicinity, so it is definitely a work in progress. It definitely wouldn't be hard to loop over any items in the tree and turn them into projectiles and loop over any water tiles and add the update flows flag.
Title: Re: Roses' Script, System, and Utilities Collection (10/13/2020)
Post by: Bumber on June 02, 2021, 07:53:08 pm
Quote from: Roses on June 02, 2021, 10:41:28 am
It definitely wouldn't be hard to loop over any items in the tree and turn them into projectiles and loop over any water tiles and add the update flows flag.

As far as I know, you can just enable updates in the tile where the plant coordinate was, and it will end up updating the whole body of water. (Unless the liquids command is doing more than just setting the single tile's flag.) Although you'd probably want to set the flag where each solid tree tile was, just in case there are setups where that matters.
Title: Re: Roses' Script, System, and Utilities Collection (10/13/2020)
Post by: Roses on June 03, 2021, 09:49:59 am
Quote from: Bumber on June 02, 2021, 07:53:08 pm
Quote from: Roses on June 02, 2021, 10:41:28 am
It definitely wouldn't be hard to loop over any items in the tree and turn them into projectiles and loop over any water tiles and add the update flows flag.

As far as I know, you can just enable updates in the tile where the plant coordinate was, and it will end up updating the whole body of water. (Unless the liquids command is doing more than just setting the single tile's flag.) Although you'd probably want to set the flag where each solid tree tile was, just in case there are setups where that matters.

Yes, I think that is correct. It would be interesting to see if the actual tree cutting functions that DF uses causes some other updates. I suppose the inside/outside or light/dark flags (can't remember their exact names) are also probably updated, but I'm sure there are more that I am not thinking about.
Title: Re: Roses' Script, System, and Utilities Collection (10/13/2020)
Post by: Bumber on June 03, 2021, 01:40:31 pm
Quote from: Roses on June 03, 2021, 09:49:59 am
I suppose the inside/outside or light/dark flags (can't remember their exact names) are also probably updated, but I'm sure there are more that I am not thinking about.

I don't think trees affect subterranean/above ground or light/dark flags, just outside/inside (like buildings.) Looks like your script always sets the tile to outside, which doesn't make sense for cavern trees. Something more may need to be done there, like setting it to the respective x/y tiles in the z-level above the tree.
Title: Re: Roses' Script, System, and Utilities Collection (10/13/2020)
Post by: myk on June 03, 2021, 07:03:54 pm
Quote from: Bumber on June 03, 2021, 01:40:31 pm
Something more may need to be done there, like setting it to the respective x/y tiles in the z-level above the tree.
This is what I do for the (in-progress) dig-now plugin (https://github.com/DFHack/dfhack/pull/1853/files#diff-2d6a3ff76af0fba5cca4b4c49bd1a415925ea68332464d4431a33b03b53d54d3R36) so light can filter down through newly dug ramps/channels. Code is in C++ but we could probably move it to the core library and expose it via the Lua API.

Code: [Select]
    df::tile_designation td = map.designationAt(pos);

    if (!map.ensureBlockAt(DFCoord(pos.x, pos.y, pos.z+1))) {
        // only the sky above
        td.bits.light = true;
        td.bits.outside = true;
        td.bits.subterranean = false;
    }

    int32_t zlevel = pos.z;
    df::tiletype_shape shape =
            tileShape(map.tiletypeAt(DFCoord(pos.x, pos.y, zlevel)));
    while ((shape == df::tiletype_shape::EMPTY
            || shape == df::tiletype_shape::RAMP_TOP)
           && map.ensureBlockAt(DFCoord(pos.x, pos.y, --zlevel))) {
        DFCoord pos_below(pos.x, pos.y, zlevel);
        df::tile_designation td_below = map.designationAt(pos_below);
        if (td_below.bits.light == td.bits.light
                && td_below.bits.outside == td.bits.outside
                && td_below.bits.subterranean == td.bits.subterranean)
            break;
        td_below.bits.light = td.bits.light;
        td_below.bits.outside = td.bits.outside;
        td_below.bits.subterranean = td.bits.subterranean;
        map.setDesignationAt(pos_below, td_below);
        shape = tileShape(map.tiletypeAt(pos_below));
    }
Title: Re: Roses' Script, System, and Utilities Collection (10/13/2020)
Post by: Bumber on June 06, 2021, 11:04:58 am
Here's a simplification of the code for erasing the plant from the map column:
Code: [Select]
-- Erase plant from correct map column
map_block_column = df.global.world.map.column_index[base.x//48*3][base.y//48*3]
for i,plant in pairs(map_block_column.plants) do
if plant.pos == base then
map_block_column.plants:erase(i)
break
end
end"//" is integer division, which avoids the need for "math.floor()".
Note that "n//m" equals "n - n%m", because it's the non-remainder portion. Edit: I guess it's "(n - n%m)/m".
Dividing by 48 instead of 3 (since 48 = 3 * 16) takes care of the column conversion.
(It's worth pointing out that "base.x//48" is a mid-level tile coord. MLT's are 3*3 tile block columns, so "base.x//48*3" is a tile block column coord. It all checks out.)
Reused "map_block_column" instead of calculating it again.

Some shroom trees use just "body.connection_north" to indicate part of their cap, so you'll need to add that to "getPositions()". You also used z1,y1,x1 in the displace logic instead of the loop variables z,y,x.

You're probably going to need to remove roots, unless that's handled automatically somehow. "tree.roots" is similar to "tree.body", except it's upside-down. It's indexed from 0 to "tree.root_depth - 1". Presence of a root is indicated by "trunk" flag. Should be as simple as adding a second z loop after the first one. (Technically, you could get away with just "tree.roots[0]" in the current version of DF, but a loop is forward compatible for root_depth > 1.)

Changes:
Code: [Select]
...
local z1 = tree.pos.z
local z2 = tree.pos.z + tree.tree_info.body_height - 1
local z_root1 = tree.pos.z - 1
local z_root2 = tree.pos.z - tree.tree_info.root_depth
for x = x1,x2 do
for y = y1,y2 do
for z = z1,z2 do
pos = {x=x,y=y,z=z}
body = tree.tree_info.body[pos.z-z]:_displace((pos.y - y) * tree.tree_info.dim_x + (pos.x - x))
if body.trunk or body.twigs or body.branches or body.connection_north then
positions[#positions+1] = pos
end
end
for z = z_root2,z_root1 do
pos = {x=x,y=y,z=z}
root = tree.tree_info.root[pos.z - z - 1]:_displace((pos.y - y) * tree.tree_info.dim_x + (pos.x - x))
if root.trunk then
positions[#positions+1] = pos
end
end
end
...I also simplified the if statements for body checks.

All that's left is to account for "position.z < base.z" for the tiletypes. Assuming roots can't grow in stone (need to test this,) then all you have to do is convert those positions to soil walls (tiletype 261.)

For the base, the floor tiletype should chose randomly from {348,349,350,351} instead of just 350 for tile variations. (That was probably already on the to-do list.)
Title: Re: Roses' Script, System, and Utilities Collection (10/13/2020)
Post by: Roses on June 07, 2021, 03:42:11 pm
Quote from: Bumber on June 03, 2021, 01:40:31 pm
Quote from: Roses on June 03, 2021, 09:49:59 am
I suppose the inside/outside or light/dark flags (can't remember their exact names) are also probably updated, but I'm sure there are more that I am not thinking about.

I don't think trees affect subterranean/above ground or light/dark flags, just outside/inside (like buildings.) Looks like your script always sets the tile to outside, which doesn't make sense for cavern trees. Something more may need to be done there, like setting it to the respective x/y tiles in the z-level above the tree.
Ah, you are correct, yeah that doesn't make much sense for underground trees.

Quote from: Bumber on June 06, 2021, 11:04:58 am
Here's a simplification of the code for erasing the plant from the map column:
Code: [Select]
-- Erase plant from correct map column
map_block_column = df.global.world.map.column_index[base.x//48*3][base.y//48*3]
for i,plant in pairs(map_block_column.plants) do
if plant.pos == base then
map_block_column.plants:erase(i)
break
end
end"//" is integer division, which avoids the need for "math.floor()".
Note that "n//m" equals "n - n%m", because it's the non-remainder portion.
Dividing by 48 instead of 3 (since 48 = 3 * 16) takes care of the column conversion.
(It's worth pointing out that "base.x//48" is a mid-level tile coord. MLT's are 3*3 tile block columns, so "base.x//48*3" is a tile block column coord. It all checks out.)
Reused "map_block_column" instead of calculating it again.
That's a lot cleaner. Honestly I don't even know where my previous code of figuring out the column blocks and such.

Quote from: Bumber on June 06, 2021, 11:04:58 am
Some shroom trees use just "body.connection_north" to indicate part of their cap, so you'll need to add that to "getPositions()". You also used z1,y1,x1 in the displace logic instead of the loop variables z,y,x.

You're probably going to need to remove roots, unless that's handled automatically somehow. "tree.roots" is similar to "tree.body", except it's upside-down. It's indexed from 0 to "tree.root_depth - 1". Presence of a root is indicated by "trunk" flag. Should be as simple as adding a second z loop after the first one. (Technically, you could get away with just "tree.roots[0]" in the current version of DF, but a loop is forward compatible for root_depth > 1.)

Changes:
Code: [Select]
...
local z1 = tree.pos.z
local z2 = tree.pos.z + tree.tree_info.body_height - 1
local z_root1 = tree.pos.z
local z_root2 = tree.pos.z + tree.tree_info.root_depth - 1
for x = x1,x2 do
for y = y1,y2 do
for z = z1,z2 do
pos = {x=x,y=y,z=z}
body = tree.tree_info.body[pos.z-z]:_displace((pos.y - y) * tree.tree_info.dim_x + (pos.x - x))
if body.trunk or body.twigs or body.branches or body.connection_north then
positions[#positions+1] = pos
end
end
for z = z_root2,z_root1 do
pos = {x=x,y=y,z=z}
root = tree.tree_info.root[pos.z-z]:_displace((pos.y - y) * tree.tree_info.dim_x + (pos.x - x))
if root.trunk then
positions[#positions+1] = pos
end
end
end
...I also simplified the if statements for body checks.

All that's left is to account for "position.z < base.z" for the tiletypes. Assuming roots can't grow in stone (need to test this,) then all you have to do is convert those positions to soil walls (tiletype 261.)

For the base, the floor tiletype should chose randomly from {348,349,350,351} instead of just 350 for tile variations. (That was probably already on the to-do list.)
I think I originally wrote this because I was only interested in removing trees in such a way that I could build buildings where they were, so it isn't surprising to me that a bunch of what I did was so piecemeal (and that I ignored roots entirely). This all looks good, and I'm glad other people are looking into this stuff.

On a different note, I finally got through reviewing the rest of my code and running through all the tests. Everything seems to be good there, so I am starting back with the stuff I said I would take care of way back when. This first update is mainly going to be adding some extra hooks to the Enhanced Items system so that you can easily add attribute and skill adjustments on gear. Currently this is already doable with linking scripts to the {ON_EQUIP} and {ON_UNEQUIP} tags, but my plan was always to have a {ATTRIBUTE:X:Y} tag that acted as a shortcut. I will have to do some tests to make sure that the equips/unequips are being triggered correctly everytime, and if they get missed sometimes I might have to add a periodic check that will run through units and make sure that the attributes/skills have been adjusted correctly.

The other Enhanced Items trigger tags (e.g. {ON_ATTACK}, {ON_WOUND}, etc...) seem to be working correctly. And the non-trigger tags (e.g. {FIRE_RATE:X:Y}, etc...) are also working correctly (see this (http://www.bay12forums.com/smf/index.php?topic=152762.msg8126876#msg8126876) post for an example of rapid fire crossbow).

Lastly, I want to get back into finishing up the Encyclopedia and Detailed Unit Viewer, since they are basically feature complete, most of what needs to be done now is visual and performance improvements. It currently looks rather unpleasing so I'll have to experiment with different color and organizational schemes. The, performance is fine for an unmodded DF, but if you try to open the Encyclopedia when using something like MW-DF it takes a while because it loads everything in and the start. This can be fixed by only loading parts, and smart loading certain information at game start, but I will have to play around with the exact configurations since we don't want to have a huge memory footprint.

Eventually I think it would be awesome to do a sort of export of the Encyclopedia into html or something similar that could be viewed externally from playing, but that would be a long way down the road unless I got someone to help me with it.
Title: Re: Roses' Script, System, and Utilities Collection (10/13/2020)
Post by: Bumber on June 12, 2021, 03:01:56 am
Discovered an edge case where part of a 2x2 trunk can be over air. Need to check for natural wall below first before putting soil floor down.

Interestingly, only trunk tiles themselves are considered indoors. They don't actually propagate it downwards like buildings or constructions do. Does this break myk's script?

Have to check for the case where the tree is separated from the surface by a thin floor and make sure it doesn't inherit the outside state. Player can also build between tree branches.

Need to do research on what happens if you turn a tree into a popsicle and chop it down. The original tiletype of a frozen tile is stored in a map block's block_events. Wouldn't surprise me if Toady himself didn't consider this bizarre case and floating branches appear when it thaws.

In keeping with a DF bug, running the script on shroom trees leaves floating down ramps. Going to need to handle those when removing an up ramp tiletype.
Title: Re: Roses' Script, System, and Utilities Collection (10/13/2020)
Post by: Fleeting Frames on June 12, 2021, 03:08:21 pm
I can confirm tree roots are created only in soil: When cavern trees have soil below them, they'll spawn roots.

Also
Quote
[DFHack]# :lua ~(7//2)
3
[DFHack]# :lua ~(7-7%2)
6

Meant (n-n%m)/m, I assume?

As for popsicle trees, quick test shows cast walls in area tree is cut down are converted into floors. As far as weird effects go, I see some ice floors didn't melt when they should have (the floating ones eventually collapse, leaving behind Unknown tile in at least one case, though generally just ice floors even with arrival of summer heat - albeit some do melt by then) , and some ice floors have ice floorx3 probe report, while others have ice floor/empty/empty.
Title: Re: Roses' Script, System, and Utilities Collection (10/13/2020)
Post by: Roses on June 12, 2021, 10:28:02 pm
Interesting stuff. So it seems like there are probably several cases where a created script might differ from in-game behavior, both on the script side of things not treating edge cases and on the DF side of things not necessarily treating edge cases consistently. In my mind I would think we should be looking at creating a script that mostly matches the in-game behavior, but treats any edge cases (that Toady might not have even thought about or considered as possibilities) self consistently. The important part for a script, in mu opinion, is that any user of the script has an expectation of what happens when they use it, even if that expectation doesn't match in game behavior (although I can definitely see how someone would want any script to exactly replicate in-game behavior, so I think it is a personal preference thing).

All that being said, I am super happy people are looking into this stuff, like I said before, I only messed around with this so that I could delete trees in order to build buildings, in particular my multi-story buildings. But if we can get a proper tree removal/script tree chopping going I could definitely see some custom civs using a version of it instead of built-in tree chopping
Title: Re: Roses' Script, System, and Utilities Collection (10/13/2020)
Post by: FantasticDorf on June 26, 2021, 10:33:24 am
Quote from: Roses on June 12, 2021, 10:28:02 pm
All that being said, I am super happy people are looking into this stuff, like I said before, I only messed around with this so that I could delete trees in order to build buildings, in particular my multi-story buildings. But if we can get a proper tree removal/script tree chopping going I could definitely see some custom civs using a version of it instead of built-in tree chopping

Not that that's particularly a problem when civilization ethics are concerned unless they dont have a equivlocal sharp axe tool, if citizens love trees usuallly because they are vanilla-elves, they often end up crying when they're cut down with a traumatic memory event.

Still handy to have around if a creative way to use the script is implemented, like construction/deconstruction of tree blocks set to templates (like a magma aquifer building directionality, generate tree height options of 1 2 3 blocks high with no leaves), but didn't want to risk cutting down your entire connected treehouse (depending on if treetiles of the same type auto-merge) to remove just a few specific blocks of it.

((i think what im trying to describe in this example is more of a natural timber-pillar spawned in with a modified /create-tree script than anything else))
Title: Re: Roses' Script, System, and Utilities Collection (07/06/2021)
Post by: Roses on July 06, 2021, 03:20:55 pm
Update to the Enhanced Item System. Previously the {ATTRIBUTE and {SKILL shortcuts were not working correctly. This fix makes sure that they are. Note that the changes when equipping/unequipping is currently happening when the item enters/exits the units inventory. Meaning a unit that picks up an item to haul it will experience the change. In the next update I will limit the equipping/unequipping changes to actually wearing/using the item, and I will add a OnPickup/OnDrop functionality for those that want something to happen on pickup/drop.

I'm going to step away from the Enhanced Systems for the next couple of updates (except for minor updates like the one above) as I get the journal and compendium back up to snuff.
Title: Re: Roses' Script, System, and Utilities Collection (07/06/2021)
Post by: Roses on September 16, 2021, 11:35:40 am
Small update, finally got around to pushing the changes to Enhanced Items so that only equipping an item as a piece of armor or using an item as a weapon will trigger the OnEquip and OnUnequip flags. Later I will put trigger flags for things like OnStuck, OnBandage, etc...

The Journal and Detailed Unit Viewer GUIs are also almost finished updating, all the new functions have been written and they have been moved into my new GUI system (which should make it a lot easier for me to write other GUIs going forward). The only thing left is to add all the functionality that the old GUIs had, and to make sure that they work on heavily modded games (and don't take forever to load)