Did you try \LOCAL ?
Edit: no, that won't work. However, I have been using \\LOCAL in the console (with modtools/create-unit) for other tests in 0.43.05-beta1, and it has been working consistently. Perhaps you have an older version of the script still. Try replacing your hack/scripts/modtools/create-unit.lua with the original from 0.43.05-beta1, and get rid of the file you have in raw/scripts (e.g. move it somewhere outside of your DF folder if you don't want to delete it). Scripts in raw/scripts always take priority, so a broken script there will override a working script in hack/scripts.
Edit 2: oh, and you should probably be using modtools/create-unit.
Okay Lethosar I returned to this issue for a few reasons...
1. I want it to work most efficiently for everyone.
2. I had another issue pop up, and went hunting for the fix, decided while I was at it that I should try and make it right.
3. Armed with a good night of sleep, more information on lua and dfhack, I've discovered the problem that neither of us was looking at.
You stated it worked when you entered it in the console with a \\LOCAL like this line...
modtools/create-unit -race GOLEM_ORICHALCUM -caste GOLEM -civId \\LOCAL -groupId \\LOCAL -name MOUNTAIN -age 1
the number of times that a backslash is removed from an argument is what we weren't looking at. I'm using this line:
modtools/reaction-trigger -reactionName ORICHALCUM_GOLEM -command [ modtools/create-unit -race GOLEM_ORICHALCUM -caste GOLEM -civId \\LOCAL -groupId \\LOCAL -location [ \\LOCATION ] -name MOUNTAIN -age 1 ]
and all the backslashes are gone long before it gets operated on in create-unit.lua....
first its one time processed when its picked up and placed in the reaction trigger tables, because when reaction-trigger tables expand it to check for \\LOCATION etc, \\LOCAL has already become \LOCAL... so after its processed there in processCommand, it's cut to LOCAL. so it already is dead, no matter what happens after.
If I turned it into [ \\LOCAL ] around it, again its already [ \LOCAL ] by the time it is being sent to processCommand. at which point it becomes [ LOCAL ], then a run to utils.processArgs from create-unit.lua it becomes a table array, which is another dead end.
so i turned them into \\\LOCAL... well its \\LOCAL when its run through processCommand, its cut to \LOCAL, then the run to utils.processArgs from create-unit.lua, its cut to LOCAL....so its dead. the final answer is \\\\LOCAL I couldn't get anything else to work, and I have no clue why it didn't work before, but I bet its my fault. really there is too many places where \ are removed. once when the argument is first made from the onLoad.init, second time when its processed by reaction-trigger, and the third time when its processed by create-unit.lua.
basically if you want any series of backslashes that works in the console to work from onLoad.init involving a trigger... you need \\\\ 4 of them. It wouldn't need that many if it didn't go through utils.processArgs 2 times and reaction-trigger.processCommand once.
Now then the reason I actually went back and tackled this... I found an error in teleport.lua:function teleport(unit,pos)
local unitoccupancy = dfhack.maps.getTileBlock(unit.pos).occupancy[unit.pos.x%16][unit.pos.y%16]
local newoccupancy = dfhack.maps.getTileBlock(pos).occupancy[pos.x%16][pos.y%16]
if newoccupancy.unit then
unit.flags1.on_ground=true
end
unit.pos.x = pos.x
unit.pos.y = pos.y
unit.pos.z = pos.z
if not unit.flags1.on_ground then unitoccupancy.unit = false else unitoccupancy.unit_grounded = false end
end
If the unit is created through create-unit.lua, there is an issue where it can fail to teleport the unit afterwards because of the line 18 indexed a nil....
I wrote this fix, but it causes Crash-To-Desktop.... around 50% of the time...
function teleport(unit,pos)
if dfhack.maps.getTileBlock(unit.pos) then
local unitoccupancy = dfhack.maps.getTileBlock(unit.pos).occupancy[unit.pos.x%16][unit.pos.y%16]
local newoccupancy = dfhack.maps.getTileBlock(pos).occupancy[pos.x%16][pos.y%16]
if newoccupancy.unit then
unit.flags1.on_ground=true
end
unit.pos.x = pos.x
unit.pos.y = pos.y
unit.pos.z = pos.z
if not unit.flags1.on_ground then unitoccupancy.unit = false else unitoccupancy.unit_grounded = false end
else --dfhack.maps.getTileBlock(unit.pos) has failed. they probably came from create-unit.
print("was unable to getTileBlock for Teleport. Using an alternative method")
local newoccupancy = dfhack.maps.getTileBlock(pos).occupancy[pos.x%16][pos.y%16]
if newoccupancy.unit then
unit.flags1.on_ground=true
end
unit.pos.x = pos.x
unit.pos.y = pos.y
unit.pos.z = pos.z
--we wont need to set previous occupancy, because the unit literally existed outside of time and space, and we do not have access to it.
end
end
I'm not sure what I did wrong... BUT... it moves the unit when the dfhack can't getTileBlock. The reason it can't getTileBlock? the only thing I can think of is that the created unit had appeared beneath hell, 2 floors beneath an eerie pit, at exactly 0,0,0. It had no map tile beneath it? I'm not sure. but since this was the first test world that acted up, out of about 20.... its a rare issue to occur, and the fix will