Brutal-OXCE 9.2.6

[Meridian]

NUL is \x00. So you seeing 2 is probably a result of some sort of UB. The actual value of that variable is 0.

I was seeing 2 (character '2', not number 2), because I was loading the broken BOXCE 9.2.2 save, not an OXCE save. Sorry for the confusion.

Anyway your fix makes sense and works, @Xilmi: see attached.

With this fix, I can load any OXC/OXCE/BOXCE save... except for the broken/incompatible BOXCE 9.2.2 saves.

[Yankes]

I think one change we should do here, this check should be in `unserializeInt`, this mean switch should have `case 0:` too.
This is useless for old properties but any new will benefits from simpler code.

On other hand, if OXCE add new property then it break BOXCE. Overall current handling work only good for "linear" backward-forward compatibility.
Any "forks" will easy break saves.

I think if better would be split binary data in separate buffers that are loaded by name:

Code: [Select]

binTiles:  AAAAAAMAGAAbAAQAAQABAAEAAQAAAAABAAAAAwD//xwABAABAP//AQABAAAAAAIAAAADAP//GwAEAAEA//8BAAEAAAAAAwAAAAMA//
binExtended:
   OXCE_X1: AAAAAAMAGAAbAAQAAQABAAEAAQAAAAABAAAAAwD//xwABAABAP//AQABAAAAAAIAAAADAP//GwAEAAEA//8BAAEAAAAAAwAAAAMA//
   OXCE_X2: AAAAAAMAGAAbAAQAAQABAAEAAQAAAAABAAAAAwD//xwABAABAP//AQABAAAAAAIAAAADAP//GwAEAAEA//8BAAEAAAAAAwAAAAMA//
   OXCE_X3_V2: AAAAAAMAGAAbAAQAAQABAAEAAQAAAAABAAAAAwD//xwABAABAP//AQABAAAAAAIAAAADAP//GwAEAAEA//8BAAEAAAAAAwAAAAMA//
   BOXCE_N2: AAAAAAMAGAAbAAQAAQABAAEAAQAAAAABAAAAAwD//xwABAABAP//AQABAAAAAAIAAAADAP//GwAEAAEA//8BAAEAAAAAAwAAAAMA//
   FTA_Z: AAAAAAMAGAAbAAQAAQABAAEAAQAAAAABAAAAAwD//xwABAABAP//AQABAAAAAAIAAAADAP//GwAEAAEA//8BAAEAAAAAAwAAAAMA//
At least now compatibility problems will be reduced to having unique names in all forks.

Question is there is use case where storing size of data is useful? aka 2byte vs 2byte or 4byte. If old code try load it, it do not have enough space it store it it will be truncated anyway.

[Meridian]

I think if better would be split binary data in separate buffers that are loaded by name:

We can recommend that for future forks, but it won't help here anymore (for those 3 existing fields anyway).

[Yankes]

Yes, this is not solution for current problem but when we try add new field to tile we need consider BOXCE too.

[Xilmi]

aaaa, this is new property that is not in OXCE, this mean my previous comment is not accurate. This mean OXCE save should not have it.
But this save was generated by OXCE? Should this save be from BOXCE?

Yes, the purpose of these is simply for the AI to remember at what turn it has scouted each tile on the map. This is used in AI-code for determining where to search for enemy-units.
Basically the longer ago a tile was scouted, the more likely the AI thinks enemy units are there.

[Xilmi]

I was seeing 2 (character '2', not number 2), because I was loading the broken BOXCE 9.2.2 save, not an OXCE save. Sorry for the confusion.

Anyway your fix makes sense and works, @Xilmi: see attached.

With this fix, I can load any OXC/OXCE/BOXCE save... except for the broken/incompatible BOXCE 9.2.2 saves.

Thanks!

Works wonderfully!

I am really grateful for the support you provide to help me maintain this fork!

[AndyFox]

Suggest adding two lines to common\Language\OCXE\ru.yml:

STR_NO_CRAFT_FILTER: "В транспорте"
STR_NOT_ASSIGNED: "Не назначен"

[Xilmi]

Suggest adding two lines to common\Language\OCXE\ru.yml:

STR_NO_CRAFT_FILTER: "В транспорте"
STR_NOT_ASSIGNED: "Не назначен"

Added in my repo but won't make a new build for this.

[Delian]

I don't think you need to include yaml-cpp.dll in the releases anymore.

[Xilmi]

I don't think you need to include yaml-cpp.dll in the releases anymore.

Can I remove both yaml-cpp and yaml-cppd or do I need to keep the latter?

[Delian]

Yes. If your build still somehow relies on yaml-cpp, then it wasn't rebased correctly.