hi
gamedev rambling again
so I took a break from animations to work on more bevy_trenchbroom stuff. I tried in vain to get the Valve SDKs working on Linux and wow they are crashy in Proton and switching to the native Linux build in Steam just removes all the executables entirely. I was hoping to peek at some sample singleplayer maps and see generally how the interactivity was done, but it turns out that was gonna be a lot harder than I expected. I still have a Windows install on this computer but it didn't seem terribly worth it.
There is a map decompiler that converts BSPs into maps for HL1 that I considered using but I determined it was entirely too much work to get files that would be different than the source, since the BSP compilation process can add/remove vertices and wouldn't match up 1:1 with the original intent. + the experience with Hammer Source on linux and it just didn't seem worth it to me.
I ended up watching some tutorials on making HL maps which filled the gap instead - watching someone use a trigger_once or a func_breakable and seeing the parameters gave me a lot of ideas for how one could code an implementation of those using Bevy+bevy_trenchbroom+bevy_rapier3d as a learning exercise.
I was able to get triggers working pretty easily (using the new relationship structure for linking Entities and then pushing events that can be observed by any entity that responds to triggers and can run custom code) but I had to override bevy_trenchbroom's built-in DynamicLight classes in order to make them able to be toggleable (ie. turn light off on a trigger, etc.), so now my game config has a light_point2, light_spot2, and light_directional2 which stinks but I couldn't find a way around that. Of course, I'm not compiling to BSP which likely would have made this a lot harder as there's some hardcoded weirdness inside BSP files apparently.
Getting doors working was surprisingly difficult as the complexity is high, and I don't quite have it yet, but in general it turns out that according to https://twhl.info/wiki/page/func_door the movement uses the bounding box of the func_door entity for calculating how much to move the door etc. Doing that in Bevy was a bit complicated, as there are two ways I could hook into spawning (bevy_trenchbroom has spawn_hooks, and there's component hooks native to Bevy), and neither of them had access to both the Transform and the Aabb component by the time they ran, so I ended up adding a FixedUpdate system that would just do the calculations once everything was fully spawned and the spawn hooks got simplified:
fn setup_func_door(
mut q_doors: Query<
(
Entity,
&FuncDoor,
&mut Transform,
&Children,
Has<TargetedBy>,
),
Without<MovingBrush>,
>,
mut q_brushes: Query<(&Aabb)>,
tb_server: Res<TrenchBroomServer>,
mut commands: Commands,
) {
// ...
// Calculate the full bounding box of all brushes
let (mut min, mut max) = (Vec3A::INFINITY, Vec3A::NEG_INFINITY);
for e_child in children {
if let Ok(aabb) = q_brushes.get(*e_child) {
min = aabb.min().min(min);
max = aabb.max().max(max);
};
}
// ...
}
There's also a lot of complexity in functionality for func_door that surprised me! A door can open when you bump into it, or it can have a flag to make it InteractOnly, or if it has a targetname it won't do either of those and will instead wait for a trigger to trigger it. It's quite a diverse set of code paths for one thing and its been really fascinating to try and get it working, but I'm not there yet.
I discovered some fun(tm) things about baldur's gate 3 lately on linux.
if you're using a CPU that needs core parking (like a CPU with P/E cores, or an X3D chip with more than one CCD) AND using
gamemoderunto run the game, the audio in the game won't work. The solution is not to usegamemoderun(or disable core parking in its ini file), as the game will do its own core parking and if you're doing it it'll crash trying to spawn audio threads. Apparently this affects Windows users using Process Lasso as well!If you love Wayland and want to get on the XWayland-free gravy train, you might know that using GE-Proton gives you new env vars you can use
PROTON_ENABLE_WAYLAND=1(No XWayland needed! For me this means more stable VRR, better Alt-Tab support, etc.) and evenPROTON_ENABLE_HDR=1(HDR without Gamescope! Works only on some games, apparently not on Vulkan-native games yet). I lost several hours tonight to this trying to play the damn game over the Internet with a friend and suffering from what appeared to be network issues - my character would rubber-band, it would take seconds and multiple clicks to activate an ability, there'd be huge delays in any action I'd take. Even though my framerate was a smooth 170 or w/e the entire time! No stuttering! Nope, it wasPROTON_ENABLE_WAYLAND. Removing that fixed it. Why does running in Wayland directly cause this game to act like its running over a 56k modem (only when connected to another player)? I don't know, why does parking cores kill audio?? I hear this is an issue on Windows too, or was at some point, if you had VSync off.I suffered. Maybe you won't have to.