Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  

Author Topic: dfhack lua script question re: userdata  (Read 1444 times)

sdp0et

  • Bay Watcher
    • View Profile
dfhack lua script question re: userdata
« on: October 10, 2014, 12:03:14 am »

I'm trying to do two things at once: learn lua and figure out how the dfhack model is structured.

I wrote a quick, ugly script that prints out the pairs of a 'unit'.  when the value is a vector, it expands it and when the value is of type userdata, it indents and recurses.

it chugs along for a while, then dies on one.

the line of death is
for n,g in pairs(t) do  //table/userdata

with error Qbad argument #1 to 'pairs' (table expected, got userdata)

to debug, prior to this line I generate this output
dumping userdata     //print("dumping " .. type(t))
userdata: 111847e8 //print(t)

for all the ones before this looked like this:
dumping userdata                    //print("dumping " .. type(t))
(gait_info.T.flags: 0x13f37778)  //print(t)

I understand that userdata is a raw chunk of memory.  Does it just so happen that untli this one that kills it that the others just happeneded to be tables?  Both have the 'type' of "userdata".
if(type(t) == "userdata")  evaluates to true for both.  Is this some memory chunk that doesn't yet have a data structure in dfhack?

Ultimately, I'd like to figure out a way to drill into the ones work like tables, and somehow expand this one (I assume 111847e8 is the address for whatever this thing is) to see what it is (or just skip it).  But since both have type "userdata" I don't know how to distinguish them with a lua statement.

I'm usually pretty smart, but feel free to assume I'm not (type slowly with little words and a condescending tone inside your head).
Logged
sdp0et has been stressed lately. He was been accosted by work recently. He has been annoyed by coworkers. He admired a wonderful bed today. He admired a wonderful woman today.  He needs Coca-Cola to get through the working day.

Putnam

  • Bay Watcher
  • DAT WIZARD
    • View Profile
Re: dfhack lua script question re: userdata
« Reply #1 on: October 10, 2014, 01:29:48 am »

That particular piece of userdata is unknown to Lua (and perhaps to DFHack in general, though I'm not sure about that) and thus cannot really be accessed by it. The best way to check for that would probably be the conditional:
Code: [Select]
if not tostring(t):find('userdata') then
 --do your stuff here
end
Just add that to whatever checks you've got. tostring will give you the exact string it shows when a thing is printed, such as <inorganic_raw: 0x0bf66120>.

Quietust

  • Bay Watcher
  • Does not suffer fools gladly
    • View Profile
    • QMT Productions
Re: dfhack lua script question re: userdata
« Reply #2 on: October 10, 2014, 01:01:07 pm »

Whenever you see "userdata", it means "raw pointer to unknown data", and in the C++ headers you will just see "void *whatever;". If you want to actually see the information inside, you will need to use other tools to reverse-engineer it (e.g. using a memory scanner + heap analyzer or locating and disassembling the code that creates the structures), add those details to the df-structures XML files, then recompile DFHack with them.
Logged
P.S. If you don't get this note, let me know and I'll write you another.
It's amazing how dwarves can make a stack of bones completely waterproof and magmaproof.
It's amazing how they can make an entire floodgate out of the bones of 2 cats.

sdp0et

  • Bay Watcher
    • View Profile
Re: dfhack lua script question re: userdata
« Reply #3 on: October 12, 2014, 09:40:29 pm »

That did it.  And I get the difference between userdata as a type vs a key now.  Thanks for the responses.
Logged
sdp0et has been stressed lately. He was been accosted by work recently. He has been annoyed by coworkers. He admired a wonderful bed today. He admired a wonderful woman today.  He needs Coca-Cola to get through the working day.