Hacking the TBL files

[Hive]

I'd better stop rambling now, as most of you don't understand what I'm talking about anyway.

Damn straight.

So when will you start working on shaping new provinces? It is, after all, what we are all waiting for...

 

[unmerged(20844)]

The community will be forever in your debt!

I promise you unseen riches and virgins in Heaven

 

[DSYoungEsq]

P.S. Yeah I know that we'll still have to keep the same number of provinces in total.

Also, is there any chance you could see if your program could be adapted to Paradox's other games, such as HoI? Victoria? CK? or possibly even HoI2?

The community will be forever in your debt!

Best watch out; he does too much and Paradox will put him on the payroll!

 

[Van Engel]

I promise you unseen riches and virgins in Heaven

I promise more.

 

[unmerged(20844)]

I promise more.

what's more than unseen riches and virgins?

go write your AAR kiddo, u cant beat me to this

 

[|AXiN|]

Real riches and virgins?

 

[Nikolai II]

P.S. Yeah I know that we'll still have to keep the same number of provinces in total.

Also, is there any chance you could see if your program could be adapted to Paradox's other games, such as HoI? Victoria? CK? or possibly even HoI2?

The community will be forever in your debt!

IIRC somewhere on the first dozen pages is mentioned that mapsystem changed somewhere along the way.. (Just look a few posts below any of the other three-four people who have asked to use same method for adapting Vicky/CK/whatever maps by this method )

 

[Inferis]

x-1 or something?

No. Moving coordinates on a block before encoding instead of after enooding. No wonder you get the wrong results then.

Not possible just to use the quadtree to make smaller blocks? That was my plan anyway. Any good reason to shelve it?

I'm not sure what you mean...

Yes, but for the ones who do, we hang on your every word...

o

 

[Inferis]

Damn straight.

So when will you start working on shaping new provinces? It is, after all, what we are all waiting for...

One thing at a time, my friend.

 

[tombom]

Very interesting. Nice that we are seeing your progress now. And I like listening to ramblings.

 

[Chas]

Real riches and virgins?

Where's anyone gonna find a real virgin?

 

[Hive]

One thing at a time, my friend.

But that's too slow...

You need more arms.

 

[Inferis]

But that's too slow...

You need more arms.

Money would help too.

 

[Vricklund]

But that's too slow...

Yeah, that came out of the right mouth.

And Inferis - I'm sure there are people around willing to donate using VISA or whatever. Probably not much, but something to show appreciation for all your hard work. Good luck trying to squeeze a Krona out of Hive though.

 

[Van Engel]

what's more than unseen riches and virgins?

go write your AAR kiddo, u cant beat me to this

I promise more than what he promises and you don't read my AAR anyway or do?

 

[Summoner]

Originally Posted by WiSK
Not possible just to use the quadtree to make smaller blocks? That was my plan anyway. Any good reason to shelve it?

I'm not sure what you mean...

Combine 4 adjacent quadtrees into a single 64x64 tree, traverse the tree, combining each set of 4 single pixels into a 2x2 node, and then write it with the 64x64node a 32x32, the 32x32s as 16x16s, .....

 

[Inferis]

Combine 4 adjacent quadtrees into a single 64x64 tree, traverse the tree, combining each set of 4 single pixels into a 2x2 node, and then write it with the 64x64node a 32x32, the 32x32s as 16x16s, .....

But that's useless since the blocks are encoded the same way as on lightmap1.tbl. They just contain "smaller" provinces and there's a lot less of them.

 

[Coder]

Ein small update...

As you can see, I solved the border problem. You own fault, I was using a wrong offset somewhere when saving the file.

Secondly, I have generated a new id.tbl from the lightmap data, and it fired up EU2 afterwards. Didn't seem to pose a problem, although I didn't play long.

Next step: do lightmap2.tbl and lightmap3.tbl. Is not a straightforward as it may seem. For example, for lightmap1.tbl I can just reference id.tbl, as it's on the same scale. For the zoomed versions, I need to properly scale down id.tbl too. I was thinking of using every other/every other 2 pixels, but that will yield inaccurate results. Thus some proper reduction is in order (ie selecting the most prominent ID for a stretch ID values).

I'd better stop rambling now, as most of you don't understand what I'm talking about anyway.

why use the id.tbl at all? what's the use?
you have all the ownership info in the lightmap files...

 

[Hive]

why use the id.tbl at all? what's the use?
you have all the ownership info in the lightmap files...

I believe Inferis mentioned that it was written in a simpler way in id.tbl...

 

[Inferis]

I believe Inferis mentioned that it was written in a simpler way in id.tbl...

Yes. Besides, when rebuilding lightmap.tbl you don't really have all the information to use freely. So you build an id.tbl from lightmap.tbl and use that when regenerating.
But you still need id info, and it doesn't depend where you get if from.

By the way, importing and exporting zoomed maps works, but I have a problem with said id.tbl. Some borders dissappear, most likely due to a granularity problem due to the enlarged block size (a 32x32 block on lightmap3.tbl is 128x128 on id.tbl, and that yields somewhat incorrect data.

Solved soon, I guess.

After that: reworking my BlockVis program into an import/export program so that it can be used to rework province names.