FO - Battle For Balkans Theater
-
No m8 I never used it, it was suggested a while back but I didn’t do much more than open it, looked at it, closed it and thought that I would look at it again later but I never did
Anyway, thanks to the team behind this theatre!! Tomorrow I will have my maiden flight, hopefully I will rtb in one piece
Cheers
-
How i can change clouds ? stock clouds are about 100x better, those flat looking are no go
-
Is this cockpit light normal?
https://dl.dropboxusercontent.com/u/17606390/balkans_pit.jpg
I would like to have a green or a yellow lighting but not this mix….
-
with all your respect, it may be time to learn F4patch
Thanks but I’m in the process of writing my own application to do the job…
Implementing a “patch” into F4Patch is like threading a hotdog through the eye of a sewing needle.
-
Thanks but I’m in the process of writing my own application to do the job…
Implementing a “patch” into F4Patch is like threading a hotdog through the eye of a sewing needle.
well this is clear that BMS using F4patch, creating another patch “plug in” will be easy to manage for dev teams
viva uniformisation
-
well this is clear that BMS using F4patch, creating another patch “plug in” will be easy to manage for dev teams
viva uniformisation
I’m aiming for a 1 click solution…
Ie. Balkans Activated / Stock Activated, with a really big button so that people can mash their palm on the keyboard and still get the desired result.
Using feet should be also compatible, stay tuned!
I beg to ask a question to all the F4Patch supporters out there…
Let’s say we did back up the SU-27 dat, ok fine.
Then update 8 comes out (as an example, probably wont be the case)
User installs update 8, fine.
BUT
Lets say they un-install or un-F4Patch the add-on after updating the main BMS version.
Wouldn’t that add an older file (backed up or store at time of install) and technically break the install just as bad?
Swapping files is a BAD solution no matter how it’s implemented. What is required here is to de-localize the sim folder and have it theater specific.
Then we wouldn’t need to use F4Patch or any other switching tools. Make every Add-On completely isolated from the main build.
Please remember just as adding / overwriting stock files is a bad idea, so is restoring older files which may have changed since the user updating, breaking the install just as bad if not worse.
-
I’m aiming for a 1 click solution…
Ie. Balkans Activated / Stock Activated, with a really big button so that people can mash their palm on the keyboard and still get the desired result.
Using feet should be also compatible, stay tuned!
I beg to ask a question to all the F4Patch supporters out there…
Let’s say we did back up the SU-27 dat, ok fine.
Then update 8 comes out (as an example, probably wont be the case)
User installs update 8, fine.
BUT
Lets say they un-install or un-F4Patch the add-on after updating the main BMS version.
Wouldn’t that add an older file (backed up or store at time of install) and technically break the install just as bad?
Swapping files is a BAD solution no matter how it’s implemented. What is required here is to de-localize the sim folder and have it theater specific.
Then we wouldn’t need to use F4Patch or any other switching tools. Make every Add-On completely isolated from the main build.
Please remember just as adding / overwriting stock files is a bad idea, so is restoring older files which may have changed since the user updating, breaking the install just as bad if not worse.
delocalize sim folder ?
why ?
do you think an aircraft will perform differently in korea than in balkan ?i dont agree .
you want to change core elements of BMS, feel free, but be aware you will break MP compatibilty with 4.33 …
best way is to work hand in hand : you want to make a FM evolve, submit your FM to BMS dev team and if it is OK we will integrate it
we dont want to end like before BMS release, i.e. with thousands of falcon4 version
1 to rule them all : BMS
-
Is this cockpit light normal?
https://dl.dropboxusercontent.com/u/17606390/balkans_pit.jpg
I would like to have a green or a yellow lighting but not this mix….
Looks like HAF lighting. I didn’t like it much the first time I saw it, but I’ve grown to like it quite a lot.
-
Let’s say we did back up the SU-27 dat, ok fine.
Then update 8 comes out (as an example, probably wont be the case)
User installs update 8, fine.
BUT
Lets say they un-install or un-F4Patch the add-on after updating the main BMS version.
Wouldn’t that add an older file (backed up or store at time of install) and technically break the install just as bad?
Swapping files is a BAD solution no matter how it’s implemented. What is required here is to de-localize the sim folder and have it theater specific.
Then we wouldn’t need to use F4Patch or any other switching tools. Make every Add-On completely isolated from the main build.
Please remember just as adding / overwriting stock files is a bad idea, so is restoring older files which may have changed since the user updating, breaking the install just as bad if not worse.
BMS have always said to apply official updates over a vanilla install only, ie an install with no modified global files. So an informed user should unapply the FM patch, run the update, then re apply the patch (assuming the patch is smart enough to always back up the current file). It’s really up to us to conform to the current limitations in regard to global files, we can’t blame BMS. And maybe in the future it will be easier. I also made these suggestions in the past: https://www.benchmarksims.org/forum/showthread.php?10570-Suggestion-Files-that-should-be-theater-dependent
-
Is there a way to send this new fm to BMS Devs and if possible after they check all the stuff if it could be integrated in this 4.32 ( I think yes ) and
after have a new BMS update 8?So maybe we solve the problem…
Too hard to do?
Just an opinion…
cheers
-
They have the FM dema, as far as I understand AS sent it to Mav-JP a few months ago to evaluate it. It is not us who made this FM. Shadow is the author of the FM IIRC for the su-27, We included the Su-27 because we were requested to do so, Myself or AS or Arch don’t even fly it…
Regards,
Mystic
-
Thanks Mystic,
I’d like, really , You balkans Devs and BMS Devs could find a common point.
Everyone who read these thread page could understand wrong things.
From a part we can say Falcon has a limit about his database “locked”.
I know this since years even I could be the last user here in this forum who can speak. You touch a file and the install is ruined.
Always in some new released, even a simple skin, is suggested to do a backup.
Also, in Archer ts and in your server another time as your previous releases you have 50 pilots, now in a beta release.
This is a great thing.
As a member of both Communities I want to see everybody happy.I know you will find a common point soon, even why if you both devs you work to improve falcon you get to work togheter.
Try to understand what I mean.
cheers
-
delocalize sim folder ?
why ?
do you think an aircraft will perform differently in korea than in balkan ?.My point was referring to the breaking (overwriting) of stock files. It makes no reference to the actual differences in performance of the flight models in question, and TBH I’m not even sure what they are.
-
Archer look also at the other side of the coin… ppl love the Balkans. All this talk is to make it even better. There is not only Balkans or FO. Those limitations are forced to a closed group - squad. When u go public u r exposed to public action and reaction.
Dont take it personaly… noone has to split anything with noone. U have wonderfull coders, devs, modders at FO they can manipulate such things.
No one is perfect , no one says that all this hard work goes down the toilet… the oposite. we like it we want it, we r just strange and want something more that was minor for the team that assembeled it or was overlooked… not a big deal… just do it yesterday cause I wanna use that SU-27 I heard ruskies have better jdams then amerikanskie and I want to deliver some to u… :lol:
Oh and dont forget son… the coin has 3 sides…
-
Question; how do you go about loading the Application and SRC files and where do they go?
-
I have been lurking on this thread and reading it with interest, and my feelings mirror Arty’s, I believe. From what I have read, we all want the same thing: a continually improving Falcon BMS experience; and I really don’t discern much of a controversy here. I can see how pilots interested in flying the SU-27 would be excited to have that feature available in BfB. OK, OF probably should have included a caveat about the data file change in their Installer. But, hey, errors of omission do occur, as they have acknowledged. Users then could make an informed decision about whether or not they wish to install. Several good suggestions have been offered to avoid this situation being repeated, so time to move on, I think. No profit in continuing to kick this poor dead horse. BfB is kick-ass by the way.
-
delocalize sim folder ?
why ?
do you think an aircraft will perform differently in korea than in balkan ?i dont agree .
Means no theater related SIM- folder (to be declared in *.tdf) for 4.33 at all?
… so if I want to use Molni’s DB for (just one) example, then I would have to write a F4Patch,
or backup/ copy … back and forth?Or if I want to use community’s 3D AC- models, for (another) example,
with it’s associated AC.dat file (animated landing gear, etc.),
then I would have to write a F4Patch, or backup/ copy … back and forth, too?Come on Mav’, with a delocalized SIM- folder it would be really easier for community/theater devs,
without touching the originally korea DB.On the other hand there wouldn’t be a reason for delocalized OBJECT- folder as well.
Cheers,
LS -
well about total delocalized database then BMS is more stable and trouble free. Cause theater dev’s will not alter or change the stock files. When minor updates are done also this doesn’t mean that the dev has to update to the new version. Finally if an update gives better data then it would be easier to just transfer the files from stock folder to theater database folder.
Some want some minor changes… like lights or what. Others do weapons… and so on and so forth… Also this is the reason that some squads that make changes on theaters don’t share publicly their work… cause they want the sensitive data changes staying at their squad… This way they could release the theater with the stock database files so that others enjoy let’s say the objectives and 3d and the rest… non sensitive data.I wonder what EMF will do or did on the subject.
To take it farther??? BMS could lock the stock files, so that the user can’t change them. At the same time with every affecting update, release the files for the theater dev’s… that go to the theater folder. That way the stock setup will be rock solid unaffected and the theater dev’s and community happy.
-
Stupid question here. Do I need to install the Balkans theater, textures, etc. BEFORE I install the campaign?
-
http://i45.photobucket.com/albums/f82/lazystone/Smileys/sCo_huhsign.gif Means no theater related SIM- folder (to be declared in *.tdf) for 4.33 at all?
… so if I want to use Molni’s DB for (just one) example, then I would have to write a F4Patch,
or backup/ copy … back and forth?Or if I want to use community’s 3D AC- models, for (another) example,
with it’s associated AC.dat file (animated landing gear, etc.),
then I would have to write a F4Patch, or backup/ copy … back and forth, too?Come on Mav’, with a delocalized SIM- folder it would be really easier for community/theater devs,
without touching the originally korea DB.On the other hand there wouldn’t be a reason for delocalized OBJECT- folder as well. http://i45.photobucket.com/albums/f82/lazystone/Smileys/headscratch.gif http://i45.photobucket.com/albums/f82/lazystone/Smileys/shrug.gif
Cheers,http://i45.photobucket.com/albums/f82/lazystone/Smileys/hat_3.gif
LSSIMDATA = AICRAFT PERFORMANCE
AIRCRAFT PERFORMANCE IS NOT THEATER DEPENDANT.