-
We have updated our Community Code of Conduct. Please read through the new rules for the forum that are an integral part of Paradox Interactive’s User Agreement.
Let's say it's a friendly warning to everyone...Fireblade said:lol Havard, your sig.. is that what you PM to people right before you ban them?
I was talking about the border problem southwest of the block you've highlighted. It shows up in the game when a different nation owns Macedonia and Bulgaria to the nation that owns Thrace.Inferis said:
EDIT: by the way, what I call province descriptors is what you call the IDList.
This looks really fantastic, much easier than what I have which is a listbox filled with all of the quadleaves.Inferis said:
Johan did mention that id.tbl is an artifact from the production process. I myself use it for hit testing, as the data is accurate enough for that. But it is filled with faults, not least that the border lines are empty. AFAIR, they are not 0s as you said above, but they are not even defined. Also, every 64 blocks horizontally and vertically there are undefined lines running straight across the whole map.Inferis said:I found out that the border values have id 0: terra incognita.
This is the fault of id.tbl, which has id 0 on the borders, and which is used in the tree coding algorithm. Those 0s should actually have the correct province ids.
Solution: generate my own id.tbl from the lightmap1.tbl data. Quite feasible, and still part of my original plan, but I hadn't done it yet because it takes some work. The same applies to the bordermap. I'd better do these first, then.
Johan, is the id.tbl shipped with EU2 the version used for creating the lightmaps? Or shouldn't I be getting the info from that file?
If I were you, I'd regenerate the whole thing. Even though I still don't understand why you want to use it at all...
Yeah, it was quite a help in getting things right.WiSK said:
Wasn't very difficult to code either: I store the quadtrees as actual trees after loading a block, and my object model has a few methods for easy traversal. This approach has paid of more than once. Only disadvantage is that it takes up more memory, but in the context of an editor this isn't much of a problem.
WiSK said:
True.
WiSK said:If I were you, I'd regenerate the whole thing. Even though I still don't understand why you want to use it at all...
Well, you need to. The border pixels need to be encoded with the nearest land province available, and the id.tbl data is the only source I have for finding out what the nearest land pixel is. You can't use adjacent.tbl for this, as it's too inaccurate.
Ultimately, it is up to the user using the editor to provide this info himself. In this case, we can rely on the existing data since we're not modifying province shapes. The ulitmate test of "the editor" will be starting from an empty map and create something new from that point, and see how EU2.exe likes it.
Also, Johan: is there a reason the borders are stored using 2 values (the "color" value in the explanation on my webpages)? AFAIK, the engine doesn't differentiate between them when drawing the map. I guess it's a leftover from earlier development.
If so, does that mean I can safely ignore the value and make it always have a 0 or 1?
If so, does that mean I can safely ignore the value and make it always have a 0 or 1?
I was also wondering about this. I did a test the other day, whereby I removed all references to descriptors which have the color bit set. Well not removed exactly, but replaced with the corresponding descriptor with no color bit set. Anyway, it worked fine in EU2. Borders looking exactly the same as they did before.Inferis said:
However, I didn't try yet to remove the actual descriptors from the IDList, but I have enough methods implemented to be able to do this and repack the lightmap. I'll try it tonight if you want.
I don't see those. Perhaps you have another version?WiSK said:
Below some (resized) screenshots from a quick hack to my program that visualises ids.
Generated from the lightmap:
From id.tbl:
Differences (marked in red):
Visuals:
Note the difference at the top of Scotland: the islands are absent in the lightmap data, but they do show in id.tbl. This leads me to think that id.tbl isn't quite up to date as it should be. There are more examples, for example a small island near the Azores too.
I hope Johan can clear something up?
More likely is that I'm doing something wrongInferis said:I don't see those. Perhaps you have another version?
Here is an example of the line running through Jutland and Skane.
Every 64 blocks you say: that's 64x32 = 2048. Quite coincidentally the size of the blocks in idgrid.tbl.WiSK said:More likely is that I'm doing something wrong
Here is an example of the line running through Jutland and Skane.
I'll check my algorithm for id.tbl decoding to see if I can find these... It's weird they don't show up for me...
I don't know why I said 'every 64 blocks' because it's not true. I had a closer look, and the lines seem to extend wherever there is a border starting from the left side of the map. So I'm more and more convinced I'm doing something wrong nowInferis said:Every 64 blocks you say: that's 64x32 = 2048. Quite coincidentally the size of the blocks in idgrid.tbl.
I'll check my algorithm for id.tbl decoding to see if I can find these... It's weird they don't show up for me...
That's enough for me!!!! Thank you, InfeGodris!!! Can't wait to change "Artois" into something better, and to get "Brabant" the Hell outta there!
Oh well...can't have everything, but seeing the Jaron province, my hopes are higher than even I expected!
P.S. Yeah, I know this post is two pages late, but c'mon, I am bringin in my own opinion. GREAT WORK, WiSK and INFERIS!!!!!!
Th :rofl:
Inferis, IIRC, those islands aren't coloured in in the game.Inferis said:I don't see those. Perhaps you have another version?
Below some (resized) screenshots from a quick hack to my program that visualises ids.
Generated from the lightmap:
From id.tbl:
Differences (marked in red):
Visuals:
Note the difference at the top of Scotland: the islands are absent in the lightmap data, but they do show in id.tbl. This leads me to think that id.tbl isn't quite up to date as it should be. There are more examples, for example a small island near the Azores too.
I hope Johan can clear something up?
Perhaps the differences between the two files could be related to the fact that one does the colouring in of the map, while the other does the graphics borders of the map or something? I dunno
Those islands are coloured in blue by the game. I think there is something to do with id.tbl in the map rendering code.
tombom said:
They are coloured in blue because they are a part of the sea zones surrounding them, and aren't counted as actual provinces.
At least that's my guess.
Yeah, that's what I was meaning to say, that they aren't coloured as part of the province, but as part of the sea.Hive said:
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.
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.
So Inferis, will we be able to build a whole new map when your program is finished?
I would LOVE to get started on cooking up something with anybody else who is interested, right now.
I would LOVE to get started on cooking up something with anybody else who is interested, right now.
x-1 or something?Inferis said:As you can see, I solved the border problem. You own fault, I was using a wrong offset somewhere when saving the file.
Not possible just to use the quadtree to make smaller blocks? That was my plan anyway. Any good reason to shelve it?Inferis said:
Yes, but for the ones who do, we hang on your every word...Inferis said:
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!
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!