SC4 Devotion Forum Archives

Sim City 4 Devotion Tools => Tools - General Discussion => SC4Mapper => Topic started by: cogeo on January 16, 2013, 12:15:48 PM

Title: SC4Mapper 2013 Version development & suggestion
Post by: cogeo on January 16, 2013, 12:15:48 PM
edit 02/25/2013 by wouanagaine ( hijacking the 1st post )
Github project started at :
https://github.com/wouanagaine/SC4Mapper-2013 (https://github.com/wouanagaine/SC4Mapper-2013)
People who want to contribute or fork the repo, please take notice that any executable version ( win, mac, linux, etc.. ) should be uploaded on LEX ( will be uploaded by LEX admin under your name if you don't have LEX upload rights )





Just saw this! So we have a new version of SC4Mapper! Excellent!

From the user's perspective, the most notable new feature (among others) is of course the Config Editor (not that the others aren't important, but features like the ability to export very large regions for example, are interesting to few users imo).

Don't know if I'm too late (and you have the time, of course), but I would like to post an idea about an enhancement here. There are two "issues" with the maps and regions currently uploaded (not SC4Mapper itself):
- Map sizes: maps tend to become larger and larger, and while many players really like this, to many others this is just annoying, as such maps are actually not playable. Regions like 60x70km large are very unlikely to ever get filled. They also pose a significant burden on system's performance: while the simulator(s) run on a city-by-city basis, some calculations are regional. Have you ever tried exiting (with saving) a city tile in a very large region? It takes a looooong time! And many players are not interested in all areas of a "Greater X-City" region, most are actually interested in the urban area and SOME of the suburbs. But given that maps are the way the are, they render the whole region, and have to landscape (or at least load-and-save) many city tiles that they actually do not want. I had requested a map for my own city (Thessaloniki (http://community.simtropolis.com/files/file/27248-thessaloniki-greece/)) from dobdriver/drunkapple, but I posted detailed specs about what (imo) would be a "good" map. The region ended up 28x28km large, and I'm never going to fill it up, although much of the area is taken up by the sea. How about a 60x70km region then?
- Region break-up may not result in good, playable city tiles. While mapmakers do their best, you often get small islands divided in two, or you are left with a very narrow land strip (between the city border and water) where you can't lay, for example a highway and a rail line, and still have space for (local) roads and zones, or you are unable to build bridges. In such cases what players usually say is "IF the border was A LITTLE far off the coast, it would be MUCH better"! They can change the config, but editing the config works in much bigger steps. And mapmakers can't really foresee all these, they basically decide the area to be included in the map, and then make a simple config (usually all-large tiles).

To solve the two above issues, here is my idea (requires two extra operations):
- Be able to define a smaller config, ie only a portion of the region (.SC4M or 8/16-bit grayscale or RGB).
- Be able to drag the config overlay over the region (with the mouse, and possibly the arrow keys, for accuracy). This way it will be possible to define the city tiles, borders, islands, rivers etc, EXACTLY the way players would like.
Then the "Save Region" operation (pls consider a different name here) would create a playable SC4 region, including only the area occupied by the config overlay.

I think this would be highly appreciated by players. Not a "request" though (I'm not going to start any new region), just an idea. Don't know if you have the time and patience, but I think it would be great.
Title: Re: SC4Mapper 2013 Version development & suggestion
Post by: wouanagaine on January 16, 2013, 01:03:47 PM
Hi Cogeo

Very nice idea you have, the first part can be almost there, as you can now 'erase' cities from the config editor. I should easily come with a way to allow the user to crop the map to the config

I will try to see how I can make user move the config overlay in a memory efficient way as I'm still fighting the big size map memory usage from nichter85' post


Edit :
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg35.imageshack.us%2Fimg35%2F3556%2Fscreenshot079g.jpg&hash=ccf5376db79ed277d391781c31af99d049decc85)
In this case, would you allow a move in any direction or only  on the left ?


Title: Re: SC4Mapper 2013 Version development & suggestion
Post by: cogeo on January 17, 2013, 02:29:47 PM
Quote from: wouanagaine on January 16, 2013, 01:03:47 PM
Edit :
In this case, would you allow a move in any direction or only  on the left ?
Can't get your point exactly I'm afraid, as the answer would otherwise be so much obvious to me: moving the overlay in any direction other than left, wouldn't result in getting out of the region's bounds? The config should only be allowed to move only within the region imo, but I may be wrong.

Quote from: wouanagaine on January 16, 2013, 01:03:47 PM
I should easily come with a way to allow the user to crop the map to the config
While I don't know how you have organised your data in memory, I suppose you have allocated a (large) memory block (or maybe some file mapping or what), containing all the region's elevation data, not per city (at least while you are processing them). Assuming this, I can't see how a different-sized config would result in higher memory usage. But "cropping" the map might not be the best possible solution, because then the player would export a (smaller) SC4 region, check the region ingame, only to find that the config should have better been moved "a little to the left", for example, and then have to repeat the procedure (as the new -smaller- region now no longer contains the cropped-out data). The ideal solution imo would be a slight review of the .SC4M file definition, ie allowing the config to be of a different size (smaller) than the .SC4M size implies. But this would require a slight review of the format as well, unfortunately (as you also need to save the config.bmp size AND its start offset). Don't know if the format is extensible (tagged or so) so as to allow extensions like these and still have older-version programs, like SC4TF, able to read back these files, so I don't have any idea how much work this could be. However this capability may be very well left out, as SC4M is a tool for the player, while SC4TF for the mapmaker, and the procedure is one-way only, ie the .SC4M files saved by the Mapper need not necessarily be able to be read by the Terraformer, and this would be quite acceptable imo.

Quote from: wouanagaine on January 16, 2013, 01:03:47 PM
I will try to see how I can make user move the config overlay in a memory efficient way as I'm still fighting the big size map memory usage from nichter85' post
As for a memory efficient way to move the overlay around, I have some suggestions to make, although I don't know what the Python interface allows and what not (my experience is from WinAPI and MFC). I guess the bitmap you display in the application's window (the region's overview) is something you generate on the fly, and it's much smaller than the region's size, as it contains only sample data (properly adjusted and coloured for the preview). Then you also need to create another similar bitmap, containing the config overlay; this bitmap should be drawn using a XOR raster operator and you have to keep the position it was drawn in some variable; then, in response to the WM_MOUSEMOVE messages arriving, draw the bitmap again (on the last position it was drawn) using a XOR ROP again (this will revert the drawing surface to its original state), and draw it once more (to its new position). Alternatively (if you are drawing lines instead of blitting bitmaps, to display the config overlay) you can slightly modify your code to work in XOR mix mode (the WinAPI function that does this is SetROP2(), don't know about Python). That is, using a XOR ROP twice at the same position (ie inverting twice) restores the graphical surface, thus not requiring any additional memory.

I have a suggestion about a small (this one is indeed small) improvement (it's display-only). I took me a few minutes to figure out that the pic you posted showed a region 6x6 small cities large, and a config with a big city tile at the bottom-right corner and some extra small tiles to the top and the left; also that the blackened tiles are the "removed" cities (they could have also been the area "out of the config overlay"). Therefore I would suggest a modification here, as described below:
- The region area would be drawn the way it is, only without any gridlines.
- The config overlay would be again as is, ie a grid of thin black lines (only it should now be moveable).
- The city tiles should be changed, you could draw a rectangle with a thick frame, coloured according to the city size (red, green or blue) inside the black gridlines (without overlapping them).
- City tiles removed from the config but inside its boudning rectangle (ie those marked gray or white in the SC4 region's config.bmp) could be grayed (set R,G and B equal) or they can simply be left unchanged (the user will be easily distinguishing them, as they are inside the config overlay -the black gridlines- but not inside a coloured city rectangle). I could make a pic if you want, but I think it's quite clear.

And of course, these need not (and should not) be drawn and moved together with the config overlay (the black grid), because what the user might want when doing so, is having as much information available as possible (eg beaches, rivers, islands etc) for accurate placement, and those coloured or grayed overlays do hide enough information. So only the black grid should be visible when the config overlay is being dragged.

It think the above must be quite easy to make, as the most difficult part (calculation of the rectangle coordonates, conversions between the actual data and the screen coordinates and units, etc) is already done. For example, you have alrady made the calculation were to draw the black gridlines for city #27, then it's not hard to draw a red frame on a rectangle four (2+2) pixels smaller, using a 3-pixel wide pen.

SC4Mapper is a fabulous tools as is, but why not make those little interface improvements?
Title: Re: SC4Mapper 2013 Version development & suggestion
Post by: wouanagaine on January 17, 2013, 02:54:43 PM
Quote from: cogeo on January 17, 2013, 02:29:47 PM
SC4Mapper is a fabulous tools as is, but why not make those little interface improvements?
Because it is almost midnight now and I have a hard time reading all you wrote :)

Joke aside, I get a version with less memory usage, I can load an RGB region of config size 132x64
Still I'm not happy with the usage and will do more optimisation


Quote from: cogeo on January 17, 2013, 02:29:47 PM
Can't get your point exactly I'm afraid, as the answer would otherwise be so much obvious to me: moving the overlay in any direction other than left, wouldn't result in getting out of the region's bounds? The config should only be allowed to move only within the region imo, but I may be wrong.
In the case of island I wish sometimes I can move the overlay, and it will create water from the void, but that work only for islands
Anyway I think like you it is better to just limit to the region

Cogeo I will get back at your post tomorrow, it deserves more time than I have now.

For people having problem with their \MyDocuments folder, ( you can see the splash screen and then it crashes ), the fix is working, I will upload a new version when the memory usage will satisfy me
Title: Re: SC4Mapper 2013 Version development & suggestion
Post by: wouanagaine on January 18, 2013, 12:59:30 AM
Quote
While I don't know how you have organised your data in memory, I suppose you have allocated a (large) memory block (or maybe some file mapping or what), containing all the region's elevation data, not per city (at least while you are processing them). Assuming this, I can't see how a different-sized config would result in higher memory usage. But "cropping" the map might not be the best possible solution, because then the player would export a (smaller) SC4 region, check the region ingame, only to find that the config should have better been moved "a little to the left", for example, and then have to repeat the procedure (as the new -smaller- region now no longer contains the cropped-out data)The ideal solution imo would be a slight review of the .SC4M file definition, ie allowing the config to be of a different size (smaller) than the .SC4M size implies. But this would require a slight review of the format as well, unfortunately (as you also need to save the config.bmp size AND its start offset). Don't know if the format is extensible (tagged or so) so as to allow extensions like these and still have older-version programs, like SC4TF, able to read back these files, so I don't have any idea how much work this could be. However this capability may be very well left out, as SC4M is a tool for the player, while SC4TF for the mapmaker, and the procedure is one-way only, ie the .SC4M files saved by the Mapper need not necessarily be able to be read by the Terraformer, and this would be quite acceptable imo
SC4M file format is versionned, so I can add things in it
however as I lost latest SC4TF source code, I can't be sure I coded the reading of files correctly for forward compatibilty ( I'm pretty sure it can only read the current SC4M version )
It can be done ( adding the proposed offset and smaller config ) but I'm not sure of the benefit, I don't really buy the fact a user won't only discover in SC4 that he has not align the config properly

Quote
I have a suggestion about a small (this one is indeed small) improvement (it's display-only). I took me a few minutes to figure out that the pic you posted showed a region 6x6 small cities large, and a config with a big city tile at the bottom-right corner and some extra small tiles to the top and the left; also that the blackened tiles are the "removed" cities (they could have also been the area "out of the config overlay"). Therefore I would suggest a modification here, as described below:
- The region area would be drawn the way it is, only without any gridlines.
- The config overlay would be again as is, ie a grid of thin black lines (only it should now be moveable).
- The city tiles should be changed, you could draw a rectangle with a thick frame, coloured according to the city size (red, green or blue) inside the black gridlines (without overlapping them).
- City tiles removed from the config but inside its boudning rectangle (ie those marked gray or white in the SC4 region's config.bmp) could be grayed (set R,G and B equal) or they can simply be left unchanged (the user will be easily distinguishing them, as they are inside the config overlay -the black gridlines- but not inside a coloured city rectangle). I could make a pic if you want, but I think it's quite clear.
I like the gray overlay over removed cities idea a lot

As for moving, my idea is that user won't move the config, but will move the region instead ( at least in term of visual effect )

Well I will do some experiences this evening

Title: Re: SC4Mapper 2013 Version development & suggestion
Post by: dobdriver on January 19, 2013, 06:03:07 AM

A lovely update to mapper Wouanagaine,

I like two features you have included, the first is the ability to export the png directly from the sc4m file. I think from memory that was something I posted in my wish list. the second is the ability to turn off the city overlay grid. (Not so important)

I also like Cogeo's idea to be able to cut and shut large maps, Many people have requested some of my maps cut and shut because they only wish to use a small part of it, while it doesn't take long it would mean they can do it as they want.

Oh, some large maps eh?

Hawai'i (http://community.simtropolis.com/files/file/28306-the-big-kahuna-hawaii/) is 132 x 148.
Bruce and Grey (http://community.simtropolis.com/files/file/28006-bruce-and-grey-counties-ontario-canada/) is 120x 136.
LA (http://community.simtropolis.com/files/file/27957-just-la/) is 144 x 96.

These should keep you busy Wouanagaine ;<)



Cogeo, most of the time taken to save large maps is to re-generate the region image. The bigger the map, the larger the image, the longer the time.



Nichter, To generate the largest maps I produce you will need to patch mapper and terraformer with this:

4GB patcher (http://www.ntcore.com/files/4gb_patch.zip)

It will patch the executable and make a back up also and will run straight out of the zip file.
SC4 will render 8bit maps up to 39 tiles square but to render the map of Cornwall I had to patch the SC4 executable, it will now render 8bit maps up to 56 tiles square.

A good alternative to photoshop to deal with 16bit tiffs and pngs is this:

Photoline (http://www.pl32.com/pages/down.php)

It is a 64bit proggy and almost similar tools to photoshop, plus it handles 32bit images far better than photoshop. written by a German mob so there is a German manual. It ain't free but at 59 euros good value I think, plus a big online support base via their forums.


Keep up this grand work.

Cheers
dobs
Title: Re: SC4Mapper 2013 Version development & suggestion
Post by: wouanagaine on January 19, 2013, 02:14:35 PM
Thanks for Hawaii link and words

I can now report that I've been able to load it in my working version and it use only 800Mb, which means no more patching
I however don't know when I'll be able to upload a new version ( during next week at most )




Title: Re: SC4Mapper 2013 Version development & suggestion
Post by: wouanagaine on January 20, 2013, 01:57:38 PM
Yild/dobdriver => good catch, will fix

SimCity4RushHour => what for ? Won't you be more interested in the SC4M format ?


So some progress :

new city overlay look : ( I'm removing a small city in this screen )
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimageshack.us%2Fa%2Fimg339%2F4442%2Fscreenshot082i.jpg&hash=2d1481f4fff7fb45feabc81af066f96eebae6ff5)

I now can offset the overlay in the correct direction
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimageshack.us%2Fa%2Fimg850%2F846%2Fscreenshot083s.jpg&hash=96ba9f5d4428e8f6759541c35d504b90d224c923)
Title: Re: SC4Mapper 2013 Version development & suggestion
Post by: SIM CITY 4 RUSH HOUR on January 21, 2013, 12:57:34 AM
Quote from: wouanagaine on January 20, 2013, 01:57:38 PM
SimCity4RushHour => what for ? Won't you be more interested in the SC4M format ?
Pourquoi faire wouanagaine, comme je fait que tu parle fançais que c'est même ta langue aussi bien que la mienne, je vais te le dire direct moi aussi j'ai python 2.7.3 et je suis intéressé donc par python comme toi et j'ai pas seulement la version Windows 32 bits de python 2.7.3, mais aussi sa version Windows 64 bits x64 de python 2.7.3 donc pour plus de mémoire ce serai Génial, et encore plus si tu mettais le code source directement pour l'interpréteur de python, comme ça ceux qui le veulent comme moi par exemple pourrais travailler dans python directement bien sur tu peut toujours indiquer les dépendances de type import et autre moins évidents, que tu à mis si elles ne sont pas faciles à trouver.
Title: Re: SC4Mapper 2013 Version development & suggestion
Post by: wouanagaine on January 21, 2013, 01:18:16 AM
Quote from: SIM CITY 4 RUSH HOUR on January 21, 2013, 12:57:34 AM
Pourquoi faire wouanagaine, comme je fait que tu parle fançais que c'est même ta langue aussi bien que la mienne, je vais te le dire direct moi aussi j'ai python 2.7.3 et je suis intéressé donc par python comme toi et j'ai pas seulement la version Windows 32 bits de python 2.7.3, mais aussi sa version Windows 64 bits x64 de python 2.7.3 donc pour plus de mémoire ce serai Génial, et encore plus si tu mettais le code source directement pour l'interpréteur de python, comme ça ceux qui le veulent comme moi par exemple pourrais travailler dans python directement bien sur tu peut toujours indiquer les dépendances de type import et autre moins évidents, que tu à mis si elles ne sont pas faciles à trouver.
Je creerai peut etre un projet sur github quand je serai content du code (qualité, commentaire, et efficacité), comme ca tout le monde pourra participer

I may create a github project when I'll be satisfied with the code, so everyone could do stuff with it, I think of a one month frame

Title: Re: SC4Mapper 2013 Version development & suggestion
Post by: wouanagaine on January 21, 2013, 01:54:28 PM
A quick update
Everything seems to work so far
the Hawaii region is certainly the biggest you can do as map creators without any patch

So far:
loading as SC4M => 800Mb
loading as RGB => 900Mb
loading as PNG => 1.1gb
then exporting to SC4M, RGB or PNG can fail due to memory
At least I can read the RGB and export to SC4M as I think that is what most map creator is doing ?

Of course loading the SC4M and saving the region is ok, as it use almost 1.1gb

I've also made a modification for creating defaultconfig.bmp
So far it created a red config.bmp ie full of small cities. Now it creates an optimal config.bmp. So if you have a map that match a 15x15 small cities it will create a config.bmp for 4 big + 1 medium + 1 small in each direction

BTW : here is the new save overview picture with a config.bmp with some offset and some removed cities
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimg850.imageshack.us%2Fimg850%2F9766%2Fmysanfranciscoover.jpg&hash=ff9541ed000894836e829c5b4c070ffb6ed463be)
Title: Re: SC4Mapper 2013 Version development & suggestion
Post by: JoeST on January 21, 2013, 02:35:13 PM
is there vertical offset too? that is such a cool addition, thanks Wou :D
Title: Re: SC4Mapper 2013 Version development & suggestion
Post by: wouanagaine on January 21, 2013, 02:40:30 PM
Quote from: JoeST on January 21, 2013, 02:35:13 PM
is there vertical offset too? that is such a cool addition, thanks Wou :D
Yes you will be able to move on any direction provided you erased outside row/line of cities in that direction




Title: Re: SC4Mapper 2013 Version development & suggestion
Post by: wouanagaine on January 22, 2013, 04:39:49 AM
A cool new feature ( IMO )

got a big region and want to play on a sub part of it ?

open the SC4M and go in edit config mode
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimageshack.us%2Fa%2Fimg9%2F5189%2Fscreenshot051wt.jpg&hash=c624ad0d18a3b79c8828a697187c2fff74152a97)

with the mouse drag over the place you want to extract
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimageshack.us%2Fa%2Fimg842%2F15%2Fscreenshot052h.jpg&hash=9a65facbad89ce4a97052f12d624d47cec850bdf)

the config will adapt at best
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimageshack.us%2Fa%2Fimg46%2F8207%2Fscreenshot053e.jpg&hash=3675e6d0fc597312c08f5b991d12fd90a51003d3)

Of course as you have invalidated most of the cities you can move the overlay on any direction to get exactly what you want

You can directly save the region, or export the sub region

on importing this region, you got only the needed data
(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fimageshack.us%2Fa%2Fimg259%2F7923%2Fscreenshot055k.jpg&hash=5de4528b4d732874bdbe641e06107e53a1a3bc6d)



Title: Re: SC4Mapper 2013 Version development & suggestion
Post by: Swordmaster on January 22, 2013, 04:53:22 AM
That's awesome!


Cheers
Willy
Title: Re: SC4Mapper 2013 Version development & suggestion
Post by: MandelSoft on January 22, 2013, 05:14:34 AM
That would be excellent for those systems that can't handle big maps ;)
Title: Re: SC4Mapper 2013 Version development & suggestion
Post by: dobdriver on January 26, 2013, 08:41:34 AM


Oh it is guys!
Wouanagaine's got himself a boomer with this mapper.

It's very efficient compared to previous versions, It loads Hawai'i using only 230MB of ram and will load a map 52 tiles square equivalent to 212.992km per side. And that is unpatched.

Now SC4 can render a map 56 tiles square or 229.376km per side but SC4 needs to be patched to do so.


Cheers
dobs
Title: Re: SC4Mapper 2013 Version development & suggestion
Post by: Swordmaster on January 26, 2013, 08:54:12 AM
That's almost the size of Belgium. Meh  ()what()


Cheers
Willy
Title: Re: SC4Mapper 2013 Version development & suggestion
Post by: whatevermind on January 26, 2013, 01:11:06 PM
I love where this program is going. I've never much used mapper, being more inclined to fire up terraformer and make my own regions. But I see huge possibility in being able to play some of these monstrous regions that are out there, and pick the most desired bits and play them at full beautiful detail, without the loss that comes with scaling them down.
Title: Re: SC4Mapper 2013 Version development & suggestion
Post by: Swordmaster on February 04, 2013, 07:00:27 AM
Would anyone be interested in this color scheme?

(https://www.sc4devotion.com/forums/proxy.php?request=http%3A%2F%2Fwww.majhost.com%2Fgallery%2Fswm666%2FVarious%2Fpetropavlovsk.jpg&hash=5348521747809e640c8643ac6b85fce5a9b92fd1)


Cheers
Willy
Title: Re: SC4Mapper 2013 Version development & suggestion
Post by: dobdriver on February 04, 2013, 07:31:32 AM


What about using the hubble palette?

I like your map though ;<)
Title: Re: SC4Mapper 2013 Version development & suggestion
Post by: wouanagaine on February 04, 2013, 08:18:30 AM
That is interesting :)

Title: Re: SC4Mapper 2013 Version development & suggestion
Post by: nichter85 on February 06, 2013, 05:48:12 PM
Hallo,
I've tested v5 and I'm amazed about the performance. I could easily create a 136x136 region from RGB, also saving the region didn't take any longer than 4 or 5 minutes.
The config editing works out fine and this tool is definitely the most convenient part of the upcoming version  :thumbsup:.

I have a question though: Does the game require any adjustments for handling these big regions? Trying to open the 136x136 region resulted in a CTD, no matter whether it was created from RGB or SC4M.
When I reduced region size to 112x136, I could open it in the game, i could open city tiles, i could even save them, but returning to region view resulted in CTD.
When I reduced the region size to 112x112 everything is OK.
Title: Re: SC4Mapper 2013 Version development & suggestion
Post by: dobdriver on February 06, 2013, 07:03:18 PM
G'Day Nichter,

I gather by those sizes that are causing crashes you are using 32bit windows?

I have opened 156x156 regions with a 64bit windows. Greater than this CTD. I patched SimCity 4.exe with 4GB Patcher (http://www.ntcore.com/files/4gb_patch.zip) and SC4 will now open 224x224 regions.


Cheers
dobs
Title: Re: SC4Mapper 2013 Version development & suggestion
Post by: nichter85 on February 07, 2013, 10:59:06 AM
Quote from: dobdriver on February 06, 2013, 07:03:18 PM
G'Day Nichter,

I gather by those sizes that are causing crashes you are using 32bit windows?

I have opened 156x156 regions with a 64bit windows. Greater than this CTD. I patched SimCity 4.exe with 4GB Patcher (http://www.ntcore.com/files/4gb_patch.zip) and SC4 will now open 224x224 regions.


Cheers
dobs

No, I use a 64 bit windows. I haven't patched SC4, so I think that's the issue. How does the patching work though?
Title: Re: SC4Mapper 2013 Version development & suggestion
Post by: dobdriver on February 07, 2013, 01:50:20 PM


G'Day Nichter,

The patcher will work from inside the zip, no installation needed.

double click the patcher and in the pane that opens navigate to the simcity 4 exe file.
Select it and click OK
A dialogue will open advising it has been patched, click OK.

It will make a back up of the executable.

Cheers
dobs


Title: Re: SC4Mapper 2013 Version development & suggestion
Post by: whatevermind on February 16, 2013, 03:07:23 PM
I tried out the new version yesterday, and I have to say it works beautifully. It's very easy to use and navigate, and I love the config editor and being able to snag only parts of some of these larger regions to play on.

One feature though that would be helpful is being able to do fine rotations of the region (or config). Something that worked similar to the config mover, where as long as you have room, you can spin the region to get the desired alignment.

I realize this can be done by exporting to PNG, rotating the PNG, cropping, and reloading - but if it was built in it would save a lot of steps. Not to mention some time for all the mapmakers who get requests for rotated regions.

Overall, excellent tool, opens up a whole new world of regions.  :thumbsup:
Title: Re: SC4Mapper 2013 Version development & suggestion
Post by: wouanagaine on February 17, 2013, 02:58:10 AM
thanks, but I really don't know if I'll do it
The source will soon be available, so maybe someone will do :)
Title: Re: SC4Mapper 2013 Version development & suggestion
Post by: wouanagaine on February 25, 2013, 01:48:19 AM
Github project started at :
https://github.com/wouanagaine/SC4Mapper-2013

The sources will come soon ( 1 or 2 days ) as well as some bug fixes new version on LEX

People who want to contribute or fork the repo, please take notice that any executable version ( win, mac, linux, etc.. ) should be uploaded on LEX ( will be uploaded by LEX admin under your name if you don't have LEX upload rights )
Title: Re: SC4Mapper 2013 Version development & suggestion
Post by: SIM CITY 4 RUSH HOUR on July 29, 2013, 05:51:47 AM
Quote from: original françaisBonjour wouanagaine et les autres, j'ai compiler d'après les codes sources les fichier *.dll de sc4mapper 2013 en 64 bits x64 qfs.c en qfs.pyd d'après le fichier qfs.c original et tools3D.cpp en tools3D.pyd d'après le fichier tools3D.cpp modifié à la ligne n° 87
tools3D.cpp original en ligne n°87
int pos = 0;
tools3D.cpp modifié pour x64 en ligne n° 87
long long pos = 0;
. Si ça intéresse quelqu'un d'avoir le SC4Mapper 2013 en 64 bits x64? et wouanagaine tu peut prend le fichier zip "SC4Mapper 2013 x64 pyd.zip" ci joint dans mon message.
Pour info le x86 32 bits est lui limiter à 2 Go de ram par processus et le x64 64 bits est lui limiter à 8 To de ram (8.192 Go de ram) par processus.

Quote from: Translator par bing Français >> Anglais
Translator by bing  French >> English
Hello wouanagaine and others, I compile from source code sc4mapper *.dll file 2013 in 64-bit x 64 qfs.c in qfs.pyd based on the original qfs.c file and tools3D.cpp in tools3D.pyd based on the tools3D.cpp file that is modified in line no. 87
original tools3D.cpp online n ° 87
int pos = 0;
Online tools3D.cpp modified for x 64 No 87
long long pos = 0;
If someone have the 2013 SC4Mapper 64-bit x 64 are interested? and wouanagaine you can take the zip file "SC4Mapper 2013 x 64 pyd.zip" attached in my message.
For info the x 86 32 bit is him limit to 2 GB of ram per process and x 64 64-bit is limited it to 8 TB of ram (8.192 GB ram) by process.
Requierements
python 2.7 x64 (http://www.python.org/)
Numpy 1.6.2 x64 or higher
PIL 1.1.7 x64 or higher
pywin32 218 x64 or higher
wxPython 2.9.4 x64 or higher
for SC4Mapper 2013 in x64
SC4Mapper 2013 source code (https://github.com/wouanagaine/SC4Mapper-2013) of wouanagaine