[ARCHIVE] SimAntics & World Development

Status
Not open for further replies.
That's a multiplayer job object, those will need to be coded separately from all the normal simantics stuff (at least, the ui+inputs will need to be)
 
RHY3756547 said:
The game assumes that you are mousing over a ground tile for placing objects, similar to how the real game works, but different in that table placed objects actually offset this down a little bit.
Click to expand...

At first I thought you meant that when you move the Hand Tool over a tile on the ground, if a surface object exists on that tile, then the game will shift the sprite of the object you're placing away from your true mouse coordinates up onto the surface. If the user is moving an object from one surface onto another of equal height, then he can't tell that his mouse coordinates have been shifted up.

However, I checked this behavior ingame, and that wasn't the case. So when you said "table placed objects actually offset this down a little bit", you meant that they offset the range of screen coordinates for which the object will be placed on that counter upwards away from the ground. (And of course, the sprite of the object will be shifted upwards onto the counter).

So when the user switches to the Hand Tool, you could create the mapping "The screen coordinate (x,y) corresponds to this object (or the ground) at tile (u,v) with z-order distance 'z'" for all (x,y), and then iterate over each of these mappings from farthest z-order distance to nearest; if the object at that coordinate (x,y) is a surface object, you create the new mapping "Screen coordinate (x,y+height) gets mapped to the surface of the surface object on tile (u,v) with z-order distance 'z'" (overwriting the old mapping).

However, since TSO lets you place new objects without pausing the game time, you would have to update the mappings after each SimAntics tick.
 
Last edited:
Working on the query panel now. Should be easy enough to populate with the relevant information:
upload_2015-7-8_15-13-2.png
One definite future problem will be rendering object thumbnails, which is needed both here and for object dialogs.

Fatbag said:
At first I thought you meant that when you move the Hand Tool over a tile on the ground, if a surface object exists on that tile, then the game will shift the sprite of the object you're placing away from your true mouse coordinates up onto the surface. If the user is moving an object from one surface onto another of equal height, then he can't tell that his mouse coordinates have been shifted up.

However, I checked this behavior ingame, and that wasn't the case. So when you said "table placed objects actually offset this down a little bit", you meant that they offset the range of screen coordinates for which the object will be placed on that counter upwards away from the ground. (And of course, the sprite of the object will be shifted upwards onto the counter).

So when the user switches to the Hand Tool, you could create the mapping "The screen coordinate (x,y) corresponds to this object (or the ground) at tile (u,v) with z-order distance 'z'" for all (x,y), and then iterate over each of these mappings from farthest z-order distance to nearest; if the object at that coordinate (x,y) is a surface object, you create the new mapping "Screen coordinate (x,y+height) gets mapped to the surface of the surface object on tile (u,v) with z-order distance 'z'" (overwriting the old mapping).

However, since TSO lets you place new objects without pausing the game time, you would have to update the mappings after each SimAntics tick.
Click to expand...
Are you talking about using the hand tool for picking objects up? That's just performed by rendering the objects with an Object ID buffer instead of colour/depth, and getting the id at the pixel clicked. It's hilariously inefficient right now though (draws all objects every tick in update... ugh), and will be worked a bit more into the static buffers system once I clean that all up, so that it's simply rendered at the same time as the colour/depth buffers using multiple render targets for minimum cost.
 
RHY3756547 said:
Are you talking about using the hand tool for picking objects up?
Click to expand...

I was referring to placing (old or new) objects down on a new "tile" (or a new surface object).

Of course, you pick an object up just by clicking on it. To know what the user is clicking on, of course you just refer to the screen z-buffer to see what object is nearest to the camera at that point.
 
upload_2015-7-8_17-4-59.png
Everything pretty much working like a charm (even with fade tween!), with a few things left to tie together + object thumbnails on the left.

Fatbag said:
I was referring to placing (old or new) objects down on a new "tile" (or a new surface object).

Of course, you pick an object up just by clicking on it. To know what the user is clicking on, of course you just refer to the screen z-buffer to see what object is nearest to the camera at that point.
Click to expand...
I had another look at the behaviour in the real game and the anchor position seems to change depending on where you picked it up from. I don't think there's anything fancy going on, just a hittest with the ground with an offset. Try picking up a big object like a fridge from multiple spots (top and bottom), and you'll see what I mean. I'll try and implement this for the next release.
 
Awnings are causing an interesting reaction. I have no idea what's causing this.
upload_2015-7-8_19-9-25.png
 
Rhys said:
Everything pretty much working like a charm (even with fade tween!), with a few things left to tie together + object thumbnails on the left.
Click to expand...

Good work, now i think you should check for some objects that has not catalog image, or maybe those are logical objects that you are not able to buy??

One definite future problem will be rendering object thumbnails, which is needed both here and for object dialogs.
Click to expand...

Why this is going to be a future problem, you cna use oject sprite for rendering the thumbnails...
 
It's not that simple. I need to render a drawgroup into a render target, and I need to calculate the total containing bounds of all the sprites before drawing it. Our draw code isn't exactly simple either.
 
Yes, youre right, it uses Drawgroup, seems the one from OBJD, Base Graphics Id, i have removed that and no object thumbnail showed in catalog description (TSO Pre Alpha)
 
That's one of the things I missed a lot. HELL YEAH~!

I'd like to be able to remove the objects that are already there though. I guess this is something you'll be working on when the rest of the build mode works great. You still need to lock out moving used objects and make it impossible to place an object on a tile where another Sim is standing. That build is really good of course.

Btw. I didn't expect this to work:
ixlSSMr.png
 
Last edited:
That is completely untested. Please don't click yes!
Rhys: awnings are from original game/expansions, right? I nearly facepalmed when I saw that, because it was screaming to me "another random IFF field change". That's where I'd look if I were you.
 
A lot of things are from the original game/expansions and they all work fine. The problem here is likely a simantics bug.
 
Shift key to duplicate now works. Now you can place as many plants/fridges/whatever as you like! ;)
830450995f8bc9cff504eca59f04a193.gif

Specific Info page is available when you pick up existing objects, but it looks like it's missing something (apart from the wear bar). Does anyone have any screenshots?
de0a7a749e1352ff08ea58e2469a3b61.gif
 
Might be a problem with those images thanks to Gyazo totally losing it. Right click on them and click "open image in new tab" to see them.
 
Status
Not open for further replies.
Back
Top