Print

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

[expwnent]

I think the problem is that run_script might not look for script in quite as many places as it's supposed to. You're allowed to have per-save scripts folders. I might have messed that up slightly. run_command circumvents internal Lua stuff so it shouldn't be a problem there.

[Putnam]

run_script runs save scripts AFAIK. I haven't had a problem with it.

Then again, I haven't tested it too rigorously.

[IndigoFenix]

Is there any simple way of getting the products of a reaction that is linked to a LUA_HOOK function?  The example function includes output_items as a parameter, but as far as I can tell it is always empty

reaction.products

Not that, that's the data from the reaction's object.  I want the actual items produced from the reaction.

I'm trying to make a function that runs after a particular reaction that produces a tool.  I want the function to run some script and then set the 'maker' field of the tool to a certain number based on that script.  How would I go about doing that?

Ah, I see what you mean. I misunderstood. As far as I know output_items should be what you want. If it isn't then I am of no help.

Well, if I use print(output_items) it prints out <vector<item*>: number>, but I can't figure out how to read or write to it.  output_items[0] is out of bounds, printall(output_items) does nothing, even though the reaction is clearly producing something.

[Gorobay]

You might also have to change the value of save_file_id. Also I'm not sure if its going to freak out over having duplicate events and such.

Looks like it still freaks out: setting the save_file_id to 1 + the maximum of all other save_file_ids didn’t fix it. Maybe I can work around this using dfhack.persistent.

[Roses]

You might also have to change the value of save_file_id. Also I'm not sure if its going to freak out over having duplicate events and such.

Looks like it still freaks out: setting the save_file_id to 1 + the maximum of all other save_file_ids didn’t fix it. Maybe I can work around this using dfhack.persistent.

Yeah I am not sure about adding an entity. But what are you trying to do? There may be other ways to handle it.

EDIT: switching run_script to run_command fixed the issue

[PeridexisErrant]

I think the request was some way to automatically hoover up on-load scripts that come with mods, so the player doesn't need to stitch them together manually.  This might simplify mod merging.

I'm picturing this as a standard bit in DFHack's onload script that runs every file in the raw/scripts folder that matches a specific filename pattern, maybe onload_*.lua|onload_*.rb.  It should be deterministically before or after the onload.init script at the root of raw.  Or put it in the raw/onload.init file, but I think the feature would be more user-proof if it functioned with the main file missing.

I'll add it to the list.

Is the goal to make it easier for homebrewed combinations of mods?

A starter pack's mod manager could in principle merge the scripts together, so yes this would be aimed at players throwing random and/or homebrewed mods together.  But it would also make the mod manager's job easier.

Regardless, I'll need to add some special-casing to the mod merger, since it currently skips anything not ending in '.txt'. 

The easiest way will simply be to test for file ending '.init', '.lua', or '.rb' and spoof an empty file as the vanilla text; and the usual merge logic can then combine the files.  Multiple files will be combined, per the usual merge logic, with no change if they're identical.

[Gorobay]

Yeah I am not sure about adding an entity. But what are you trying to do? There may be other ways to handle it.

I am trying to add proper linguistics to the game. I was representing languages as entities, so that historical figures could have links to languages they knew, and civilizations could have links to their default languages. It worked perfectly, except for the crashing. Anything that allows such links would work; I think I might try sites next.

[Spacebat]

No, they're memory offsets. You might want to try +0x400000 (on Windows) if cheat engine is using file offsets.

IIRC the offsets in symbols.xml might be for binary file so they could be offset by 0x400000. In cheat engine that might look like "Dwarf Fortress.exe" + offset-0x400000

Thanks, but neither of these worked.

[Boltgun]

I think the request was some way to automatically hoover up on-load scripts that come with mods, so the player doesn't need to stitch them together manually.  This might simplify mod merging.

I'm picturing this as a standard bit in DFHack's onload script that runs every file in the raw/scripts folder that matches a specific filename pattern, maybe onload_*.lua|onload_*.rb.  It should be deterministically before or after the onload.init script at the root of raw.  Or put it in the raw/onload.init file, but I think the feature would be more user-proof if it functioned with the main file missing.

I'll add it to the list.

Is the goal to make it easier for homebrewed combinations of mods?

A starter pack's mod manager could in principle merge the scripts together, so yes this would be aimed at players throwing random and/or homebrewed mods together.  But it would also make the mod manager's job easier.

Regardless, I'll need to add some special-casing to the mod merger, since it currently skips anything not ending in '.txt'. 

The easiest way will simply be to test for file ending '.init', '.lua', or '.rb' and spoof an empty file as the vanilla text; and the usual merge logic can then combine the files.  Multiple files will be combined, per the usual merge logic, with no change if they're identical.

I might be reading that wrong, but isn't that already done with an init.d subfolder loading all lua files there on save load?

It is worth extending that to rb and init files  so you can add reaction triggers easily.

[expwnent]

I might be reading that wrong, but isn't that already done with an init.d subfolder loading all lua files there on save load?

It is worth extending that to rb and init files  so you can add reaction triggers easily.

Right now that only works for Lua and Ruby scripts, not for dfhack commands like dfhack.init.

[Dirst]

I might be reading that wrong, but isn't that already done with an init.d subfolder loading all lua files there on save load?

It is worth extending that to rb and init files  so you can add reaction triggers easily.

Right now that only works for Lua and Ruby scripts, not for dfhack commands like dfhack.init.

Good point, what I originally proposed was Lua/Ruby scripts, but what I really meant was init files with DFHack commands.  Each mod can have its own init file that registers reactions, etc.  Since an init file can call scripts easily, it's probably best to process only init files automatically.

[Putnam]

No, there are good reasons to have an init.d/*.lua or init.lua file. The onUnload() function is necessary for me to avoid a crash upon starting a second new game in Fortbent, for example.

[Dirst]

No, there are good reasons to have an init.d/*.lua or init.lua file. The onUnload() function is necessary for me to avoid a crash upon starting a second new game in Fortbent, for example.

Sheesh I'm unclear today.  No good would come from removing the existing feature to auto-run Lua.  I was trying to clarify that a way to auto-run .init files would be helpful if mods could seamlessly add to the onload queue without physically merging the onload.init file at the root of raw.  So kind of what I said above, except that it runs each ./scripts/*.init either just before or just after the ./onload.init file.

[Centigrade]

I used reveal, saved while reveal was on, loaded the save, and now cannot unreveal. Is this intended, or is there a workaround?

[cdombroski]

I used reveal, saved while reveal was on, loaded the save, and now cannot unreveal. Is this intended, or is there a workaround?

I don't remember if it's a known bug/feature, but the workaround is to use revflood.