Attached is an example of a demo that shows the "Demo playback failed for file" dialog but audio plays in the background. Calling the function Canvas.setContent(PlayGui); shows the demo playing back normally. isPlayingDemo returns true.
Playback works fine on RC2a. TribesForever's very permissive demo parser has no issues either.
Krash, we're playing around with AI upscaling for textures and 2x-4x file sizes get kind of big. Is there a maximum size a vl2 can be? Seems after 2gb it stops loading textures.
Standard resource manager file sizes in bytes are limited to a signed 32 bit integer, so after about 2.14GB you'd be feeding the zip handler an incorrect stream length. If any of the textures are being CRC checked, you may also run into issues with the frame allocator being too small if the texture being checked exceeds 3MB; I don't remember offhand if that was increased already.
I can confirm this demo works fine on my end. Would have to look closer to spot any oddities, but generally it shouldn't show that abort message unless it fails to load entirely, I think the exception being a soft fail added to the patch for debugging when the terrain failed to load, but that shouldn't be the case here.
Only one or two new serverprefs will be added automatically after the first run/export (the boosted rate for sending datablocks faster being one), anything else will be optional additions. Would be curious to know what the dll warning was, but the installer is essentially just a compressed package extracting files and making sure that the license agreement is accepted; if the server runs it's probably fine, if required dlls are missing it won't start at all. AVX has been optional for a while, it should detect support and switch code paths on older hardware.
No avx probs here, server is replete with avx goodness, however I have tried pretty much everything to get t2csri.vl2 and attendant eula to overwrite by the patch and no go, patch error msg complains about not being able to overwrite. I gave the folder all permissions, I gave the files all permissions, I ran the patch as admin, I copied another t2csri.vl2 from another source and no go. I gave pretty much all entities listed in properties for the freaking thing full control and no go.
CRC checking isn't generally going to be the cause of a stutter, not because the computation is particularly fast, but because it's only done at load time, and isn't going to be performed on textures loaded during gameplay where the host isn't requiring it. High resolution textures do have quite a bit more work to do in runtime load processing though, because all those extra bytes need to be read from disk, decompressed (both from the vl2 if deflate compression is used and from the image format compression itself), converted from a raw bitmap to an optimal format and uploaded to the GPU by the driver, and have an entire mipmap chain generated — the last, while much faster than the original software implementation, can still be a fairly heavy process and the main thread will block until the driver finishes for each texture being loaded in a frame. A lot of this load time would be avoidable by supporting more modern texture containers like dds or kxt, which can both hold offline-generated mipmaps and store everything compressed in a format directly transferrable to and readable by the GPU... Technically it'd be possible to add something like ktx2 support, though it'd need to bypass most standard texture handling, and of course only really something that'd likely be noticed with very large textures.
Krash, I'm wondering if you can help me out with a very odd problem that I'm having. I often play on Blakhart's server, named Blair Lag Project. He has a lot of bots there. One of them is named Sami-FIN. That's also the name I use to play. Just some hours ago, it wasn't possible to join Blair Lag Project. The server was very broken. It wasn't even showing up here on the website's server list. I went to some other server then to play. It only had players and that demo bot that records gameplay. As I joined that server, I noticed an odd message in the chat: ''Sami-FIN has been muted.'' It was true: I couldn't use the Voice Game System. I checked out a few servers. I was probably muted on all the game's servers except for TRIUMPH BotAbuse 300Maps server. However, I managed to get myself unmuted by removing my pyrdb file in the base, prefs folder. I can play now, but I would like to know how to play using that pyrdb file again. As I understand, it stores muted players as numbers. I don't know if my name is in there.
What I'm guessing is going on is that often when I join Blakhart's server, and my bot version is already there, it gets named to Sami-FIN.1. I often mute that bot, because it uses the same voice as I and because it gets confusing listening to and reading its messages. Maybe the last time I played on Blair Lag (before this muting problem) I muted my bot version. I left, and later on Blakhart's server broke down, and somehow my muting of Sami-FIN.1 bot got saved somewhere permanently, and the game thinks Sami-FIN.1 and Sami-FIN are one and the same. I don't know. I do know that muting those bots isn't permanent: I can mute them, leave the game, come back to the server, and they are unmuted again.
Since bots don't have guids, you most likely accidentally muted your previous client after timing out and reconnecting.
The pyrdb format is pretty simple, you can open it up in any text editor, and each line is a guid and two 0/1 boolean values: mute text and mic voice, respectively. Remove the line starting with your guid (it'll match the name of the file after pyrdb), and you should be fine to keep using the rest.
You could in theory also host a local listen server and connect to it with a second instance of the game and mute/unmute yourself there, but note whichever client closes last will overwrite the prefs.
This won't have prevented other players from seeing your messages, of course; being able to mute yourself is just an unexpected quirk of that system.
Odd thing is about muting, when The Sami was in our server later on he indeed was muted in chat, no chat from him but did get the canned chat sounds. Dunno if a corrupted server had anything to do with it.
I checked to see if I somehow I muted him, he wasn't, dunno wtf was going on there. That said, I will do my best not to put up a server without immediate testing after serious changes have been made, it was well borked for a major portion of the day.
Comments
Hi Krash. This is likely fixed in the next patch. Here's a reproduction case anyway.
Demos captured with this script https://github.com/tribes2/scripts/blob/master/client/auto-record.cs don't always play back on QoL. I've had success with demos captured in a client/non-dedicated LAN server but issues with online client demos.
Attached is an example of a demo that shows the "Demo playback failed for file" dialog but audio plays in the background. Calling the function
Canvas.setContent(PlayGui);shows the demo playing back normally.isPlayingDemoreturns true.Playback works fine on RC2a. TribesForever's very permissive demo parser has no issues either.
Krash, we're playing around with AI upscaling for textures and 2x-4x file sizes get kind of big. Is there a maximum size a vl2 can be? Seems after 2gb it stops loading textures.
Standard resource manager file sizes in bytes are limited to a signed 32 bit integer, so after about 2.14GB you'd be feeding the zip handler an incorrect stream length. If any of the textures are being CRC checked, you may also run into issues with the frame allocator being too small if the texture being checked exceeds 3MB; I don't remember offhand if that was increased already.
I can confirm this demo works fine on my end. Would have to look closer to spot any oddities, but generally it shouldn't show that abort message unless it fails to load entirely, I think the exception being a soft fail added to the patch for debugging when the terrain failed to load, but that shouldn't be the case here.
Only one or two new serverprefs will be added automatically after the first run/export (the boosted rate for sending datablocks faster being one), anything else will be optional additions. Would be curious to know what the dll warning was, but the installer is essentially just a compressed package extracting files and making sure that the license agreement is accepted; if the server runs it's probably fine, if required dlls are missing it won't start at all. AVX has been optional for a while, it should detect support and switch code paths on older hardware.
No avx probs here, server is replete with avx goodness, however I have tried pretty much everything to get t2csri.vl2 and attendant eula to overwrite by the patch and no go, patch error msg complains about not being able to overwrite. I gave the folder all permissions, I gave the files all permissions, I ran the patch as admin, I copied another t2csri.vl2 from another source and no go. I gave pretty much all entities listed in properties for the freaking thing full control and no go.
Also any chance of getting a module built in to watch for and log crashes with as much detail as Krash desires?
Would the strategy to prevent CRC stuttering to keep textures under 3mb?
CRC checking isn't generally going to be the cause of a stutter, not because the computation is particularly fast, but because it's only done at load time, and isn't going to be performed on textures loaded during gameplay where the host isn't requiring it. High resolution textures do have quite a bit more work to do in runtime load processing though, because all those extra bytes need to be read from disk, decompressed (both from the vl2 if deflate compression is used and from the image format compression itself), converted from a raw bitmap to an optimal format and uploaded to the GPU by the driver, and have an entire mipmap chain generated — the last, while much faster than the original software implementation, can still be a fairly heavy process and the main thread will block until the driver finishes for each texture being loaded in a frame. A lot of this load time would be avoidable by supporting more modern texture containers like dds or kxt, which can both hold offline-generated mipmaps and store everything compressed in a format directly transferrable to and readable by the GPU... Technically it'd be possible to add something like ktx2 support, though it'd need to bypass most standard texture handling, and of course only really something that'd likely be noticed with very large textures.
Maybe the file was in use? Weird, but if you still couldn't get it in there, you could always just make another install folder and copy the mods over.
Krash, I'm wondering if you can help me out with a very odd problem that I'm having. I often play on Blakhart's server, named Blair Lag Project. He has a lot of bots there. One of them is named Sami-FIN. That's also the name I use to play. Just some hours ago, it wasn't possible to join Blair Lag Project. The server was very broken. It wasn't even showing up here on the website's server list. I went to some other server then to play. It only had players and that demo bot that records gameplay. As I joined that server, I noticed an odd message in the chat: ''Sami-FIN has been muted.'' It was true: I couldn't use the Voice Game System. I checked out a few servers. I was probably muted on all the game's servers except for TRIUMPH BotAbuse 300Maps server. However, I managed to get myself unmuted by removing my pyrdb file in the base, prefs folder. I can play now, but I would like to know how to play using that pyrdb file again. As I understand, it stores muted players as numbers. I don't know if my name is in there.
What I'm guessing is going on is that often when I join Blakhart's server, and my bot version is already there, it gets named to Sami-FIN.1. I often mute that bot, because it uses the same voice as I and because it gets confusing listening to and reading its messages. Maybe the last time I played on Blair Lag (before this muting problem) I muted my bot version. I left, and later on Blakhart's server broke down, and somehow my muting of Sami-FIN.1 bot got saved somewhere permanently, and the game thinks Sami-FIN.1 and Sami-FIN are one and the same. I don't know. I do know that muting those bots isn't permanent: I can mute them, leave the game, come back to the server, and they are unmuted again.
Since bots don't have guids, you most likely accidentally muted your previous client after timing out and reconnecting.
The pyrdb format is pretty simple, you can open it up in any text editor, and each line is a guid and two 0/1 boolean values: mute text and mic voice, respectively. Remove the line starting with your guid (it'll match the name of the file after pyrdb), and you should be fine to keep using the rest.
You could in theory also host a local listen server and connect to it with a second instance of the game and mute/unmute yourself there, but note whichever client closes last will overwrite the prefs.
This won't have prevented other players from seeing your messages, of course; being able to mute yourself is just an unexpected quirk of that system.
Odd thing is about muting, when The Sami was in our server later on he indeed was muted in chat, no chat from him but did get the canned chat sounds. Dunno if a corrupted server had anything to do with it.
I checked to see if I somehow I muted him, he wasn't, dunno wtf was going on there. That said, I will do my best not to put up a server without immediate testing after serious changes have been made, it was well borked for a major portion of the day.
Seems like this gui bg is getting messed up passed 150% UI scale or @2x