Block 70 coming?
-
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.