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.
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.