changelog for a new build lists technical updates, bugfixes etc. in a very short form - ok, thats common in software engineering. some of them are more or less self explanatory, others need a lot of time to understand how they will work and which are the restrictions etc. beta testers (we) invest sometime a lot of time that the update does NOT work like we had understood from the changelog... This leads normaly into a long "conversation" in an forum thread (best examples: "Build 118 Released") I work years in teaching engineers. I had to explain how they can use a computer system to do their daily work. To make information useful and easy to understand how this may touch your work/your behaviour lets do an example: A simples statement as "More UI stuff for RealRoad loading/saving" can be transformed in some informations -how "the state of the road can be saved during practice, qualify and race session". -that we can save several states with different names in files -that we can determine a state/file to be loaded at sessions start -that rFactor2 save the state automatically (when??) ..... See what I mean ?? I think ISI should find someone, who looks after this kind of "transformation" to explain the information given in changelogs. Someone should accompany the software development with the "eyes of the user" and write it down. At least it is necessary to produce an comprehensive manual.
I think its clear that they do not care for such details now. I hope they will, though. We are in dark basically from day 1. What works, what not, no body knows. There is 4 page thread with arguing and experimentation if tires wearing off or not, and no body knows for sure...
That's right. There is no massive documentation. The things we really need checked each time, everyone can check.
