Print

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

[sdp0et]

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

[Putnam]

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]

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.

[sdp0et]

That did it.  And I get the difference between userdata as a type vs a key now.  Thanks for the responses.