Cross-Platform Civ3 Editor

Cross-Platform Editor for Conquests now available! 1.48

That's odd that the editor accepted the image with dimensions that were off - it should reject images that have a number of pixels it can't work with. Although if they were off by just the right amount, it may have been able to work with them (and, say, create a 178x160 map instead of 180x160 if it was off by the right amount).
I don't remember the exact dimensions anymore, but it was a "good" number vertically, horizontally it was off. Want to say it was 2424 x 1616, but not sure.

The editor does have a build-in pixel calculator (Map -> BMP Size Calculator), though a spreadsheet probably would be more handy for quick reference..
I do use the editor's calculator when thinking about resizing, cropping or extending maps. It's a great tool! I made the spreadsheet so that I don't have to open the editor just to compute changes to image files when scaling them. Plus, my desktop gets so cluttered, it's easier to notice a bit of a spreadsheet window than to find the little calculator & bring it to the top. :lol:

I still have a few ideas up my sleeves, too, although not all of them relate to maps.
Definitely looking forward to all your ideas. Maps are my entry to scenario design, I'm sure other people start with tech trees or units lines. But we all need all of it sooner or later. :coffee:
 
It looks like I need to either add a scroll bar to the color-mapping window,
There are still some problems with disappearing scroll bars when re-sizing the map window. I only notice this with the horizontal bar - regardless of how I resize the window.

Also sometimes the pull down menu has blank entries. Remember these were problems in earlier versions - don't know if you ever had a chance to look at them.

menu screenshot
Spoiler :



When I go into GIMP, and go to Image -> Mode -> Indexed, there's an option to set the number of colors in the optimum palette:



This value defaults to 256; I've set it to 32 in the below picture. You can also set your own custom palette, with your own number of colors.
When reusing a custom palette I find it useful to deselect the "remove unused colors" option. Had problems in the past with pcx where programs "fill in the blanks" with other colors - usually black - which shifts the end slots (magenta & green) so they no longer function as alphas.


Did more palette tests this morning. Ideally I want 2 things
  • That the colors in the dialog are in an order which makes assigning terrains straightforward.
  • That the editor re-uses the custom palette assignments.
After a small handful of tests ...

  • At first it seemed that the editor picked out colors in a random order - I don't know what algorithm is used.
  • Using a custom palette with colors in the order of my chart seems to achieve the first goal. "Seems to" because I haven't done enough tests yet to really know if it works with same palette consistently, and the same thing happens with different palettes.
  • Once I noticed the bmpcolors.txt I tried saving the text file under a different name, deleting the old one, then redoing the import again after closing/reopening the editor. Got everything assigned as Water - expected since there was no bmpcolors.txt to use.
  • Next I renamed a copy back to bmpcolors.txt & tried re-importing a different bmp - really just the first one scaled down and saved with a new name. The standard colors were assigned terrains as expected, but the LMs were all assigned water.
  • While comparing before & after texts following one experiment saw that I had accidentally swapped the lm & standard assignment for pine forests. Despite the position swap the editor assigned terrains as with all the rest (standard ok, water for lm).
The image below is from the most recent tests with my current palette: the editor's window with the reassignments from the before text, as well as the before & after texts for comparison. You can see my pine forests error.
Spoiler :

Maybe the LMs might be resetting because enabling advanced mode comes after assigning the colors?
 
Re; "Import from CSV" feature for units - ability to group change various numeric values for units (e.g. Double all A/D/B)

Quote "I think there may be a way to do something like this in Steph's editor, as I'm pretty sure it has a table-based display for units. "

I haven't been able to see a way of doing that with Steph's editor (for all its many and wonderful features). It does allow boolean (Yes/No) values to be set for multiple entries, but I can't yet see a way to either apply a multiplier to the numeric values or to export / import to a separate file to enable the same to be done.

Steph's Web-site reads ; "You can also select several items. In that case, the controls appear initially as "indeterminate".
While several items are selected, you can modify the parameters. Doing it will apply the change, for these parameters, to every selected unit. In the example on the right, I've selected the chariot, catapult, tank and modern armor, and I have made them all wheeled units with one click.
"

It is possible to set a range of units to the same A/D/B etc. but I can't work out how to multiply chosen numerics by a factor of 2 or 10 etc.

But if anyone can enlighten me as to a way to do it (via any means apart from line by line), I would be most grateful.
 
There are still some problems with disappearing scroll bars when re-sizing the map window. I only notice this with the horizontal bar - regardless of how I resize the window.

Also sometimes the pull down menu has blank entries. Remember these were problems in earlier versions - don't know if you ever had a chance to look at them.

menu screenshot
Spoiler :



When reusing a custom palette I find it useful to deselect the "remove unused colors" option. Had problems in the past with pcx where programs "fill in the blanks" with other colors - usually black - which shifts the end slots (magenta & green) so they no longer function as alphas.


Did more palette tests this morning. Ideally I want 2 things
  • That the colors in the dialog are in an order which makes assigning terrains straightforward.
  • That the editor re-uses the custom palette assignments.
After a small handful of tests ...

  • At first it seemed that the editor picked out colors in a random order - I don't know what algorithm is used.
  • Using a custom palette with colors in the order of my chart seems to achieve the first goal. "Seems to" because I haven't done enough tests yet to really know if it works with same palette consistently, and the same thing happens with different palettes.
  • Once I noticed the bmpcolors.txt I tried saving the text file under a different name, deleting the old one, then redoing the import again after closing/reopening the editor. Got everything assigned as Water - expected since there was no bmpcolors.txt to use.
  • Next I renamed a copy back to bmpcolors.txt & tried re-importing a different bmp - really just the first one scaled down and saved with a new name. The standard colors were assigned terrains as expected, but the LMs were all assigned water.
  • While comparing before & after texts following one experiment saw that I had accidentally swapped the lm & standard assignment for pine forests. Despite the position swap the editor assigned terrains as with all the rest (standard ok, water for lm).
The image below is from the most recent tests with my current palette: the editor's window with the reassignments from the before text, as well as the before & after texts for comparison. You can see my pine forests error.
Spoiler :

Maybe the LMs might be resetting because enabling advanced mode comes after assigning the colors?

I do recall the scrollbar-when-resizing issues. I'll have to look at that again; I suspect I may be seeing it less since I generally either leave the window the same size, or maximize it. On a potentially relevant note to that, one of the changes in the next version will be that the editor will remember its size from the last time - so if you always resize it now, that shouldn't be necessary anymore.

I don't recall the menu-dropdowns-being-blank issue - is that only in the open/save dialogs? I haven't seen it on 10.4 Tiger that I can recall. That component is one I'm using from the standard Java implementation, so I can't easily tweak it, though I could write my own. More realistically, since with 0.99 I'm going to be moving to a newer version of Java, I can see if there's a new standard control for that, and use that if so. Most likely, that would solve any issues with the old standard control on newer versions of OS X.

You are correct about the LM terrains resetting due to advanced mode being enabled after assigning the colors. That's something I may be able to look into changing - it's been quite awhile since I wrote it, and I don't remember exactly whether that was due to a significant technical challenge, or simply because it was easier (but not that difficult to enhance it). Kind of thinking the latter, but don't want to say for sure without checking.

I thought the editor displayed the colors in the order they were saved in the palette, but that's another thing I can double check when it's less late (I'm an inveterate night owl, really need to start going to sleep earlier, probably shouldn't jump back in to the code tonight).

Re; "Import from CSV" feature for units - ability to group change various numeric values for units (e.g. Double all A/D/B)

Quote "I think there may be a way to do something like this in Steph's editor, as I'm pretty sure it has a table-based display for units. "

I haven't been able to see a way of doing that with Steph's editor (for all its many and wonderful features). It does allow boolean (Yes/No) values to be set for multiple entries, but I can't yet see a way to either apply a multiplier to the numeric values or to export / import to a separate file to enable the same to be done.

Steph's Web-site reads ; "You can also select several items. In that case, the controls appear initially as "indeterminate".
While several items are selected, you can modify the parameters. Doing it will apply the change, for these parameters, to every selected unit. In the example on the right, I've selected the chariot, catapult, tank and modern armor, and I have made them all wheeled units with one click.
"

It is possible to set a range of units to the same A/D/B etc. but I can't work out how to multiply chosen numerics by a factor of 2 or 10 etc.

But if anyone can enlighten me as to a way to do it (via any means apart from line by line), I would be most grateful.

That does sound correct now that I read through it :(.

Was able to complete the core proof of concept for my next idea tonight; there's still a few other puzzle pieces to solve but the main one is proven-doable. Just thought of this one a few weeks ago and it's exciting to have a new feature to work on that I'm pretty sure hasn't been done in any Civ3 utility yet.
 
I don't recall the menu-dropdowns-being-blank issue - is that only in the open/save dialogs? I haven't seen it on 10.4 Tiger that I can recall.
Last time we talked about it was 2013.:lol: It seems to be the pull down directory list & the behavior is inconsistent. Sometimes the list shows, show times it's blank, sometimes - like this morning - items appear as I move the mouse down through the list & disappear as I move it back up. The most annoying thing about it is that the item pointed at is blank - making it difficult to be sure what is selected.

I thought the editor displayed the colors in the order they were saved in the palette, ...
This does seem to be the case. It only appeared random because when the images were indexed the colors were ordered differently, and I didn't understand the way the editor worked with them. Sorry I wasn't clear.

You are correct about the LM terrains resetting due to advanced mode being enabled after assigning the colors.
Once I have a set palette, it will be arranged with alternating standard/LM colors anyway (easiest to work with in map-making imho). So it seems like just a matter of me matching lm to the terrain just above it in the import list. Annoying, but a small price to pay for having the ability to make and edit maps. Glad it's on your to-do list, but no super-rush now that I understand what's going on & how to work with it.
 
I am running 10.5.8 on my older laptop, and 10.8.5 on my wife's laptop that I use sometimes. I think that the desktop Mac is running 10.7, but will check. I also have a Windows laptop running XP and one running Windows 7.

A heads-up - I've been working on the next new feature using Java 8, the most recent version of Java. As far as I can tell, it requires OS X 10.8 or later, and Windows XP or newer (officially Vista, but it runs without issue on XP... haven't found similar reports of it running without issue on OS X 10.7 yet, though there's a chance it would install and work on it). So at this point, it looks like the next version with all features would require OS X 10.8, or Windows XP or later.

I did look into whether I could get it working with Java 7, which would add OS X 10.7 to the mix (and be de facto the same on Windows). The conclusion I've reached so far is that while possible, it would require a decent amount of work, which I'd rather devote to adding features.

For awhile at least, I plan to release versions that support Java 5 as well, but they likely won't have many/any major new features. Thus, it will looks like:

All new features: OS X 10.8 and later, Windows XP and later
Minor updates, all features through 0.98: OS X 10.4 - 10.7, Windows 98/ME/2K

I believe 10.8 (and later) is a free update for OS X 10.6 and 10.7, so that may be an option... although it looks like 10.7 is the last version to support running PowerPC applications, so that may be a reason to remain on it.
 
Guintillus, is there anything specific that I need to do to run under Windows XP? I know that means that I have strayed to the Dark Side, but I still have more Macs than Windows boxes.
 
Guintillus, is there anything specific that I need to do to run under Windows XP? I know that means that I have strayed to the Dark Side, but I still have more Macs than Windows boxes.

So long as a recent enough version of Java is installed, it should work just the same as it does on OS X. You can check which version of Java is installed by opening a terminal window (Start -> Accessories -> Command Prompt), and typing:

Code:
java -version

Which will return something like:

Code:
java version "1.8.0_60"
Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)

The key part if the 1.8.0_60 - the 1.8 indicates Java 8 (and similarly, 1.5 through 1.7 indicate Java 5 through Java 7). The editor currently requires Java 5 or later, although the next version will have some features that require Java 8.

As a side note, the same process will tell you the currently-installed Java version on OS X, too, though via Terminal instead of the Command Prompt.

If the version of Java is too old, or if there isn't any Java installed at all (in which case it will say something about Java not being recognized), I have the download links listed in the first post under "Java Download Links" (unfortunately I haven't figured out how to add links to the middle of a post).
 
Thanks for the answer, Quintillus. I suspect that I need to update the Java version on the Windows laptop that I am using.

Next question:
I opened up a .SAV file to see what changes that I had left out of a mod I had made while tired and falling asleep. I found out that I had not made some of the changed that my tired brain thought that I had made. I was wondering how I keep that as a .SAV file to continue playing with the corrections. Right now, when I save it, it have a file with the following endings:

.SAV.BIQ
 
This isn't exactly about terrain in the editor itself. It also is not about a separate terrain type, so I don't think you need to add anything to your list of terrains for processing graphics into maps. But this thread is the most likely place for people using a lot of special terrains to see it without needlessly necro-ing a thread.

Came across a discussion by the masters about using the pines graphics found in the Marshes pcx. Apparently these rows are used when there is forest next to marsh regardless of whatever terrain underlies the forest itself. There can be weird results when, for example, there is one tile of forest between a marsh & a desert.

Something to keep in mind when designing bmp maps to translate into biqs.
 
Interesting, unless I'm misinterpreting something, my observations playing around with this tonight don't line up with what Vuldacon or Leaven were saying in that thread. Leaven said there (and Vuldacon later confirmed):

Ok, if I understand what you are saying correctly, the marsh-pine images at the bottom are optional, and can be used to replace those images in the second 2 rows of the marsh file (which correspond to the Jungle-small lines in the forest file). Is that correct?

I used the method you suggested to figure out where each tile is used. It seems that the top 2 rows are for marsh tiles completely surrounded by other marsh tiles, while the second 2 rows are for edges. Thus, if i replace the second 2 rows with the pines, then the edges of the marshes will look like these forests, but they're still marshes.

However, when I tested it out tonight in the Firaxis editor, what I observed instead is that the third and fourth row are used for any marsh tiles that border at least one coast tile (along the edge of the tile, not across a diagonal), or where either the southwest or southeast neighboring tile (but not northwest or northeast) contains hills, mountains, or snow-peaked mountains.

Provided that exceptions to this rule aren't found (or that if they are, they follow a consistent pattern), I could add that to this editor. Currently, the editor does not use the third or fourth row in the marsh PCX file, as I hadn't known what triggered the use of that row before. And while the pine marshes are processed by the editor (rows 9-10 of the PCX file), it doesn't actually use them at all since I hadn't found a trigger for that, either.

I haven't figured out what determines which image within a set of two rows is used, though I suspect it may be like forest/mountain/hill graphics in that while there is a pattern, figuring it out would be more effort than it would be worth.
 
Unfortunately they may have changed their minds & actual agree with you - with that part of the conversation buried in a completely different thread.

I only posted the link for the info on the bottom of the pcx - marsh+trees. Disappointing if they don't actually appear in game. Specific graphical slots for transitions between terrains could be very useful.

As with the various experiments on hills/mountains, at one point I did a lot of work on forests. Same or similar results. There's a pattern with a stochastic algorithm involved, and it's also affected by the base/surrounding terrains. iirc (only vaguely), the forests straddle the tile borders rather than lining up with them. So there's a complex pattern overlaying a complex pattern. In that imaginary perfect world we all want, the actual programmer would be part of our community (we did have Brad, who worked on the Mac editor, for many years). In that same paradise the code would be properly and thoroughly commented.

I gave up. As you said, it was turning into a crankish obsession, a black hole for creative time and energy. Too intense a quest for perfection destroys practicality.
 
I recall that Mike B., who wrote the Windows editor, was also part of the community for awhile back in the 2001 - 2003 era - I don't remember whether he was more active on Apolyton or CFC, but I've seen some of his posts on both. It certainly is helpful to have first-party community members - among his contributions was a complete list of conquests.ini options. I can't remember if it was him or Brad who helped in providing corruption algorithms.

But yes, the terrain algorithms were a creative black hole for me as well. I spent quite a bit of time on that before throwing in the towel. The other black hole for this project was an effort to improve the code quality from what I knew in 2009 to what I knew in 2014. I think I would've been better off limiting that to specific areas as I encountered them rather than trying to improve it generally, since it didn't directly enhance the editor and I was spending much less time on it in 2014 than in 2009. That was largely responsible for the lack of updates for the better part of a year in mid-2014, and also falls into the perfection-destroying-practicality category. Now I'm back to focusing on changes that will enhance the usefulness of the editor, often while being more enjoyable to work on as well.

I might've also not tried to embark on a general refactoring had I realized that I had about 75,000 lines of code. Even considering that a fair amount of that is either boilerplate, auto-generated, focused on the user interface, whitespace, or comments, there's still a lot of code to keep track of. About 1/3 of that is purely focused on the BIQ file, including importing it from and exporting it to files.
 
Made a custom palette file to use for indexing any image. The palette has 40 colors, with the infamous magenta & green, black, and white "reserved" - not to be used in images. These colors showed up in the terrain selection window even though they were nowhere in the image. Not every possible terrain appeared in the image. It seems like the editor is filling in the selections from unused colors in the palette. Question - is it picking colors from one end of the palette all the time? Seems likely since those colors are in indexes 36-39.


The problem with blanks in the pull down menus is in many places, not just in the open or save dialogues. I can't say it's there 100% of the time, but it happens enough that I guess so.

Map zoom - when I change percentage I get various strange effects - lower part of map not there (acts like it was cropped), random tiles at left & right edges, random parts of the map placed next to each other. Always one of those, but not consistently the same. If I bring up the zoom window again the problems correct themselves. sometimes just clicking anywhere within the window triggers the correction, sometimes clicking cancel does so.

Using OSX 10.9.5
 
Graphics
For some of these new Terrains you can have new graphics. These are all located in the Art/Terrain as usual.
LM Tundra uses LXTGC.pcx
LM Coast uses numerous PCXs... basically all L*.pcx that have coast in it
LM Ocean uses LWCSO.pcx and LWOOO.pcx
LM Pine Forest uses 5th and 6th rows of LMForests.pcx
LM Jungle, Marsh and Volcano use their base graphics and cannot be changed

The Result
More terrain! Some quick ideas:
- Real tundra vs. Glacial terrain - like on the screenshot below
- Named LM Volcano with different stats e.g. Vesuvius or Mount Doom
- LM Ocean with lower movement cost (winds,currents)
- LM Coast with higher movement cost (reefs, shoals) - over it you can place a resource, e.g. rocks, since it works better than editing the terrain PCXs
- LM Pine Forest - adds variety to the terrain

Here is a screenshot showing Tundra vs. LM Tundra with new graphics; Jungle, Marsh and Volcano with LM marks, LM Pine Forest with Sn00py's forest-marsh graphics contrasted with Palm-Trees-LM-Forest at the bottom. It also shows Jungle-on-plains, ...
Does the editor look for the "new" LM files listed by embryodead? Are there others he didn't specifically name that this editor looks for? For example you've got LM Plains, Grassland & Tundra Pine Forests as separate choices in the editor. Are those all coming from the LMForests.pcx or from LM versions of the other forests files?

It would be handy to have a single post with a complete list of all pcx files it's possible to access from the editor. Admittedly I haven't thoroughly searched all 580+ posts of this thread to see if there's already a list.
 
Made a custom palette file to use for indexing any image. The palette has 40 colors, with the infamous magenta & green, black, and white "reserved" - not to be used in images. These colors showed up in the terrain selection window even though they were nowhere in the image. Not every possible terrain appeared in the image. It seems like the editor is filling in the selections from unused colors in the palette. Question - is it picking colors from one end of the palette all the time? Seems likely since those colors are in indexes 36-39.


The problem with blanks in the pull down menus is in many places, not just in the open or save dialogues. I can't say it's there 100% of the time, but it happens enough that I guess so.

Map zoom - when I change percentage I get various strange effects - lower part of map not there (acts like it was cropped), random tiles at left & right edges, random parts of the map placed next to each other. Always one of those, but not consistently the same. If I bring up the zoom window again the problems correct themselves. sometimes just clicking anywhere within the window triggers the correction, sometimes clicking cancel does so.

Using OSX 10.9.5

For the color palette for importing BMP files, the editor will display all colors present in the BMP palette, regardless of what color they are or if they show up in the BMP. I hadn't really envisioned having colors in the palette that would be reserved like in Civ3 PCX files, although any color that is in the palette but not present at all in the BMP should have no impact on what happens to the imported map, regardless of what terrain you assign to it on the import window.

I suspect the drop-down menu issue may be something that only happens on more recent OS X systems than the 10.4 Tiger I have. Since I don't need yet another computer, I've set up a Hackintosh virtual machine with 10.9, and should be able to test with that. It's sort of quirky, but since the editor doesn't use the GPU, I think it will be testable. All encouragements to Apple to sell a version of OS X so development can be done on non-Apple hardware without hacks are encouraged. Hopefully now I'll be able to see this issue first-hand.

I have been able to reproduce the zoom issue. It was not present in version 0.83 (March 2013), which introduced the custom-zoom-level option, and I haven't made any zoom-specific changes since then. :hmm: However, clicking outside the editor and back fixes it, so I suspect it may be related the map panel being refreshed, which I may have changed since then. I'll look into that and should be able to identify which change caused it with further investigation.

Does the editor look for the "new" LM files listed by embryodead? Are there others he didn't specifically name that this editor looks for? For example you've got LM Plains, Grassland & Tundra Pine Forests as separate choices in the editor. Are those all coming from the LMForests.pcx or from LM versions of the other forests files?

It would be handy to have a single post with a complete list of all pcx files it's possible to access from the editor. Admittedly I haven't thoroughly searched all 580+ posts of this thread to see if there's already a list.

So, after checking, it seems that I overlooked LMForests.pcx :blush:. All the other landmark files, including for base terrains, mountains, and hills, are used, but somehow I missed forests. So when displaying the landmark forests, currently, the landmark icon is shown, but the forest graphic is the same as for the regular forest. That will go on the to-fix list.

In the specific case of pine forests, the difference is in what the base terrain is. So, LM Plains Forest will have the pine forest graphic (which should be the landmark pine forest graphic) on plains, LM Grassland Pine Forest will be the same, except on grass terrain, and LM Tundra Pine Forest will be the same, but on tundra.

I do agree that having a post listing not only all the PCX's used, but various other capabilities and how-tos, would be useful. In spring 2014 I'd started a blog focused on capabilities of the editor, but naturally since it wasn't on CFC, and writing things up well requires time, it never really got off the ground. Yet, a CFC thread is too long to search through, and updating posts to stay accurate also distorts the historical record. Meanwhile, the in-editor help is too limited in its HTML abilities to be as useful as it should be.

The next version, however, will be able to view modern web pages. So I plan to improve its documentation. I also recently learned that my email provider has file-storage/website capabilities, so that will work nicely for hosting the editor documentation. For now I've uploaded the editor's existing help here. Going forward, I plan to add to that, including graphics, and make that the default help site for the editor since 0.99 will be able to view modern sites, including images. It will fall back to the existing 1996-style help only if it's operating offline.

Though, to set expectations realistically, it will be awhile until that site really evolves significantly beyond what the help is now.
 
Thanks for the thorough reply!
... the editor will display all colors present in the BMP palette, ... colors in the palette that would be reserved like in Civ3 PCX files .... although any color that is in the palette but not present at all in the BMP should have no impact on what happens to the imported map ...
I tried an odd number of colors (40 rather than 16 or 256) just to see what would happen. 36 possible terrains + 4 extra colors. I just used the bright magenta, green, etc. to make it easy to spot them in the assignment list if they showed up. I wouldn't normally do that.

Part of the goal is to figure out how to consistently match the palette order to the way the colors/terrains are listed in the editor. Just part of streamlining my own workflow, by making it easier to run down the list. Maybe the question is "When making the initial assignments to the list does the editor start with the color in the 0 index position, or at the other end (255 in the case of the 256 palette)?" I guess I could experiment by rearranging the palette for the same image, but if you already know the answer ...

This is what happened - the map looked ok. No LM terrains were in the bmp or on the map. So far so good. OTOH, there were more colors in the palette than there are terrains. So the editor "filled in the blanks" so to speak but included some of the extra colors. There is no "None" option in assigning terrains. OK since those colors weren't used in the image anyway. But kind of a pain to have to go through & manually change every unused terrain slot to make sure none duplicate used colors.

Ultimately the solution (as a map-maker) is to create a palette with exactly the same number colors as the terrains available.

I suspect the drop-down menu issue may be something that only happens on more recent OS X systems than the 10.4 Tiger I have.
Sounds likely. I know the newer versions require updated java, etc. So there may be some differences affecting the menus.

so I suspect it may be related the map panel being refreshed, which I may have changed since then.
Refreshing was my hunch. There is the slight (expected) delay when first opening a map file, or when scrolling, but this is something different, as you've seen.


In the specific case of pine forests, the difference is in what the base terrain is. So, LM Plains Forest will have the pine forest graphic (which should be the landmark pine forest graphic) on plains, LM Grassland Pine Forest will be the same, except on grass terrain, and LM Tundra Pine Forest will be the same, but on tundra.
If I understand you correctly, they are all sharing the pine graphic from the LMForests.pcx. Which must be another one of the hard-coded limitations. Just means we can't use unique graphics for each of them separately. Disappointing that we can't have separate graphics for each of the forests, but that's something we just have to live with.

We now have LM Floodplains. The game engine uses Desert for the base terrain then overlays the floodplains.pcx onto it. So with LM Floodplains is it using the LM Desert ? Is it possible to create & use an LMfloodplains.pcx? Or is it the same as what embryodead said about the jungle, marsh & volcano - the LM Floodplains shares the same graphic as the standard terrain? I could create files & test this, but maybe the answer is already known.


In spring 2014 I'd started a blog focused on capabilities of the editor, but naturally since it wasn't on CFC, and writing things up well requires time, it never really got off the ground. Yet, a CFC thread is too long to search through, and updating posts to stay accurate also distorts the historical record.
Agreed on editing posts. I'm sure a second thread here dedicated to the documentation/help files would be possible. The CFC creation & customization wiki would have been a good choice, except that has never gotten off the ground either. The wiki is in place, but is just a skeleton, lacking any real content.


I guess the executive summary is - my questions are about understanding the editor & creating an efficient easy to follow workflow. Nothing major to fix about the mapping process, just trying to get a working knowledge of how the files are used. Then maybe I can help with creating documentation of at least that part of the editor. Been wanting to put together a map-making tutorial incorporating the communal wisdom anyway.
 
Small question Quintillus:

''Future Possibilities

The capabilities of this functionality could potentially be expanded to allow extracting maps or custom player data. If you want this functionality, please request it in the forum thread - so far little has been heard about this ability''

Have you still not done this? I think it could be useful for bug hunting. I was playing a real game without debug on, and my game had a fatal crash. As of now I dont know of a way of using your editor to load my save, turn the debug mode on, and go find my bug.

Can I do this with your editor as is? What I mean is import sav, modify, export sav. I really need to tackle this bug now that I've found it rather than having to remake a whole game with debug on.

What I'm trying to do is playing the modified save picking up where I left off and find out whats causing my crash the following turn. Thanks!
 
Top Bottom