Yeah, like I mentioned, it's not related to the patch, rather the servers you've tested are likely running a mod with an introduced task threshold specific to player objects.
If you can look in your own serverTasks.cs and find function serverCmdSendTaskToClient where you'll see the line %targetName = getTargetGameName(%targetId); you can get a pretty good picture of how a server mod would prevent that task info from being sent. For example, if a host wanted to introduce a timeout on how often you could send a task on a player, the simplest version of that could be to add something like:
I'm back and I have tribaloutpost.com website back online and will be kept online. It has over 14k objects that it tracks for automatic map download. Another 12k+ for scripts/textures.
I've rebuild the autodownloader from tribes2maps.com days, https://tribaloutpost.com/autodownload - Krash I noticed your patch notes about downloading from a depot you might have. If you are interested, I'd love to work with you to get this directly built into the QoL patch and working with tribaloutpost.com. If not no big deal.
Users will be able to submit maps again soon, along with all other content.
I think I might've fallen asleep before hitting send on a private message reply over the weekend, but anyway, that's cool that they're back up. I don't recommend any approach for distribution using an external application for clients to use though. Most people these days (rightly) don't trust random executables, particularly unsigned, and installing the game at all is already a big enough ask for anyone who isn't tech-savvy. It'll show Windows users a big warning, and secure or not, the uptake of players willing to run it would be extraordinarily low compared to something simple they can run as a clientside script – which may in itself be low given many people download a pack with all the common maps included, or are satisfied enough with the included system.
The patched game includes the basic enhancements needed to download the files purely using a script in-game if you want to offer an additional source beyond the existing auto-downloader.
After performing a standard get/post query to call your lookup api, you can use HTTPObject.getFile(request-url, save-path, <mode>) to download vl2 files from secure hosts as long as $pref::Net::allowDownloads = 1; is set. The <mode> arg can be "w" (overwrite), "a" (append), or left out to abort if the destination file already exists.
During transit, HTTPObject.getStatus() will return "Downloading" and for each block your object will receive onProgress callbacks indicating how many bytes have been transferred. You won't get text-mode onLine callbacks, obviously.
On completion, a vl2 will be automatically scanned, with its contents added to the resource manager, ready to use. You'll then get an onDisconnect callback, and HTTPObject.getStatus() will return "Complete" if it the download finished without error.
The existing built-in automatic asset download mechanism in the patch allows the game's resource manager to query depot.tribes2.net as a source for missing files immediately as they're being loaded, as though this remote were a disk in your system, using a very quick lookup in a local index cache to avoid attempting requesting files that aren't there. For simplicity and security, the game downloads only exactly the clientside assets needed by the client as they are needed, not entire vl2 archives that potentially could contain scripts or larger collections of content. It's specifically designed to allow clients to join servers without a noticable interruption. Of course, without the mission files, you can't easily use those files to host servers running those maps.
Because this is a service that has to be completely trustworthy and for which I'd be left footing the bill for any unexpected expenses, it can't be allowed to be exploited as a generalized file host by bad actors, nor serve any content which could create a legal, security, or game performance issue... The main performance consideration being that due to how the engine is designed, pretty much all resource manager i/o operations are synchronous on the main thread, so assets expected to read mid-gameplay (so custom player skins and audio being loaded for playback) would block for too long if a remote download were to take place.
For now this all means it's essentially a curated depot currently serving a little over 11k terrains, interiors, shapes, and associated textures; not a completely exhaustive set of everything ever released, but a decent array of everything I personally had backed up or could find still hosted. If you have a single collection of every archived map posted to those sites, I can process them and see if anything there was missed.
For newly created maps though... I had considered building some moderated process allowing submission, but since nobody is even posting new content to the forums, it's very low priority. The core necessity of this will have been parsing and validation of every file to ensure compatibility and acceptable standards; no hidden/extraneous data, no attempts to exploit the engine with intentionally broken assets, no disguised/renamed formats, dealing with name collisions, ensuring any included textures are directly required by the assets or referenced in the mission objects, etc.
Terrains are straightforward enough to be safely reconstructed from the height/splat bitmaps and a few strings; they can technically be sent (slowly) directly from game host servers without much issue, or hosts could even be allowed to have their dynamically running terrain served by the depot. The other binary asset formats have complications that definitely need that extra bit of validation. New scripts and mission files (also scripts)... well, those have some serious potential to become a security issue if someone's determined enough, and I can't take on the liability of automatically distributing them to players without a strict human review/moderation process.
100% understand and agree. I will take a look at what you have given me there in code, appreciate it. I sent another DM as a follow up. I'm planning on turning on asset management again in tribaloutpost.com allowing map submissions etc .. if I do, checks of assets like .ter, .mis, etc will definitely need to be checked to some degree I agree, the world was much different 25 years ago.
Most everyone has moved to Discord and are sharing content that way to be honest, it's a 25 year old game, new content is always going to be slow.
I never wanted to. take tribes2maps.com down, I created. tribaloutpost.com because at the time I was taking over tribes 1 content, there was promise in vengenace and ascension and was hoping to be a central repository, that clearly didn't work out, but I never got to make it what I was hoping it could be.
Anyways, I know I've been gone for a while, I plan to stick around, get all content on tribaloutpost.com accessible again. If I can help, or you want help, I'm one email way.
Krash, just upped rates to 66pps in the server, runs ok, pps received varies from say 35 to 70 on my xp/original t2 install, others with your update report 66. Obs has an issue where it stutters as one moves around but play seems smooth and it's not just my install that notices this. Is the obs issue a known thing or is it just our server?
Stutter while moving the observer camera at boosted packet rates? Hmm... yes, I suppose that should've been expected: the thing that would normally tend to happen if a server sends additional packets in the same tick period is that certain synchronization data would be sent again, so if they're recieved more than a few milliseconds apart, the client could end trying to "rewind" their own control object to a slightly earlier state when the process the same server reset position twice.
The patched server avoids sending these sync points again during the same tick, but the change was limited to the most relevant classes (i.e. players and vehicles) at the time for safe testing. The observer camera must've slipped my mind, but it's an easy fix.
Thanks for the prompt response and good on all. As to running higher tickrate, what is the max if there is one? I note the ping varies wildly as well as pps rate on my xp/original t2 install. For example the pps may be 33 one sec and 77 a few ms later, the ping from 0 to 27 or so that also fluctuates wildly on a ms scale and I'm on the lan to the server. Is that due the engine sending just what it needs and no more or less at the time state was calculated ie by design and I don't need to concern myself about not getting at least 66 pps at all times, or is my server just latency flakey? I had 7 players and one said they were getting 66 pps so I wondered if an unpatched t2 install would report what I am seeing. It'd be nice to lock it down to a stable pps for more predictability of sorts.
On patched servers, the game state ticks at stable fixed 32ms increments, and there is always one packet per tick delivered to all clients. This never changes. There's some variation to the timing of when the packet for that tick will go out, because it happens after all processing occurs; after parsing input packets, running the physics, executing scripts/callbacks, etc.
If after sending this packet there's no more scoped data available to send to a client, there's absolutely no reason to send more packets. If there was information about lower priority objects that didn't fit in the tick packet, it can either be sent as part of an extra packet if you have an increased rate set, or it can be tested again for scope/priority the next tick, after the server state changes.
Your ping fluctuates because rather than it expecting an immediate response from the server, it's a measure of the round trip time from when your client sends a move packet to the first tick packet acknowledging it, and the two sides aren't synchronized to run at an identical pace. On a local machine or LAN where your network latency is effectively 0, this means that your ping is just the time between your input and the packet sending phase of the next 32ms tick. Sometimes you'll have sent your input right before the tick is processed, sometimes you might drift past it and have to wait for the next tick. Patched clients have an advantage in responsiveness here because rather than being limited in when their move input packets are sent, priority messages like weapon triggers attempt to send immediately and can more easily arrive before a server tick is processed -- which also means their pings will fluctuate a little differently.
Unpatched servers don't send every client an update of the game state with every tick, they're following a packet rate delay cycle managed per client, and due to additional problems inherent to the old timing mechanisms, the last packet a client was sent will often be an additional full tick behind before the next update is sent, or (on modern Windows) every third tick could be skipped entirely. Because the unpatched server delays can match up more closely to the client's send schedule (particularly unpatched clients, who can only send inputs at fixed intervals), the ping can look a little more stable from their end, but will always display as a little higher, and will in actual practice always actually be much higher in input/response latency. In some cases an unpatched server/client pair could effectively have double the delay in seeing a response to an input.
"On patched servers, the game state ticks at stable fixed 32ms increments, and there is always one packet per tick delivered to all clients. This never changes."
Considering the above, what is the use of increasing the pps over 32 then? If only 32 game state packets are ever sent what is being sent beyond that 32 pps and how relevant is it?
The test case is a bot server with 50 bots and vehicles. The reason I bothered with this is bombers showed a slight but obvious stutter in flight, and increasing the pps from 33 to 66 seemed to smooth that out but not completely, so may have been placebo. Packet size is 960.
The tick update packet sent when the server state changes is only able to send as much data as fits in a single packet. Typically, this means prioritizing players, projectiles, and vehicles directly in your field of view. Keeping the things you can see or are a threat to you updated as often as possible. Vehicles need far more data than other objects to synchronize the physics simulation, so they're often only sparsely updated if they're not directly in front of you or coming right at you. Items often only send an update the one time unless an external force acts on them. Players are constantly under external control, so they constantly need to be updated with new positions, velocities, view direction, etc.
Some data types can be packed pretty efficiently, but the game's not using any modern stream compression mechanisms: once you have hundreds of objects with a dozen or more bytes in their payload, that first packet is going to fill up, and some objects that have changed on the server will be considered too low priority to be included. Sometimes things like distant vehicles are going to stay low priority and not update for a few ticks unless you get close. If your packet rate to clients limit is raised beyond 32, that additional information unable to fit in that packet can then be sent in a second packet in order to keep lesser scoped objects in your periphery or around you relatively smooth; a little delayed, but keeping the client's version of the simulation closer to the server's.
A raised packet size ensures more of high priority payload data can be delivered immediately, obviously, but it's not a silver bullet if there's so much activity that even that limit is exceeded. If the server never exceeds the size limit however, it's never going to test if it's allowed to send that extra data in an extra packet, it'll just send the single update per tick. Similarly, if there's no additional data after an extra data packet is sent, it has no reason to test if it's allowed to send more.
Comments
Yeah, like I mentioned, it's not related to the patch, rather the servers you've tested are likely running a mod with an introduced task threshold specific to player objects.
If you can look in your own
serverTasks.csand findfunction serverCmdSendTaskToClientwhere you'll see the line%targetName = getTargetGameName(%targetId);you can get a pretty good picture of how a server mod would prevent that task info from being sent. For example, if a host wanted to introduce a timeout on how often you could send a task on a player, the simplest version of that could be to add something like:%targetObj = getTargetObject(%targetId); if (%targetObj.getType() & $TypeMasks::PlayerObjectType) { %now = getSimTime(); if (%now < %client.currentTaskTimeout) return; %client.currentTaskTimeout = %now + 500; }Obviously this wouldn't be the most robust way to cover the interaction, but you get the idea.
I'm back and I have tribaloutpost.com website back online and will be kept online. It has over 14k objects that it tracks for automatic map download. Another 12k+ for scripts/textures.
I've rebuild the autodownloader from tribes2maps.com days, https://tribaloutpost.com/autodownload - Krash I noticed your patch notes about downloading from a depot you might have. If you are interested, I'd love to work with you to get this directly built into the QoL patch and working with tribaloutpost.com. If not no big deal.
Users will be able to submit maps again soon, along with all other content.
Thanks for all you've done for this community.
I think I might've fallen asleep before hitting send on a private message reply over the weekend, but anyway, that's cool that they're back up. I don't recommend any approach for distribution using an external application for clients to use though. Most people these days (rightly) don't trust random executables, particularly unsigned, and installing the game at all is already a big enough ask for anyone who isn't tech-savvy. It'll show Windows users a big warning, and secure or not, the uptake of players willing to run it would be extraordinarily low compared to something simple they can run as a clientside script – which may in itself be low given many people download a pack with all the common maps included, or are satisfied enough with the included system.
The patched game includes the basic enhancements needed to download the files purely using a script in-game if you want to offer an additional source beyond the existing auto-downloader.
After performing a standard get/post query to call your lookup api, you can use
HTTPObject.getFile(request-url, save-path, <mode>)to download vl2 files from secure hosts as long as$pref::Net::allowDownloads = 1;is set. The<mode>arg can be "w" (overwrite), "a" (append), or left out to abort if the destination file already exists.During transit,
HTTPObject.getStatus()will return "Downloading" and for each block your object will receiveonProgresscallbacks indicating how many bytes have been transferred. You won't get text-modeonLinecallbacks, obviously.On completion, a vl2 will be automatically scanned, with its contents added to the resource manager, ready to use. You'll then get an
onDisconnectcallback, andHTTPObject.getStatus()will return "Complete" if it the download finished without error.The existing built-in automatic asset download mechanism in the patch allows the game's resource manager to query depot.tribes2.net as a source for missing files immediately as they're being loaded, as though this remote were a disk in your system, using a very quick lookup in a local index cache to avoid attempting requesting files that aren't there. For simplicity and security, the game downloads only exactly the clientside assets needed by the client as they are needed, not entire vl2 archives that potentially could contain scripts or larger collections of content. It's specifically designed to allow clients to join servers without a noticable interruption. Of course, without the mission files, you can't easily use those files to host servers running those maps.
Because this is a service that has to be completely trustworthy and for which I'd be left footing the bill for any unexpected expenses, it can't be allowed to be exploited as a generalized file host by bad actors, nor serve any content which could create a legal, security, or game performance issue... The main performance consideration being that due to how the engine is designed, pretty much all resource manager i/o operations are synchronous on the main thread, so assets expected to read mid-gameplay (so custom player skins and audio being loaded for playback) would block for too long if a remote download were to take place.
For now this all means it's essentially a curated depot currently serving a little over 11k terrains, interiors, shapes, and associated textures; not a completely exhaustive set of everything ever released, but a decent array of everything I personally had backed up or could find still hosted. If you have a single collection of every archived map posted to those sites, I can process them and see if anything there was missed.
For newly created maps though... I had considered building some moderated process allowing submission, but since nobody is even posting new content to the forums, it's very low priority. The core necessity of this will have been parsing and validation of every file to ensure compatibility and acceptable standards; no hidden/extraneous data, no attempts to exploit the engine with intentionally broken assets, no disguised/renamed formats, dealing with name collisions, ensuring any included textures are directly required by the assets or referenced in the mission objects, etc.
Terrains are straightforward enough to be safely reconstructed from the height/splat bitmaps and a few strings; they can technically be sent (slowly) directly from game host servers without much issue, or hosts could even be allowed to have their dynamically running terrain served by the depot. The other binary asset formats have complications that definitely need that extra bit of validation. New scripts and mission files (also scripts)... well, those have some serious potential to become a security issue if someone's determined enough, and I can't take on the liability of automatically distributing them to players without a strict human review/moderation process.
100% understand and agree. I will take a look at what you have given me there in code, appreciate it. I sent another DM as a follow up. I'm planning on turning on asset management again in tribaloutpost.com allowing map submissions etc .. if I do, checks of assets like .ter, .mis, etc will definitely need to be checked to some degree I agree, the world was much different 25 years ago.
Most everyone has moved to Discord and are sharing content that way to be honest, it's a 25 year old game, new content is always going to be slow.
I never wanted to. take tribes2maps.com down, I created. tribaloutpost.com because at the time I was taking over tribes 1 content, there was promise in vengenace and ascension and was hoping to be a central repository, that clearly didn't work out, but I never got to make it what I was hoping it could be.
Anyways, I know I've been gone for a while, I plan to stick around, get all content on tribaloutpost.com accessible again. If I can help, or you want help, I'm one email way.
Krash, just upped rates to 66pps in the server, runs ok, pps received varies from say 35 to 70 on my xp/original t2 install, others with your update report 66. Obs has an issue where it stutters as one moves around but play seems smooth and it's not just my install that notices this. Is the obs issue a known thing or is it just our server?
Stutter while moving the observer camera at boosted packet rates? Hmm... yes, I suppose that should've been expected: the thing that would normally tend to happen if a server sends additional packets in the same tick period is that certain synchronization data would be sent again, so if they're recieved more than a few milliseconds apart, the client could end trying to "rewind" their own control object to a slightly earlier state when the process the same server reset position twice.
The patched server avoids sending these sync points again during the same tick, but the change was limited to the most relevant classes (i.e. players and vehicles) at the time for safe testing. The observer camera must've slipped my mind, but it's an easy fix.
Thanks for the prompt response and good on all. As to running higher tickrate, what is the max if there is one? I note the ping varies wildly as well as pps rate on my xp/original t2 install. For example the pps may be 33 one sec and 77 a few ms later, the ping from 0 to 27 or so that also fluctuates wildly on a ms scale and I'm on the lan to the server. Is that due the engine sending just what it needs and no more or less at the time state was calculated ie by design and I don't need to concern myself about not getting at least 66 pps at all times, or is my server just latency flakey? I had 7 players and one said they were getting 66 pps so I wondered if an unpatched t2 install would report what I am seeing. It'd be nice to lock it down to a stable pps for more predictability of sorts.
On patched servers, the game state ticks at stable fixed 32ms increments, and there is always one packet per tick delivered to all clients. This never changes. There's some variation to the timing of when the packet for that tick will go out, because it happens after all processing occurs; after parsing input packets, running the physics, executing scripts/callbacks, etc.
If after sending this packet there's no more scoped data available to send to a client, there's absolutely no reason to send more packets. If there was information about lower priority objects that didn't fit in the tick packet, it can either be sent as part of an extra packet if you have an increased rate set, or it can be tested again for scope/priority the next tick, after the server state changes.
Your ping fluctuates because rather than it expecting an immediate response from the server, it's a measure of the round trip time from when your client sends a move packet to the first tick packet acknowledging it, and the two sides aren't synchronized to run at an identical pace. On a local machine or LAN where your network latency is effectively 0, this means that your ping is just the time between your input and the packet sending phase of the next 32ms tick. Sometimes you'll have sent your input right before the tick is processed, sometimes you might drift past it and have to wait for the next tick. Patched clients have an advantage in responsiveness here because rather than being limited in when their move input packets are sent, priority messages like weapon triggers attempt to send immediately and can more easily arrive before a server tick is processed -- which also means their pings will fluctuate a little differently.
Unpatched servers don't send every client an update of the game state with every tick, they're following a packet rate delay cycle managed per client, and due to additional problems inherent to the old timing mechanisms, the last packet a client was sent will often be an additional full tick behind before the next update is sent, or (on modern Windows) every third tick could be skipped entirely. Because the unpatched server delays can match up more closely to the client's send schedule (particularly unpatched clients, who can only send inputs at fixed intervals), the ping can look a little more stable from their end, but will always display as a little higher, and will in actual practice always actually be much higher in input/response latency. In some cases an unpatched server/client pair could effectively have double the delay in seeing a response to an input.
"On patched servers, the game state ticks at stable fixed 32ms increments, and there is always one packet per tick delivered to all clients. This never changes."
Considering the above, what is the use of increasing the pps over 32 then? If only 32 game state packets are ever sent what is being sent beyond that 32 pps and how relevant is it?
The test case is a bot server with 50 bots and vehicles. The reason I bothered with this is bombers showed a slight but obvious stutter in flight, and increasing the pps from 33 to 66 seemed to smooth that out but not completely, so may have been placebo. Packet size is 960.
The tick update packet sent when the server state changes is only able to send as much data as fits in a single packet. Typically, this means prioritizing players, projectiles, and vehicles directly in your field of view. Keeping the things you can see or are a threat to you updated as often as possible. Vehicles need far more data than other objects to synchronize the physics simulation, so they're often only sparsely updated if they're not directly in front of you or coming right at you. Items often only send an update the one time unless an external force acts on them. Players are constantly under external control, so they constantly need to be updated with new positions, velocities, view direction, etc.
Some data types can be packed pretty efficiently, but the game's not using any modern stream compression mechanisms: once you have hundreds of objects with a dozen or more bytes in their payload, that first packet is going to fill up, and some objects that have changed on the server will be considered too low priority to be included. Sometimes things like distant vehicles are going to stay low priority and not update for a few ticks unless you get close. If your packet rate to clients limit is raised beyond 32, that additional information unable to fit in that packet can then be sent in a second packet in order to keep lesser scoped objects in your periphery or around you relatively smooth; a little delayed, but keeping the client's version of the simulation closer to the server's.
A raised packet size ensures more of high priority payload data can be delivered immediately, obviously, but it's not a silver bullet if there's so much activity that even that limit is exceeded. If the server never exceeds the size limit however, it's never going to test if it's allowed to send that extra data in an extra packet, it'll just send the single update per tick. Similarly, if there's no additional data after an extra data packet is sent, it has no reason to test if it's allowed to send more.