Print

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

[expwnent]

That's a bug, thanks.

Hm. Eventful does reaction triggers slightly differently. The problem is that I carefully wrote EventManager to detect JOB_COMPLETED events even when no products are produced and no skills are improved. Eventful uses a fancy schmancy way of "catching" a call that DF itself makes (only sometimes possible, sadly), but I'm 90% sure it doesn't get called unless there's some product produced. It's possible to take events from both sources and prevent double-triggering, but it's messy. I'll look into it. The alternate way is to keep track of job items of every job as they change but that's messy and terrible and doesn't easily grab the new items.

onLoad.init goes directly in the df/raw/ folder.

[Roses]

Not only does it not get triggered if there are no products, it actually gets triggered for each product, which has some unfortunate side effects. Well if you can figure out a way to do it, that would be great, otherwise I will think of another solution.

[Roses]

Question on script structure and organization:

At this point in my script development I can choose to keep all of my scripts in the hack/script folder and use dfhack.run_script() to run necessary components (like for the wrapper script which I separated out), or I can move some of the scripts into the hack/lua folder and use them as require(). Both methods allow for argument return, so the only real reason to choose one over the other is preference (or if there is some speed factor I am unaware of). What are your thoughts on the matter?

To be clear I am talking about something like

Code: [Select]

isSelected = require('wrapper\\isSelected')
  local selected,targetList,unitSelf,verbose,announcement = isSelected(unit1,unit2,unit3,args,count)vs

Code: [Select]

local selected,targetList,unitSelf,verbose,announcement = dfhack.run_script('isSelected',table.unpack({unit1,unit2,unit3,args,count}))
Also, do you feel scripters should be making their own folders inside the hack/scripts and hack/lua folders in order to avoid possible overwrite? Or should we keep them all in a singular folder for ease of use? (Right now my scripts are just all over the place since I have been just testing them and writing new ones, but its about time for me to regroup and get ready to release the updated versions)

[Warmist]

Require is for modules. That is if you have a script system that has libraries containing many scripts, require is used because it caches. If you do "a=require("lib")" and then "b=require("lib")" it will only run code once.
Imho scripts should be split like this:

• anything that has one use goes to "hack/scripts" - this is what player will use through keybindings and so on. Though recently all the scripts-as-commands brake this...
• anything that can be reused goes into "hack/lua" - this way you will not be reinventing the wheel when you see that e.g. item module already has that function you are trying to add

I'm also trying to advertise third option: mods folder. That way mod specific stuff will be in it's own folder only, also player doesn't need to think about copying anything, there is low chance of overwrite and stuff that is common to many mods can be moved to libraries.
That said: best way to prevent overwrite- use official repository. If it's not there there is a chance that somebody will overwrite stuff. Also bonus for somebody improving your own scripts.
Although i'm not a fan of this idea, you could add hack/scripts/roses folder and put everything there.
Lastly expwnent has been doing reorganization and added folder "hack/scripts/modtools" for scripts that mods call from various reactions and so on.

Personally i'm putting everything into hack/scripts when developing (and e.g. requiring("hack.scripts.jobs")) and then moving either to mod folder or hack/lua.
Oh and last-last thing:

Code: [Select]

isSelected = require('wrapper\\isSelected')
  local selected,targetList,unitSelf,verbose,announcement = isSelected(unit1,unit2,unit3,args,count)

Usually require uses "." as separator. I.e. isSelected = require('wrapper.isSelected')

[expwnent]

What Warmist said basically.

Also in the next release you can have a raw/scripts folder that will be checked before dfhack/lua/scripts.

[Roses]

Sounds good.

EDIT: Should scripts that just need to be initialized once be put in onLoad.init or kept in dfhack.init?

[expwnent]

Almost everything should go in onLoad.init. A goal for the future is to make it so that you can exchange savegames even if those savegames have mods that rely on scripts you don't have. Therefore only the stuff that you want regardless of what mod is in effect should go in dfhack.init. Anything remotely mod-specific should go in onLoad.init.

[Quietust]

It looks like the next version of Dwarf Fortress will support using [PRODUCT:100:1:GET_ITEM_INFO:reagent:NONE] to duplicate an item in a reaction, so the above mentioned "copy item" Lua hook will no longer be necessary. Granted, it won't be able to handle "complicated" item types (like corpses), but for simple stuff like equipment and furniture it should work quite nicely.

[WillowLuman]

Gotta keep on eye on this. Can't wait for stability