Print

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

[Roses]

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.

[Roses]

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.

[Roses]

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.

[Putnam]

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.

[Roses]

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.

[Elowin]

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.

[Roses]

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.

[Fleeting Frames]

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)

Code: [Select]

[DFHack]# detailedunit
./hack/lua/dfhack.lua:507: Could not find script functions/gui
stack traceback:
[C]: in function 'error'
./hack/lua/dfhack.lua:507: in function 'run_script_with_env'
./hack/lua/dfhack.lua:490: in function 'script_environment'
.../user/DF/df4303LNP/df_linux/hack/scripts/detailedunit.lua:37: in function 'f'
./hack/lua/dfhack.lua:562: in function <./hack/lua/dfhack.lua:503>
(...tail calls...)


oh ok, a dependency, lets add it...

Spoiler (click to show/hide)

Code: [Select]

[DFHack]# detailedunit
...user/DF/df4303LNP/df_linux/hack/scripts/functions/gui.lua:2263: Cannot read field vector<historical_figure*>.40699: index out of bounds.
stack traceback:
[C]: in function '__index'
...user/DF/df4303LNP/df_linux/hack/scripts/functions/gui.lua:2263: in function 'getEntity'
...user/DF/df4303LNP/df_linux/hack/scripts/functions/gui.lua:2437: in function 'getBaseOutput'
.../user/DF/df4303LNP/df_linux/hack/scripts/detailedunit.lua:414: in function 'fillMain'
.../user/DF/df4303LNP/df_linux/hack/scripts/detailedunit.lua:317: in function 'fun'
./hack/lua/class.lua:98: in function 'invoke_after_rec'
./hack/lua/class.lua:127: in function 'UnitViewUi'
.../user/DF/df4303LNP/df_linux/hack/scripts/detailedunit.lua:622: in function 'show_editor'
.../user/DF/df4303LNP/df_linux/hack/scripts/detailedunit.lua:626: in function 'f'
./hack/lua/dfhack.lua:562: in function <./hack/lua/dfhack.lua:503>
(...tail calls...)


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)

Code: [Select]

[DFHack]# detailedunit
...user/DF/df4303LNP/df_linux/hack/scripts/functions/gui.lua:2805: attempt to index field 'roses' (a nil value)
stack traceback:
...user/DF/df4303LNP/df_linux/hack/scripts/functions/gui.lua:2805: in function 'getClassDetails'
.../user/DF/df4303LNP/df_linux/hack/scripts/detailedunit.lua:467: in function <.../user/DF/df4303LNP/df_linux/hack/scripts/detailedunit.lua:464>
[C]: in function 'on_select'
./hack/lua/gui/widgets.lua:532: in function 'moveCursor'
./hack/lua/gui/widgets.lua:463: in function 'setSelected'
./hack/lua/gui/widgets.lua:458: in function 'setChoices'
.../user/DF/df4303LNP/df_linux/hack/scripts/detailedunit.lua:460: in function 'classList'
.../user/DF/df4303LNP/df_linux/hack/scripts/detailedunit.lua:324: in function 'fun'
./hack/lua/class.lua:98: in function 'invoke_after_rec'
./hack/lua/class.lua:127: in function 'UnitViewUi'
.../user/DF/df4303LNP/df_linux/hack/scripts/detailedunit.lua:622: in function 'show_editor'
.../user/DF/df4303LNP/df_linux/hack/scripts/detailedunit.lua:626: in function 'f'
./hack/lua/dfhack.lua:562: in function <./hack/lua/dfhack.lua:503>
(...tail calls...)


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?

[Roses]

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.

[Fleeting Frames]

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.

[Roses]

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.

[Fleeting Frames]

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.

[Roses]

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.

[Fleeting Frames]

...

...How did I miss that?

...

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

>_> (Didn't RTFM.)

[Roses]

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).