The original simulated net params did function in online games, and as such were used to exploit the same flaw timescale changes did: servers would stop simulating a player that stops sending packets. On the client end it was restricted to local listen server connections to mitigate this, though it'd be safe enough to allow it in offline mode in general for testing on dedicated lan servers.
At the time I rewrote the packet delivery logic, the simulated net delay settings were being used for routing through part of the original netcode for testing certain behaviour with both protocols speaking to each other. The round-trip timing is tracked differently on the original code, which is why the ping display breaks down with it being routed, and you also consequently currently only have a delay for packets going in one direction.
Alright I feel silly for saying it wasn't a cheat now even though I suppose I must have suspected it might be a bit sketchy or I wouldn't have mentioned that.
Thanks for the quick reply. Do you care to elaborate on the last sentence please? The delay only going in one direction.
Does it mean, it is no good to practice with offline for the purpose of simulating a higher ping?
For the moment, in the current version you're only applying a delay to packets sent from the client to the listen server. The listen server is still sending you packets every ~32ms regardless, but because listen servers don't communicate with the host over the network, and aren't currently allowing simulating a delay, every server packet is processed by the client instantly. This means for every other object you see moving in a local game, there's zero delay from the server, but... Because the server tries to keep your player object synchronized to moves it receives from you, delaying client input packets can effectively simulate the feel of latency on your own player object: server trigger responses for weapon firing, jetpacks, jumps, etc. will all be visually delayed more or less as expected (but if you were targetting a moving enemy, it may have travelled twice as far as expected before your projectile actually fired on the server).
For testing skiing routes this is probably fine. As you've noticed though using the prefs to apply it, those variables are halved by the host startup script - because the control applies a delay of x milliseconds on any packet sent by a connection object, the script normally tries to apply half the requested delay to the trip back.
If you check the previous page, there was some discussion on the subject to catch up on, but because there are so few people using them, it's taken some time to get crashlogs/information to narrow down what issue MacBook users are having. Currently, I'd been hoping to hear back on the capabilities the Apple OpenGL driver is reporting (specifically most importantly the supported formats and extensions), as mentioned at the end of this post:
Any idea why my ping to all T2 servers whether they are in the US or Europe could have doubled overnight?
I used to ping 100-105 in the T2 browser tab to Chicago servers, 135-145 in game. Now it is 200 with some rubberbanding to boot. I have tested with my old Vanilla non QoL install, exact same issue. Been playing for almost a year and my ping has been rather stable until yesterday.
The most puzzling part is I don't have this problem at all with other games. Just T2 and last week was just fine.
I spent 3 hours on the phone with my ISP help desk, they ran all sorts of tests. I mean I even talked to a guy that sounded competent. I did reset my router twice, plugged, unplugged everything. People at my ISP say my connection is good, debit is good, my wifi is great too and I have tried messing with my DNS. No Luck.
Hmm, well, the game itself fires off raw UDP packets well under the IPv4 MTU, meaning there's no additional overhead or fragmentation of the packets to cause delays or drop packets under modern broadband, and there are no DNS lookups involved in game server connections. Essentially as soon as the packets are created they're out of the game's control, and your OS passes them along to your router/modem.
Barring hitting your bandwidth limits and not having queue priority, or something bizarre like your router's CPU being overloaded, I wouldn't expect anything within your own network to create a delay of more than a few milliseconds.
I'm sure you might know some of this info, but I'll throw it in in case it helps you or others reviewing the latency you might see from the game:
The ping shown in the browser is (when both client and server are patched) is an almost pure measure of the time it takes to send a packet to the server and receive a response. The "almost" being that a server isn't necessarily handling those packets instantly if there's a heavy load, being that the event loop running network processing and gameplay all runs on the same thread. It's the most optimal ping you'll see, though.
The ping shown in the lobby is a recent record of the running average of the time it takes for a gameplay packet sent by the server to reach you, be noted in one of your input move packets and sent back, and finally to be received back by the server. Because the server only sends gameplay packets every 32ms, and the client response time may be slightly delayed if e.g. you have opengl's blocking vsync on (but not to a problematic degree), it's normal for this to be a little higher than the raw ping.
The ping shown in the network options, huds, or with client variables is the running average of the time it takes for an input packet sent by you to reach the server, be noted in a gameplay packet, and arrive back. This also affected by the server's gameplay tick rate, so will be reasonably close to the server's measurement shown in the lobby, but is usually a little lower.
Are the pings higher to all servers, or just the ones you normally playing on? My suspicion for a sudden increase in latency of that magnitude would be that the it's using a new BGP route to reach some servers, maybe one of the hops the traffic passes through started advertising incorrect info or is terribly inefficient... but the specifics in broader ISP network management in that area aren't my field of expertise. Your ISP could work around this if it were confirmed, but you'd probably have to get a case escalated to someone on their end willing to take the time.
You could try running a traceroute to each of the servers impacted, and ask one of the server hosts to run a traceroute to your IP. Maybe fiddle around with a BGP toolkit or looking glass utility. If anything does point to an obvious problem node, you could note it down to present to your ISP's tech.
Otherwise... you could try seeing if you get similar results while using a VPN, if only to confirm that the routing path is the issue. It'd probably still come in a little higher than your "normal" expected ping, but the packets would take a different path across the net, so you could rule out local issues if it's any lower latency than you're getting now.
Yes pings are much higher, roughly twice as high as before, to all T2 servers, US or Europe.
I suspect it is a routing issue like you suggested. But I have re-checked with different games: I am not seeing any ping increase there so it is baffling that it would only affect T2 traffic.
I will try to get a VPN to see if I am seeing the same behavior. I have a scheduled call with a tech next week.
A traceroute will not affect your latency in any way, it'll just try to account for where the packet is passing through and how long it takes to get to each stop and back. It won't work in every case, since not all hosts will respond to the diagnostic packets, but it can be very useful to dig into what's happening along the route.
But yeah, it's not really plausible for the problem to be isolated to T2 traffic. It could be done intentionally, sure, but it's not traffic that would be treated differently for any standard reasons.
Comparisons to other games would vary... Many new games use systems designed to essentially work as a VPN with traffic relayed through an optimized private backbone network, rather than freely over the public internet. You'd need to measure against a game with similar direct IP UDP traffic to say if it's truly isolated to the packets sent by T2.
Sterio set me up with a Vultr relay for the tourney that acts as a tunnel for my T2 traffic only, using Wireguard.
And when I use the relay, my ping is back to what it was before even though in the T2 in game browser I see no change. But when I join, in game it is as good as before.
That does likely point to the culprit being the routing or some service filtering and throttling the unencrypted UDP traffic for some reason.
With the problem affecting every server though, it'd pretty much have to be either local to your systems or happening at a point every packet has to pass through. This makes the routing explanation a little iffier, but it's always possible your ISP recently pushed a wonky change to their setup.
I had some random ping increases last year that would come and go. I called my ISP and they moved me from a dynamic IP to a static IP and it completely fixed the issue. Could be worth calling your ISP..
In certain cases unusual interpolation settings can advance the other player on your client and cause them to pass through from your perspective, but this pass-through wouldn't be visible to other players, and would usually self-correct on the next physics step. That doesn't appear to be the case here since you kinda do-si-do there for a second, but I wouldn't entirely rule it out without confirmation of what another player saw.
Since player-player collisions try to prevent interpenetration at the bounding box level, passing the point where you would normally collide can essentially allow you to move around inside/through the other player object. It's almost impossible for this to happen in normal circumstances unless collision is momentarily disabled on either object or the server forces one of the objects to move to a new position. One possible explanation for the latter happening could be the server performing some sort of script-level mitigation of deadstopping on flagstands (although... obviously passing through players in that zone wouldn't be ideal for defenders).
I'd definitely be interested to know if this ever happened again, and if it was restricted to the server or map.
Using Crossover I installed the base installer then the preview over top of it. When launching I use the -online argument in the run command prompt. This pops up...
When I close this error the game actually loads and when I go to check the server it says the game is not running the patch 🤔 Odd because the Background is the TribesNext one.
Also generated a massive log file whilst running this but it sits at 1.5Gb so here is the first few lines... if its helpful I can find a way to send the full file. Just let me know.
CrossOver also generated a login of 1.5Gb but not sure if that's helpful to you or not. If you think it is I can find somewhere to upload it. Just let me know.
Anyway, I was super happy to be able to even play just the training guides. It took me back 20 years playing CTF with =Rebels= on Katabatic v2 🙂
Sorry, I didn't realize the spam filter had flagged you, it rarely ever catches false-positive posts at this point and doesn't actively notify that there's something in the queue...
But yes, thank you, that report is exactly what I need to finish verifying the changes to the rendering setup and hopefully have the new version fixed on that platform (although probably having to disable various changes). The 1.5gb log won't be necessary.
If you're still trying to get the current build running I can review the output you have there, but I would note that the rubyintersect stuff is from the much earlier patch versions, and not used any more. There is another old build of that version that was made specifically for some issues on Linux/Mac that can be found on the forums, which might help just get that version running, but it'd be missing any new enhancements.
On some more demo review and talking with other HOFs this is the first we have seen of this interaction. So, probably too rare to replicate/fix but will update if we have more occurrences.
Huh, interesting. That interaction is much slower than I expected, it should've tested collision on each of you against the other at least half a dozen times before you crossed the boundary. I'll have a look at the demo with some physics debug views on later, but it looks far too slow to be your basic precision or interpolation error.
Fast moving objects can technically pass through eachother in extreme scenarios (far more extreme with the patch), but that requires them to be far exceeding the normal limits to happen consistently, since it'd have to be beyond what can reasonably be calculated in the 32ms physics frames. The only times I can remember seeing this happen on slow moving players has been either intentional or the result of various scripts actions on Construction servers back in the day (warping to positions, changing the object scales, spawning inside, mounting/dismounting objects, etc). It's certainly possible there was a oddball physics edge case here, but the server scripts having taken some action that resulted in this would be the easiest explanation.
Comments
The original simulated net params did function in online games, and as such were used to exploit the same flaw timescale changes did: servers would stop simulating a player that stops sending packets. On the client end it was restricted to local listen server connections to mitigate this, though it'd be safe enough to allow it in offline mode in general for testing on dedicated lan servers.
At the time I rewrote the packet delivery logic, the simulated net delay settings were being used for routing through part of the original netcode for testing certain behaviour with both protocols speaking to each other. The round-trip timing is tracked differently on the original code, which is why the ping display breaks down with it being routed, and you also consequently currently only have a delay for packets going in one direction.
Alright I feel silly for saying it wasn't a cheat now even though I suppose I must have suspected it might be a bit sketchy or I wouldn't have mentioned that.
Thanks for the quick reply. Do you care to elaborate on the last sentence please? The delay only going in one direction.
Does it mean, it is no good to practice with offline for the purpose of simulating a higher ping?
For the moment, in the current version you're only applying a delay to packets sent from the client to the listen server. The listen server is still sending you packets every ~32ms regardless, but because listen servers don't communicate with the host over the network, and aren't currently allowing simulating a delay, every server packet is processed by the client instantly. This means for every other object you see moving in a local game, there's zero delay from the server, but... Because the server tries to keep your player object synchronized to moves it receives from you, delaying client input packets can effectively simulate the feel of latency on your own player object: server trigger responses for weapon firing, jetpacks, jumps, etc. will all be visually delayed more or less as expected (but if you were targetting a moving enemy, it may have travelled twice as far as expected before your projectile actually fired on the server).
For testing skiing routes this is probably fine. As you've noticed though using the prefs to apply it, those variables are halved by the host startup script - because the control applies a delay of x milliseconds on any packet sent by a connection object, the script normally tries to apply half the requested delay to the trip back.
Yes it is for running HO routes. Okay this is pretty clear now, good explanation.
Thanks a lot.
Hi, I'm new here and hoping to get up and running on an M4 Max MacBook Pro. Is there anywhere I can find a guide?
I'm willing to spend some time helping @Krash or anyone else get this up and running if I can.
Thanks in advance!
If you check the previous page, there was some discussion on the subject to catch up on, but because there are so few people using them, it's taken some time to get crashlogs/information to narrow down what issue MacBook users are having. Currently, I'd been hoping to hear back on the capabilities the Apple OpenGL driver is reporting (specifically most importantly the supported formats and extensions), as mentioned at the end of this post:
Any idea why my ping to all T2 servers whether they are in the US or Europe could have doubled overnight?
I used to ping 100-105 in the T2 browser tab to Chicago servers, 135-145 in game. Now it is 200 with some rubberbanding to boot. I have tested with my old Vanilla non QoL install, exact same issue. Been playing for almost a year and my ping has been rather stable until yesterday.
The most puzzling part is I don't have this problem at all with other games. Just T2 and last week was just fine.
I spent 3 hours on the phone with my ISP help desk, they ran all sorts of tests. I mean I even talked to a guy that sounded competent. I did reset my router twice, plugged, unplugged everything. People at my ISP say my connection is good, debit is good, my wifi is great too and I have tried messing with my DNS. No Luck.
HALP.
Hmm, well, the game itself fires off raw UDP packets well under the IPv4 MTU, meaning there's no additional overhead or fragmentation of the packets to cause delays or drop packets under modern broadband, and there are no DNS lookups involved in game server connections. Essentially as soon as the packets are created they're out of the game's control, and your OS passes them along to your router/modem.
Barring hitting your bandwidth limits and not having queue priority, or something bizarre like your router's CPU being overloaded, I wouldn't expect anything within your own network to create a delay of more than a few milliseconds.
I'm sure you might know some of this info, but I'll throw it in in case it helps you or others reviewing the latency you might see from the game:
Are the pings higher to all servers, or just the ones you normally playing on? My suspicion for a sudden increase in latency of that magnitude would be that the it's using a new BGP route to reach some servers, maybe one of the hops the traffic passes through started advertising incorrect info or is terribly inefficient... but the specifics in broader ISP network management in that area aren't my field of expertise. Your ISP could work around this if it were confirmed, but you'd probably have to get a case escalated to someone on their end willing to take the time.
You could try running a traceroute to each of the servers impacted, and ask one of the server hosts to run a traceroute to your IP. Maybe fiddle around with a BGP toolkit or looking glass utility. If anything does point to an obvious problem node, you could note it down to present to your ISP's tech.
Otherwise... you could try seeing if you get similar results while using a VPN, if only to confirm that the routing path is the issue. It'd probably still come in a little higher than your "normal" expected ping, but the packets would take a different path across the net, so you could rule out local issues if it's any lower latency than you're getting now.
Yes pings are much higher, roughly twice as high as before, to all T2 servers, US or Europe.
I suspect it is a routing issue like you suggested. But I have re-checked with different games: I am not seeing any ping increase there so it is baffling that it would only affect T2 traffic.
I will try to get a VPN to see if I am seeing the same behavior. I have a scheduled call with a tech next week.
Thanks for the help. Much appreciated.
"You could try running a traceroute to each of the servers impacted, and ask one of the server hosts to run a traceroute to your IP."
I've the feeling you will find the lag increase with this method and it'll be out of your or your isp control.
A traceroute will not affect your latency in any way, it'll just try to account for where the packet is passing through and how long it takes to get to each stop and back. It won't work in every case, since not all hosts will respond to the diagnostic packets, but it can be very useful to dig into what's happening along the route.
But yeah, it's not really plausible for the problem to be isolated to T2 traffic. It could be done intentionally, sure, but it's not traffic that would be treated differently for any standard reasons.
Comparisons to other games would vary... Many new games use systems designed to essentially work as a VPN with traffic relayed through an optimized private backbone network, rather than freely over the public internet. You'd need to measure against a game with similar direct IP UDP traffic to say if it's truly isolated to the packets sent by T2.
update:
Sterio set me up with a Vultr relay for the tourney that acts as a tunnel for my T2 traffic only, using Wireguard.
And when I use the relay, my ping is back to what it was before even though in the T2 in game browser I see no change. But when I join, in game it is as good as before.
That does likely point to the culprit being the routing or some service filtering and throttling the unencrypted UDP traffic for some reason.
With the problem affecting every server though, it'd pretty much have to be either local to your systems or happening at a point every packet has to pass through. This makes the routing explanation a little iffier, but it's always possible your ISP recently pushed a wonky change to their setup.
I had some random ping increases last year that would come and go. I called my ISP and they moved me from a dynamic IP to a static IP and it completely fixed the issue. Could be worth calling your ISP..
Thanks for the tip.
Hi Krash,
Had a player model clipping interaction on the flag stand the other night. Was wondering if you were aware or what might be the cause.
https://youtu.be/8APicKXXAoA
Thanks,
wing
In certain cases unusual interpolation settings can advance the other player on your client and cause them to pass through from your perspective, but this pass-through wouldn't be visible to other players, and would usually self-correct on the next physics step. That doesn't appear to be the case here since you kinda do-si-do there for a second, but I wouldn't entirely rule it out without confirmation of what another player saw.
Since player-player collisions try to prevent interpenetration at the bounding box level, passing the point where you would normally collide can essentially allow you to move around inside/through the other player object. It's almost impossible for this to happen in normal circumstances unless collision is momentarily disabled on either object or the server forces one of the objects to move to a new position. One possible explanation for the latter happening could be the server performing some sort of script-level mitigation of deadstopping on flagstands (although... obviously passing through players in that zone wouldn't be ideal for defenders).
I'd definitely be interested to know if this ever happened again, and if it was restricted to the server or map.
OK Thanks I've made some progress.
Using Crossover I installed the base installer then the preview over top of it. When launching I use the -online argument in the run command prompt. This pops up...
When I close this error the game actually loads and when I go to check the server it says the game is not running the patch 🤔 Odd because the Background is the TribesNext one.
Also generated a massive log file whilst running this but it sits at 1.5Gb so here is the first few lines... if its helpful I can find a way to send the full file. Just let me know.
`Running launcher: Tribes2 (StartMenu.C^3A_users_crossover_AppData_Roaming_Microsoft_Windows_Start+Menu/Tribes2.lnk)
Command-line options: -online
Bottle: Tribes
Debug channels: +relay,+d3d
Extra environment variables: VKD3D_DEBUG=trace VKD3D_SHADER_DEBUG=trace MVK_CONFIG_LOG_LEVEL=4
Bottle:
Name: Tribes
Template: win7_64
Windows Version: win7
Managed: False
Arch: win64
Graphics: D3DMetal
Vulkan: MoltenVK
DLSS: Enabled
High resolution mode: Disabled
MSync: Disabled
Preview: Unavailable
Product:
CrossOver
Version:
26.3.0
Install location:
/Applications/CrossOver.app/Contents/SharedSupport/CrossOver
Bitness:
64-bit
Desktop session:
Locale:
Locale:
LC_CTYPE: en_US.UTF-8
System Information:
Chipset Model: Apple M4 Max
Type: GPU
Bus: Built-In
Total Number of Cores: 14 (10 Performance and 4 Efficiency)
Vendor: Apple (0x106b)
Metal Support: Metal 4
Display Type: Built-in Liquid Retina XDR Display
Resolution: 3024 x 1964 Retina
Main Display: Yes
Mirror: Off
Online: Yes
Automatically Adjust Brightness: Yes
Connection Type: Internal
Model Name: MacBook Pro
Model Identifier: Mac16,6
Model Number: FX2G3B/A
Chip: Apple M4 Max
Memory: 36 GB
System Firmware Version: 18000.161.10
OS Loader Version: 18000.161.10
System Version: macOS 26.6.2 (25G83)
Kernel Version: Darwin 25.6.0
Time since boot: 43 days, 10 hours
Warnings:
Properties:
Libraries:
CXConfig->read(/Applications/CrossOver.app/Contents/SharedSupport/CrossOver/etc/CrossOver.conf)
674: Grabbing the '/var/folders/_h/bz4ccx0x36d5nmhdfj6yrl200000gn/T//.wine-501/bottle-100000d-2090775.lock' lock
674: Got the '/var/folders/_h/bz4ccx0x36d5nmhdfj6yrl200000gn/T//.wine-501/bottle-100000d-2090775.lock' lock
CXConfig->read(/Users/user/Library/Application Support/CrossOver/Bottles/Tribes/cxbottle.conf)
674: Releasing the '/var/folders/_h/bz4ccx0x36d5nmhdfj6yrl200000gn/T//.wine-501/bottle-100000d-2090775.lock' lock
Bottle environment variables:
CX_GRAPHICS_BACKEND -> d3dmetal
D3DM_ENABLE_METALFX -> 1
DXMT_ENABLE_NVEXT -> 1
CXRWConfig->new(/Users/user/Library/Application Support/CrossOver/Bottles/Tribes/cxmenu.conf)
'/Users/user/Library/Application Support/CrossOver/Bottles/Tribes/cxmenu.conf' not modified -> no need to save
Starting 'StartMenu.C^3A_users_crossover_AppData_Roaming_Microsoft_Windows_Start+Menu/Tribes2.lnk'
system encoding='UTF-8'
Exec-ing '"/Applications/CrossOver.app/Contents/SharedSupport/CrossOver/bin/wine" --bottle "Tribes" --check --wait-children --start "C:/users/crossover/AppData/Roaming/Microsoft/Windows/Start Menu/Tribes2.lnk" --cx-log - --debugmsg +relay,+d3d --env "VKD3D_DEBUG=trace VKD3D_SHADER_DEBUG=trace MVK_CONFIG_LOG_LEVEL=4" -online'
3751191.972:0020:0024:trace:process:NtCreateUserProcess L"\\??\\C:\\windows\\system32\\wineboot.exe" image L"C:\\windows\\system32\\wineboot.exe" cmdline L"\"C:\\windows\\system32\\wineboot.exe\" --init" parent 0x0 machine 0
3751191.974:0020:0024:trace:process:send_to_cx_loader wineserversocket 7 stdin_fd -1 stdout_fd -1 unixdir (null) winedebug "WINEDEBUG=+timestamp,+pid,+seh,+unwind,+process,+module,+loaddll,+threadname,+relay,+d3d"
3751191.974:0020:0024:trace:process:send_to_cx_loader CX_ALT_LOADER_SOCKET is not set; nothing to do
3751191.997:0028:002c:trace:module:get_load_order got hardcoded default for L"\\??\\C:\\windows\\system32\\wineboot.exe"
3751191.997:0028:002c:trace:module:get_load_order got hardcoded default for L"\\??\\C:\\windows\\system32\\wineboot.exe"
3751191.997:0028:002c:trace:module:find_builtin_dll looking for "wineboot.exe" for file L"\\??\\C:\\windows\\system32\\wineboot.exe"
3751191.997:0028:002c:trace:module:map_image_into_view mapping PE file L"\\??\\C:\\windows\\system32\\wineboot.exe" at 0x140000000-0x14002a000
3751191.997:0028:002c:trace:module:map_image_into_view mapping L"\\??\\C:\\windows\\system32\\wineboot.exe" section .text at 0x140001000 off 400 size 7c00 virt 7ad0 flags 60000060
3751191.997:0028:002c:trace:module:map_image_into_view clearing 0x140008c00 - 0x140009000
3751191.997:0028:002c:trace:module:map_image_into_view mapping L"\\??\\C:\\windows\\system32\\wineboot.exe" section .data at 0x140009000 off 8000 size 600 virt 550 flags c0000040
3751191.997:0028:002c:trace:module:map_image_into_view clearing 0x140009600 - 0x14000a000
3751191.997:0028:002c:trace:module:map_image_into_view mapping L"\\??\\C:\\windows\\system32\\wineboot.exe" section .rdata at 0x14000a000 off 8600 size 11e00 virt 11d00 flags 40000040
3751191.997:0028:002c:trace:module:map_image_into_view clearing 0x14001be00 - 0x14001c000
3751191.997:0028:002c:trace:module:map_image_into_view mapping L"\\??\\C:\\windows\\system32\\wineboot.exe" section .pdata at 0x14001c000 off 1a400 size 400 virt 2c4 flags 40000040
3751191.997:0028:002c:trace:module:map_image_into_view clearing 0x14001c400 - 0x14001d000
3751191.997:0028:002c:trace:module:map_image_into_view mapping L"\\??\\C:\\windows\\system32\\wineboot.exe" section .xdata at 0x14001d000 off 1a800 size 400 virt 2f8 flags 40000040
3751191.997:0028:002c:trace:module:map_image_into_view clearing 0x14001d400 - 0x14001e000
3751191.997:0028:002c:trace:module:map_image_into_view mapping L"\\??\\C:\\windows\\system32\\wineboot.exe" section .bss at 0x14001e000 off 0 size 0 virt 5c0 flags c0000080
3751191.997:0028:002c:trace:module:map_image_into_view mapping L"\\??\\C:\\windows\\system32\\wineboot.exe" section .idata at 0x14001f000 off 1ac00 size 1600 virt 148c flags c0000040
3751191.997:0028:002c:trace:module:map_image_into_view clearing 0x140020600 - 0x140021000
3751191.997:0028:002c:trace:module:map_image_into_view mapping L"\\??\\C:\\windows\\system32\\wineboot.exe" section .rsrc at 0x140021000 off 1c200 size 8000 virt 7ee0 flags 40000040
3751191.997:0028:002c:trace:module:map_image_into_view mapping L"\\??\\C:\\windows\\system32\\wineboot.exe" section .reloc at 0x140029000 off 24200 size 200 virt 80 flags 42000040
3751191.997:0028:002c:trace:module:map_image_into_view clearing 0x140029200 - 0x14002a000
3751191.999:0028:002c:trace:module:map_image_into_view mapping PE file L"\\??\\C:\\windows\\system32\\ntdll.dll" at 0x6ffffff40000-0x6ffffffee000
3751191.999:0028:002c:trace:module:map_image_into_view mapping L"\\??\\C:\\windows\\system32\\ntdll.dll" section .text at 0x6ffffff41000 off 400 size 72000 virt 71eb0 flags 60000020
3751191.999:0028:002c:trace:module:map_image_into_view mapping L"\\??\\C:\\windows\\system32\\ntdll.dll" section .data at 0x6ffffffb3000 off 72400 size e00 virt d30 flags c0000040
3751191.999:0028:002c:trace:module:map_image_into_view clearing 0x6ffffffb3e00 - 0x6ffffffb4000
3751191.999:0028:002c:trace:module:map_image_into_view mapping L"\\??\\C:\\windows\\system32\\ntdll.dll" section .rdata at 0x6ffffffb4000 off 73200 size 17e00 virt 17d40 flags 40000040
3751191.999:0028:002c:trace:module:map_image_into_view clearing 0x6ffffffcbe00 - 0x6ffffffcc000
3751191.999:0028:002c:trace:module:map_image_into_view mapping L"\\??\\C:\\windows\\system32\\ntdll.dll" section /4 at 0x6ffffffcc000 off 8b000 size 800 virt 798 flags 40000040
3751191.999:0028:002c:trace:module:map_image_into_view clearing 0x6ffffffcc800 - 0x6ffffffcd000
`
Ok I've made some progress.
I installed the base installer then the preview on top using CrossOver and a Windows 7 bottle.
When launching the game I run with the -online argument as a command line option.
I get the rubyintersect.dll error and the report is attached here too.
I also installed the glCapsViewer and uploaded that to the database which can be found here if it's helpful?
https://opengl.gpuinfo.org/displayreport.php?id=17587
CrossOver also generated a login of 1.5Gb but not sure if that's helpful to you or not. If you think it is I can find somewhere to upload it. Just let me know.
Anyway, I was super happy to be able to even play just the training guides. It took me back 20 years playing CTF with =Rebels= on Katabatic v2 🙂
Hope this helps!
Sorry, I didn't realize the spam filter had flagged you, it rarely ever catches false-positive posts at this point and doesn't actively notify that there's something in the queue...
But yes, thank you, that report is exactly what I need to finish verifying the changes to the rendering setup and hopefully have the new version fixed on that platform (although probably having to disable various changes). The 1.5gb log won't be necessary.
If you're still trying to get the current build running I can review the output you have there, but I would note that the rubyintersect stuff is from the much earlier patch versions, and not used any more. There is another old build of that version that was made specifically for some issues on Linux/Mac that can be found on the forums, which might help just get that version running, but it'd be missing any new enhancements.
Confirmed that sweetcheeks saw it on her side as that's why she tried to walk through me again.
Demo:
Load this into exogen's mapgenius (have you seen this tool?!), event occurs at 29:12 gametime.
Also posting the view through mapgenius here
Update:
On some more demo review and talking with other HOFs this is the first we have seen of this interaction. So, probably too rare to replicate/fix but will update if we have more occurrences.
Huh, interesting. That interaction is much slower than I expected, it should've tested collision on each of you against the other at least half a dozen times before you crossed the boundary. I'll have a look at the demo with some physics debug views on later, but it looks far too slow to be your basic precision or interpolation error.
Fast moving objects can technically pass through eachother in extreme scenarios (far more extreme with the patch), but that requires them to be far exceeding the normal limits to happen consistently, since it'd have to be beyond what can reasonably be calculated in the 32ms physics frames. The only times I can remember seeing this happen on slow moving players has been either intentional or the result of various scripts actions on Construction servers back in the day (warping to positions, changing the object scales, spawning inside, mounting/dismounting objects, etc). It's certainly possible there was a oddball physics edge case here, but the server scripts having taken some action that resulted in this would be the easiest explanation.