[ARCHIVE] SimAntics & World Development

Status
Not open for further replies.
Rhys, dunno if it would help you, but you can always look at the TS3 code by decompiling it. There are other ways, but one way of doing it is described here.
 
That stuff isn't really relevant at all to SimAntics, it's just a small point of interest that they only changed it starting with TS3.
 
SimAntics is a bytecode language that's kind of its own thing, the programming language that it's coded in isn't relevant. SimAntics is executed through a VM like interpreter that could really be coded in any language. TS3 doesn't use simantics though, it instead uses c# code.
 
RHY3756547 said:
SimAntics is a bytecode language that's kind of its own thing, the programming language that it's coded in isn't relevant. SimAntics is executed through a VM like interpreter that could really be coded in any language.
Click to expand...
Patrick J. Barrett III said:
the objects and the Sims are written in SimAntics.
Click to expand...
No wonder it was so easy to make expansions! And why it felt like I was an running operating system at some points.
 
What do you mean with VM? Virtual Machine??? Also if sims antics is bytecode language why the sims engine need c++ core to interpretate the objects and other elements.
 
It needs c++ code to interpret the bytecode, computers can't run it directly as it's not x86! It's like emulating a console, you need a form of intermediate software to interpret the instructions and simulate the functionality of the "machine".
 
The sims antincs can be implemented into c++, csharp or v.net??? because i only know vb.net, and can be interesting test with that...
 
Yes, you can code a SimAntics emulator for just about anything. It requires mass loading of all of the objects in the game though, as well as an understanding of how SimAntics functions.
 
Technically, what Rhys is doing isn't an emulator though, he's rebuilding the VM.
 
Hmm, with the current version the Stack Object seems to be being treated as the "Callee", which is definitely not the case. This is causing changes of the stack object to attempt to load BHAVs from other objects (or null)...
 
Yea I was coming up against this before I stopped. An interesting thing I noticed was a lot of objects in their init bhav set Stack Object ID to My object id. However, in the OBJD the same objects have 0 as their init tree ID. Was not clear if this was deprecated or maybe the init only runs on the server VM so the client copy has 0 for the tree ids?

So this was a hack to get stuff working until I fully understood the relationship between the my & stack objects. Although it may be as simple as swapping the my & stack objects current meaning and getting init functions to work for object threads.
 
Last edited:
I think it's most likely just a utility variable that you can use to reference an object. Stack object seems to always be implicitly set to the callee on queuing an interaction, though it can be changed to another object or null without altering the execution flow.

I'm still not sure of its relation to stack frames. It seems that the stack object carries onto any subroutines, but any changes to it remain in that subroutines stack frame (would explain the naming, "stack object".) In the module inspector, it's roped in with the parameters and locals.
 
Agree, the stack object seems to be the object being invoked against. So a bhav to change a sprite frame would act on the stack object. That is logical I guess. Take the aquarium. It has a main loop, this runs in a thread owned by the object so My = the aquarium. That thread starts up. The init function changes stack object to be my id and then subsequent bhavs can be shared by both user invoked routines and the objects own thread because the stack object for both point to the aquarium. So a utility to set the sprite based on object state can be used by both contexts.

However, that would suggest changing the stack object is persistent which it may not be given the name like you pointed out. If it was per stack frame the init function setting the stack object would only effect primitives and sub-calls within init. The aquarium does this variable set just before it calls a private "set graphic by state".

May be worth tweaking a TS1 object to perform a primitive if stack object ID == my object ID in init / main and after a change and pop of the stack.
 
Actually, all of the bhavs that run against the object thread do this. init, load and main. So if the assumption is these bhavs all run in the same thread then it seems like it probably is set per stack frame.
 
Did some testing and found this:
stackframeobj.png

Stack objects behave as I expected when calling subroutines. The stack object in the new stack frame is set to the current one, but changes to it do not persist back.

stackobjauto.png

First shot is from Dialog alerting "I am $Me" in init (don't do this btw, you get stuck in a perpetual loop of dialogs), and second one is alerting "Object is $Object" from directly at the start of a test interaction. This shows that at the start of the function the stack object is automatically the object - and another interesting thing is that BHAVs have a property called "Default Stack Object" which is usually set to "Normal" but can be set to any object type in the game... This is especially weird because there is no space for a whole GUID in the BHAV header.

The stack object set in init does not affect the stack object when the interaction is called (it will still be the callee, the aquarium), I set it to the Object with ID 1 and it still used the Aquarium for the interaction. Also, if you set the Stack Object ID to something that doesn't exist the game will freak out (simulation froze for me when doing it in init routine)!
 
Status
Not open for further replies.
Back
Top