Multiple instances of same object being created?
by Justin Mosiman · in Torque Game Engine Advanced · 07/01/2007 (2:56 am) · 4 replies
Hello,
I am working on pathfinding for atlas, and I have the pathfinding nodes generated based on the terrain, but I'm having a problem accessing those points.
First off, I am calling the genPathfinding through the console within AtlasInstance2, such as:
This calls the following method:
This method correctly generates the nodes, and stores it in a 2D array of type:
I can correctly output all of the nodes under mPathfind->genPathfinding(), so I know that it is generating the nodes correctly. But when I want to output the nodes for display purposes in AtlasInstance2::renderObject(SceneState *state, RenderInst * ), Torque crashes. I am just trying to output the nodes the same way I did within genPathfinding... so it shouldn't crash.
This leads me to thinking that multiple instances of the same object are being created in memory. I'm out of town for another two weeks so I am doing this on my laptop which isn't the best for debugging. So I'm wondering if there is something obvious that I am missing.
Thanks,
Justin
I am working on pathfinding for atlas, and I have the pathfinding nodes generated based on the terrain, but I'm having a problem accessing those points.
First off, I am calling the genPathfinding through the console within AtlasInstance2, such as:
ConsoleMethod(AtlasInstance2, generatePathfinding, void, 2, 2, "")
{
object->genPathfinding();
}This calls the following method:
void AtlasInstance2::genPathfinding()
{
mPathfind->genPathfinding();
}This method correctly generates the nodes, and stores it in a 2D array of type:
U8 **mPathfindData;
I can correctly output all of the nodes under mPathfind->genPathfinding(), so I know that it is generating the nodes correctly. But when I want to output the nodes for display purposes in AtlasInstance2::renderObject(SceneState *state, RenderInst * ), Torque crashes. I am just trying to output the nodes the same way I did within genPathfinding... so it shouldn't crash.
This leads me to thinking that multiple instances of the same object are being created in memory. I'm out of town for another two weeks so I am doing this on my laptop which isn't the best for debugging. So I'm wondering if there is something obvious that I am missing.
Thanks,
Justin
#2
Additionally, for data within an object to be transmitted, you have to add it to packUpdate and unPackUpdate yourself, if it's something that you have added (which you have in this case).
The reason that's important is these path nodes will only exist on the server if that's where you create them, or the client if that is where you created them--and while both the member variable and the console methods will exist on the client, the data itself won't.
Keep in mind here though that you probably don't actually want this data on the client--you simply want to make sure you are always on the server when you are using the data--which is most cases, except for rendering, which leaves you somewhat stuck, since all rendering happens on the client.
It's not really a trivial solution, although in a single player instance (client and server in same executable) you can "cheat" and access server side data from the client directly--it's just not really a good idea unless you protect it very well.
07/01/2007 (8:02 am)
Caveat to Phil's post: if the object derives from NetObject, and is marked as ghostable (default).Additionally, for data within an object to be transmitted, you have to add it to packUpdate and unPackUpdate yourself, if it's something that you have added (which you have in this case).
The reason that's important is these path nodes will only exist on the server if that's where you create them, or the client if that is where you created them--and while both the member variable and the console methods will exist on the client, the data itself won't.
Keep in mind here though that you probably don't actually want this data on the client--you simply want to make sure you are always on the server when you are using the data--which is most cases, except for rendering, which leaves you somewhat stuck, since all rendering happens on the client.
It's not really a trivial solution, although in a single player instance (client and server in same executable) you can "cheat" and access server side data from the client directly--it's just not really a good idea unless you protect it very well.
#3
Wouldn't I want pathfinding data to be on the client and not the server? If every time a client wanted to move a unit it would then have to communicate with the server, and wouldn't that generate a lot of unnecessary traffic?
07/01/2007 (8:00 pm)
Ah, thanks, I forgot about the whole client server thing since I am running it as a single player instance for now.Quote:
Keep in mind here though that you probably don't actually want this data on the client
Wouldn't I want pathfinding data to be on the client and not the server? If every time a client wanted to move a unit it would then have to communicate with the server, and wouldn't that generate a lot of unnecessary traffic?
#4
07/03/2007 (8:20 am)
That already happens Justin. Remember that one computer must contain the "official" copy of the game world, and that is the server. If too much "trust" is placed in data that is coming from the client as far as unit movements and such then your game is more open to hacking and cheating. 
Torque 3D Owner Phil Carlisle
Even local games are "networked" in this sense.