I have been digging through VehicleGame project for a few hours and now I am starting to notice that parts of the code are not even in use and can be fully removed. Clearly it looks like it is created by experienced engine programmer as there used quite complicated things for so simple game. There is custom audio node and some RPM cache update on audio thread and two visual effects systems. One is not even used and whole thing with custom audio node and audio thread is not used at all as it is replaced by one “set audio param” node in blueprints.
I think it should be priority to keep it updated because people use these to learn and understand how things work and this can be pretty confusing when example project is outdated and there is mixed old and new stuff, especially advanced things like threading, custom audio nodes, physics and so on.
Hi SkyLonxe.
I strongly believe, documentation is not a UE4´s priority. It has been the same way for months and probably years. I come back from time to time to the engine, just too see if i can learn it, but i always find the same outdated documentation I will tell you what they say : “We will look into that”, and will never happen.
If you ask for updated documentation they say more or less the same, “We will improve it” or “you can learn looking into example projects”, really hard to learn that way but well, i think they dont care about c++ starters(in the API, not the language).
Yes, I understand. Lucky, I passed that initial learning curve years ago, so I am fairly experienced, as I am working with unreal for years but I am at point at which I am seeking for good pratices and patters. I thought Epic’s project will be great example and show me some new and interesting stuff about organization and optimization but I ended up confused. After hour of reading I noticed that some classes are not even used in project and half of things were just overcomplicated or deprecated. Epic’s projects should mirror “best solution” for every version of Unreal.
With the new audio engine coming online, we’re looking at ways we can spruce up old sample projects with new example implementations both to show off new capabilities but also have some good sample projects showing non-trivial audio implementation strategies. Vehicle Game is on our radar, as are a number of other sample projects.
As for how things get to their state with sample projects, Epic is doing a lot of new features all the time and sometimes a new feature will break existing sample projects. Instead of delaying the feature, or shipping with broken/crashing sample projects, a programmer will simply go back and make the sample project “work” (i.e. not crash). Then, we’ll create a backlog task to re-do the content. Unfortunately, this involves dealing with the schedule of content creators, who are very likely working on other higher-priority tasks to ship games. Epic is currently working a large number of games (Paragon, Fortnite, Unreal Tournament, etc) and our audio team is quite small. We recently hired a new technical sound designer (Dan Reynolds), who will have as one of his primary focuses audio community support, which means better documentation, tutorials, blogs, and sample content.
In this case, I believe what happened is the new audio thread feature (came out about a year ago) resulted in a crash with the custom sound cue node created in vehicle game since it was doing very not-thread-safe things (getting game thread data directly into a sound cue node rather than go through the normal route). So, rather than totally redo the content (as mentioned above), we opted to simply fix the threading issue so vehicle game wouldn’t crash.
Awesome, that sums it up pretty much :). Would be awesome to have last paragraph as a comment right in vehicle game, near disabled audio stuff. Thank you very much for getting to us.
I will tell you what they say : “We will look into that”, and will never happen.