Block 70 coming?
-
Is anyone interested on perhaps putting together a proof-of-principle? Perhaps to “convince” the BMS guys that this is the way to go?
This is indeed one thing we are/were thinking about. But … nothing has been really really seriously been discussed yet. IIRC, Falcas has some good ideas about it. Maybe one day. (?)
… Anybody if free to give a try about creating a tool able to manage a “master database” like described above …
-
I have to agree with Eagle-Eye who sums up the whole debate in one fell swoop… If it’s all fictitious, what difference does it make which aircraft remain in the DB even if they aren’t used in that particular campaign?
As a development team, I would think your focus should be centered more on CREATING avenues for the community to enjoy the game in whatever way they find that pleases them, not pigeon-holing them into a “My way is the only ‘Right’ way” approach. Is that the entire point of being able to modify and create theaters and campaigns? I completely understand not putting squadrons in the campaign for the units you don’t see fitting into your idea of a KTO CAMPAIGN. But to remove the aircraft completely from the DB seems silly in a dozen different ways, almost to the point of arrogance, unless their existence is preventing some other object from being added to the DB.
KTO is the “starting point” for almost every other theater out there. Removing things from the DB entirely does little more than stifle potential community development for those out there who want to develop theaters and campaigns for other historical and geographical settings. Truth be told, KTO is a prime target for a more modern, and potentially feasible future conflict theater in the game. It would be hard to argue that of all the possible air war scenarios that might happen in real life over the next 10-20 years that a Korean AOR would not be one of the 3 most likely, and that it would be a relatively large and drawn out conflict–lest we forget the Korean War never technically ended, and could in theory ramp back up to a full scale conflict at the drop of a hat. So why not enable someone out there to do a modern-ish campaign in Korea with modern aircraft from all over Europe/SWA/US? The reality is, if the theoretical conflict lasted more than 2 weeks they would probably all be involved in some way or another.
-
what difference does it make which aircraft remain in the DB even if they aren’t used in that particular campaign?
RAM used for textures, 3DDB size, … man-work to maintain the core DB, parents allocations and textures IDs (17 funking variants of F-4s ! …) … who is doing the job? … you?
But to remove the aircraft completely from the DB seems silly in a dozen different ways, almost to the point of arrogance, unless their existence is preventing some other object from being added to the DB.
Dam! I am falling off my chair! … you are speaking about arrogance!?! … but mate, feel free to do whatever you want with your install. Extract the 3D models and data from your 4.32/4.33 and replace it into your own future 4.34 install if you like to have the AH-1 Skyraider in KTO or in any other theaters … but please, don’t tell us what we have to do with KTO.
4.33 DB is plenty of shit, garbage, non working and unfinished stuff that nobody cared since years …
VS
Where do you prefer to work Mortesil?
Cleaning it a little bit is a good point to start thinking about adding more in a cleaner and proper way and add thinking only if they have reached a correct level of accomplishment.
Tidy up and cleaning up a little bit that thing sounded a good idea to our DB guys … even if still way way imperfect and lot of things could be done.
Feel free to finish your own project before considering giving us some lessons about the way we are managing our.
Once done … you will be truly welcome to start working on a tool making the work of adding/replacing CT entries in a easy way and we will be able to discuss more seriously bout a master DB with the hole words inside.
Seriously?!! …
I know I am bit emotive those last weeks, but this one is killing me. Just about to vomit on the community. I can’t believe I am still “part” of it.
-
Hummm… guys…don’t overact. It is just a DB…let’s keep positive and try to find solution. I am totally for approaching that problem again. DJ and Falcas, are you up to do some brainstorming together? !
-
You’re diverging into a completely different logic than what you said before. Cleaning out unused or non-functional objects from the DB is an entirely different scenario than removing things because you don’t think they “fit” the campaign environment. “Cleaning Up” is always a good idea, and if you had said that from the beginning I would not have made a comment about it all. But that’s not what you said, you said:
Grrrrrrrrrrr !!! ….
No prob to have many different aircraft in DB especially when they fit with theater or are useful. It is rather having tons and tons of variants (or similar) which might be a pain … But, honestly, I would not be against an F-16A nor a F-16CB60/70. (ok ok … I admit that I am not really in favor of Qatari F-16 in standard KTO DB … mmm … I have nothing against Qatar, it is just an example of course, which, BTW, could be a bad example if one day we have a brand new kicking ass “Operation Desert Strom” theater …)
Correct … that is why some of us wished to suppress them from KTO DB (and some has been indeed suppressed). But … Hummm, it has not been really appreciated LOL … so at least, we will try to limit and, if possible, avoid that kind of airframes/varients in the future (speaking about regular KTO DB only.)
RAM used for textures, 3DDB size, … man-work to maintain the core DB, parents allocations and textures IDs (17 funking variants of F-4s ! …) … who is doing the job? … you?
Cleaning it a little bit is a good point to start thinking about adding more in a cleaner and proper way and add thinking only if they have reached a correct level of accomplishment.
Tidy up and cleaning up a little bit that thing sounded a good idea to our DB guys … even if still way way imperfect and lot of things could be done.
Two completely different arguments. One has merit, the other does not.
PS… My project IS done. I have my reasons for not pushing it out to the community yet, not the least of which being the impending release of an update which very well may require some serious changes to it.
-
You are of course free to express what you think … so do I.
You want arrogance? … let me give you some :
One has merit, the other does not.
I do not owe you anything Mortesil and I think what we are doing with core DB is not your concern. What we are doing on our free time is nothing but our own call. I will not dictate you how to deal with your tool. And we don’t need to justify any of our choices.
You will make your own mind about the 4.34 once released. If it will please you => Good. It won’t => I couldn’t care less. Again … feel free to feed your own DB as you wish as long as DB is not locked or encrypted.
Definitively … talking about development here is something toxic for modjo.
Now please excuse me … I need to leave the place … I’m running out of air.
-
Boyz IMHO there is no need to take personal point-of-views as attacks, moreover get in a dogfight with written-language comments that as we all know and experience in the past is can be easily misunderstood depending the good-or-bad day of the reader. BMS will evolve with time to whatever will be, no individual opinion can stop or influence the future, a feature, a db, a cockpit, whatever that might be.
-
Hi Raptor,
I agree with your words !!!malpaso
-
Suggestion for New DB fields:
Theater id.
Campaign id.
And you can even combine them to one.
Sure will need a table for theaters and campaign to store the ID’s.Then you can have all the garbage in the world in your DB.
If its ID’s are null no one will use them and it will just take space.No master, no locks no encryption.
U want encryption? Encrypt only the kto and campaign ID’s. U could do it in a third field named enc_id or if u want quick access theater_enc_id campaign_enc_id. And provide a sample for the rest unencrypted entries so guys to have a starting point.
That way no new entries for the kto from 3dparty guys unless they brake the 256 or 128 encryption.
Encryption will add resources needs. And test troubles to theater devs like I want to try something new in kto. they will have to edit only current records or do the tests on another unencrypted theater.
I’m sure u guys have better ideas, just thought to share mine
Sent from my MI 5 using Tapatalk
-
and if you had said that from the beginning I would not have made a comment about it all.
Uhm, I don’t believe that for one second!!!
C9
-
my 2 cents:
Is anyone interested on perhaps putting together a proof-of-principle? Perhaps to “convince” the BMS guys that this is the way to go?
So because it is your 2 cents and you believe it is the way to go, then it, by all means, the BMS team should be convinced to do what you feel is the way to go??
Hmmmm, seems to make sense……SAID NO ONE EVER!!!
C9
-
Cloud, with all due respect, it is a suggestion to be discussed. As I wrote, it works very well in CMANO and, yes, I believe it could work somehow in F4.
There is no need to attack my post per se/person. Attack my suggestion and it’s content (as Arty did), that is the way to go, yes, I believe. -
@Arty: Your suggestion does not solve though the problem of having same platforms in different theaters with different specs.
In the same way, different names but same platforms in different theaters can also happen.
My suggestion was to lock the Master DB. It is kept clean and self consistent by a team, for example. The individual DB of a theater could still be in the same format that we have now, if people wants it. I personally don’t see any advantage.
As we have 3D models freaks in this forum/ community, I am DB enthusiast who would like to see consistent entries names and specs, around all theaters. On the contrary to 3D modelling, on the DB I can contribute. -
There is no need to attack my post per se/person. Attack my suggestion and it’s content (as Arty did), that is the way to go, yes, I believe.
So anytime anyone says anything about what you post it is now an attack on your person!?!?!?! Hmmmm
The rules that exist on darn near every forum, IS, attack the post, not the person, I didn’t in ANY way attack your person!! What is this world coming to???
I LOVE how people can’t handle retorts to their opinions!! SMDH
Edit: Well it WON’T work with BMS!! Have you met their members???
C9
-
-
My suggestion was to lock the Master DB…
This would be a death sentence for modding. Worst idea ever, FF DB for a while was locked and was the darkest era of Falcon to me…
-
Locking a Master DB, which would NOT be delivered with your mod theater would not stop any theater developing.
Molni, you could still continue developing and when you think you nailed the edits you would request these entries in Master DB. If those entries already exist and you just changed a name, for example, you can go in two directions:
1. Comply with what is in the DB, use the entry of Master DB.
2. Or say, that you don’t care about it and you will use whatever you want. This is what happens nowadays, without a Master DB, so to say. It certainly works for many theaters, but it is not something that helps fast modding if you need to repeat the work over and over.If it is a new entry, great, it will be then added.
In the whole process you were not stoped or blocked of modding.
The advantage, though, is that if there is similar entries in your modded DB and the Master, you could use what people did before and other people could use what you have done. Same names, same data, different theaters. Would not that be great?
Or imagine have all your 80s entries in the Master DB to reuse in the next BMS version? Just few clicks and import.EDIT: perhas to clarify, the master DB is not what goes with your theater install. It would be something used to deposit all entries of all theaters to be reused and centralized edited.
-
Had I known this would be the result, I never would have asked the question. :-? Apologies, FWIW.
-
-
Yet again a discussion is derailed.
This is a forum, expect others to have different opinions from you. You may feel you are right and they are wrong, it doesn’t matter. What does matter is when people resort to personal attacks. Please keep it constructive and impersonal.
We are a community, stronger when we’re together and weaker when we’re fighting amongst ourselves.