Print

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

[Roses]

Sorry, I have been away for a while recovering from some rl and work stuff. I will be uploading all of my fixed scripts tomorrow along with basic read me documentation To help use them.

[Roses]

Ok, so I have uploaded the updates for all the scripts as well as a working version of the Event and Civilization Systems. There were unfortunately some changes to core things so I just want to mention them explicitly.

• To use the various systems in your game you should replace all calls to base/classes, base/civilizations, and base/events to your onLoad.init file and replace them with base/roses-init -classSystem -civilizationSystem -eventSystem, or simply base/roses-init -all. It is suggested to use the -all command since it will load all necessary scripts and plugins. Note that if you do not have a file in the raw/objects folder for the various systems they will automatically be ignored.
• Various scripts have been renamed they are (note these are just name changes, and all scripts should work just as they have before)
  • item/improve.lua -> item/quality-change.lua
  • item/upgrade.lua -> item/subtype-change.lua
  • item/imbue.lua -> item/material-change.lua
  • special/projectile.lua and special/falling.lua -> item/projectile.lua
  • special/propel.lua -> unit/propel.lua
  • special/spawnflow.lua -> flow/spawnflow.lua
  • special/customweather.lua -> flow/customweather.lua
  • special/eruption.lua -> flow/eruption.lua
  • tile/change.lua -> tile/material-change.lua and tile/temperature-change.lua
  • unit/value-change.lua -> unit/counter-change.lua
• Old LUA_HOOK based scripts have been removed, old scripts should still work

In addition to just updates, there were some new scripts written

• modtools/building-trigger.lua - this allows for some interesting choices in restricting buildings being built
• building/remove.lua - documentation in ReadMe - Scripts
• building/subtype-change.lua - documentation in ReadMe - Scripts
• base/persist-delay.lua - used in all of my scripts in order to have persistent calls between save/load (load with base/roses-init -persistentDelay)
• base/global-tracking.lua - used in the three systems to track information (load with base/roses -globalTracking)

There are also a set of ReadMe's included which provide information on all scripts and systems.

How do I use teleport? I can't seem to figure out the format. Can it even be used from the DFhack console?

teleport can be used from the command line or with any of the *-trigger scripts. See the help section for the exact command

Code: [Select]

special/teleport.lua
  Teleport items and units to a given location
  arguments:
   -help
     print this help message
   -unit id
     REQUIRED
     id of the unit to center on
   -direction TYPE
     REQUIRED
     where to teleport to
     valid types:
      UNIT:\\UNIT_ID - teleports to the given units location
      IDLE - teleports to a random idle location
      ROOM - teleports to a random room
      BUILDING:WORKSHOP - teleports to a random workshop
      BUILDING:FURNACE - teleports to a random furnace
      BUILDING:\\BUILDING_NAME - teleports to a random specified building
   -type TYPE
     specify what to teleport
     valid types:
      unit - teleports units and their inventories
      item - teleports items lying on the ground
      both - teleports both
     DEFAULT both
   -radius #,#,#
     specify the radius in x,y,z that will be teleported
     DEFAULT 0,0,0
  examples:
   special/teleport -unit \\UNIT_ID -direction UNIT:\\ATTACKER_ID -type unit -radius 10,10,0
   special/teleport -unit \\UNIT_ID -direction BUILDING:BUILDING_TELEPORTER_2 -type unit -radius 2,2,2
 ]]

[expwnent]

How is performance of queries for the persist-table stuff? I've heard it's worse than it should be.

Discussion

It really should be quite fast. In the existing system all histfig stuff is just a binary search on the C++ side. I'm very surprised it's that slow and I'm not sure what the problem is.

With the new system, the Lua interface will be the same and old saves will be upgraded automatically to the new system, and accessing persistent data will be as fast as traversing a pointer (basically). There will still be an overhead of calling a C++ function from Lua but that can't be avoided.

[Putnam]

Ah--I mentioned that "I doubt anyone will ever get to as extreme a use case as me", and I really do mean that. I have 176 spells and 144 classes.

It's about 600 ms between each print in this function when a unit levels up:

Code: [Select]

function levelup(unit)
 local unitClasses = persistTable.GlobalTable.roses.UnitTable[tostring(unit)]['Classes']
 local currentClass = unitClasses['Current']
 local classes = persistTable.GlobalTable.roses.ClassTable
 local currentClassName = currentClass['Name']
 local currentClassLevel = tonumber(unitClasses[currentClassName]['Level'])+1
 unitClasses[currentClassName]['Level'] = tostring(currentClassLevel)
-- if classes[currentClassName]['BonusPhysical'] then
  for _,x in pairs(classes[currentClassName]['BonusPhysical']._children) do
   local i = classes[currentClassName]['BonusPhysical'][x]
   dfhack.run_script('unit/attribute-change',table.unpack({'-unit',tostring(unit),'-physical',x,'-fixed','\\'..tostring(tonumber(i[currentClassLevel+1])-tonumber(i[currentClassLevel]))}))
  end
-- end
-- if classes[currentClassName]['BonusMental'] then
  for _,x in pairs(classes[currentClassName]['BonusMental']._children) do
   local i = classes[currentClassName]['BonusMental'][x]
   dfhack.run_script('unit/attribute-change',table.unpack({'-unit',tostring(unit),'-mental',x,'-fixed','\\'..tostring(tonumber(i[currentClassLevel+1])-tonumber(i[currentClassLevel]))}))
  end
-- end
-- if classes[currentClassName]['BonusSkill'] then
  for _,x in pairs(classes[currentClassName]['BonusSkill']._children) do
   local i = classes[currentClassName]['BonusSkill'][x]
   dfhack.run_script('unit/skill-change',table.unpack({'-unit',tostring(unit),'-skill',x,'-fixed','\\'..tostring(tonumber(i[currentClassLevel+1])-tonumber(i[currentClassLevel]))}))
  end
-- end
-- if classes[currentClassName]['BonusTrait'] then
  for _,x in pairs(classes[currentClassName]['BonusTrait']._children) do
   local i = classes[currentClassName]['BonusTrait'][x]
   dfhack.run_script('unit/trait-change',table.unpack({'-unit',tostring(unit),'-trait',x,'-fixed','\\'..tostring(tonumber(i[currentClassLevel+1])-tonumber(i[currentClassLevel]))}))
  end
-- end
-- if classes[currentClassName]['Spells'] then
  for _,x in pairs(classes[currentClassName]['Spells']._children) do
   local i = classes[currentClassName]['Spells'][x]
   if tonumber(i['RequiredLevel']) <= currentClassLevel then
    if i['AutoLearn'] then dfhack.run_script('classes/learn-skill',table.unpack({'-unit',tostring(unit),'-spell',x})) end
   end
  end
-- end
 if currentClassLevel == tonumber(classes[currentClassName]['Levels']) then
  print('REACHED MAX LEVEL FOR CLASS '..currentClassName)
  if classes[currentClassName]['AutoUpgrade'] then dfhack.run_script('classes/change-class',table.unpack({'-unit',tostring(unit),'-class',classes[currentClassName]['AutoUpgrade']})) end
 end
end

[TheFlame52]

Thank you, it was very helpful. What I wanted to do was teleport a male jabberer away from a forgotten beast and into my cage traps, but instead the jabberer killed the FB and wandered into my traps anyway. He will be the father of generations of domestic jabberers.

[expwnent]

I only see one print statement at the end. That can be made faster by caching lookups a little more aggressively.

Code: [Select]

function levelup(unit)
 local unitClasses = persistTable.GlobalTable.roses.UnitTable[tostring(unit)]['Classes']
 local currentClass = unitClasses['Current']
 local classes = persistTable.GlobalTable.roses.ClassTable
 local currentClassName = currentClass['Name']
 local currentClassLevel = tonumber(unitClasses[currentClassName]['Level'])+1
 unitClasses[currentClassName]['Level'] = tostring(currentClassLevel)
 local temp = classes[currentClassName]['BonusPhysical']
-- if temp then
  for _,x in pairs(temp._children) do
   local i = temp[x]
   dfhack.run_script('unit/attribute-change',table.unpack({'-unit',tostring(unit),'-physical',x,'-fixed','\\'..tostring(tonumber(i[currentClassLevel+1])-tonumber(i[currentClassLevel]))}))
  end
-- end
 temp = classes[currentClassName]['BonusMental']
-- if temp then
  for _,x in pairs(temp._children) do
   local i = temp[x]
   dfhack.run_script('unit/attribute-change',table.unpack({'-unit',tostring(unit),'-mental',x,'-fixed','\\'..tostring(tonumber(i[currentClassLevel+1])-tonumber(i[currentClassLevel]))}))
  end
-- end
 temp = classes[currentClassName]['BonusSkill']
-- if temp then
  for _,x in pairs(temp._children) do
   local i = temp[x]
   dfhack.run_script('unit/skill-change',table.unpack({'-unit',tostring(unit),'-skill',x,'-fixed','\\'..tostring(tonumber(i[currentClassLevel+1])-tonumber(i[currentClassLevel]))}))
  end
-- end
 temp = classes[currentClassName]['BonusTrait']
-- if temp then
  for _,x in pairs(temp._children) do
   local i = temp[x]
   dfhack.run_script('unit/trait-change',table.unpack({'-unit',tostring(unit),'-trait',x,'-fixed','\\'..tostring(tonumber(i[currentClassLevel+1])-tonumber(i[currentClassLevel]))}))
  end
-- end
 temp = classes[currentClassName]['Spells']
-- if temp then
  for _,x in pairs(temp._children) do
   local i = temp[x]
   if tonumber(i['RequiredLevel']) <= currentClassLevel then
    if i['AutoLearn'] then dfhack.run_script('classes/learn-skill',table.unpack({'-unit',tostring(unit),'-spell',x})) end
   end
  end
-- end
 if currentClassLevel == tonumber(classes[currentClassName]['Levels']) then
  print('REACHED MAX LEVEL FOR CLASS '..currentClassName)
  if classes[currentClassName]['AutoUpgrade'] then dfhack.run_script('classes/change-class',table.unpack({'-unit',tostring(unit),'-class',classes[currentClassName]['AutoUpgrade']})) end
 end
end
It would also be worthwhile to cache classes[currentClassName] because you use it so often, but I didn't know what to call it because you already have currentClass as a variable and I only skimmed the code. Using "temp" as a variable is terrible of course but you get the idea. Every time you do persistentTableEntry.blah you have to do a binary search through all histfigs. It's reasonably cheap but not so cheap you can safely consider it to be free.

This won't make it faster but it will make it cleaner: you don't really need table.unpack. You can just use commas to separate arguments passed to dfhack.run_script. Just make sure that they're all strings. 99% of the time it won't be a problem but it's best to be safe.

[Putnam]

Most of the print statements are in the run_script calls, I think.

[expwnent]

The new "scripts as libraries" system should help with that too.

Code: [Select]

--old way
dfhack.run_script('unit/attribute-change',table.unpack({'-unit',tostring(unit),'-physical',x,'-fixed','\\'..tostring(tonumber(i[currentClassLevel+1])-tonumber(i[currentClassLevel]))}))

--new way
dfhack.script_environment('unit/attribute-change').changeAttribute(unit, x, tonumber(i[currentClassLevel+1])-tonumber(i[currentClassLevel]))

This does require changing unit/attribute-change.lua of course.

A recent unreleased change in DFHack should also improve performance. In old versions we had to load (and compile) each script every time it's run (every call to dfhack.run_script). Now scripts are only reloaded when it's necessary. I haven't timed the performance but it should be better.

[Roses]

Sounds like I should change all the run_script commands to script_environment commands. That's going to involve a fair amount of changes to make sure none of the command line functions change, but that they can be used as script functions directly (or maybe it won't be that bad, most of my scripts already use functions imbedded in them).

@expwnent, I've been away for awhile and am not sure if you ever got the reaction product thing to work. Is that something that is available now?

@Putnam, you undoubtably have more experience with lag and such attributed to the class system, have you upgraded to my newest scripts, and if so, have you noticed an increase in loading speed of the class system?

[Putnam]

I haven't upgraded yet, and I modified your code enough before that I won't be sure about whether there was an actual improvement (though the modification related to that was simply a check to see whether it's been initialized on that world yet).

[expwnent]

I believe that modtools/reaction-product-trigger will give you what you want.

Script environments should also simplify wrapper.lua based on my (old) memories of how it works.

[expwnent]

Roses: consider using histfig id instead of unit id.

Disadvantage: can't store data on non-histfigs (note that almost everybody you deal with in-game is historical)

Advantage: invaders that leave and come back keep the same stored data

[Roses]

I haven't upgraded yet, and I modified your code enough before that I won't be sure about whether there was an actual improvement (though the modification related to that was simply a check to see whether it's been initialized on that world yet).

Well truthfully, the only thing I changed for the class system was the read-file script. So if you didn't make any changes to that I would try using the new file. It was consistently around 4-5x faster for me.

I believe that modtools/reaction-product-trigger will give you what you want.

Script environments should also simplify wrapper.lua based on my (old) memories of how it works.

Looks good, was just checking it out in the dfhack develop branch, a couple questions. Am I correct in thinking that \\INPUT_ITEMS and \\OUTPUT_ITEMS returns a table of item ids? Does only input items with PRESERVE_REAGENT get included in the input items list, or do all items? Does it only trigger if an item is created?

Roses: consider using histfig id instead of unit id.

Disadvantage: can't store data on non-histfigs (note that almost everybody you deal with in-game is historical)

Advantage: invaders that leave and come back keep the same stored data

Units that leave and come back don't keep the same unit id? Interesting, I figured that was just a constant for the whole game. I should definitely switch to histfig id, at least for the class system.

[expwnent]

\\INPUT_ITEMS is the list of ALL input items, even ones that will be consumed (I think). OUTPUT_ITEMS is a list of item ids, yes. It will only trigger if an item is created, and if multiple products are created at the same time it will trigger more than once.

[Roses]

Good to know, thank you!