Print

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

[notfood]

Where can I download the event stuff to test it? I don't see it in github. I must be blind.

[Roses]

I'm not sure if I am understanding correctly, basically what you are talking about is moving the modules from hack/lua to scripts in hack/scripts, while still performing the same functionality correct? For me it wouldn't really matter since the only scripts I have in the hack/lua are not meant for command line calling, and are just used as checks for various things. Although it would allow for consolidation and mergeability as Putnam mentioned.

@notfood, you are not blind, the event stuff has a couple errors that I am still working on. Hopefully it will be uploaded this week.

[expwnent]

Basically, yes, and also it would make it so that for things like repeat or add-syndrome the Lua file that deals with console commands would be the same as the script that exposes functionality to other Lua scripts.

[expwnent]

Multiline commands will be supported for dfhack.init in the next DFHack release.

https://github.com/DFHack/dfhack/blob/4c5b6a528240482b13e1c334995a5fd51a026fdb/dfhack.init-example#L199-214

https://github.com/DFHack/dfhack/blob/4c5b6a528240482b13e1c334995a5fd51a026fdb/Readme.rst#commands

[expwnent]

You may also want to replace the findScript() function in dfhack.lua with the one here. It should correct the issue with run_command vs run_script.

[Roses]

Multiline commands will be supported for dfhack.init in the next DFHack release.

https://github.com/DFHack/dfhack/blob/4c5b6a528240482b13e1c334995a5fd51a026fdb/dfhack.init-example#L199-214

https://github.com/DFHack/dfhack/blob/4c5b6a528240482b13e1c334995a5fd51a026fdb/Readme.rst#commands

Nice, this will make things so much cleaner!

You may also want to replace the findScript() function in dfhack.lua with the one here. It should correct the issue with run_command vs run_script.

Does that mean I can switch run_command back to run_script? And what is the issue with keeping it run_command?

Basically, yes, and also it would make it so that for things like repeat or add-syndrome the Lua file that deals with console commands would be the same as the script that exposes functionality to other Lua scripts.

That does sound like it would be useful.

As for an update. I was all set to get the Event System and updates scripts pumped out this week, but then I got the flu and strepthroat at the same time. Haven't done much but sleep the last couple days. That being said, I *think* the Event System is now ready for public tests, and I am half way through updating my old scripts to use my new persistent delay system. (Also building-trigger and a few other new scripts)

After that I really want to get some lengthy examples out for the Class System, Civilization System, Event System, and Spell Book that are based off of my own mod. And then finally move on to the Journal System that I have mentioned on the first post. I am not going to say any time line, but I would like to get my to-do list whittled down before some new crazy idea pops into my head.

[expwnent]

run_command should still work. run_script was looking for scripts in the wrong places.

[Putnam]

EDIT: Figured out that "j" in the classes thing is actually line number (NAME YOUR FRIGGIN VARIABLES) and isolated the problem; it was a missing level.

EDIT 2: Your errors aren't very helpful without line numbers, either... so I made it more like this:

Code: [Select]

print('Incorrect amount of physical bonus numbers on line '..j..', must be equal to number of levels + 1. Assuming previous physical bonus')
EDIT 3: Oh yes, and one more thing. I made my class file ridiculously larger now, 3402 lines. This gives me loading times on the order of a minute. Could base/classes somehow check if it's already been loaded on this world?

EDIT 4: This seems to work:

Code: [Select]

function classesAreNotAlreadyLoaded()
    return (not persistTable.GlobalTable.roses.ClassTable) or #persistTable.GlobalTable.roses.ClassTable._children<1
end

local dir = dfhack.getDFPath().."/raw/objects/"
for _,fname in pairs(dfhack.internal.getDir(dir)) do
 if split(fname,'_')[1] == 'classes' or fname == 'classes.txt' and classesAreNotAlreadyLoaded() then
  read_file(dir..fname)
 end
end
In base/classes.

EDIT 6: It's looking for [SPELL_AUTO_LEARN when what it actually gets is [SPELL_AUTO_LEARN], which has the effect of making [SPELL_AUTO_LEARN] not work at all unless fixed (which is as simple as adding a right bracket to the check in read-file)

[Meph]

Hey Roses, doing some testing. I have the newest dfhack and the newest collection of your scripts. I'm trying to improve the quality of an item used in a reaction.

I put this into onload.init:

Code: [Select]

modtools/reaction-trigger -reactionName LUA_HOOK_IMPROVE_ITEM_BREASTPLATE -command [ base_improveitem \\this upgrade-skill ]

The reaction is simple, just for testing:

Code: [Select]

[REACTION:LUA_HOOK_IMPROVE_ITEM_BREASTPLATE]
[NAME:Improve breastplate]
[BUILDING:STILL:CUSTOM_NONE]
[REAGENT:target:1:ARMOR:ITEM_ARMOR_BREASTPLATE:NONE:NONE:NONE][NOT_IMPROVED][PRESERVE_REAGENT]
And this is the errorlog that dfhack gives me:

Code: [Select]

Improvable Items: Loaded
... Reborn\Dwarf Fortress\hack\scripts/base_improveitem.lua:97: Cannot read field vector<syndrome*>.0: index out of bounds.
stack traceback:
        [C]: in function '__index'
        ... Reborn\Dwarf Fortress\hack\scripts/base_improveitem.lua:97: in function '?'
        ...work Reborn\Dwarf Fortress\hack\lua\plugins\eventful.lua:49: in function <...work Reborn\Dwarf Fortress\hack\lua\plugins\eventful.lua:47>
Improvable Items: Loaded
[DFHack]#

[Roses]

Thanks Putnam for testing all those things, changes have been made, and some optimization has been done that will be included in the new release.

@Meph, you are actually mixing two different systems there. The LUA_HOOK system doesn't need a reaction-trigger. And since reaction-trigger doesn't currently give you a reference to the items used or made in the reaction, you have to use the LUA_HOOK system. Which hasn't changed in the update. So you still need an inorganic and all the stuff referenced in the base/item-improve. When reaction-trigger can give the reagents and products I will switch those over to the new system.

[Meph]

*eye twitch

So LUA_HOOK with reaction and an inorganic and the command/arguments in it still works?

[Roses]

*eye twitch

So LUA_HOOK with reaction and an inorganic and the command/arguments in it still works?

It should LUA_HOOK hasn't been changed, its value has just been lessened. But until reaction-trigger gets item support LUA_HOOK is the only way to do what you want. Sorry.

[expwnent]

Soon! I'll do an r2 once I finish that and a few other things.

[Meph]

Haha, you guys... this is good news for me. Finally I can do stuff without having to look up that modtool syntax all the time.

[Boltgun]

*eye twitch

So LUA_HOOK with reaction and an inorganic and the command/arguments in it still works?

Upgrade item did not use autosyndrome's command, merely reading an inorganic for order. Tbh I think we can upgrade this script to work without using an inorganic now.