CATE for 4byte Terrain

[Phoenix711]

Managed to make it work with 4byte terrain.

In my tests, I've succesfully managed to run all the Aegean configs I made before with the first created blank (but converted to 4byte) terrain.

After every step, I've checked the resulting l2 file with TerrainviewLG (4byte version), and had no problems.

I'm sending the EXE to Snakeman and CCC, because I don't want anyone to use it before Snakeman and CCC makes their own tests and approve it for use.

Remember that this is a BETA. It is someone elses code, and I've just tweaked some numbers (from 7 to 9 etc), and some data types (from Integer to Long).

Cheers.

[Snake Man]

Is this compiled from the source code that is available?

[Phoenix711]

Yes.

[ccc]

thanx for the offering ... but i am not good at terrain-making, and i rarely use terrain tools.

just wait SM's comment.

[Sherlock]

If Snakeman doesn't have the time or if you want an additional tester I am available. I have experience with CATE scripts and CATE.

[Closter]

Here in F4Spain we could make good testing with that tweaked tool, if you need it. We are in the process of correcting our CATE tiling, and I can see 1 or 2 things to be made with CATE after hand correction..

[Phoenix711]

OK. Here is the link.

Snakeman had problems with ODS 128 theater so please be careful. I don't want anyone to lose work or data because of this, even I'm using it myself. Just need to be cautious, and make backups between each operation.

http://92.45.21.211//Web_Yayin/Yarasa/PMC/Cate4Byte.rar

Thanks in advance for all the input.

[Snake Man]

Backups? Why?

I never ever run CATE, (can it even be run like that?) that it overwrites the source files. Actually yeah, I don't think you can do that.

You always start from the "first pass" and proceed from there, in my configs there is 7 passes, basically starting from 0 pass to prepare the L2 and then end at 6 pass which is the random tile placement and L2 finalization like the dropping of rivers etc. What happens is I have the initial source L2, the 0 pass produces a new L2 which I'm loading and then choosing 1 pass, then I take the first pass produced L2 and use it as source for ... second pass... and so on. I'm always keeping the initial source file untouched.

THAT is the beauty of CATE and TacEdit TCL scripts which so many people still to this date do not understand... you never ever lose your data as you do the work with CATE / TCL as all the "magic" is on the config/script files.

So I cant think of way how this would destroy someones data

[Phoenix711]

I do the same as you. Just want to warn ppl.

[Luk]

I have used 4byte CATE about 6 times to update X value in last 2 days.
The result was moved(picture is taken aproximately from the center of theater) :
BTW The Eastern border was 3 tiles moved to West.
http://www.maxipicture.cz/verejne/09/43 ... _lores.jpg

I have tried to move X1.bmp (source image) map 3tiles to East.
Here is result - view from East near Balatone lake. I filled the area for reference.
Dots are lightening the position of TDF placed Balaton border (river tiles) - it is the position, where it should be.
Result is moved to East now ....ufff
BTW the Eastern border was ok, but Western coast had the same problem as the Eastern border before.
http://www.maxipicture.cz/verejne/09/43 ... _lores.jpg

I had a feeling already before, that picture is not only moved to West.
It is verified now.
It looks the paterns are generaly ok, but moved/messed? a little bit.
Somewhere moved 3 tiles, somewhere 5? tiles to some direction...

I can say, it is still better, than 2byte CATE 4.17 - result was totaly messed up pattern (colorfull noise).
So converting to 2byte is not solution for me. I have tried 2byte CATE about 5 times.
It looks the BMP rule for handeling X1 value is not well implemented.

Is it possible to solve the acurracy of placement in 4byte CATE please?
Is the acuracy ok in case of tile rules(so the problem is BMP rule only?)?

Luk

[Luk]

I am sorry. This version of CATE works perfectly with X1 value. Problem was solved. It was somewhere between the chair and ....

Luk

[Luk]

It looks the previous reported problem is not my fault at all.
4byte(I am sure also 2byte ver.) CATE has some problem with *.bmp loading (bmp rule).
It works quite fine for the first time - it makes some bad source movement, but it works.
Later it does not work.

Luk

[Luk]

EDIT: A* pythfinding part I was talking about here has nothing to do with file-paths, but features-paths. So there is no relation to bitmap-loading problems.

The next thing is, I have also checked the size of my uncompressed BMPs. They are 4.194.416 in size, compared to 4.195.382 size of SnakeMans BMP files I have seen somewhere. Can this be the reason of the second mentioned problem - moved map?
What bitmap editor did you use Snakeman? PaintShop or Photoshop?

I have just tried to create 2048*2048 bitmap and save it as 8 bit BMP(full-256colours). In all cases I have got 4.195.380 file in size, no matter it was saved in Win/OS2/reversed/unreversed format, no matter which colors I used. The only thing influences the file size - the number of indexed colours in use. Four (4) colours palette makes the file 4.194.376 in size etc...

Luk

[Snake Man]

Hum I think you refer to the Terrainview bitmaps, those are saved by Terrainview. Not sure if there were the terrain type BMP's in the theater development files, I think I did that in ... must have been in paint shop pro (long time ago, now I use photoshop).

[Luk]

I think I have solved both problems.

1st problem - loading a bitmap, loading changed bitmap etc.

Do not use relative paths in your configs. Relative means - "../datas/example.bmp" for example.
Use complete path like "d:/CATE/datas/example.bmp".

With complete paths the CATE works great!


2nd problem - moved result when bmp rules used
Your 8 bit BMP file must have full 256 colour palette. In case you have for example 20 colours in BMP file, you should fill your palette with some "balast" colours to have all colour slots full. Rather do not use "logical" colours ("black, white" named in save dialogue). You can use them as generic colours "rgb 0,0,0" etc.
2048x2048 (128 theater) bmp is fine when 4 195 384 bites in size. Other sizes causes moved result. If you miss few colours in your palette, your result will be moved just few tiles. If your palette is more space-saving, your result can be moved about half of theater...

So mentioned problems are common for all CATE versions and can be easily avoided. It is not 2byte/4byte dependent, neither system dependent.

4 byte CATE version, compiled by Phoenix is great software!

Luk