Which theaters are compatible with 4.33U1 ?
-
Considering objetice qty. limitations and ATO such large theaters are practically impossible.
-
Considering objetice qty. limitations and ATO such large theaters are practically impossible.
I was afraid that you would reply that, Molnibalage… but thanks for your frankly way of explaining matters. “I had to ask the same”, to tell you my position in short.
Best regards,
-
About Ikaros theater
version Ikaros433_v2_2 is compatible with 433 but old.
The version IKAROS_v3 is compatible with 433 and is newer and better.
I thought that is very logic if the older version v2_2 is 433 compatible of course the newer version v3 is also 433 compatible.
But if moderators believe that must be writen as IKAROS433_v3 please change the folder name because I can’t and please correct the link in the first post to the newer version 3.
Thank you
sparta -
First post updated.
As you said, no real need to update the title of the Ikaros v3 thread. If people still have a doubt, they will see the installation instructions are for 4.33
-
Could you folks revise the list and make it for theatres that are compatible with BMS 4.33 Update 1?
-
+1, it would be particularly useful at this time.
With many thanks and best regards,
-
Done. ATM I have Cougar’s Balkans, ITO, and Korea 2012 in the list, tell me if I missed any.
-
what are the differencies between 4.32 - 4.33 - 4.33 U1 regarding compatibility? Just few sentences please.
-
Database Heights I believe those 2 are enough.
sent from my Xperia Z3 compact via TapaTalk
-
I do not have better idea than posting here. After 4.33 and U1 how can adapt their theaters so fast the 3rd party theater makers? What tool or method were use? Is ther any way to make usable 4.32 DB changes to 4.33 without doung manually again the whole DB work?
To me it takes 1-2 years to make a MOD on level what I wish. Considering the life span of a major BMS4 varaiant (4-5 years) is very painful to do again and again the same.
-
Falcon Editor.
Export from 4.32
Import from 4.33Of course where ever this is available.
-
I am a little confused, what exactly causes a previous version like 4.32 to not work with 4.33? What exactly gets busted, causing crashes or what? What is the fix, is it Step 1, 2, 3, , , , etc different across every theater?
-
I am a little confused, what exactly causes a previous version like 4.32 to not work with 4.33? What exactly gets busted, causing crashes or what? What is the fix, is it Step 1, 2, 3, , , , etc different across every theater?
The problem is I recycled many DB entries of 4.32 and in 4.33 can be elements what with same CT and other entires are the same but are used for different role. For ex. now we have ECM pods and chaff/falre pods with unique ECM values - even all AC and pod have the same value but now you can set up different - etc.
-
Molni - are you doing DB now? I know you like spreadsheets, you sent me enough of them, hehehe.
The way I keep things sorted is do a total assessment of the DB - break it down by CTs, parents, models, skins, Flight models etc, all on Excel spreadsheets - so that you know what connects with what - that is the only way I an keep from introducing conflicts as I step my way thru a DB with new material. I keep a detailed change log of every DB edit session and test it, clearing all the crashes and bugs each time before moving forward. I have found that being systematic like that avoids fixing one thing but breaking another. Falcon is very interconnected.
-
Molni - are you doing DB now? I know you like spreadsheets, you sent me enough of them, hehehe.
The way I keep things sorted is do a total assessment of the DB - break it down by CTs, parents, models, skins, Flight models etc, all on Excel spreadsheets - so that you know what connects with what - that is the only way I an keep from introducing conflicts as I step my way thru a DB with new material. I keep a detailed change log of every DB edit session and test it, clearing all the crashes and bugs each time before moving forward. I have found that being systematic like that avoids fixing one thing but breaking another. Falcon is very interconnected.
Currently I’m not working on anything and I did not documented everything becaues it would take forver creating the theater.
Funny thing I do not ever remember I how created exactly the JP-233 usage in my MOD what was explained by WaveyDave 5-6 years ago.
-
Molni,
There very first rule of DB for me is to create a ton of spreadsheets, extract all the raw data and put into those sheets - then, when you wan to make an edit - your ensure your edit doesn’t share one single data point with any other item. Otherwise you wind up chasing your tail. Yes, the spread sheets take a while to put together, but once you have them the pay big dividends and most all your edits then work without causing crashes.
The other really good thing is late at night, you can, with a cup of Earl Grey tea, sort the various spreadsheets in different rows to check for data entry errors - I found a lot of errors where a digit was dropped or somehow a 0 or 255 pops up like a sore thumb that doesn’t below. Once you look at the data long enough you begin to recognize obvious errors or when common entities are hugely different and have no reason to be.
Currently I’m not working on anything and I did not documented everything becaues it would take forver creating the theater.
Funny thing I do not ever remember I how created exactly the JP-233 usage in my MOD what was explained by WaveyDave 5-6 years ago.
-
You read the matrix not see it.
There is no spoon Neo.Nice one. But excel for the extent falcon db has I believe is not the way.
Maybe good to work on specific things or if no other tool available. But bms team might leap and I’ll be left looking those spreadsheets for looooooong.Sent from TapaTalk
-
Molni,
There very first rule of DB for me is to create a ton of spreadsheets, extract all the raw data and put into those sheets - then, when you wan to make an edit - your ensure your edit doesn’t share one single data point with any other item. Otherwise you wind up chasing your tail. Yes, the spread sheets take a while to put together, but once you have them the pay big dividends and most all your edits then work without causing crashes.
The other really good thing is late at night, you can, with a cup of Earl Grey tea, sort the various spreadsheets in different rows to check for data entry errors - I found a lot of errors where a digit was dropped or somehow a 0 or 255 pops up like a sore thumb that doesn’t below. Once you look at the data long enough you begin to recognize obvious errors or when common entities are hugely different and have no reason to be.
Next time maybe I follow this way in case will be next time, but the problem is I would make a table only for relevant DB changes not for all DB values because what I do not change is not important for the MOD. The problem in case anybody wish to integrate new stuff from later DB. This is the problem. Manually doint this kind of Excel table creation is simply so time consuming…
Is the any way export the whole DB (different tab values and CT values) to Excel tables?
-
yeap time consuming but ensures legacy.
For me every dev or modder should have and use.
Once he stops or leaves something in the middle with full record of his work and steps another one can jump in and continue from where the other left. This in case we want to share for the common good, and not just go for the personal credit gouhooouuu goohooou.Am sure lack of those info or comments drive manual or guides ppl nuts… RedDog am sure was pulling his hair in the process of writing the manuals…
I know it’s a killer and boooooring and rather extend the work or add to the work but equally valuable.Imagine Ranger822 now giving models away with no info on dofs switches tex sets scripts hitbox values etc… would they be usable? or how much more time will be needed to rediscover the wheel?
-
yeap time consuming but ensures legacy.
Even if I made such table in case of CT and other later conflicts I cannot do anything… With F4B I could make a copy of existing battalion, sensor or anything and F4B do the most of the work to avoid conflitcs, I just had to give the right value to give good unit icon, setting good battalion properties, recalt of battalion stats., link IR sensor to new missile, etc. But I never was able to delete or doing anything if cometing had bad cross references in DB…
I apllied some very basic steps over and over and the result was my MOD with totally different DB which provided totally different environment.