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.
  • img.png
«13

Comments

  • Here are a few shots of some ships we cloned. About 3227 pieces... good fun.
    • Halsshot1131.png
    • Halsshot1130.png
    • Halsshot1129.png
    • Halsshot1128.png
    • Halsshot1126.png
  • Another issue, which I'm not sure is related to Wine or your script, but when I activate the vl2, I can only run the client for a few seconds before it freezes completely and I must kill it from the terminal. Without the vl2, Linker's modified client works fine. I'm guessing this has something to do with the autoupdater, or maybe Wine is just failing. I dunno.

    Edit: Using just the client.cs without the vl2 works.
  • Lol, it says "Shoo! Get out of here!"
  • The server has a sytax error.
  • That's because those files have additional metadata for the auto-update script. You aren't supposed to download them directly -- but if you do, I expect you are smart enough to see and remove the metadata.

    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.
  • I did not download it directly, I used the auto-updater.
  • Here are a few shots of some ships we cloned. About 3227 pieces... good fun.


    Those are great ships!

    Creators = You and Shane?
  • Seems I had it set to limit it to only allow you to edit you posts within 2 days. Should be set to allow you to edit it indefinitely now.

    Yeah, Shane did the big ship, I did the cargo hauler.
  • I like that little emblem, Thyth/Krash.
  • Server side script/executable has been updated. See the first post for details.
  • Tried out the new server executable myself last night, works nicely. :)
  • That's a good sign. Is there any way we can help contribute to the development of this?
  • Yes. Write a fast system for the client side for ghost duplicate detection. Ideally, one that can detect duplicates without massive lagspikes. Keep in mind that ghosts are not necessarily transmitted at the same time as the object is created, or made visible to the client as the SI server notifications are, and even if they are... the ghost arrives after the virtual ghost.

    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.
  • Oh, you make it sound so complicated. :rolleyes:
  • He's really good at that. Thats usually why after we tells me something that i don't understand, i get him to tell me again in layman's terms. Then it turns out to be something i'm already doing. :)
  • You want layman's terms? Ok...

    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.
  • even your laymans terms are a bit complex....
    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
  • oh oh oh, idk if your wrong or not, but can i sue you? :lol:
  • around the order of 1048576 steps

    usually when you say "around the order of", you shouldn't include a very detailed figure.
  • I would attempt such an optimization if i had the mathematics skills, but... i don't.
  • Maybe if you can do a container search on each object for, like, one meter, and check the objects detected, that would be less steps.
  • Except i would imagine a container search take longer than a simple compareing
  • By simple comparing, I think he means, take a piece, and compare it to the rest (in SI, there'll be well over the vis limit), then go on to the next piece, and compare it to the rest, etc.

    If you use a container search instead of a loop, maybe it'll be better.
  • No, it would be the same. How do you think container searches work?

    It's a moot point anyway, as container searches don't work on the client side.
  • I'm just tossing out ideas. I didn't expect that suggestion to make it far, anyways.
  • it does work if you put objects onto the server container

    or if you point the search to run on the client container
  • Apparently objects aren't properly removed by SI when you're observer. . .
    • screen1.png
  • dude 3k + peices :eek:
  • Great eyecandy.
Sign In or Register to comment.