Print

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

[Roses]

Yeah, I know how to save values between saving and loading, the question is how to make sure the building itself will run the reaction. I think I have an idea, but not sure yet if it will work, I will have to test it out.

EDIT: Yeah, I think my idea should work, at least I don't see a reason why it wouldn't. Hopefully on my day off tomorrow I will have a chance to test it.

[Meph]

Good luck.

[IndigoFenix]

Why do you need a counter at all?  It would be much simpler to just periodically (once every few frames or whatever) check the season.  If the season is different, change all the seasonal workshops to their appropriate version.

[expwnent]

Or you could do it "properly" with eventful and have a timer so you don't have to check every few frames. Add another script that runs on load to restart the timers at the correct values and you're all set.

[Roses]

Why do you need a counter at all?  It would be much simpler to just periodically (once every few frames or whatever) check the season.  If the season is different, change all the seasonal workshops to their appropriate version.

Yes, that is what I would call the "brute force" method. It would work, but I am hoping for something a little more elegant.

Or you could do it "properly" with eventful and have a timer so you don't have to check every few frames. Add another script that runs on load to restart the timers at the correct values and you're all set.

This is how I wanted to do it, but I didn't see anything in eventful with relation to time (whether it be changing of the season, the day, the month, etc...).

[Putnam]

Why do you need a counter at all?  It would be much simpler to just periodically (once every few frames or whatever) check the season.  If the season is different, change all the seasonal workshops to their appropriate version.

Yes, that is what I would call the "brute force" method. It would work, but I am hoping for something a little more elegant.

Or you could do it "properly" with eventful and have a timer so you don't have to check every few frames. Add another script that runs on load to restart the timers at the correct values and you're all set.

This is how I wanted to do it, but I didn't see anything in eventful with relation to time (whether it be changing of the season, the day, the month, etc...).

You could probably just use dfhack.timeout set to (however many ticks until season change).

[Roses]

Why do you need a counter at all?  It would be much simpler to just periodically (once every few frames or whatever) check the season.  If the season is different, change all the seasonal workshops to their appropriate version.

Yes, that is what I would call the "brute force" method. It would work, but I am hoping for something a little more elegant.

Or you could do it "properly" with eventful and have a timer so you don't have to check every few frames. Add another script that runs on load to restart the timers at the correct values and you're all set.

This is how I wanted to do it, but I didn't see anything in eventful with relation to time (whether it be changing of the season, the day, the month, etc...).

You could probably just use dfhack.timeout set to (however many ticks until season change).

That was my original idea, but then I thought about how to handle saving/loading and I wasn't sure how to make that work.

[Putnam]

Make a new timeout on load that will go off at the next season switch; season switches should be at the same ticks every year and the current year tick can be checked easily.

[expwnent]

It's possible we specifically didn't include the time delay "event" from EventManager in eventful because there is another way of doing that in lua with dfhack.timeout(30, 'ticks', function) (I forget the syntax but it's something like that). To make sure that they survive reload, put a few appropriate lines in onLoad.lua (again, I forget if that's what it's called, but I think that's it).

[Meph]

Hey, I figured another use of the building upgrade script. It can enhance Rendermax.

By making "small fire, large fire" you could alter the lumen, how bright it is. You can also change color, for example the "Gem of Light" could turn a random color when you touch it, or you can make a reaction "burn specific plant/dye", which gives light of the color of the material.

If you add that timer, you can even make temporary light sources. And if you are really, really good with the timings, you can do laser/light shows.

[Roses]

Hey, I figured another use of the building upgrade script. It can enhance Rendermax.

By making "small fire, large fire" you could alter the lumen, how bright it is. You can also change color, for example the "Gem of Light" could turn a random color when you touch it, or you can make a reaction "burn specific plant/dye", which gives light of the color of the material.

If you add that timer, you can even make temporary light sources. And if you are really, really good with the timings, you can do laser/light shows.

Well you can already add a duration to the building change, so you could run a reaction, "light small fire", and have it change the "pyre" building to "small fire" building for 3600 (or whatever) ticks and then it will change back. The only thing it doesn't do now is give the reagents back after it changes back.

So I have trugged through a bit on my todo list and figured I would throw up an update.

First off I have to say sorry, I switched the names of some of the scripts in order to better illustrate which you need to load with the df.init, and which you can use from the command line (and therefore autosyndrome and syndrometrigger). You can see all the changes below

Code: [Select]

-Name Changes
--upgradeitem -> base_upgradeitem
--upgradebuilding -> base_upgradebuilding
--teleportbase -> base_teleport
--countersbase -> base_counters

-New Scripts
--base_copyitem - Allows for copying of one or more items using reactions
--base_improveitem - Allows for changing quality of one or more items using reactions
--base_imbueitem - Allows for changing of materials of one or more items using reactions
--improveitem - Allows for changing quality of one or more items using interactions
--upgradeitem - Allows for upgrading one or more items using interactions

-Script Changes
--base_upgradeitem - Now also accepts a duration for the upgrade
--base_upgradebuilding - Now also accepts a duration for the upgrade <==

[Meph]

Ah, I thought you were still working on that, but that was about the time (seasons/days), not the time in ticks.

[Roses]

Yep, self upgrading buildings are still a little ways away, but you can already have timed upgrades manually.

EDIT: With the new r5 up I will be running through my various scripts and making sure nothing is broken. From what I looked at in the change logs and in df-structures I don't foresee anything being a problem, but there might be a couple variables that have been renamed that need to be fixed. (If anyone else wants to help check too and post error logs if they don't work I would be much appreciative)

[Meph]

Ok, I finally updated to V1.1, because I wanted to try out that building upgrade with ticks. I am on dfhack r4. I have the syntax correct, it worker with  V.1.0 (obviously not with the ticks/time syn_class, because you added that later), but after the update, everything broke. I get this error message:

Code: [Select]

        [C]: in function '__index'
        ....09\Dwarf Fortress\hack\scripts/base_upgradebuilding.lua:110: in function '?'
        ...rkDF V.5.09\Dwarf Fortress\hack\lua\plugins\eventful.lua:49: in function <...rkDF V.5.09\Dwarf Fortress\hack\lua\plugins\eventful.lua:47>
....09\Dwarf Fortress\hack\scripts/base_upgradebuilding.lua:110: Cannot read field vector<reaction_reagent*>.1: index out of bounds.
stack traceback:
        [C]: in function '__index'
        ....09\Dwarf Fortress\hack\scripts/base_upgradebuilding.lua:110: in function '?'
        ...rkDF V.5.09\Dwarf Fortress\hack\lua\plugins\eventful.lua:49: in function <...rkDF V.5.09\Dwarf Fortress\hack\lua\plugins\eventful.lua:47>
....09\Dwarf Fortress\hack\scripts/base_upgradebuilding.lua:110: Cannot read field vector<reaction_reagent*>.1: index out of bounds.stack traceback:
        [C]: in function '__index'
        ....09\Dwarf Fortress\hack\scripts/base_upgradebuilding.lua:110: in function '?'
        ...rkDF V.5.09\Dwarf Fortress\hack\lua\plugins\eventful.lua:49: in function <...rkDF V.5.09\Dwarf Fortress\hack\lua\plugins\eventful.lua:47>
[DFHack]#
The raws are fine. Reaction, Inorganic, Building IDs, all works with the previous version of "upgradebuilding.lua", before you renamed it to "base_upgradebuilding.lua".

Any idea what might cause this?

[Roses]

Yep, just a stupid error on my part. Line 110 was a print statement I added to make sure it all works, but it will give that error on occasion (for instance if you have only one PRESERVE_REAGENT as well as a couple other cases). Just delete the printall() line and it should work fine. I'll make sure to change the actual script.