Was having a bit of a talk with Antman last night, and he tells me that there is another 4 byte variable that must be changed (2^b and b), and if done right, it negates the need of the additional script.
I'm not exactly equipped to test it out for myself, but maybe it'll help.
He is wrong. I have explored this avenue a long time ago.
The id length variables are stored in ENUMS, which are calculated at COMPILE TIME and SUBSTITUTED into the code. the code doesn't look up the variable, the constant is PLACED in place of the variable at compile time.
This means there are 40 something places that you need to change, and probably more places that have that number, but doesn't have anything to do with id length. Determining where you should change and where you shouldn't change will take several orders of magnitude more time than the current solution.
He clearly haven't actually tried to do what he suggests, or have any idea what he is talking about, or have any idea how C/C++ actually works, or how enums are compiled.
Wow, Golly Jee, Linker, way to put down someone who has several years of C++ experience over you.
Either way, no, I am not wrong; they are not stored in enum's last time I checked in Torque...
There are two defines, one which defines the maximum total number of objects, and one that defines the number of bits that can be used to transmit a ghost ID.
The former is used to define the array of ghosts, the latter is used in the netcode.
The two are not interchangeable, and the compiler is generally aware of that; one cannot use '1024' to define the number of bits in the ghost integer, nor can they use '10' to define the maximum number of ghosts.
You clearly haven't actually tried to do what you suggest, or have any idea what you are talking about, or have any idea how C/C++ actually works, or how defines are precompiled (notice, precompiled).
Which, I point out, is what I actually said that you had to do in the first place, though Krash made a good job of putting it out of context. The C++ precompiler replaces any instances of that macro/enum (they are pretty much treated the same) with that variable, although there are errors in the C++ code where the macro is not used (they just used a standard definition).
I don't recall actually ever stating that it wouldn't take far more work, I recall stating that it would be the -correct- way to do it.
My response was a response to Krash about the validity of your statement based on his presentation, it was not meant as an insult to you, I apologize for provoking you. Don't take it as an insult to you, but rather to Krash's presentation of your words, since Krash's version seems to be distorted quite a ways from what you've expressed.
In terms of enum vs define, my version says this, perhaps its a new addition, which version of torque do you have?
netConnection.h:
enum GhostConstants
{
GhostIdBitSize = 12,
MaxGhostCount = 1 << GhostIdBitSize, //4096,
GhostLookupTableSize = 1 << GhostIdBitSize, //4096
GhostIndexBitSize = 4 // number of bits GhostIdBitSize-3 fits into
};
I don't lack the knolwedge of how define works, I simply didn't mention it because the variables are not stored as macros in the version that I referenced.
Either way, enums and defines have the same end effect in that they are baked into the code as constants, regardless of whether they are indeed one or the other. So the distinction of how the variables are actually stored doesn't really matter.
And in terms of what actually does matter, that the variables are baked into the code, we seem to be in consensus.
The basis for my view of your experience came from Krash's rendition of your words, so therefore they shouldn't be taken as an attack against you.
I'm sorry for making you create an account for the purpose of defending yourself based on judgements made from Krash's mis-quotations.
Whatever man, whatever. You say out of context, I say slightly compressed.
Feb 13 22:34:13 <Antman> shark -- however
Feb 13 22:34:16 <Antman> as linker SHOULD know
Feb 13 22:34:31 <Antman> there's also another 4 byte variable that must be changed
Feb 13 22:34:47 <Antman> if he did it right
Feb 13 22:34:50 <Antman> there should be no need of script.
---
Feb 13 22:38:47 <Antman> because I -know- that there are two variables
Feb 13 22:38:53 <Antman> because I know how V12's netcode works
Feb 13 22:39:04 <Antman> theres the 2^b variable, and the b variable
Feb 13 22:39:14 <Antman> they are two separate constants
[00:29:37] <Antman> you'd have to go into the ASM
[00:29:40] <Shane> ive heard different
[00:29:41] <Antman> and change the value manually
[00:29:47] <Shane> ive heard that the limit is set at 1028
[00:29:49] <Antman> err
[00:29:50] <Antman> 1028
[00:29:55] <Antman> i couldn't reember the exact value
[00:30:01] <Antman> there is also a SECOND define
[00:30:07] <Antman> that is how many bits are in 1028
[00:30:12] <Antman> which you also must change.
[00:30:17] <Antman> and since it's a define
[00:30:20] <Antman> it's not a single value in ASM
[00:30:21] <Shane> elec isnt changing the source
[00:30:25] <Antman> it's at every single location
Yes, I acknowledge that it would be a pain to change every single location value in source (unless you wanted to go into TGE and rewrite it for compatibility with Tribes.. that would be fun... sounds like a project, actually.)
Let's rewrite TSE for Tribes compatibility... I still have the V12 codebase to use as reference for the netcode though any other netcode issues can be resolved using some disassembly and packet-grabbing.
You'll notice you were talking to Shane, not Shark / Krash, I didn't get there for another 2 minutes and 20 or so lines because I was messing with my router, so it's not my fault I caught the back end of the conversation - what I quoted matches almost exactly what was said in response to me mentioning that Linker had modified 4 bytes in the executable and that Elec was working on a script to sync them up. You guys just made a big deal out of nothing, and it didn't really conflict with anything else anyways.
Ant has been writing a game engine which we're going to stick construction on. Very top-secret like.
be nice if it wasn't so secret so i didn't go off make my own -_-
does it do CSG?
also, unpacked version of the client executable is attached.
edit2: this version has staticshapes and some other objects call "GameBaseData::onAdd" when added on the client
I seem to recall in old versions of Torque, there were two constants defined (id bit length, max ghosts), neither of which actually ended up being used in the code anywhere. There were quite a few hard-coded bit lengths.
Couldn't say if it does or not, he hasn't told us a whole lot on the specifics of it other than the odd thing here and there. He'll probably say something if he shows up on here later.
It's only available in Clockworks, The Construct BC (Offline Server). The only way to tell if its running, is to join a game which has the infinite script thing, and join a team, you should see a hud that pops up in the middle of your screen.
But yeah, This works nice. I loaded about 1.7K pieces on the offline server, and I couldn't see anything I deploy, but it takes time to load everything, So I haven't actually tried waiting yet
Dragon, modify a shortcut to t2 to use the new exe.
The client is a bit iffy in telling the server that it's running the script sometimes if you joined right away after starting up (it may not have completed the initial download), so if when you load something and it just stops at 1024 it's probably not marked you as running it - but you should see the centerprint verify it if you have. If it's working you should see the pieces loading slowly and get two large lag spikes.
Comments
He is wrong. I have explored this avenue a long time ago.
The id length variables are stored in ENUMS, which are calculated at COMPILE TIME and SUBSTITUTED into the code. the code doesn't look up the variable, the constant is PLACED in place of the variable at compile time.
This means there are 40 something places that you need to change, and probably more places that have that number, but doesn't have anything to do with id length. Determining where you should change and where you shouldn't change will take several orders of magnitude more time than the current solution.
He clearly haven't actually tried to do what he suggests, or have any idea what he is talking about, or have any idea how C/C++ actually works, or how enums are compiled.
I'll make sure to tell him he was wrong, he'll like that.
Either way, no, I am not wrong; they are not stored in enum's last time I checked in Torque...
There are two defines, one which defines the maximum total number of objects, and one that defines the number of bits that can be used to transmit a ghost ID.
The former is used to define the array of ghosts, the latter is used in the netcode.
The two are not interchangeable, and the compiler is generally aware of that; one cannot use '1024' to define the number of bits in the ghost integer, nor can they use '10' to define the maximum number of ghosts.
You clearly haven't actually tried to do what you suggest, or have any idea what you are talking about, or have any idea how C/C++ actually works, or how defines are precompiled (notice, precompiled).
Which, I point out, is what I actually said that you had to do in the first place, though Krash made a good job of putting it out of context. The C++ precompiler replaces any instances of that macro/enum (they are pretty much treated the same) with that variable, although there are errors in the C++ code where the macro is not used (they just used a standard definition).
I don't recall actually ever stating that it wouldn't take far more work, I recall stating that it would be the -correct- way to do it.
In terms of enum vs define, my version says this, perhaps its a new addition, which version of torque do you have?
netConnection.h:
enum GhostConstants { GhostIdBitSize = 12, MaxGhostCount = 1 << GhostIdBitSize, //4096, GhostLookupTableSize = 1 << GhostIdBitSize, //4096 GhostIndexBitSize = 4 // number of bits GhostIdBitSize-3 fits into };I don't lack the knolwedge of how define works, I simply didn't mention it because the variables are not stored as macros in the version that I referenced.
Either way, enums and defines have the same end effect in that they are baked into the code as constants, regardless of whether they are indeed one or the other. So the distinction of how the variables are actually stored doesn't really matter.
And in terms of what actually does matter, that the variables are baked into the code, we seem to be in consensus.
The basis for my view of your experience came from Krash's rendition of your words, so therefore they shouldn't be taken as an attack against you.
I'm sorry for making you create an account for the purpose of defending yourself based on judgements made from Krash's mis-quotations.
Feb 13 22:34:13 <Antman> shark -- however
Feb 13 22:34:16 <Antman> as linker SHOULD know
Feb 13 22:34:31 <Antman> there's also another 4 byte variable that must be changed
Feb 13 22:34:47 <Antman> if he did it right
Feb 13 22:34:50 <Antman> there should be no need of script.
---
Feb 13 22:38:47 <Antman> because I -know- that there are two variables
Feb 13 22:38:53 <Antman> because I know how V12's netcode works
Feb 13 22:39:04 <Antman> theres the 2^b variable, and the b variable
Feb 13 22:39:14 <Antman> they are two separate constants
Yes, I acknowledge that it would be a pain to change every single location value in source (unless you wanted to go into TGE and rewrite it for compatibility with Tribes.. that would be fun... sounds like a project, actually.)
Let's rewrite TSE for Tribes compatibility... I still have the V12 codebase to use as reference for the netcode though any other netcode issues can be resolved using some disassembly and packet-grabbing.
does the copy of engine you have have the won authentication code by any chance?
Ant has been writing a game engine which we're going to stick construction on. Very top-secret like.
does it do CSG?
also, unpacked version of the client executable is attached.
edit2: this version has staticshapes and some other objects call "GameBaseData::onAdd" when added on the client
But yeah, This works nice. I loaded about 1.7K pieces on the offline server, and I couldn't see anything I deploy, but it takes time to load everything, So I haven't actually tried waiting yet
The client is a bit iffy in telling the server that it's running the script sometimes if you joined right away after starting up (it may not have completed the initial download), so if when you load something and it just stops at 1024 it's probably not marked you as running it - but you should see the centerprint verify it if you have. If it's working you should see the pieces loading slowly and get two large lag spikes.