U2 and ITO 1.0.1 compatibility

[DarkFib3r]

Can anyone verify if ITO 1.0.1 and 4.33U2 are compatible? Thanks!

[Badger]

We’re in the same boat with an ITO campaign underway.
I think changes to the database and cam files may be problematic so, we are staying on U1 just a little longer.

Hopefully, someone pops in and says otherwise.

[Echo7]

ITO 1.0.1 and 4.33U2 are not compatible because of DB updates in U2. An updated theater is in the works. You will probably be able to use your current TEs and campaigns with it.

[agalnov]

Is there any chance to share “what to look for” in order to identify why or not a theatre is compatible with new U2 (or future releases).

So far, for Pillars of Hércules (POH) theatre development, we always did it in the hard way… just start from ZERO with the DB (rebuilding from the Brand new DB every update).
This is humpering big time the progress, and everytime we do, there is always something forgoten or wrongly done (human mistake)… so we tried to fix something which was not really broken… until we discover our mistake… and so on …

Is there anyway for Developers (theatres or BMS itself) to be a bit more “precise” giving the changelog and how fixes affects the Sim… or how they could be implemented directly into others DB… so we dont have to start it over again? (I´m sure many of you can feel our pain)

Just asking here because I has the sense that ITO was historically keeping up very well with every BMS update/upgrade… specially when we moved towards 4.33.x

Thanks in advance.

And keep it up with this wonderfull theatre!

[Arty]

Well the U2 exe file is one that can be extracted? Or if the devs reported affected files we could know.
I believe a redone is necessary cause of 3d and data database files and records change. Some might be related to ctd’s fixes.

For sure once again the update tool for theaters is greatly needed.

On the other hand you can stay with U2 exe and U1 database. I believe it will work fine. U will not have the latest database changes… But till release there might come and a U3 and a U4, redoing it each time will kill your release. So do it once only before release.

Sent from TapaTalk

[Raptor]

I’ve spent hundred hours the last 6 months working on Ikaros DB based on U1, there is no way to adopt the new U2 DB/fixes without rebuilding from scratch… So, IMHO stick with build-update version might be the only road for many theater builders until a solution / tool is found.

[schnidrman]

@Echo7:

ITO 1.0.1 and 4.33U2 are not compatible because of DB updates in U2. An updated theater is in the works. You will probably be able to use your current TEs and campaigns with it.

Are you saying that existing TE and Campaign saves will still work, but creating a new TE and/or starting a new campaign after the update will not work properly?

Just curious, because I have flown three missions in ITO since the update with no apparent problems. What problems might I expect?

[Echo7]

@schnidrman:

Are you saying that existing TE and Campaign saves will still work, but creating a new TE and/or starting a new campaign after the update will not work properly?

Just curious, because I have flown three missions in ITO since the update with no apparent problems. What problems might I expect?

Then you are basically flying U2 exe with U1 DB. Apart from the fact that this eliminates the U2 data fixes and updates, generally some EXE changes are coupled to DB changes, so this could lead to instability or unexpected behavior (there were actual cases with previous versions of ITO). Being more specific would require digging deep into the data and exe changelogs, and frankly not needed as a fully compatible theater will be released soon.

@Arty:

On the other hand you can stay with U2 exe and U1 database. I believe it will work fine. U will not have the latest database changes…

Again not recommended since some EXE changes expect specific data.

@Arty:

I believe a redone is necessary cause of 3d and data database files and records change. Some might be related to ctd’s fixes.

Yeap.

@Raptor:

I’ve spent hundred hours the last 6 months working on Ikaros DB based on U1, there is no way to adopt the new U2 DB/fixes without rebuilding from scratch… So, IMHO stick with build-update version might be the only road for many theater builders until a solution / tool is found.

@Arty:

For sure once again the update tool for theaters is greatly needed.

@agalnov:

So far, for Pillars of Hércules (POH) theatre development, we always did it in the hard way… just start from ZERO with the DB (rebuilding from the Brand new DB every update).
This is humpering big time the progress, and everytime we do, there is always something forgoten or wrongly done (human mistake)… so we tried to fix something which was not really broken… until we discover our mistake… and so on …

Is there anyway for Developers (theatres or BMS itself) to be a bit more “precise” giving the changelog and how fixes affects the Sim… or how they could be implemented directly into others DB… so we dont have to start it over again? (I´m sure many of you can feel our pain)

Just asking here because I has the sense that ITO was historically keeping up very well with every BMS update/upgrade… specially when we moved towards 4.33.x

I maintain that rebuilding a DB from scratch is the only safe way the make sure a theater is compatible with the main release after anything more then a really minor update - almost never the case - is published. While one could theoretically upgrade an existing DB, even when knowing the DB inside and out, sometimes there is lack of data in published changelogs, or changes are too interconnected (indexes change).
I feel ITO and its previous generations in F4 / AF have been stable throughout the years in part because of this approach.

For the moment I’d definitely recommend keeping an updated list of all the DB changes you have in your theaters and do rebuild the DB for each BMS update. I used this path for years and I feel your pain. If you cannot do that because it’s too much work, limit yourself to KTO’s DB. Obviously it greatly reduces the depth and accuracy of a theater, but not being able to keep in in sync with future versions means such DB work will most likely be rendered obsolete and unusable in the future.

As for ITO updates nowadays, and for automated solutions in general: as the scope of our DB expanded - it currently requires around 1000 DB modifications - it became impractical to rebuild it manually each time, just as you are feeling. Having not found a better solution, I spent several months writing MATLAB scripts that would rebuild our DB from a given KTO DB, so nowadays this process is mostly automated for ITO, which is how we are able to keep up with new releases relatively easily. Now, before you stone me for not releasing it : It requires an experimental BMS feature which is currently not released. But even without that, it also requires reasonable knowledge of MATLAB programming, very good understanding of the F4 DB (KTO’s and your own), has some manual stages and the final product still needs testing. So I wouldn’t call it “the holy grail” of theater building. That said, a much more sophisticated solution is currently in the works (not by me), so do keep your faith…

[Raptor]

@Echo7:

I spent several months writing MATLAB scripts that would rebuild our DB from a given KTO DB, so currently this process is mostly automated for ITO, which is how we are able to keep up with new releases relatively easily. Now, before you stone me for not releasing it : It requires an experimental BMS feature which is currently not released. But even without that, it also requires reasonable knowledge of MATLAB programming, very good understanding of the F4 DB (KTO’s and your own), has some manual stages and the final product still needs testing. So I wouldn’t call it “the holy grail” of theater building. That said, a much more sophisticated solution is currently in the works (not by me), so do keep your faith…

Thank you m8. Having hope for such a tool in the future is the best news after bms release.

[agalnov]

Thanks for the reply.

I played with Matlab in the pass …too much for me on actual days… I´ll wait to BMS tool.

Big time thanks

[Dee-Jay]

Is there anyway for Developers (theatres or BMS itself) to be a bit more “precise” giving the changelog and how fixes affects the Sim… or how they could be implemented directly into others DB… so we dont have to start it over again? (I´m sure many of you can feel our pain)

IMO … the easiest and safest way for theatre Devs to maintain their theatres working along updates without the need of endless binary DB rebuild from scratch … is to use default database and accept some compromises.

[agalnov]

Our compromisses (as long as POH Dev team stay alive) will be always to make it happen… so if Full Rebuild is the only way… we will have to walk it over and over.

Thanks mate.

[Mystic_J]

@Dee-Jay:

IMO … the easiest and safest way for theatre Devs to maintain their theatres working along updates without the need of endless binary DB rebuild from scratch … is to use default database and accept some compromises.

True, this would be the easiest way. Regarding the Ikaros theater we have passed the point of no return. That means lots of work and DB editing in 4.33 U1. So, we have agreed to implement only the U2 or U3, U4 etc. features that are / will be relevant to the theatre. A full scratch rebuilding will be done in 4.34.

I believe the same path will be followed by other major theater creators, otherwise we will stuck forever in development.

[Arty]

@Dee-Jay:

IMO … the easiest and safest way for theatre Devs to maintain their theatres working along updates without the need of endless binary DB rebuild from scratch … is to use default database and accept some compromises.

Sorry but this is not the only way.

We have talked thoroughly in this forum about it I believe.

If theaters are stack with default database only then there is no uniqueness, no differentiation than terrain and TE.
In that way the database should be locked or not in a structure that theater creators could adjust it as previously. I mean before 4.33.

So avoiding a database tool to easily make theaters compatible with new versions of BMS ain’t the way I believe.

If theater guys start updating and in the meantime adding altering etc they will release for a few months and then a new bms version and ok here we go again and again and again…
So at some point re inventing the wheel should be stopped.

[Arty]

Matlab for db edits I see trouble….

Sent from TapaTalk

[Raptor]

@DeeJay

If the Greek and Turkish communities would be blessed in the future bms releases to have unique F-16 airframe records in the stock database, for our 4 main HAF aircraft versions, as and the respective 4 THK ones, then that would be more than enough to help reduce in half the necessary time for our theater mods. Now we have only one “generic” version with/without CFT’s (representing a single-seat HAF PXIII bird), and to be honest, that would help not only Ikaros, but other area theaters like EMF and Aegean the same way. Just like ITO has populated its unique airframes for Netz, Barak’s and Sufa, single-seats and two-seaters.

(And if, as my hopes, one day we get the CFT’s implemented properly as external tanks with the relevant code, and not requiring a full airframe model only to represent the CFT version, this would also help reduce the records. But that’s another story.)

So m8, can you please at least pass internally this personal request, if devs can consider and evaluate such an addition for the future? Please?

[cannon]

Please release a useful DB-conversion/adaptation tool soon.
As we (theater devs) respect your work, consider you guys respecting ours.
This endless developing really discourages other than Korea’s theater devs…

It would be much wiser to stop releasing Ux updates, or even 4.xx versions if no conversion/adaptation tool is included.

Along with the FalconBMS as a super-duper simulation software, THEATERS variants are the two key elements that keep the falcon community still alive. Remove one, Falcon dies.

[Raptor]

I do agree, BUT, i consider more valuable to have the proper assets (F-16’s) in the stock db, just like ITO.

[Arty]

And because we are not so crazy and we understand the pain the BMS team has to deal with and we know how much effort and time needs a database tool for theaters compatibility. I believe it would be, for a first stage, easier to have excel import and export.
Something like that will be needed for the db tool we talk about also I believe, so the work for such excel import export will not be in vain.
Having this feature I believe it will not be ideal but for sure can help greatly to manage such changes , spot them in the blink of the eye and import back what the theater team wants. By this what will remain would be the 3ddb issue but it would be better than nothing.
Even for the 3ddb a same tool will help by knowing previous records and new records in excel. The dev will easily know what and where to do it.

[cannon]

@Raptor:

@DeeJay

If the Greek and Turkish communities would be blessed in the future bms releases to have unique F-16 airframe records in the stock database, for our 4 main HAF aircraft versions, as and the respective 4 THK ones, then that would be more than enough to help reduce in half the necessary time for our theater mods. Now we have only one “generic” version with/without CFT’s (representing a single-seat HAF PXIII bird), and to be honest, that would help not only Ikaros, but other area theaters like EMF and Aegean the same way. Just like ITO has populated its unique airframes for Netz, Barak’s and Sufa, single-seats and two-seaters.

(And if, as my hopes, one day we get the CFT’s implemented properly as external tanks with the relevant code, and not requiring a full airframe model only to represent the CFT version, this would also help reduce the records. But that’s another story.)

So m8, can you please at least pass internally this personal request, if devs can consider and evaluate such an addition for the future? Please?

+1