-
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.
What I'm wondering about.. would *edited* map files be incompatible with stock paradox files? (as far as I can tell, they do not change gamePLAY, just the way it's shown, I might ofcourse be mistaken)
ForzaA said:
They would only be incompatible if you start moving Siberian provinces into other parts of the world. What they are planning in the AGCEEP for example will definitely be incompatible with the stock files, but that's okay because the AGCEEP runs in it's own folder (via moddir), and there will just be a separate AGCEEP map folder which doesn't interfere with the standard map.
On the other hand, I'm sure people will want to produce maps that are compatible with the stock EU2 scenarios. As long as they only change the graphics and not the province positions then it will all work okay.
WiSK said:
They shouldn't be CtD incompatible either - only incompatible as in 'will produce very very strange and confusing results..'
As promised, a screenshot of the connection from Kazan to Igrim. Compared to the original screenshot I posted in the AGCEEP section, this one doesn't have the problem with messy graphics along the Volga River.
WiSK -- i have a suspicion that the moddir doesn't work for lightmap files... you're going to have to make a special request to Johan to get him to do that....
XieChengnuo said:
It's okay, it works (check the screenie two posts up)
EDIT: Okay, what I've been doing for the last few hours is making the View connections page a bit more user friendly. I also spent some time making saving faster and I gave it a couple of those nice progress bars. Saturday it was taking about 3-4 minutes to save because it was unpacking and repacking the whole map. Now it only repacks in the areas when you've changed some connections. The result is that it only takes 20 seconds to save now.
Last edited:
yeah, with a little picture of some russian army crossing over pti in it. very nice work wisk.
-Matt
-Matt
Update:
Of the few hours I had this evening, I spent most of them thinking. I have to make a decision similar to one Inferis wrote about quite some time ago.
It comes down to the fact that the map is too large to hold in memory if you want any chance at editing it. Just viewing it is not a problem, because you can leave it compressed and it's only 20 megs. But when you unpack it it becomes much larger. Huge in fact. Even a semi-compressed map might be around 250 megs minimum. There'd be enough swapping to virtual memory to drive you crazy. Pun intended.
The way Johan chose to approach the problem (AFAIK) was to only write a program to convert from Illustrator/Photoshop directly into the EU2 files. It's a smart system for the programmer because you don't have to hold the whole lot in memory at the same time, you can do a bit at a time. However, I'm not sure it's ideal for the user. You want to scroll around the map, paste a chunk here, a chunk there, fiddle with some borders, etc. You also kind of want to see it 'working' in the editor before testing it in EU2, not just blindly hoping that the export went correctly. Such a system would also mean some prior knowledge about the way the maps are encoded, so there'd be many users asking questions like 'why does the program not export my maps correctly?' So ideally you want a full editor that can read from and write to the map with the compression being fairly transparent.
There's the middle of the road option as well, which I think is what Inferis was considering. A sort of half-conversion into a format which doesn't have the disadvantages of working with compressed files, but you'd still have to repack everything before you can load it into the game.
Another thing is that, as I'm progressing with the program, my goals are getting more grandiose. Only a few days ago I posted that I just want to connect some provinces and change some province names. I'm struggling to stick to this. On the one hand, I don't want to try to run before I can walk, but on the other hand, I don't want to be writing code that will hardly be used.
So my conclusion is that I need to think some more... hopefully there's not much on at work tomorrow
Of the few hours I had this evening, I spent most of them thinking. I have to make a decision similar to one Inferis wrote about quite some time ago.
It comes down to the fact that the map is too large to hold in memory if you want any chance at editing it. Just viewing it is not a problem, because you can leave it compressed and it's only 20 megs. But when you unpack it it becomes much larger. Huge in fact. Even a semi-compressed map might be around 250 megs minimum. There'd be enough swapping to virtual memory to drive you crazy. Pun intended.
The way Johan chose to approach the problem (AFAIK) was to only write a program to convert from Illustrator/Photoshop directly into the EU2 files. It's a smart system for the programmer because you don't have to hold the whole lot in memory at the same time, you can do a bit at a time. However, I'm not sure it's ideal for the user. You want to scroll around the map, paste a chunk here, a chunk there, fiddle with some borders, etc. You also kind of want to see it 'working' in the editor before testing it in EU2, not just blindly hoping that the export went correctly. Such a system would also mean some prior knowledge about the way the maps are encoded, so there'd be many users asking questions like 'why does the program not export my maps correctly?' So ideally you want a full editor that can read from and write to the map with the compression being fairly transparent.
There's the middle of the road option as well, which I think is what Inferis was considering. A sort of half-conversion into a format which doesn't have the disadvantages of working with compressed files, but you'd still have to repack everything before you can load it into the game.
Another thing is that, as I'm progressing with the program, my goals are getting more grandiose. Only a few days ago I posted that I just want to connect some provinces and change some province names. I'm struggling to stick to this. On the one hand, I don't want to try to run before I can walk, but on the other hand, I don't want to be writing code that will hardly be used.
So my conclusion is that I need to think some more... hopefully there's not much on at work tomorrow
Oh, I'm so wrong
I have been forgetting about the role of boundbox.tbl and id.tbl in terms of locating provinces in the map. So maybe it is feasible to keep the entire map compressed in memory. Sure the editor will be slower when changing blocks of data (because it would need to decompress and recompress on-the-fly), but then it's an editor and no one is going to be particularily worried about frames per second.
Also, I finally did something I should have done ages ago, which is search on Google for 'quadtree'. Not being a games programmer, it didn't occur to me that the quadtree might be a standard technique used in all kinds of games and rendering algorithms. Even with academic papers written about it. You see, I'd been reinventing the wheel a bit.
I have been forgetting about the role of boundbox.tbl and id.tbl in terms of locating provinces in the map. So maybe it is feasible to keep the entire map compressed in memory. Sure the editor will be slower when changing blocks of data (because it would need to decompress and recompress on-the-fly), but then it's an editor and no one is going to be particularily worried about frames per second.
Also, I finally did something I should have done ages ago, which is search on Google for 'quadtree'. Not being a games programmer, it didn't occur to me that the quadtree might be a standard technique used in all kinds of games and rendering algorithms. Even with academic papers written about it. You see, I'd been reinventing the wheel a bit.
Update:
Rewrote all my code for loading in the table files. It now keeps all the files in compressed in memory. Seems to speed up saving and viewing the map by a lot, although I think I could get even more speed by using a linear quadtree instead of a regular quadtree. I also made classes for id.tbl and boundbox.tbl, but no supporting methods yet, only load and save.
Then I was thinking about how to store any changes. So I decided to stress test my computer. I thought, what if the user makes changes to all ~180,000 blocks and they are mostly not very compressable (say 1000 bytes per block where in the standard EU2 map some blocks are only 6 bytes). To my surprise I could do this easily. So then I tried 300,000 blocks at 2000 bytes per block. Er, like, that's 600 megs. And it worked! Media Player stayed running and didn't skip a note. Moreover, CodeGuard stayed running and even could tell me about one little block I 'forgot' to throw away.
I know that might all sound quite technical to some readers, but I just needed to tell the world
What it means is that I have an answer to my dilemma. The editor won't need to pre-convert the files into some other format. It won't need to deal with huge temporary files. Any new maps you make will save fairly quickly and be immediately ready to test/use with EU2. The downside is that changing stuff might be a little slow here and there, but at this point it's all looking rosey.
Rewrote all my code for loading in the table files. It now keeps all the files in compressed in memory. Seems to speed up saving and viewing the map by a lot, although I think I could get even more speed by using a linear quadtree instead of a regular quadtree. I also made classes for id.tbl and boundbox.tbl, but no supporting methods yet, only load and save.
Then I was thinking about how to store any changes. So I decided to stress test my computer. I thought, what if the user makes changes to all ~180,000 blocks and they are mostly not very compressable (say 1000 bytes per block where in the standard EU2 map some blocks are only 6 bytes). To my surprise I could do this easily. So then I tried 300,000 blocks at 2000 bytes per block. Er, like, that's 600 megs. And it worked! Media Player stayed running and didn't skip a note. Moreover, CodeGuard stayed running and even could tell me about one little block I 'forgot' to throw away.
I know that might all sound quite technical to some readers, but I just needed to tell the world
What it means is that I have an answer to my dilemma. The editor won't need to pre-convert the files into some other format. It won't need to deal with huge temporary files. Any new maps you make will save fairly quickly and be immediately ready to test/use with EU2. The downside is that changing stuff might be a little slow here and there, but at this point it's all looking rosey.
WiSK,
I'm a complete idiot, I don't even come close to understanding anything you're doing, but it sounds like progress. KEEP UP THE GOOD WORK
I'm a complete idiot, I don't even come close to understanding anything you're doing, but it sounds like progress. KEEP UP THE GOOD WORK
tombom said:
that is indeed an interesting question...
if it doesn't make music skip notes on a 128mb ram, excellent... but if you need 2gb ram for that, not so excellent
Still, it sounds like good progress is being made
I have WinXP and 512 megs RAM.
WinXP makes a big difference to the stability. I don't think that you will be wanting to do full edits of the whole map under Win95/Win98/WinME unless you have a fair amount of memory. Shouldn't be a problem really because if it seems to be struggling, you can just click save which will clean up the memory and start anew.
WinXP makes a big difference to the stability. I don't think that you will be wanting to do full edits of the whole map under Win95/Win98/WinME unless you have a fair amount of memory. Shouldn't be a problem really because if it seems to be struggling, you can just click save which will clean up the memory and start anew.
wow, impressive
why dont you and inferis work together for faster output?
or am i missing some difference between your editor and his?
why dont you and inferis work together for faster output?
or am i missing some difference between your editor and his?
I'm using a different development environment (and programming language). Also, I don't think he's got very much time at the moment.von Loch Ness said:
More memory always helps in Windows|AXiN| said:
But for the editor it just means you will start to experience slowdowns as Windows struggles to juggle the available space around between its RAM and the hard drive. So the more RAM you have, the less you will notice any slowdowns.