Print

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

[Amostubal]

the only issue that would remain with that instant reaction causing nil... is that if there is any 'effects' caused by that item that suddenly disappeared.  scriptors will have to watch out about making things that are used up in an instant(no-skill) reaction.  I use them because I don't want coinage with 'quality',lol.

[lethosor]

relation issue:  how to get lastattacker ID lol.... on-death.lua script from roses.... was going to contact them next on that one.  its under relationship_ids in the gm-editor.  but unit.relationship_id.lastAttacker, unit.relationship_ids.lastAttacker, and unit.lastAttacker all do not work.

unit.relationship_ids.LastAttacker. Case matters.

Edit: unit.relationship_ids[df.unit_relationship_type.LastAttacker] would also work, or, equivalently, unit.relationship_ids[4] (but you really shouldn't ever use the last one). unit.relationship_ids is really just an array, except with names for each index as well (corresponding to df.unit_relationship_type).

[Amostubal]

relation issue:  how to get lastattacker ID lol.... on-death.lua script from roses.... was going to contact them next on that one.  its under relationship_ids in the gm-editor.  but unit.relationship_id.lastAttacker, unit.relationship_ids.lastAttacker, and unit.lastAttacker all do not work.

unit.relationship_ids.LastAttacker. Case matters.

....... lol..... okay.. I should of kept plugging away... I'd of spotted it, eventually.... good thing too.... there's a opossum on this save that is probably tired of his groundhogs day...

and that good sirs gives me a no red console within 5 mins of game load.... first time in 4 months.  I'll post the line fix to roses page, mark it as a 43.05.  although I bet they already know, they just aren't moving their scripts to the dfhack 43.05 x64 architecture yet.

I owe you Lethosor, you can get an ale on me, if you visit my corner of the world.

[lethosor]

item-trigger? That's in the DFHack scripts repo, so I'm going to fix it there. I'm not sure if your/Roses' version is different, but the line numbers matched up with DFHack's, and DFHack's hasn't been changed in 9 months.

Ideally, scripts wouldn't require many changes to work under x64. There were a couple structure changes we had to make in 0.43.05, but those apply to x86 as well. Besides that, nearly all scripts don't need to be updated specifically to work with x64.

[Amostubal]

yeah I had item-trigger.lua from dfhack 43.05 beta 1.  the relations bug was in on-death.lua from roses base folder... there's a lot of relations usage in roses scripts.  I'll post the fix line for that file over there.  I don't think they are moved over to dfhack 43.05 architecture yet.  I'm sure someone out there is scratching their head over there.

So really other then those 2 fixes to item-trigger.lua the only other thing that I had for you, that you may want to fix, is the structures repository for units.xml it still mentions relations as the way to access the unit_relationship_type array. wish I had remembered gm-editor, I would of been done with that problem yesterday, so thanks to PatrickLundell, too!

I appreciate the work everyone does in this community... Its simply amazes me how much of people's free time are devoted to helping each other out here.

[Amostubal]

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...

Code: [Select]

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:

Code: [Select]

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:

Code: [Select]

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...

Code: [Select]

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

[Roses]

You could switch from getTileBlock to ensureTileBlock, not sure if that will fix the problem though.

[Amostubal]

You could switch from getTileBlock to ensureTileBlock, not sure if that will fix the problem though.

nah same problem.... I'm not sure what the rest of the script is for other than repairing occupancy of the 2 blocks that its transfering between.  The interesting thing, is that I have an operating save, where the above reaction is being tested.... basically load and the reaction completes a few seconds later.  every other attempt it crashes with the above script, a flat out wipe clean and gone crash, nothing left.... I hate those, nothing in the errorlog or the stderr

[Rose]

Is there any possibility of upgrading the protobuf version were using?

Protobuf 3 is backwards compatible, and supports compiling for more languages than just c++.

There's two ways we could go about it. One would be to compile the new version with DF, otherwise just keep the binaries for each platform we build for, and link against that.
Tge second one would be far easier, I think.

[lethosor]

I'd be fine with protobuf 3. I'm not sure if anything relies on protobuf 2.x that would break with 3.x. One thing to note, though, is that the reason we use libprotobuf-lite currently is because libprotobuf has some sort of global registry of protobufs (according to angavrilov/ag) that would cause crashes when reloading plugins that use them. I'm not sure how the situation would change with protobuf 3, but I'd be fine with trying it out.

I'd rather avoid distributing protobuf 2 binaries if we're moving to protobuf 3, though.

[ragundo]

I use all the time protobuf3 with dfhack. They are binary compatible.

You just need to add the syntax attribute to your .proto file and ready.

Here is df::coord in proto3


syntax = "proto2";
option optimize_for = LITE_RUNTIME;

message DF_coord
{
   required int32 x = 1;
   required int32 y = 2;
   required int32 z = 3;
}


Switching to proto3 would be all advantages:

• Go, JavaNano, Ruby, and C# bindings added to proto2 C++, Java and Python
  
• CMake support
  
• Google support, etc
  

[Warmist]

• Google support, etc
  

heh

[lethosor]

Yeah, the version we're using is pretty ancient. We did add in CMake support, though, so that wouldn't be new in protobuf 3.

Is it difficult to move existing .proto files over to protobuf 3? There really aren't that many (well, except for ragundo's "export everything" plugin).

I'd really rather distribute protobuf 3 libraries in case anyone does want to use protobuf 3 features, although it's good to know that they're binary-compatible. Is there an advantage to not compiling protobuf 3 along with DFHack, like we currently do with protobuf 2?

[ragundo]

There are only 6 proto files in DFHack

• Basic.proto
• BasiApi.proto
• CoreProtocol.proto
• isoworldremote.proto
• Japa's RemoteFortressReader.proto
• rename.proto

The changes needed are adding the line
syntax = "proto2";
to each file.

In my Linux box I need to compile the plugin proto files using DFHack's protoc because if not, the files are not compatible with system protocol buffers 3 protoc compiler.
Also, you need to link with DFHack's protobuf library instead of the system one for plugins, not client code.

Anyway, my export df structures plugin is not intendend to be included in DFHack's source code at all!!!. I'll distribute it in binary form (but source code available), because it takes more time to compile than the whole DFHack  .

[lethosor]

The changes needed are adding the line
syntax = "proto2";
to each file.

I meant to ask what would be required without using that line (i.e. are there changes to the protobuf syntax that would require changing the body of those files?).