Static Shape not showing

#1 The problem results from the StaticShape not being scoped to the client. It can be changed via the console function...

objID.scopeToClient(clientID)

Now that will make it visible to the particular client, for all of them you will have to loop through the clientGroup. As for why they must be scoped to become visible, or if there's a better way to do it, I couldn't tell you :/

#2 /engine/sim/netConnection.h has a pretty good overview of how scoping works, and why--I've not yet been able to track down a list of scope types, etc. to control where/when objects are scoped, but in general what Martin said points to how to do things (scoping to client).

However, something Anthony said makes me concerned:

Quote:Is this a result of moving most the calculation to the client?

Could you expand on what you mean by this? If you mean that you are making your seeding calculations and processing, then creating the objects themselves on the client side of the environment, then yes, that's a problem. Clients should -never- "create" objects that are part of a networked game environment--at most, they should request the server to make them, and then receive the objects back when they get scoped.

One thing that can be difficult with Torque development, especially in scripting, is the very fact that the server and clients sides of the equation are so transparent--hell, if you run an app in single player mode, everything is done in one process, and everything is available to the client as well as the server, so it tends to lead devs in the wrong path--making things on the client side of the equation and expecting them to show up on other clients.

Ironically, while it was a lot harder to configure and set up, having a full dedicated client--dedicated server model to develop in as we do has made the separation and "who should do what" a whole lot easier to understand. Even the stock RTS SK Starter scripts make a few small assumptions about data availability that are actually not correct in all configurations (see this bug report post: Selection Display incorrect assumption--client datablocks ).

#3 Well I was able to get the cleint see the objects by taking advantage of startplacingbuilding method. I think inevitablely a new startresoureplacement will be needed.

I just looked at a bit of the engine it looks like they took off a majority of the objects scoping, to reduces the information traveled across the network. If you do want your static shapes ghosatble add mNetFlags.set(Ghostable); to the constructor.

#4 @Stephen

Can you quantify:

Quote: a lot harder to configure and set up

How much of an effort (Person-days, Person-months) is this?

#5 Well my inital assumtion seems to be wrong. However I did use MArtins solution which did work. So incase you all are wondering

HERE is the template I am using to spawn randomw static shapes later to be actual resources.

If you want it automatic call the seedResource() function in serverCmdMissionStartPhase3Ack() prior to the start mission call to the client, in the file common/server/missionDownload.cs

Note this is happening on the server, so if you need to reseed you can use my server comd function found in the file to do it directly from any client.

A quick thanks to Phil C. who has a great function for getting terrian height which I lifted from RW.

#6 @Jeff L: Greg did 99% of the work on the separation of Server and State(client), and I know it was a lot rougher for him 7 months ago than it would be now (we had just gotten the engine), but I think he started working on the split in may, and by mid June we were up and running--that was all "part-time" work, and with just about zero knowlege of the engine at that time.

Now, with 8 months of engine experience? My bet would be not more than a week. The hardest part about it is breaking out the boot up sequence on both sides while keeping them synched, and that's more of a validation thing than anything else.

For reference, it took the two of us 3 days (he did code conversion, I did most of the script conversion) to get the RTS pack integrated. The "extra time" was actually tracking down a bug in the selection display code that only shows up in a remote server setup.

#7 Actually Your initial assumption was correct, you just missed setting another mask....

mNetFlags.set(Ghostable | ScopeAlways);

I think the reason that by default the StaticShapes are not in scope is because of the way the RTSCamera handles the onCameraScopeQuery. You will notice the differences between it and the shapeBase method, since it does not call findObjects or mSceneManager->scopeScene. This is probably due to the RTS visibility manager. If you add the sceneManager scoping calls into rtsCamera method it will make statics visible without setting any special net flags, but I just bet it will also make all the enemy units visible whenever they are in in a viewable position from the RTS camera.

So depending on how you want to use them, it might be best to simply set the statics to scopeAlways similar to TSStatics, however if you will be needing some more specialized scoping it would probably be better to add to the search in RTSCamera::onCameraScopeQuery and look for staticShapes as well as RTSUnits.