Confirmation needed for VietnamSea_Targets.INI for Patch 8.30.06

[+swambast 722]

Hi all,

 

I am currently adding some very complex error array checking within my Swambast Target Translator program. It basically parses out all areas and checks for proper target sequencing for every single target area. Now, I use a lot of test VietnamSea_Targets.INI files, so was not surprised to see at first a lot of errors pop up. BUT - when I loaded what I thought was the original VietnamSea_Targets.INI directly extracted from the Master VietnamSEA.CAT Extracts for Patch 8.30.06, I was VERY surprised to see STT report out errors!!! Anyway, is it at all possible that TK shipped the original VietnamSea_Targets.INI with errors - or did something go wrong with my CAT extracts...?

 

Can someone kindly please double check this for me, using the VietnamSea_Targets.INI directly extracted from VietnamSEA.CAT for Patch 8.30.06?

 

Here is JUST ONE EXAMPLE (there are other TargetArea errors reported out as well) of the STT error:

 

"Sequencing Error in TargetArea123: Vinh Airfield - Last Tgt Object was 050 but was expecting 044"

 

and when I review the VietnamSea_Targets.INI, sure enough here is what I see:

 

[TargetArea123]

Name=Vinh Airfield

.

.

.

Target[042].Type=blastshield

Target[042].Offset=518.60,-221.40

Target[042].Heading=270

Target[043].Type=blastshield

Target[043].Offset=518.60,-295.60

Target[043].Heading=270

Target[050].Type=vBarrack1

Target[050].Offset=621.86,-226.03

Target[050].Heading=90

[+comrpnt 16]

Hi all,

 

I am currently adding some very complex error array checking within my Swambast Target Translator program. It basically parses out all areas and checks for proper target sequencing for every single target area. Now, I use a lot of test VietnamSea_Targets.INI files, so was not surprised to see at first a lot of errors pop up. BUT - when I loaded what I thought was the original VietnamSea_Targets.INI directly extracted from the Master VietnamSEA.CAT Extracts for Patch 8.30.06, I was VERY surprised to see STT report out errors!!! Anyway, is it at all possible that TK shipped the original VietnamSea_Targets.INI with errors - or did something go wrong with my CAT extracts...?

 

Can someone kindly please double check this for me, using the VietnamSea_Targets.INI directly extracted from VietnamSEA.CAT for Patch 8.30.06?

 

Here is JUST ONE EXAMPLE (there are other TargetArea errors reported out as well) of the STT error:

 

"Sequencing Error in TargetArea123: Vinh Airfield - Last Tgt Object was 050 but was expecting 044"

 

and when I review the VietnamSea_Targets.INI, sure enough here is what I see:

 

[TargetArea123]

Name=Vinh Airfield

.

.

.

Target[042].Type=blastshield

Target[042].Offset=518.60,-221.40

Target[042].Heading=270

Target[043].Type=blastshield

Target[043].Offset=518.60,-295.60

Target[043].Heading=270

Target[050].Type=vBarrack1

Target[050].Offset=621.86,-226.03

Target[050].Heading=90

Hi Steve, confirmed. I see the same thing from the extracted _targets.ini for that entry, from that version of WOV:

 

[TargetArea123]

Name=Vinh Airfield

...

Target[043].Type=blastshield

Target[043].Offset=518.60,-295.60

Target[043].Heading=270

Target[050].Type=vBarrack1

Target[050].Offset=621.86,-226.03

Target[050].Heading=90

 

Regards, Paul.

[+swambast 722]

Paul, thanks for the prompt reply - I kept double-checking my code and my files and questioning whether it was right - I guess you just confirmed that. That is really an interesting find to me - I wonder if future .INI entries are also incorrect such as in the new SF2V? Would be great is someone could check the new .INIs!

 

Here is the rest of my array error report, and you can clearly see the common trend of where multiple errors are made due to attempting to copy/paste erroneous target area entries:

 

Sequencing Error in TargetArea114: Gia Lam Airfield - Last Tgt Object was 050 but was expecting 044

Sequencing Error in TargetArea116: Kep Airfield - Last Tgt Object was 050 but was expecting 044

Sequencing Error in TargetArea117: Khe Phat Airfield - Last Tgt Object was 050 but was expecting 044

Sequencing Error in TargetArea118: Kien An Airfield - Last Tgt Object was 050 but was expecting 044

Sequencing Error in TargetArea119: Na Son Airfield - Last Tgt Object was 050 but was expecting 044

Sequencing Error in TargetArea120: Noi Bai Airfield - Last Tgt Object was 050 but was expecting 044

Sequencing Error in TargetArea121: Quang To Airfield - Last Tgt Object was 050 but was expecting 044

Sequencing Error in TargetArea122: Quon Lang Airfield - Last Tgt Object was 050 but was expecting 044

Sequencing Error in TargetArea123: Vinh Airfield - Last Tgt Object was 050 but was expecting 044

 

I think I will also post my findings at the Thirdwire forums just to let TK know...and maybe even just use STT to fix all the errors and send him the updated .INI file. I guess he would really appreciate that...?

[+Dave 2,322]

Unless it is like that for a reason? Like he took something out? It is interesting that the error is common.

[FastCargo 412]

Well, couple of other questions are if that was changed in the Oct 08 patch or SF2 versions, and does it affect gameplay.

 

I know for a fact that in certain ini files, as long as there aren't duplicate entries, you can have 'gaps' in counts. SystemNames in data.ini files come to mind.

 

Good find anyway...anything that can make it easier to sort through ini files is a boon.

 

FC

[+PureBlue 71]

FC is right these missing entries are filled in for the WOV 08 Patch. And the target areas you listed, that gave errors, have continuous numbering. (Mostly vBarrack1 for the target objects 43 thru 49)

I compared the SF2V Cat and WOV 08 Patch, _Target.ini. The two main differences were:

 

1)

SF2V has some objects with ActiveDate=MM/YYYY

WOV with ActiveYear=YYYY

 

2)

SF2V has a few target areas with the definition starting:

AirfieldDataFile=vietnamSEA_airfield1_NV.ini

NumSquadrons=3

Target[001].Type=Runway1_NV

 

WOV has the same areas with this:

AirfieldDataFile=vietnamSEA_NVairfield1.ini

NumSquadrons=3

Target[001].Type=Runway1

 

 

The two target.ini are essentially the same. (The Runway1_NV has a darker runway texture then Runway1)

Edited September 10, 2009 by pureblue

[+swambast 722]

Thanks for the update!

 

So, I guess at this point my question is this: is there any value in performing such an "integrity" check? Even though I have it coded to use an array, obviously this will come with a slight performance hit and if it only impacts a minority of "old" .INIs would it still be valuable? I'd like to hear your opinions, and appreciate the feedback.

[+PureBlue 71]

Steve, I think it could be useful as a separate function.

Perhaps, For performance reasons don't include it in the normal conversion process but have it as a separate button that Modders can click and "check integrity" before releasing a terrain.

 

I have to check but if you have missing target objects in between, the rest of the target area is not rendered.. (?)

Sometimes when doing manual editing of the target.ini w/ notepad, it's possible to make a typo/mistake/deletion and not notice it. (Especially after staring at this file for a whole night, getting cross eyed!)

And if this mistake is in an area you are done and tested already, you'll never notice it, until somebody else points it out..

[+swambast 722]

...have it as a separate button that Modders can click and "check integrity" before releasing a terrain.

 

Umut, that is a great idea - I think that is exactly what I will do then! Great suggestion...

 

I have to check but if you have missing target objects in between, the rest of the target area is not rendered.. (?)

 

Yes, I am almost positive that is correct - it will only render the last properly sequenced entry.

 

That sounds like the way to go...I'm going to move forward with this idea, always good to have options...right?