Why are datablocks sent twice? Arghhhhh
by Max Robinson · in Torque Game Engine · 01/26/2003 (3:11 pm) · 8 replies
I've been working with all kinds of additions to particles, and also with some new classes I've made, and one of the biggest leaps is just adding in stupid things to the datablocks pack and unpack datas.
Right now I'm trying to make every particle have the ability to "decay" into another particle after a percent of it's lifetime has expired (like fire turning to smoke).
The idea is great, and it was a cinch to add. I ran the game without any datablocks using the feature, no error. Then I put one in and, as so often happens for me, it crashes while loading datablocks. What makes me really mad is that the problem doens't make sense.
First: It does packData twice. There is only 1 client. The first time, it has it's particleData figured out OK. The second time, it is 0, and it causes a crash when I do ->getId();
Second: The client can find the particle data perfectly fine, even if it's not sent. This should NOT happen.
This thing where the client knows too much has happened to me elsewhere, also. In one instance, the client already knew what texture to use, and when I tried to send it, it would cause errors.
Does anyone who worked on the engine, or maybe knows a lot about the datablock handling, know what causes this problem?
Right now I'm trying to make every particle have the ability to "decay" into another particle after a percent of it's lifetime has expired (like fire turning to smoke).
The idea is great, and it was a cinch to add. I ran the game without any datablocks using the feature, no error. Then I put one in and, as so often happens for me, it crashes while loading datablocks. What makes me really mad is that the problem doens't make sense.
First: It does packData twice. There is only 1 client. The first time, it has it's particleData figured out OK. The second time, it is 0, and it causes a crash when I do ->getId();
Second: The client can find the particle data perfectly fine, even if it's not sent. This should NOT happen.
This thing where the client knows too much has happened to me elsewhere, also. In one instance, the client already knew what texture to use, and when I tried to send it, it would cause errors.
Does anyone who worked on the engine, or maybe knows a lot about the datablock handling, know what causes this problem?
#2
It is well understood that things that work on a single client/server machine can show an ugly face when running on seperate machines. Essentially it should be transparent but you can get subtle bugs when running only locally.
Hope this helps,
- Melv.
01/28/2003 (11:51 am)
I'm not sure I've got the time to help you fully here but you should be aware that connecting locally e.g on the same machine does not equate to connecting remotely e.g. from another. A local client connection takes all sorts of shortcuts for performance reasons that can result in certain bugs not showing their ugly heads.It is well understood that things that work on a single client/server machine can show an ugly face when running on seperate machines. Essentially it should be transparent but you can get subtle bugs when running only locally.
Hope this helps,
- Melv.
#4
To help understand whats going on, I often use the isServerObject() method in my debugging console output because so many methods are called twice.
01/28/2003 (2:37 pm)
Running your game on a local machine still results in two sets of datablocks - a server version and a ghost (client) version. Your machine is essentially running both the server and client in this scenario.To help understand whats going on, I often use the isServerObject() method in my debugging console output because so many methods are called twice.
#5
Not that this is going to help you here. ;)
- Melv.
01/29/2003 (10:30 am)
Justin is quite correct but what I was trying explain is that under LocalConnection conditions it is possible to have something working that won't work when connecting remotely. This will only happen if you do something illegal but it is the reason why I constantly check stuff remotely rather than develop on a single machine.Not that this is going to help you here. ;)
- Melv.
#6
I think I have a new question...
I've thrown in a lot of little console echoes to the preloading packing, etc...
Here is what I get:
(This is from packData)
(SERVER) PARTICLE DATABLOCK: 23364844
Decay time pct: 0.800000
Decay particle ID: 69
Decay particle DB: 23364188
(This is from unpackData)
(CLIENT) PARTICLE DATABLOCK: 23889580
Decay time pct: 0.799609
Decay particle ID: 69
Decay particle DB: 0
(This is from preload)
PARTICLE DATABLOCK: 23364844
DECAY PDATA DB: 23364188
DECAYING: 0
As you can see, 23364844 and 23889580 are the same thing. I can tell because there is only 1 decaying particle datablock in right now, and they have the same time pct (kinda). Thier decay particle ID is also identical. So as far as I can tell, it's working. The problem is, it still isn't. The preload is apparently only being done by the server, as you can see by the datablock numbers. Also, the server doesn't think the decaying particle's decay flag is set, which is wrong. Very wierd.
To me, it seems like the server changes some of the values at some point, for some strange reason, like they don't match up to a default/template or something like that.
I think I need to work on this some more...
01/29/2003 (11:33 am)
I went through and made it always send the ID, but I also made it make sure there was a datablock to use. So, it doens't crash, but instead it just doesn't work.I think I have a new question...
I've thrown in a lot of little console echoes to the preloading packing, etc...
Here is what I get:
(This is from packData)
(SERVER) PARTICLE DATABLOCK: 23364844
Decay time pct: 0.800000
Decay particle ID: 69
Decay particle DB: 23364188
(This is from unpackData)
(CLIENT) PARTICLE DATABLOCK: 23889580
Decay time pct: 0.799609
Decay particle ID: 69
Decay particle DB: 0
(This is from preload)
PARTICLE DATABLOCK: 23364844
DECAY PDATA DB: 23364188
DECAYING: 0
As you can see, 23364844 and 23889580 are the same thing. I can tell because there is only 1 decaying particle datablock in right now, and they have the same time pct (kinda). Thier decay particle ID is also identical. So as far as I can tell, it's working. The problem is, it still isn't. The preload is apparently only being done by the server, as you can see by the datablock numbers. Also, the server doesn't think the decaying particle's decay flag is set, which is wrong. Very wierd.
To me, it seems like the server changes some of the values at some point, for some strange reason, like they don't match up to a default/template or something like that.
I think I need to work on this some more...
#7
Since One Executable file is playing both Client And Server Part.
Many things are Executed Twice, but some are executed only once.
The following is just what I think after spending some time on the engine. They maybe wrong and I hope someone cauld help me clarfly them...
1.When The Executable is just started. It is just a Client (and not yet connect to any Server yet). So it create some datablock only ONCE for itself.(Like some GUI profiles).
2.Until You Create a Game, You Acturally Created a Server. Then The Client is connected to the server locally.
3.As the Server Started, It create the Datablock for the main part of the game. (e.g. Armor, Crossbow, Heathpatch etc).
4.It also tell the client to create those datablock then. So that you got two instance of the same datablock (one serverobject, one ghost).
5.Then, the Server and the Client is run its loop separately, and communciating throught events. (The UI belongs to the client side)
Maybe You need to make sure, when you are creating the datablock, you are "DOING IT AS THE SERVER" or "DOING IT AS THE CLIENT".
03/29/2003 (2:20 pm)
I have simular problem on something else.Since One Executable file is playing both Client And Server Part.
Many things are Executed Twice, but some are executed only once.
The following is just what I think after spending some time on the engine. They maybe wrong and I hope someone cauld help me clarfly them...
1.When The Executable is just started. It is just a Client (and not yet connect to any Server yet). So it create some datablock only ONCE for itself.(Like some GUI profiles).
2.Until You Create a Game, You Acturally Created a Server. Then The Client is connected to the server locally.
3.As the Server Started, It create the Datablock for the main part of the game. (e.g. Armor, Crossbow, Heathpatch etc).
4.It also tell the client to create those datablock then. So that you got two instance of the same datablock (one serverobject, one ghost).
5.Then, the Server and the Client is run its loop separately, and communciating throught events. (The UI belongs to the client side)
Maybe You need to make sure, when you are creating the datablock, you are "DOING IT AS THE SERVER" or "DOING IT AS THE CLIENT".
#8
I have a hunch that to fix this it'll require a very specific, possibly painfully obvious, and of course very hard to find, solution. I've heard of a few other strange problems with datablocks in Torque, all of them slightly different from eachother, and mine.
04/07/2003 (7:46 pm)
Hmm. I'm just having my stuff follow the leader with the rest of the other stuff, I'm pretty sure. It sends with the other stuff, which works for the most part. I forget how I fixed this now, I think I broke it so it'd work...I have a hunch that to fix this it'll require a very specific, possibly painfully obvious, and of course very hard to find, solution. I've heard of a few other strange problems with datablocks in Torque, all of them slightly different from eachother, and mine.
Torque Owner Max Robinson