Small EOY update...
-
@Seifer Of course not, I was just having a bit of a joke
-
@Seifer Great news, thanks
-
Amazing!
-
Looking forward to the next version when it’s ready!
Thanks and Stay Awesome !!
-
Thanks guys!!!
-
Thanks BMS Team for all your hard work.
-
@Seifer said in Small EOY update...:
@Atlas hey buddy, didn’t mean it in a bad way
I will leave only one hint th ll leave only one hint though cheers!
Too bad nobody seem to understand
-
@I-Hawk said in Small EOY update...:
@Seifer said in Small EOY update...:
@Atlas hey buddy, didn’t mean it in a bad way
I will leave only one hint th ll leave only one hint though cheers!
Too bad nobody seem to understand
| | | | -
@I-Hawk said in Small EOY update...:
@Seifer said in Small EOY update...:
@Atlas hey buddy, didn’t mean it in a bad way
I will leave only one hint th ll leave only one hint though cheers!
Too bad nobody seem to understand
I found it Very Revealing
[ ] [ ]
-
I if may Ask
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 ?
Thank you devs for your work -
@digle Well, I’d say it’s a combination of a couple of changes, but the “human factor” still wins hands down. We release now more often because we decided to switch to that way of work. The other changes (technical, mainly) are a consequence of that decision. However, many changes were done behind the scenes and with HUGE efforts in order to get us to this more efficient state.
In general, it’s much more healthy and sane to release more often, Devs should be more motivated when their stuff is released more often, ESPECIALLY in cases where a new development doesn’t depend on other changes (For example a new 3D model created).
-
@digle said in Small EOY update...:
I if may Ask
Is there a reason about this short period of time between releases since 4.35 ?
Rembember 4.33 took several years to be debugged
New debugging tools ? Change of the software architecture ?
Thank you devs for your workWe changed the way we work
It’s much easier to code / test and release smaller updates
All changes are now flagged which means we can revert them when we want
-
Thanks for all you for giving us this great Sim. Everything you do is appreciated. Have a great holiday season!!!
-
@I-Hawk said in Small EOY update...:
Too bad nobody seem to understand
I think I need to adjust my IPD a little bit to get that joke
@I-Hawk @Mav-jp Very happy to hear this and looking forward to more progress in this sim. Not that it needs it but can’t have too many cherries on top of this cake, can we?
-
@digle said in Small EOY update...:
New debugging tools ? Change of the software architecture ?
Hi Digle, this is an actually interesting question and I will start by asking another question:
Do you think the current way is better or worse?
MavJP/I-hawk already answered most of the reasons why we are doing things as we are now. But there is a downside as well: the WOW factor is reduced (as you accumulate more changes, the release has a bigger impact, since it brings more new features).
In terms of deving, the answer is quite clear: smaller, faster iterations are much easier to maintain and move forward. But from the user perspective, it can be kinda disappointing.
I’ll be honest though, I don’t see us going back to the old method. But knowing the user feeling is good, so that we can also see if anything can be done from the dev side.
Aside from that, IMHO next release will be an exciting one. After a long period of fixing/refactoring code/internal only stuff, we are finally having some time to do some cool new features (well, not really “we”, but other coders who are doing their magic). I hope you all enjoy it, at least I feel the dev team has been enjoying it as well.
-
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.
-
-
Hello, dear mate.
If I dare to say mine own, thanks to all I-Hawk, Mav-Jp and your explainations your project seems to be highly reasonable because put a step-by-step progressing strategy - if I got its sense correctly.
Not only this, but more. From my own point of view, more frequent releases mean giving to me, a modest user, the possibility to focalize my attention to what’s new and how it has improved my flight experience overall. If not, why, helping me to report that to your devs’ attention.
But last, and most important above all, is this valuable statement of yours: we (devs. and users) are one. That because we (and we only, in spite of any other one) are a strongly connected community. Or so I have to guess.
Please keep on going this way, becasue it’s fair right.
With best regards.
-
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?
-
@Seifer said in Small EOY update...:
@digle said in Small EOY update...:
New debugging tools ? Change of the software architecture ?
Hi Digle, this is an actually interesting question and I will start by asking another question:
Do you think the current way is better or worse?
Hi Seifer and thank your for your detailled answer
The current way is better,I was just curious about how technically you achieve this -
@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.