In 2011, BMS 4.32 was chaos when considering the documentation. The sim had been through many different group updates and the single document was the so called Dash-34 written by many different individuals each in its own style and not addressing the real public needs.
Back in these times I was leading the training squadron of a Virtual Fighting Wing and started to write documents about learning to fly the F-16 in the sim.
Realizing that such documents could benefit a greater community I published the BMS 4.32 Dash-1 based on the real F-16 Dash-1 but totally dedicated to the BMS F-16.
Working later as part of the BMS dev group, I step forward and created the BMS Doc team.
The release of BMS 4.33 in 2015 saw a huge step forward in the documentation with a manual suite which renewed with the huge flight simulation manuals from a past century.
I created the Training Manual documenting 20 training missions, updated the Dash-1, maintained the F-16 checklists & KTO charts I created upon the release of Falcon 4.0 in late 1998 and assembled a team of motivated individuals ready to work with me in the documentation aspect of BMS.
BMS 4.34 was released in 2018 and I created the BMS manual documenting all sim specific aspects of BMS. This was done with the help of my VFW and some dedicated BMS members.
The BMS technical manual was also created upon the same initiative when it was realized some chapters of the BMS manual became too technical. Previous documents were updated according to the new version of BMS. This sounds like an easy process but unfortunately work within the dev group has never been quite team spirited and many individuals never quite cared about BMS aspects they don’t work with.
Nevertheless two new documents were created:
– The Comms and Nav book which was published from my previous Falcon navigation tutorial (published back in the Falcon 4.0 days) and documented the new ATC and radio communications procedures.
– The Naval Ops document dedicated to naval ops in BMS which was created in reaction to DCS becoming more efficient in featuring carrier ops with the F/A-18.
From this point on the presence of DCS started to scare some BMS coders and some of them couldn’t stand the comparison and became a liability to the BMS dev group (and still are today unfortunately). It became known to BMS beta testers that if they wanted to have something implemented, all it took was to explain how DCS did it and these coders immediately started to provide something similar.
BMS stopped having the upper hand.
This was nevertheless ample proof that competition is beneficial. Unfortunately ego was in the way of accepting that fact. For some dev, it became critical to release more often regardless of the loss of quality and this is the story of the BMS 4.35 release.
4.35 was meant to be released late 2019. Only 1 year after 4.34. Unfortunately the bright planners never took into account the time required to update the now 2000 pages of BMS documentation.
It took basically a year for the doc team to be ready to release and that delay could not be forgiven.
The fact that the BMS 4.35 was not ready for release neither end of 2019 or current 2020 as many bugs were reported and found thanks to the manual writing process was of course ignored.
As the December 2020 public release and its lot of huge bugs, CTDs and issues remaining proved, 4.35 was still not ready nor polished for release. The fact that nobody really stepped up to help the doc team during the so called feature freeze and the actual release remains a mystery to us to this day.
It is easy to blame and points finger to a scapegoat but really addressing the problems as a team is much harder.
As planned and communicated to Dev since 4.35 document work started, all BMS documents were eventually updated in December 2020 and as initially planned by the Doc team the release could happen around Xmas 2020. As the rules required, the source files were uploaded to BMS as well
A few days after the disclosure of the source files, and as I enjoyed a break from a full year of hobby time dedicated to BMS documents, I received a message from an aggressive dev member, who apparently took ownership of BMS Dev management stating that the “team” changed the BMS docs, would move to a wiki platform maintained by everyone rather than PDF maintained by a single person.
Here’s is the message, words for words:
Hello,
A couple of updates regarding documentation:
1. The BMS team performed some updates to the existing docs and intend to ship those with 4.35 U1.
2. The BMS team is switching to a docs platform that will be delivered in both PDF and web-based formats.
3. there is no longer 1 person that is responsible to create the docs, but everyone in the team with access to the docs repository will be able to edit the docs and create the necessary final version for shipment.
The fact that this was decided without even showing the curtesy to debate this with the doc team in general and me as the head of the doc team in particular once more showed the value of what team spirit means to those Freefalcon guys now having taking control of the BMS dev team.
The decision though made sense as a wiki is clearly a good way to proceed at this stage – but my opinion was never asked. The huge flaw again in that planning is that everyone would have access to the wiki and the big picture* one might have managing the whole thing will inevitably be lost.
Furthermore the fact that the BMS dev side tracked the working bees and took property of the documents was rude and showed all the respect the new BMS “team” has for its contributors.
I replied to him suggesting that he checks the copyright notice on each manuals intending to let him realise what he could and what he could not use in his new grand plan for the BMS documentation.
Of course he jumped the gun and saw this as a legal threat !!
Should he have acted as an adult, he would have realised that the IP of the BMS manuals are shared between me as sole author for many manuals that were written even before they were included in the BMS documentation suite and that many other manuals, although created on my own initiative and mostly written by me as the main author, were the IP of the BMS doc team and thus free for BMS to use as they see fit. Without surprise it was easier for him to disguise reality and justify his next move with a lie
Early February I finally received another short message from the same guy again stating that I simply was no longer a BMS dev member. No reason was given, access on dev were simply revoked.
Let me emphasize that even with guys leaking content to the public in the past, access key was NEVER removed. Here’s the full message:
Hi,
Just wanted to let you know that you are no longer part of the BMS team. Also you are no longer a moderator of this forum.
Good Luck!
Yoni
Interesting to note that my position as a BMS public forum moderator was removed as well. Logic you might say as this is the main reason drama queens wanted me out of their way.
My job as a moderator on BMS public trying to keep all users (dev included) abiding to the dev group own rules was particularly in the way of some Devs as they liked to think they were above the rules and therefore should be allowed to show disrespect to other users – a false prerogative they used quite a lot and created a lot of trouble for the moderators who stepped forward to maintain the BMS public forum open.
I hope this post will show you the true nature of what BMS dev group has become. For years they have been saying that they do not care about the public. It seems clear to me they now do not even care for the people having contributed freely for two decades either. And indeed all it takes is looking at the ever growing list of moderate and rationale members who left the group, now replaced by new guys who ultimately will go through the same ordeal and leave when it stops being fun.
This is what BMS has become today.
*During 4.35 development I was asked to give source document so ‘someone’ could correct a “mistake” made in its original code layout explanation. These “mistakes” were usually made by too much copy and paste from “other, more knowledgeable source” documents….
I denied the request and rather asked what to correct and do it myself as other chapters in the document suite might be impacted. And I was very right to do so. I was asked to modify AGM-88 chapters of the dash-34 but none of them realized that other manuals of the BMS suite needed to be corrected as well.
Failing to have the big picture is the best way to have contradictory – or worse as in the case above – information within the document suite.
To some extend this was the mess the BMS documents were before 4.32 and unfortunately this is what lays ahead of the BMS community for 4.36, unless…