More than three.

[NoQ]

Just how are these applied, anyway?

cd to the src/ folder and run

Code: Select all

patch -i file.patch

where file.patch is the full path to the patch you downloaded. You don't need to specify the files to patch. Don't forget to make. To patch addon.lev, cd to the data/mp/ directory instead.

If you build wz from git,

Spoiler:

you can use

Code: Select all

git diff > file.patch

to create patch files; any changes you made to the source will be written to the patch. Use

Code: Select all

git status

command to find out what files you changed. These commands are to be executed in the git root. Use

Code: Select all

git reset --hard

to revert all changes.

[Goth Zagog-Thou]

Ahh, very good, thanks. Will apply it immediately.

[NoQ]

Emm, probably

Code: Select all

patch -p1 -i file.patch

in the code root is how it is supposed to be done

[NoQ]

It seems to me that maximum height of 256 is hardcoded in a huge lot of different places in FlaME

[aubergine]

Sounds like a good project for someone to define a constant and go through the code replacing the 256

[Goth Zagog-Thou]

Yep. It really is, and I've likewise not found a way to get even the master branch of FlaME to do different heights than that. We may have to get Flail to change it.

[Iluvalar]

hmm, guys. the height is limited to 256 because it's the maximum you can code in a byte. If you want to increase it further, you gonna need a new map format right ?

[Goth Zagog-Thou]

I thought it was an adjustable value? o.O

If it's hardcoded like that then we'll have to mess with the height multiplier instead. Still do-able. It would break the look of all maps that have come before, and that's not someplace I wanted to go.

[Shadow Wolf TJC]

It seems to me that maximum height of 256 is hardcoded in a huge lot of different places in FlaME

I'm willing to bet that one of these areas has to do with how heightmaps appear.

[NoQ]

Add an .ini file to the map that changes height multiplier, set to default if the file is not found?

[Goth Zagog-Thou]

I thought that was already in. In the old Editworld it was a variable. The absolute maximum was still 255 height though.

[vexed]

Heightmap has always been 256 max.
While it is possible to use the ALPHA channel to add a multiplier, I am wondering why you would need to make huge mountains or deep valleys ?
The path finding routines have a hard enough time as it is.

[aubergine]

I thought PNG greyscale images were 16 bit? I know you can have 8-bit PNGs but most software will default to 16-bit for PNGs (or 32-bit for colour)?

@vexed: I can see one benefit of deep valleys: oceans -- somewhere that naval propulsion can go. And as for huge mountains, they could go outside the playable area of the map to provide a nice mountainous border to the map...

[vexed]

I thought PNG greyscale images were 16 bit? I know you can have 8-bit PNGs but most software will default to 16-bit for PNGs (or 32-bit for colour)?

@vexed: I can see one benefit of deep valleys: oceans -- somewhere that naval propulsion can go. And as for huge mountains, they could go outside the playable area of the map to provide a nice mountainous border to the map...

PNG does support 16 bit grayscale, but Warzone don't at this time.
The problem with high mountains or anything else that is really high is the camera / VTOLs "hug" the terrain, so they would always have to be higher...if you don't have a smooth transition, then you can end up with units inside the mountain.

As for naval stuff, guess we will cross that bridge when we get there.

The current engine is just not up to having huge tall/deep maps, you would get massive performance hits.

[NoQ]

Now that i think of it, tile-*.png files are clearly two-digit. Is anybody sure more than 100 tiles will work?