Battlescape development

[Amunak]

I'd suggest just using save file compression instead of using binary. You could edit it freely if you want, but it won't take up too  much space. There would also preferably be a switch to turn the compression on or off and the game would be able to read both compressed and uncompressed save files. Dwarf Fortress does it this way and it works nice.

[Volutar]

Compression wont help, because yaml loading of 100500 lines of numbers, even if they would be compressed, is very slow.

[hmaon]

I made the binary saves work. Part of the problem was that YAML doesn't seem to actually implement base64 decoding. I had to rip some code out of libb64. Another problem was some confusion when saving 32-bit -1 to an unsigned 16-bit int and then reading it back as 65535. Good times.

Here's the code: https://github.com/hmaon/OpenXcom/tree/binary_saves

I've made a pull request.

[Volutar]

I've faced with IMHO bad battlescape/basescape dimentions naming.
Like:
X = _width
Y = _length
Z = _height

I'm asking for permission to rename them into
X = _Xsize
Y = _Ysize
Z = _Zsize

In sake of better understandability and readability.
so getLength() will be renamed to getYSize()
getLength is actually nonsense in terms of 3d object.

[Daiky]

It's a matter of preference imo, both are used. In fact in 3D modelling tools, like 3D studio max, when creating a box for example, you are asked to enter width/length/height. Because you use these words daily when defining the size of objects, it should be familiar terms.

I don't think it's the most urgent problem in openxcom at the moment, better we spend our valuable time (our _Tsize?) in fixing horrible things like aliens seeing and shooting through the roof of the Skyranger... I was kinda shocked during the last stream, I've never seen that happen before.

[Volutar]

Daiky, there's a hole in skyranger's cabin. And that could (and most probably) happened in xcom1 too. You cannot fix that without fixing MCD files.
voxel22 is slice of level 22 (2nd level, z=20).
from save "losholes" given by warboy.
First person view of what Etherial have saw is on FPSlook.jpg

See, we can do nothing about it. This bug is xcom1 legacy. If you didn't see how this happened before - it doesn't mean it was never happened.

[Daiky]

Volutar, thanks for clarify that one up It must have been something like that.
We probably have to make the discussion of openxcom providing patches to data files active again.

[Volutar]

By searching for cause of this "bug" I've made an eye-shot.
In debugging purpose it could be quite helpful.

[pmprog]

Are those FPS shots something you've added into the battlescape code? or an external util that loads a save game?

[michal]

Looks like it's waiting to be merged

https://github.com/SupSuper/OpenXcom/pull/305

[moriarty]

very cool... that's a very useful tool for tracking down LOS/LOF problems. nice work!

[Volutar]

moriarty, but not terrain-based, since there is no voxel tracing. for terrain "discovery" tile "stoplos" flag used. that's all.

[moriarty]

I'm not sure I get that:
are you saying that for terrain, there's no LOS voxel tracing?
instead the game uses some other algorithm to check if the terrain between a unit and another tile is "in the way"?

what about unit discovery? does the game check for "true" (voxel-based) LOS?

what happens when a hill tile has been destroyed? does it still block LOS?

[Volutar]

unit-unit los/lof is always voxel-based. terrain fov calculation uses tile-based "scan".

[SupSuper]

Volutar, thanks for clarify that one up It must have been something like that.
We probably have to make the discussion of openxcom providing patches to data files active again.

I have no problem with people making fixed version of the data files (just make it separate from the binary release). After all people have been patching the original for ages. It's just me and Warboy found out those patches have their own bugs... so, you know, if anyone actually manages to fix the bugs without introducing new ones, I'm totally all for it.