dynamic datablock interest?
by D Player · in Torque Game Engine · 11/02/2002 (11:44 pm) · 12 replies
Here's the deal,
I just finished modifying datablocks, the details are below. The question is, does anybody else want me to take the time and effort to make a proper patch and resource? Would anyone else get any use out of this?
Changes:
I just finished modifying datablocks, the details are below. The question is, does anybody else want me to take the time and effort to make a proper patch and resource? Would anyone else get any use out of this?
Changes:
About the author
#2
11/03/2002 (9:01 am)
The level of interest shown will directly effect the amount of time I put into this.
#3
I'm wondering what kind of stress this puts on the networking system though?
11/03/2002 (10:25 am)
That sounds pretty cool.I'm wondering what kind of stress this puts on the networking system though?
#4
11/03/2002 (1:40 pm)
Something I don't understand here... Aren't datablocks a separate type because they're supposed to be static by nature? If I'm remembering correctly, the server sends the information to clients at the beginning of a session and that's it (unless it's explicitly requested to send a datablock), thus saving bandwidth.
#5
Actually instance creation should use the datablocks for defaults and have local variables for anything dynamic because datablocks affect ALL object instances of a type.
11/03/2002 (2:47 pm)
James is right, the datablocks are static by design and are only used for static data at engine start up.Actually instance creation should use the datablocks for defaults and have local variables for anything dynamic because datablocks affect ALL object instances of a type.
#6
11/03/2002 (3:28 pm)
James and Jarrod are correct.... datablocks should be left the way they were meant to be... you can use internal code to change some values on the fly... if you need to... but datablocks should be static..
#7
I admit to being somewhat perterbed that you don't see the use, but I guess I can take a moment to explain more about them.
Robert, transmission of datablock IDs would now be 32 bits instead of 10. I don't know how often they are transmitted, but I doubt there's all that much traffic there. As for the datablocks themselves, since there is now an inheritance system it no longer has to transmit redundant information so it will be much quicker for child datablocks.
Defiant, that's the generally given explanation for datablocks but a better explanation is that datablocks represent the static portion of items, that which will be the same between all objects of a certain type. This is a good system and all, but what if you want to make new types on the fly? The only difference is is that it allows creation of more types, and the creation of types on the fly.
Jarrod, see above.
Exodus, datablocks are const once created, in the C++ meaning of const. A specific datablock is not duplicated, I'm just creating new datablocks on the fly.
For all of you, remember that datablocks are small already, and child datablocks are 32 bits, plus a handful of bits of overhead, plus your changes from the parent/template. That's almost no bandwidth usage. Remember that this is all Hoffman compressed as well.
If you still don't see the use, well that's fine; I'm not going to say what I'm using it for. This is a nice system if you feel the need, otherwise it's not a big change (since I didn't fix the normal script inheritance system, which is just an outright copy).
11/03/2002 (4:36 pm)
hmm...I admit to being somewhat perterbed that you don't see the use, but I guess I can take a moment to explain more about them.
Robert, transmission of datablock IDs would now be 32 bits instead of 10. I don't know how often they are transmitted, but I doubt there's all that much traffic there. As for the datablocks themselves, since there is now an inheritance system it no longer has to transmit redundant information so it will be much quicker for child datablocks.
Defiant, that's the generally given explanation for datablocks but a better explanation is that datablocks represent the static portion of items, that which will be the same between all objects of a certain type. This is a good system and all, but what if you want to make new types on the fly? The only difference is is that it allows creation of more types, and the creation of types on the fly.
Jarrod, see above.
Exodus, datablocks are const once created, in the C++ meaning of const. A specific datablock is not duplicated, I'm just creating new datablocks on the fly.
For all of you, remember that datablocks are small already, and child datablocks are 32 bits, plus a handful of bits of overhead, plus your changes from the parent/template. That's almost no bandwidth usage. Remember that this is all Hoffman compressed as well.
If you still don't see the use, well that's fine; I'm not going to say what I'm using it for. This is a nice system if you feel the need, otherwise it's not a big change (since I didn't fix the normal script inheritance system, which is just an outright copy).
#8
11/03/2002 (9:09 pm)
it is not a question of bits and bandwidth but more of an architectual question. If you have a use for such a fundamental architectual change great.
#10
Not only is that not really a "better" explanation, but it's almost the same explanation. And actually, they're not constants. Try it in the console, you can edit the members of a datablock and things respond in kind. Just don't rely on it. That said, I can see possible value in being able to create new ones on the fly, but I fear that it could lead to some less-than-optimal designs.
I might still be missing the point, of course. *shrug*
11/03/2002 (10:00 pm)
Quote:...a better explanation is that datablocks represent the static portion of items, that which will be the same between all objects of a certain type.
Not only is that not really a "better" explanation, but it's almost the same explanation. And actually, they're not constants. Try it in the console, you can edit the members of a datablock and things respond in kind. Just don't rely on it. That said, I can see possible value in being able to create new ones on the fly, but I fear that it could lead to some less-than-optimal designs.
I might still be missing the point, of course. *shrug*
#11
11/04/2002 (5:36 am)
This seems interesting, but I'm having trouble putting the pieces together, mentally-wise. Can you give an example of what this is good for?
#12
Another idea I had, which is related, was to use client-side datablocks. In most cases both the client and server would have access to the datablocks, unless it was an MMORPG. Instead of requiring every datablock to be sent back and forth, the client could do a CRC-type thing the datablocks, and on joining, have the server verify that its datablocks are identical. If not, the client side errors could be replaced with the server's ones. This doesn't allow any extra cheating. Clients can already modify datablocks they have for the most part, and the important, gameplay-altering facets of the game are still going to be server-side.
Just wondering if that seems like a good idea. I, personally, see a lot of use for more dynamic datablock creation/modification/deletion in games with lots of semi-unique items like RPGs. Adding this support would help more than it would hurt in a LOT of cases.
11/10/2002 (7:40 pm)
I don't know what problem other people are having with this, or why they think datablocks MUST be static (you know they aren't, right? the server can modify then do transmitDatablocks(true) to all the clients, and it will refresh anything that isn't preloaded), but just from the first few lines of your first post I got excited. I would have killed for this to be in Tribes2, seeing as I hit the absolute hard coded limit on datablocks in that game (2048, if I remember correctly). EVERY RPG project will need this sort of functionality, unless they do a lot of tricks with thier system so that the in-use instances (not datablocks) can be modified a lot, which is also a valid idea, and may even be better suited for a more massive project. Still, I still think this is great idea. Deletion of datablocks is also a good idea too, a game where only a portion of the objects are usually in use at once could keep the size small by using a system based off of this.Another idea I had, which is related, was to use client-side datablocks. In most cases both the client and server would have access to the datablocks, unless it was an MMORPG. Instead of requiring every datablock to be sent back and forth, the client could do a CRC-type thing the datablocks, and on joining, have the server verify that its datablocks are identical. If not, the client side errors could be replaced with the server's ones. This doesn't allow any extra cheating. Clients can already modify datablocks they have for the most part, and the important, gameplay-altering facets of the game are still going to be server-side.
Just wondering if that seems like a good idea. I, personally, see a lot of use for more dynamic datablock creation/modification/deletion in games with lots of semi-unique items like RPGs. Adding this support would help more than it would hurt in a LOT of cases.
Associate Stefan Beffy Moises
Creating datablocks on-the-fly sounds like a very helpful feature and I'm definately interested in this...