Try searching the error log for the GUID, see if you can find the token itself. You'll have to change the GUID to decimal, since the log dumps everything in decimal, not hex.

How do I convert the guid ID to the log guid? I know how to convert to/from hex. It's just the log guid are negative numbers.

If they're negative numbers in the guid, they'll be negative numbers in the log.

Ummm.. nearly all the tokens are negatives...
I can't even find the controllers token in the list. (0xEC191A23 [3961068067])

I do however see the attributes and several temps (are those locals?)

Just quickly, it's easier for me if you attach the entire log rather then just the particular segment. There's context information which can be pretty valuable.

The inventory segment that you posted - was that for the active sim?

Locals are listed in the stack trace at the start of the log. Temps are temps, there's no funky naming going on there.

Well here you go then

Temps are temp? well for once maxis isn't playing "lets utterly confuse the poor coder"

I've attached the log. If you want my code I can send that too. The undefined transition is from Get nth token returning error.

A hex number converts to a negative decimal number if the highest bit is set. In a 32-bit hex GUID that would be 0x80000000 and up.

0x80000000 converts to 2,147,483,648 in decimal. But since we are using signed numbers (because that's what Maxis used), we take all the low 31 bits, subtract them from 2,147,483,648 and stick a minus sign in front.

So, for 0x80000000, 2147483648 minus zero becomes -2147483648.

0xFFFFFFFF would be 0x80000000 and 0x7FFFFFFF combined. 0x7FFFFFFF converts to 2,147,483,647. 2147483648 minus 2147483647 becomes -1.

There are merely 2 billion or so examples I left out.

There is a number converter built into SimPE. Or buy a calculator with hex notation built in. I use the calculator, although I know how to do it step-by-step, being a remnant of when pencils were cheaper than calculators.

<* Wes *>

Okey dokey, the reason you're not finding the tokens you'd expect in that log is that neither "My" nor the SO are pointing to the relevant sim. Run your object's code, the use shift-click to force an error on the sim itself and look at that error log. You should hopefully find the token in there.

There's that token hiding.... I see the problem, the token is empty.

Heres my create token code:

Your index needs to be pointing to the same variable in both the "set to next" and the "push property". Make the index for push property temp 0.

That did it. So basically in Set to Next GUID's index is a returned value that contains a 'pointer' to the token list. And everything else uses that pointer to access the token. Sorta like how you'd pass structures in C. The token list in the log now contains one entry. Although I see Value is a hex, so it was 0x666, but it's there non-the-less. Now I can get to work on saving setting function.

BTW is it just me or could SimPE use better language descriptions? Like the index value in Set to Next GUID?

Index is an index more so than a pointer - the first token in the sim's inventory is 0, the next is 1, the next is 2, and so on. More like... Well C doesn't have a good parallel, but I suppose you could equate it to a dynamically resized array. For clarification, basically your code translates a bit like this:
(this is more Java than C I'm afraid, because chaining in C is even less readable!)



If you are interested in submitting changes to the BHAV plugin under SimPE, you'd be best to check out the PJSE forums: http://simlogical.com/SMF/index.php .

Ok now how does Read token, Get Nth and Set Nth parameters work?

Read Token:
after setting Set to Next.
index: this is the where the pointer will be stored in, i.e. Temp 0

Get/Set Nth Token:
property: the pointer, i.e. Temp 0
Value: is this where the data will be stored in? or is this the Nth location. If this is the location where is the data stored in/retrieved from?

You know, one of these days you're going to ask an easy question!

Okay, first thing to note is that there is a special and rarely used variable called "Temp Token". It is not the same thing as the regular temp variables (temp 0, temp 1, etc), in that it is not an integer variable but actually a token variable. You only get the one, and you can only edit its contents using the "Manage Inventory" primitive.

"Read token at index into temp" takes a type which is either counted or singular. You want singular. The neighbor id is of course the id of the sim, and the index is the index supplied to you from the set to next call. Running this command will copy the relevant token from the neighbor's inventory into the temp token so that you can manipulate its contents.

"Get Nth Property From Token In Temp" assumes that the relevant token has now been loaded into the temp token, and asks which property you want from that token (starting from 1 I believe). It stores the value of that property into whichever variable you pass in the "value" parameter.

"Set Nth Property From Token In Temp" is the same as above, except that instead of writing the property into value, it writes the value into the nth property of the temp token.

Finally, "Save Token in Temp" writes the changes made to the temp token back to the place in the sim's token array which it was originally read from.

If it's an easy question, theres a good chance I'll answer it myself Yes I was aware of Temp token. I didn't know that the functions already knew about them or it needed to get passed. Ugh... good reason why globals are bad.

I'm now getting an attribute out of range error.

heres the code: (all target inventory is singular neighbor my attribute Neighbour ID)


It gets the nth property ok, but complains when it's setting the nth property.

If I look at the sims force reset log its got:

So I know I'm not going out of bounds.

That's a bit confusing... What was the value of local 0 in the log for the "attribute out of range" error?

Is this what your looking for?

Looks okay to me. Have you tried the elimination method of finding which parameter it's complaining about? Try changing the property value to something else and re-running, see if anything changes. Then change it back and alter the value property and see if that fixes anything. Maybe even try a different value to 0x666, something smaller, and see if that's why it's having a hissy fit?

Ok this is a bit strange... I've modified the code to read the property into local then immediately write it back.. still gives the same error.



Yes i've changed the property value to check, still causes the error.

Okay, this is going to sound weird, but try it anyway.

Using the ["] button, paste these values in over the top of your "set" command:
03090000083409000000070100190000
and these over the top of your "get" command:
03090000073409000000070100190000

And try that. If that doesn't change anything, then I'm a bit stumped. If it does change something, let me know.

Well this time Get's giving me stack error. I've attached it. What did that numeric version do differently? The param enter dialog looked the same.

No idea. A couple of the less well-known commands sometimes have flags and stuff which we don't know about, and so we cannot decode. The PJSE wizards just put values into the boxes it knows about, it won't take values out of boxes it doesn't know about. That means that occasionally you'll end up with values in an operand which don't look to us like they're doing anything, but which end up causing unexpected errors. The best way to check if this is the case is to either fill all the operands with zeros and then re-enter the parameters, or to copy the parameters from an object you know already works. The values I gave up in my last post were pulled straight from the cauldron code, which was in turn pulled from the toddler potty, so I knew that they worked.

Your stack error is showing up in node 6, not node 9 like the previous one you posted. What command is running on node 6? Are you perhaps trying to...
- look at a local > 0?
- look for a parameter?
- Access a value belonging to the stack object without setting the stack object first?

Your suggestion to zero out did the trick, at least it's not complaining anymore. I'll have to test to make sure it's doing the right thing tomorrow.... umm latter today LOL.

Odd question, when I click on the object any code that deals with My attribute is incorrect (usually just 0), but if I just Stack Objects's attribute (Stack ID wasn't assigned). Shouldn't My point to the object too?

Not sure what your question means... I think there's a missing clause after the second brackets?

"My" refers to the owner of the stack that the code is running in, so it depends on how the code gets called and more importantly, from where. The SO can be changed at any point, but when the code starts it gets whichever value the caller had in the SO at the time... Does that help at all?