Small EOY update...
-
@Seifer said in Small EOY update...:
@JOKER_duke said in Small EOY update...:
Good news, thanks for the information and for the hard work of all BMS devs!
I am a campaign editor/creator, what about the camaign engine? Do you have any plans to upgrade the dynamic campaign engine?
There are a couple of bugfixes related to campaign engine, mostly related to AWACS flight generation not working because of the flight going over enemy territory. This affects ITO mostly.
I also started working on generating some campaign data to make some analysis possible: people are reporting ground units stopping after a few days.
So for this next release, no, not much. For the future, I hope so, because campaign is falcon precious gem.
There has already been a big improvement in AI initiative towards the ground war. Campaigns’ tempo is not the same.
-
@Seifer said in Small EOY update...:
Just to complement last answer, from a technical perspective for those who are curious:
-
we moved to git (much better version control management, allows multiple changes to be easily managed at the same time). Downside: some coder had a hard time adapting to it.
-
Gitea infrastructure: much better reviews (which are still optional, but we do anyway). More pairs of eyes looking at the code means knowledge being spread and more people to catch bugs.
-
A few coders write some units test, which is good to avoid future regressions. But this is still a small effort.
-
Flag: almost every change is flagged, so we can revert and test in case of problems. This is very close to 100%.
-
Quicker test iterations: we try to generate internal installers for testing much quicker than we used to be, to get constant feedback.
-
Comms: we are trying to improve, having a common comms center. This is still not adopted by all but Max made some magic integrating Discord with Rocket channel. And we also a internal wiki which we are trying to feed with useful information. And we are also trying to be more open/closer to the community: we are all on the same team. We are one.
-
Bug philosophy: one CTD is one CTD more than what we want. We really chase bugs as they show up. Stable code allows us to do more magic in the future.
-
Getting rid of legacy/old stuff: we are slowly killing old stuff, which was just a pain to maintain.
-
Plaaning: as soon as we release a version, we try to create a roadmap to the next one. This kinda guides us in terms of features. It is not set to stone: this release for example, has a totally new feature related to… well, chevrons, which wasn’t planned. But the main feature was the top priority all the time.
Very interesting, thank you for taking the time to describe some of the dev process.
-
-
@Seifer I bet you could’ve just said “we’ve stopped sacrificing mass-produced chickens and now exclusively use free-range chickens to sacrifice to the BMS gods and it’s giving us better results” and most of us would’ve probably focused on the “better results” part
Glad to see internal progress has been made and is now translating to being able to do better and more efficient work with the game. Mad respect to all you guys, I’m sure you’re all on Santa’s “good boys and girls” list.
-
@digle said in Small EOY update...:
Is there a reason about this short period of time between releases since 4.35 ?
Remember 4.33 took several years to be debugged
New debugging tools ? Change of the software architecture ?I’m not a BMS dev so folks can correct me if I’m wrong. Just looking from the outside, I saw a few new tools, and things happen since 2020… beyond the inside-baseball stuff Seifer outlined.
-
the move to x64 only, and end of life for Win7 (and soon Win8) reduces the test-matrix by a lot
-
I think in mid 2021 (sometime early/mid 4.35 era), the dev team started using AppVerifier [1] to catch mem leaks, double-free bugs, and heap buffer-overruns … uncaught SEH exceptions, etc. and other related tricks eg. /GZ or /RTC compiler flag, for debug-builds, to catch stack buffer-overruns.
One can imagine there was probably a huge logjam of noise in those initial reports… imagine 20 years of accumulated bugs (and starting out with a lot, lol)! But through heroic efforts of Seifer and other devs, once the random noise of dozens (hundreds? thousands?) of nondeterministic CTD bugs is squashed… at some point you begin to cross an inflection point, enjoying increased velocity in all other aspects of development and testing.
[1] https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/application-verifier- maybe increased use of smart-pointers? I haven’t seen the code, so this is entirely heresay, but it sounds to me like some of the coding style/guidelines have matured from “1998 game-dev C++” to … well at least “2008 C++”, lol. maybe just for newer code, at least?
Definitely the hardest part of C/C++ development is enforcing clear lifecycle-ownership of memory and other resources (network connections, file handles, COM objects, etc)… C++ smart-pointers, combined with RAII [2] mindset, is the best “tool” I know of to tackle that.
[2] https://en.cppreference.com/w/cpp/language/raii- Divide and conquer: increased reliance on external, community-driven features like Alt Launcher, WDP and TacView etc, helps keep BMS priorities focused on the core sim engine.
Those things were there before 4.35, but it seems like a clear change in strategy to embrace them, as loosely coupled dependencies. (eg. the default ACMI format no longer compat with the builtin playback feature.)
-
-
All this talk of improvements and efficiency and improving BMS at a faster rate, well…
-
@Atlas said in Small EOY update...:
All this talk of improvements and efficiency and improving BMS at a faster rate, well…
-
@airtex2019 said in Small EOY update...:
[1] https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/application-verifier
- maybe increased use of smart-pointers? I haven’t seen the code, so this is entirely heresay, but it sounds to me like some of the coding style/guidelines have matured from “1998 game-dev C++” to … well at least “2008 C++”, lol. maybe just for newer code, at least?
Definitely the hardest part of C/C++ development is enforcing clear lifecycle-ownership of memory and other resources (network connections, file handles, COM objects, etc)… C++ smart-pointers, combined with RAII [2] mindset, is the best “tool” I know of to tackle that.
Yes, this is doing magic for our code.
our old code (this example is not the exact code we have though…just describing you an idea):system = new System();
is now like:
system = std::make_unique<SystemF16>();
this is another hint teasing 4.37 feature for you who knows c++ guess what we have now.
(oh but please don’t spoil even if you “notice” ) -
@chihirobelmo damn Chihi, all you think is f16… Why not an f15?
-
@Seifer Because BMS “has been” F-16 sim
-
@chihirobelmo took a crash Google course on c++ just to reveal the hint, accidently created Falcon 5. Sorry will be busy for the next month playing this new creation.
-
@Seifer said in Small EOY update...:
@JOKER_duke said in Small EOY update...:
Good news, thanks for the information and for the hard work of all BMS devs!
I am a campaign editor/creator, what about the camaign engine? Do you have any plans to upgrade the dynamic campaign engine?
There are a couple of bugfixes related to campaign engine, mostly related to AWACS flight generation not working because of the flight going over enemy territory. This affects ITO mostly.
I also started working on generating some campaign data to make some analysis possible: people are reporting ground units stopping after a few days.
So for this next release, no, not much. For the future, I hope so, because campaign is falcon precious gem.
Hi there, dear Seifer, it’s me again.
Sorry in case for bothering you. I am a mission creator (mostly, always planning to become a campaign maker after the new 4.37 released, though).If I assume correctly the sense of all of yours above, could those apply, even if partially, to new custom TEs too?
Thanks a lot for your attention, and with best regards.
-
Hi there!
Thanks a lot. Great you’re moving on dev-wise. I know how hard it is to migrate a mature process / codebase to any kind of new tool / process / framework whatever.
You’re doing a great job!
Take your time! -
@chihirobelmo forget the code, I think many of us are excited to see that you’re a member of the dev team now!
-
Implemented a unique avionic only for F16? I could not think of what that will be.
-
Mods, can we please ban @chihirobelmo and @Seifer and possibly others for being such teases? I don’t even need any medication now, much less whatever it is that @VIPER-0 is peddling
-
@Jackal hi Jackal, not bothering at all.
No the changes I made were related to campaign engine only (where it tries to generate AWACS flights). IIRC, TE does not have this problem.
-
@chihirobelmo This would be the most groundbreaking new feature if it means what I think it means… even the original devs couldn’t decouple the avionics and ended up scrapping their planned A-10 expansion…
-
We all appreciate what we have and anything more is just spoils to the community.
Thank you BMS team!
-
@ajthenoob said in Small EOY update...:
@chihirobelmo This would be the most groundbreaking new feature if it means what I think it means… even the original devs couldn’t decouple the avionics and ended up scrapping their planned A-10 expansion…
Because you really think Bms devs are not much better than original devs ? Seriously ?
-
@Mav-jp said in Small EOY update...:
@ajthenoob said in Small EOY update...:
@chihirobelmo This would be the most groundbreaking new feature if it means what I think it means… even the original devs couldn’t decouple the avionics and ended up scrapping their planned A-10 expansion…
Because you really think Bms devs are not much better than original devs ? Seriously ?
Man-jp sounds like chihirobelmo’s assumption is correct.
I expect each aircraft do not depend on F-16 avionic anymore with next release version. That will be amazing change for us!