They are undocumented IMO unforgivable. Were they not specked during design? Best practice would be document during design and programming (detailed comments in the xml would do the trick and could be summarized in a readme file). I do understand that are some language issues with Wasteland which make this difficult.
How would you like it to be documented?
There is full list of events
There is a full explanation of what the triggers and checks are doing in the events
99% of triggers and checks are commented in the xml file
You can check the description of events in the language data base.
What else do you want to have?
They 'fire' randomly in PBEM without player intervention again for things that have huge impact this could be fixed but not by modding.
That was a strictly design decision, to save you sending the file back and forth couple of times during one turn.
The events drive the game the impact is HUGE the events have massive effect overshadowing in many cases player actions. This could at least be mitigated by a bit of documentation.
Could you share some examples? Most of the events have at least two option, so you can choose your path. WOuld you like to know ten turns earlier that there will be 'famine
Doom refers to 'turning them off' or turning some off. Great idea. A tool to set an ON/OFF flag for events would be great. Expecting 'end users' to wade though a ton of xml and successfully edit it is not an practical solution.
As I am lobbying for change my remarks will be pointed, please realize I want to effect positive change.
Regards to documenting the events this will be time consuming to implement, but likely would save more effort than it costs down the road particularly if the events eventually migrate to an upcoming Time of ???? game on the same topic. It would also streamline the patch upgrade process. Doom does not likely have the management authority for that type of decision but a pretty good case could be made that this would save $$ rather than cost it in the long run. I have had involvement with very large, large, medium as well as small scale programming projects (I would classify ToF as perhaps medium by comparison) and as complexity increases the value of adequate documentation increases. ToF has likely passed that tipping point by a fair amount. Any project that spans years and evolves over time requires adequate documentation.
This is pretty well documented. I understood that for somebody who was not involved into the development and did not manage whole stuff, some time is needed. If you are hiring a new employee into a medium project, how much time he needs to feel comfortable with the documentation? Day, week, month?