Structrual Infinity
You can can find a quick installer here.
I'm sure you've all read Linker's thread on the piece limit, and are aware that I was in the process of working on the script end.
I'll be using this post to provide a single place for up to date status information on the script. Krash has generously provided hosting for this script. If you wish to download the current version, it is available here.
The script download is (for the time being) an automatic updater which downloads the client and server scripts from The-Construct.net on launch. It can take up to a minute to perform this download.
Since I'll probably be making dozens of changes in the near future, I don't want to have everyone manually downloading new versions continually. Believe me, it's better this way.
Installation (Server):
-Download the VL2 from the link above. Put it somewhere in T2/GameData/Construction/.
-Launch a Construction dedicated server as before.
Installation (Client):
-Download the VL2 from the link above. Put it somewhere in T2/GameData/Construction/.
-Launch Tribes 2 as you would before.
If you are running the server, you must be running TribesNext RC3 or newer to get setGhostable functionality. The script will check for functions added in RC3, and if they are not available, you won't get slack space. SI will still work, but in a reduced mode.
Current Server Version: 0.7 Core (Beta)
Current Client Version: 0.9 Core (Beta)
Current Known Issues:
-Fading is not completely supported on virtual ghosts. Fade-in seems to work correctly, but fade-out simply jumps to full transparency when the fade completes.
-Cloaking is not supported at all on virtual ghosts. (Expect to fix by server 0.8)
-The server can spam massive quantities of notifications that result in perceived lag on the client side as further notifications get queued. (Expect to work on a first fix for server 0.9)
The usual: I'm not responsible if it crashes your game, blows up your computer, fries your video card, makes your girlfriend break up with you, or any other negative consequences.
Update History:
-Client 0.1-r2 posted (02/17/2008): Added cleanup when leaving servers. No more UE's when rejoining a server, or joining a different server.
-Client 0.1-r3 posted (03/31/2008): I still consider it alpha-quality. No changes were made to the server version of the script. This version has some slight differences in the way client side objects are stored (group rather than set), and an additional blob of code that properly kills client side duplicated ghosts.
-Server 0.2 posted (05/06/2008): Server has now reached "beta" quality. Slack space is allocated for non-deployable ghosts. Deployable objects will stop ghosting after 800 deployables, and this value is configurable in the script. Make sure to use the modified Tribes2_server.exe in conjunction with this version.
-Server 0.3 posted (07/10/2008): Working on some performance enhancements that require calibration (thus no real benefit yet to the 0.1 series clients). Fixed a few minor bugs. I'll need for servers to run this in real world situations before an enhanced client will be made available.
-Server 0.4 completed (7/26/2008): Working on packet conglomeration in an effort to improve loading rates for large buildings. Results are a bit less promising than initially anticipated since T2 does a lot of compression already, but I think I can still get close to the double data rates with a bit more work. If packeting doesn't pan out, I'll remove it.
-Client 0.5 completed (8/20/2008): Working on a first generation spatial partitioning system and some things that manage the out of order notification reception.
-Client 0.6 completed (8/22/2008): Reworked the spatial partitioning system to use spatial hashing. This reduces object object lookup by transform/scale/datablock to essentially constant time, rather than the quadratic time complexity in the pre-0.4 clients. Out of order notification handling is in, and allows objects to be arbitrarily ghosted and virtual-ghosted after creation; this will be used in the SI server to implement support for cloaking.
-Server 0.5 completed (8/26/2008): Packeting didn't help transfer rate performance. Removed it in favor of Huffman code length minimization, which provides roughly 30% improvement in transfer rate performance. Fixed a few bugs with on-create notification not propagating cloak state, fade state, or tag state. Added support for duplicate "protection", which allows marking objects on the client side for duplication tolerance; some mod functions require having two different objects in one place -- this allows specifying those situations for loose enforcement of duplication removal.
-Client 0.7 completed (8/26/2008): Added client side support for Huffman code length minimization for improved transfer rate performance. Added support for duplicate protection in the spatial hashing code. Fixed a few minor bugs with state handling of cloaking with regards to the spatial hashing code.
-Server 0.6 Core posted (9/17/2008): Completed catch support for tag changes on the server side. Killing support for all client script versions older than 0.7 (the first beta release) -- users of these clients will be notified that their script is too old, and that they should upgrade.
-Client 0.8 Core posted (9/17/2008): Completed client side processing of tag labels. This requires a raycast patched client which will be posted soon. Fixed a bug regarding texture swapping and duplicate removal. Implemented isClientGhost in script for all relevant object types, and changed its method of functioning. Later DLL clients can now be used without generating duplicate objects. Forcefields are also not duplicated anymore.
-Client 0.8b Core Posted (3/27/2009): No new features. Added support for RC2 TribesNext clients.
-Client 0.9 and Server 0.7 posted (5/31/2010): Added a new filtered remote method invocation, which is used to implement animations and damage notifications for SI pieces. Added a new health bar HUD that very closely emulates the one the game draws for non-SI pieces (you shouldn't be able to tell the difference). Both the server and the client must be running the latest versions to get these notifications. This update should make it much easier to deal with complex power based buildings, as both switches and generators animate.
I'm sure you've all read Linker's thread on the piece limit, and are aware that I was in the process of working on the script end.
I'll be using this post to provide a single place for up to date status information on the script. Krash has generously provided hosting for this script. If you wish to download the current version, it is available here.
The script download is (for the time being) an automatic updater which downloads the client and server scripts from The-Construct.net on launch. It can take up to a minute to perform this download.
Since I'll probably be making dozens of changes in the near future, I don't want to have everyone manually downloading new versions continually. Believe me, it's better this way.
Installation (Server):
-Download the VL2 from the link above. Put it somewhere in T2/GameData/Construction/.
-Launch a Construction dedicated server as before.
Installation (Client):
-Download the VL2 from the link above. Put it somewhere in T2/GameData/Construction/.
-Launch Tribes 2 as you would before.
If you are running the server, you must be running TribesNext RC3 or newer to get setGhostable functionality. The script will check for functions added in RC3, and if they are not available, you won't get slack space. SI will still work, but in a reduced mode.
Current Server Version: 0.7 Core (Beta)
Current Client Version: 0.9 Core (Beta)
Current Known Issues:
-Fading is not completely supported on virtual ghosts. Fade-in seems to work correctly, but fade-out simply jumps to full transparency when the fade completes.
-Cloaking is not supported at all on virtual ghosts. (Expect to fix by server 0.8)
-The server can spam massive quantities of notifications that result in perceived lag on the client side as further notifications get queued. (Expect to work on a first fix for server 0.9)
The usual: I'm not responsible if it crashes your game, blows up your computer, fries your video card, makes your girlfriend break up with you, or any other negative consequences.
Update History:
-Client 0.1-r2 posted (02/17/2008): Added cleanup when leaving servers. No more UE's when rejoining a server, or joining a different server.
-Client 0.1-r3 posted (03/31/2008): I still consider it alpha-quality. No changes were made to the server version of the script. This version has some slight differences in the way client side objects are stored (group rather than set), and an additional blob of code that properly kills client side duplicated ghosts.
-Server 0.2 posted (05/06/2008): Server has now reached "beta" quality. Slack space is allocated for non-deployable ghosts. Deployable objects will stop ghosting after 800 deployables, and this value is configurable in the script. Make sure to use the modified Tribes2_server.exe in conjunction with this version.
-Server 0.3 posted (07/10/2008): Working on some performance enhancements that require calibration (thus no real benefit yet to the 0.1 series clients). Fixed a few minor bugs. I'll need for servers to run this in real world situations before an enhanced client will be made available.
-Server 0.4 completed (7/26/2008): Working on packet conglomeration in an effort to improve loading rates for large buildings. Results are a bit less promising than initially anticipated since T2 does a lot of compression already, but I think I can still get close to the double data rates with a bit more work. If packeting doesn't pan out, I'll remove it.
-Client 0.5 completed (8/20/2008): Working on a first generation spatial partitioning system and some things that manage the out of order notification reception.
-Client 0.6 completed (8/22/2008): Reworked the spatial partitioning system to use spatial hashing. This reduces object object lookup by transform/scale/datablock to essentially constant time, rather than the quadratic time complexity in the pre-0.4 clients. Out of order notification handling is in, and allows objects to be arbitrarily ghosted and virtual-ghosted after creation; this will be used in the SI server to implement support for cloaking.
-Server 0.5 completed (8/26/2008): Packeting didn't help transfer rate performance. Removed it in favor of Huffman code length minimization, which provides roughly 30% improvement in transfer rate performance. Fixed a few bugs with on-create notification not propagating cloak state, fade state, or tag state. Added support for duplicate "protection", which allows marking objects on the client side for duplication tolerance; some mod functions require having two different objects in one place -- this allows specifying those situations for loose enforcement of duplication removal.
-Client 0.7 completed (8/26/2008): Added client side support for Huffman code length minimization for improved transfer rate performance. Added support for duplicate protection in the spatial hashing code. Fixed a few minor bugs with state handling of cloaking with regards to the spatial hashing code.
-Server 0.6 Core posted (9/17/2008): Completed catch support for tag changes on the server side. Killing support for all client script versions older than 0.7 (the first beta release) -- users of these clients will be notified that their script is too old, and that they should upgrade.
-Client 0.8 Core posted (9/17/2008): Completed client side processing of tag labels. This requires a raycast patched client which will be posted soon. Fixed a bug regarding texture swapping and duplicate removal. Implemented isClientGhost in script for all relevant object types, and changed its method of functioning. Later DLL clients can now be used without generating duplicate objects. Forcefields are also not duplicated anymore.
-Client 0.8b Core Posted (3/27/2009): No new features. Added support for RC2 TribesNext clients.
-Client 0.9 and Server 0.7 posted (5/31/2010): Added a new filtered remote method invocation, which is used to implement animations and damage notifications for SI pieces. Added a new health bar HUD that very closely emulates the one the game draws for non-SI pieces (you shouldn't be able to tell the difference). Both the server and the client must be running the latest versions to get these notifications. This update should make it much easier to deal with complex power based buildings, as both switches and generators animate.
img.png
1.1K
Comments
Edit: Using just the client.cs without the vl2 works.
Edit:
After the main issues are addressed, I am considering a group move/rotate "accelerator" system. It would be both a server and client side script that could issue multi-object move commands to move any number of pieces as "one" command. The client side would be able to interpolate intermediate values for the transformation, thus allow moving large groups of objects as smoothly as the client frame rate.
Those are great ships!
Creators = You and Shane?
Yeah, Shane did the big ship, I did the cargo hauler.
I was thinking octree type spatial partitioning, but I'm open to... other suggestions.
Oh and... based on the new server, I've come up with a few ideas for a server side alteration that would fix cloaking and fading on the client side -- provided no more than say... 800 objects are cloaked or in the process of fading at once.
That would require a reliable, dynamic, ghost duplicate detector on the client side, prior to implementation, however.
If high performance data-structures are your forte, give a ghost duplicate detector a shot.
You have a blob of object transformations and scales, basically 10 floating point numeric values per object. Since they are floating point numeric values, "identical" numbers can be off in the last decimal points (6.99999 is equivalent 7 for the purposes of this exercise).
You have n of these objects represented by the 10 floating point values. Find all duplicates, making sure to handle the "off" decimal values. That's it in "layman's terms".
The current SI client does it in n*n steps, with a few tricks to make it a bit less. Still... somewhere around the order of 1048576 steps for 1024 objects (1024 steps per object). Considering each step takes between 3 and 10 milliseconds, you get the pile of lag on the client side.
It is possible, however, to do the exact same duplicate detection in 3 to 4 steps per object in the case of 1024. Thus... 3072 to 4096 steps, rather than 1048576 steps.
That disparity becomes even more obvious with larger object counts. Given 20,000 objects, it would take 4 to 5 steps per object using the smart method, a total of 80,000 to 100,000 steps for the entire duplicate sweep. Or 400,000,000 for the current method.
If you think you've already made something along the lines of the smarter method, go ahead and integrate it into the SI code.
basically, n pieces are all based on a fixed number of pieces of the limit, creating a base of duplicates all in the same "category" of fixed pieces
if im wrong, dont sue me
usually when you say "around the order of", you shouldn't include a very detailed figure.
If you use a container search instead of a loop, maybe it'll be better.
It's a moot point anyway, as container searches don't work on the client side.
or if you point the search to run on the client container