EvilTurtleProductions

Yes, we are aware. That's why I said that Steam has issues installing it Setting the redists for the game was one of the first things we did. This problem seems to have been plaguing many commercial games already and it doesn't seem it's gonna change anytime soon. Hence my post about it, because I'm sure more people might run into this.

Yeah from what I've seen it doesn't always fail. It seems things start breaking when people uninstall OpenAL themselves and then at a later date install a Steam game that has OpenAL as a dependency. Somehow Steam doesn't start the installation process. Judging by the many, many forum posts for other games this is a very common issue. Some bigger titles too.

So... We found out the hard way that Steam has issues with installing OpenAL (45% refund rate oof). If OpenAL isn't installed the game simply doesn't start, without any error messages... To Josh: is it possible to make it so the engine/game gives an error message if OpenAL fails to initialize or if the DLL isn't found? If you intend to publish your LeadWerks game on Steam I highly recommend creating a custom installation script for OpenAL. I did this by including the OpenAL installer in the game folder and writing the following SteamWorks InstallScript: "InstallScript" { "Run Process" { "2.0.7.0" { "HasRunKey" "HKEY_CURRENT_USER\\SOFTWARE\\Valve\\Steam\\Apps\\YOUR_DEPOT_NUMBER_HERE" "process 1" "%INSTALLDIR%\\oalinst.exe" "command 1" "/s" "NoCleanUp" "1" } } } Don't forget to add the InstallScript to your BuildScript too, keep in mind that the paths may be different for you depending on how you have your SteamWorks build process setup: "FileMapping" { // copy install script into depot root folder "LocalPath" "..\\openalinstall.vdf" "DepotPath" "." } "InstallScript" "..\\openalinstall.vdf" For more information on this check: https://partner.steamgames.com/doc/sdk/installscripts https://partner.steamgames.com/doc/sdk/installscripts#build

Valve has given the go-ahead, so the game's now scheduled to release June 1st 2022!

Awesome! I'll definitely get more active with helping to find and figure out bugs, knowing this. I'm so happy to hear this is actually happening now For example: there's that bug in the editor which breaks the camera and debugging and lately I've been noticing that when updating model files (had to fix an UV map) and thus an hierarchy change (because I always collapse things) causes some things to break in the editor and I had that bug come back too in that moment. I'll make a proper report thread on the forum on that once I've figured it out fully though, as I'm not able to replicate it properly yet. Right now I'm going to experiment with setting the Sources to zero range and see how that goes

I see! I had an vague hunch it was something to do with stereo sounds and spatialization, thank you so much for diving into this! I guess my only option is to use mono sounds with clever Source placement. using Sound->Play() is not an option because it has no volume controls. Unless there's another way to control volume for Sound? You mentioned a "range greater than zero". Would setting the Source range to zero help, or would that rather exacerbate the problem? If you're still planning to do that last LeadWerks update, maybe then...? heehee

Good luck with the release and 'fest Always a very exciting and stressful period

Right, I forgot I switched to Sources, which mostly solved the problems. Mostly though, still have sounds cutting out every now and again and it does get worse after playing a few levels, see below too. To replicate my issue: In actor_player.cpp there's this bit: footsteps->SetSound(sounds[stepsoundind]); footsteps->SetPosition(this->entity->GetPosition()); footsteps->Play(); Comment that out and add: this->entity->EmitSound(sounds[stepsoundind], 10.f, vol_fx); Sources should now increment as you walk around and eventually cause sound issues. As for the Releasing of things: The reason I release stuff in all Detach() calls is because I never switch worlds, so world delete never gets called during gameplay. Level generation is all procedural. If you go out the door, walk upstairs and to the left there should be two screens and a couple of big 'ol buttons: If you press the ACCEPT button (green, highlighted in the image) it should load up a level, which increases the Sources list because a couple are created in various bits of level code. When you press ACCEPT again you end the mission. ACCEPT again to get a new selection of missions and ACCEPT yet again to do a mission. You should see things stack up and sounds should start cutting out when you walk through the level.

GameMaker has something what I think might be a good middle-ground (maybe?), seeing as how subscription is often frowned upon especially by Indies: You can use the tools for free, but if you want to use the publishing tools to build/publish you pay a subscription. This means you don't constantly have to pay while experimenting and means you can explore the toolset to see if it works for you without a paywall. When you actually seriously start doing stuff you pay a monthly fee for as long you need the compiling/publishing tools. This allows new devs to get their feet wet, seeing as how you try to cater to new devs and Indies this might be an idea. Not sure if it'd be profitable though. Definitely an issue that could keep you awake, I imagine. Also: very happy to hear you are (possibly?) going to do a final update for LeadWerks, it desperately needs it I'd be more than willing to help out with that, since I do have quite a few (minor) things that need that last final touchup , and I've been trying to figure out what causes these bugs since I encounter them quite a few times during development

I'll PM you a link with the project, thanks

I'm well aware of Source, it's what I mostly use for sounds that play often/constantly i.e. the breathing sounds in the code I posted earlier. I release any created Sources or Sounds that haven't been released yet in the Detach() method and this seems to work for the most part. The issues is that sounds/Sources are not being released properly when using EmitSound() (and possibly Source too), causing the amount Sources to build up which causes sounds to cut off or not play. I'm revising bits of code to use Source as much as possible and this has helped a little. EmitSound() is a lot more convenient though... From what I've gathered mono sounds aren't generally causing this issue, though as mentioned before overlapping sounds on the same entity can cause problems. Stereo sounds seem to be the biggest culprit, such as the footsteps I've been experimenting with. I'm now using a Source for the the stereo footsteps as well as player hurt sounds (also stereo) and I don't see the Sources list increment bug now, which surprised me. I'm going to experiment with this further. Perhaps EmitSound() is just buggy when it comes to stereo sounds and should be avoided for those? Another interesting observation: when playing a stereo sound using either EmitSound() or a Source() while the Listener is outside of the sound range the sound doesn't play at all. Seems there's still some spatialization going on despite it not being used? Is there actually a specific way to properly play stereo sounds, with volume control, in LeadWerks? It's not an huge issue as long as you make sure the Listener is always in the sound's range, but it all seems a bit odd

That's the thing though, there's quite a few non-spatial sounds in the game (such as the footsteps) but Sound::Play() has no control over volume etc. Unless there's some way to route sounds to dedicated buses that can have their volume set I'm stuck with Source and EmitSound(), because I want players to be able to set the volume of things like sound effects, voices and music. Also I discovered just now Sound::Play() also has the same issue now with the sources list increasing, I'm very confused haha Gotta delve some more I guess.

Okay another observation: just playing one sound with EmitSound() doesn't increment the sources list size. So it seems playing different (overlapping) sounds on the same entity breaks things? This seems to coincide with what I observed on the reactor core entity in the game too. EDIT: no, sorry I'm being an idiot, I accidentally set it to the flashlight sound, which doesn't have the issue.

As a test I commented out every single line with EmitSound() and Source's Play() methods so not a single sound would play. As expected the amount of sources (sources.size()) stays at 21 (I didn't disable the Source creation code, also 21 seems a bit much?). If I uncomment the EmitSound() line in the above footstep sounds code then again the sources start at 21, but as soon as I start walking around it increments with each footstep i.e. the behavior as described in my post.

I'll cut it up to the bits related to sound, it's a bit much otherwise. Most of the code is very similar to the standard FPSplayer LUA script anyways, albeit C++ Here's where the sounds are loaded in and Sources are setup: //sounds sounds[0] = Sound::Load("Sound/Player/flashlight_02_on.wav"); sounds[1] = nullptr; //TODO use a sound here, suit noises loop? sounds[2] = Sound::Load("Sound/Footsteps/Astronaut/step1.wav"); sounds[3] = Sound::Load("Sound/Footsteps/Astronaut/step2.wav"); sounds[4] = Sound::Load("Sound/Footsteps/Astronaut/step3.wav"); sounds[5] = Sound::Load("Sound/Footsteps/Astronaut/step4.wav"); sounds[6] = Sound::Load("Sound/Footsteps/Astronaut/step5.wav"); sounds[7] = Sound::Load("Sound/Footsteps/Astronaut/step6.wav"); sounds[8] = Sound::Load("Sound/Player/deathfx1.wav"); sounds[9] = Sound::Load("Sound/Player/deathfx1.wav"); //TODO more death sounds sounds[10] = Sound::Load("Sound/Player/deathfx1.wav"); //TODO more death sounds sounds[11] = Sound::Load("Sound/Player/deathfx1.wav"); //TODO more death sounds sounds[12] = Sound::Load("Sound/Player/breathing_normal.wav"); sounds[13] = Sound::Load("Sound/Player/breathing_panting.wav"); sounds[14] = Sound::Load("Sound/Player/breathing_cooldown.wav"); sounds[15] = Sound::Load("Sound/Player/breathing_asphyx.wav"); sounds[16] = Sound::Load("Sound/Player/grunt1.wav"); //sources Sound* airhisssnd = Sound::Load("Sound/Player/airhiss.wav"); airhiss = Source::Create(); airhiss->SetSound(airhisssnd); airhisssnd->Release(); airhiss->SetLoopMode(true); airhiss->SetVolume(0.5f * vol_fx); airhiss->Play(); breathingA = Source::Create(); breathingA->SetSound(sounds[12]); breathingA->SetLoopMode(true); breathingA->SetVolume(1.f * vol_fx); breathingA->Play(); breathingB = Source::Create(); breathingB->SetSound(sounds[13]); breathingB->SetLoopMode(true); breathingB->SetVolume(0.f * vol_fx); breathingB->Play(); breathingmode = BREATHING_CALM; breathingblend = 1.f; //tutorial tutorialVO = Source::Create(); tutorialVO->SetVolume(vol_vo); tutorialVO->SetLoopMode(false); tutorialmode = false; The footstep sounds in UpdatePhysics call, 'vol_fx' is the volume setting value for sound effects: //footstep sounds if (inputx != 0.f || inputz != 0.f) { Vec3 speed = this->entity->GetVelocity(); steptiming += speed.Length(); if (steptiming > 150.f) { steptiming = 0.f; stepsoundind++; if (stepsoundind > 7) stepsoundind = 2; this->entity->EmitSound(sounds[stepsoundind], 10.f, vol_fx); } }

I've been having issues with the audio in our game Disinfection lately. Sounds cut off or don't play at all. I've also been seeing some crashes with an OpenAL AL_INVALID_VALUE error in the log. I've been trying to figure out why, here's some of my observations: I'm not sure if these are the right values to check but this is how I've been keeping track of the channels and sources available/in use: System::Print("MAX available sound channels: " + std::to_string(listener->sounddriver->GetMaxChannels())); System::Print("Sound channels in use: " + std::to_string(listener->sounddriver->sources.size())); I also checked 'usedchannels' in the Sounddriver object which gave similar results as the size of the sources list. I noticed when using sounds with EmitSound() that the size of 'sources' keeps increasing every time I call EmitSound(), if the sounds overlap. For example: I use 6 different stereo sounds for the player footsteps and the size of 'sources' keeps going up, eventually reaching very high values like 400+. I noticed that crashes often happen at this point too. At first I thought this was an issue with stereo sounds because when I accidentally set the footsteps sound to the (mono) flashlight sound, which is much shorter, the issue was gone. I then tried using the footstep sounds in mono but the issue was back, because the sounds overlap again. Another time when I noticed this when the monster entity had a bug where it would do a certain action in quick succession, also producing the same sound in quick succession causing sounds to overlap and the list to increase in size rapidly. I then started noticing the same issue with other sounds in the game too. For example there's a Fusion Reactor in the game which produces various sounds (a mono looping hum sound and mono start/stop sounds). However this Entity is using a Source for the looping sound and a Source for the start/stop sounds. Again when sounds overlap the 'sources' list keeps growing. The bigger 'sources' grow the more things start cutting off or not playing at all. I'm not entirely sure the OpenAL crashes are directly linked to it, but they did start happening recently too. I've started using EmitSound() and Source a lot more, since I implemented volume settings in the game. I was simply using Sound->Play(); for a lot of sounds, but it doesn't have volume control so I switched to EmitSound() mostly and that's when this issue started becoming apparent. The volume settings are saved as System property values and fetched in various parts of the code where needed. Any ideas on what I could be doing wrong or if this is a known bug or something?

Here's some screens from a recent testing session:

Aw thank you. And hey everyone is different, everyone has their weaknesses... and more importantly: their strengths Play on yours

I've been experimenting with the lighting and GI probe shaders and done some minor tweaks that have had a huge impact for the visuals. Especially metal surfaces look a lot more... metal. The specular reflection intensity and size is now more correct to the surface roughness and metallic values. GI probe reflections are more balanced too now. Been working hard on the new lobby map too, since it's the place players will meet up and accept missions. Loads of new models in place and I also updated the mission- and player screens to make them much more clear and comprehensive. CRT screen shader has reflections now too

Oh yes Blender is quite overwhelming. I am planning to make a tutorial post here on the LW forums in which I will detail my workflow and how to make PBR-textures in Blender with the plugin as well as texture packing in Materialize. Don't expect that anytime soon though, I am incredibly busy with the game atm haha

it's a combination of vertex-shader mesh deform and using the render buffer that's available for z-buffered materials. In Blender I made a simple plane, subdivided to 8k vertices, which I exported to the game. I then made another copy of the plane that has a very high amount of vertices, I use this plane to sculpt whatever shape I like (in this case that claw). Since the UV map for both planes is the same (Blender automatically interpolates when subdividing) I can simply bake the vertex positions to a small texture (I used 128x128 in above screenshots) which is then used by the vertex-shader to offset the plane's vertices into the shape of the thing I sculpted. The reason I use a plane is because I want to fetch the screen fragments whatever is behind the plane and draw these fragments onto the plane itself, using the UV coordinates of the plane. When the plane is undeformed you see no difference, but as soon as the plane deforms the fragments deform with it et voila you have yourself something creepy growing out of the walls, ceiling etc Only drawback is that this is a screen-space effect, so much like SSR it has a visual glitch/needs a fadeout at screen edges. Another drawback is the lack of shading, since the material needs to be drawn last and thus z-buffered needs to be checked. Given the creepy nature of the effect this isn't a big issue, though I'm open to suggestions on alternatives

Yes. I was planning this for lights that are completely off. Thanks.

Big dumb moment there. I was staring at the wrong problem, haha, thanks. I implemented a different solution than the while loop though, since not all children might be lights. Instead I use a vector that I fill with all the lights, then loop through this vector to re-parent the lights.

Thank you so much 😄 I use Wings3D for the modelling, Blender with the PBR Painter 2 plugin for the textures and animations. Can highly recommend that by the way, it's made things ten times easier and faster. I've heavily customized the original PBR shader in LeadWerks to better implement PBR and to implement texture packing so metallic, roughness, AO (baked in Blender), emission, height and extra data such as a texture for the infection effects is contained in just 2 textures. Albedo and normal maps are 2 more textures, for 4 textures in total. It's not perfect yet, but getting there

https://store.steampowered.com/app/1921130/Disinfection/ Our game is gonna release by the end of the month (if all goes well), on Early Access. Made in LeadWerks 4.6 with loads of customization