Print

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

[Roses]

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.

[Isngrim]

will EnchancedItems be able to change the items subtype after a certain number of kills as well?

[expwnent]

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.

[Roses]

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 ]

[Max™]

I'm used to things like tiletypes and liquids does with range 8 2 1 so I kinda like the second one myself.

[Askot Bokbondeler]

ptw

[expwnent]

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.

[Dirst]

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.

[expwnent]

Roses: I've been integrating the script library into DFHack. What's the difference between the hack/scripts directory and the raw/scripts directory?

[Rumrusher]

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.

[Roses]

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.

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

[expwnent]

That all sounds good. Let me know when you're done.

[Roses]

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?

[expwnent]

I don't think so. The changes should be here.

[Dirst]

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.