Cross-Platform Editor for Conquests now available! 1.48

[timerover51]

So, is it safe to download the 0.97 version, or better to go back one or two?

 

[Quintillus]

So, is it safe to download the 0.97 version, or better to go back one or two?

If you're editing BIQs with existing rules, 0.97 should work just fine. The error Blue Monkey encountered affects when you try to create a completely new BIQ, or try to add rules to a BIQ that didn't have rules previously. Those are both fairly new, so if you wish to use them the best option is to wait a few minutes for an update. Otherwise, 0.97 should be fine.

 

[Quintillus]

Version 0.98 is now available. This includes a few fixes plus a change to make editing civ colors more convenient.

• Enabling custom rules, as well as creating new BIQs, now works on OS X.
• You can now easily start editing Civ Colors even if you haven't set up duplicate ntp##.pcx files; the editor will do this for you if you have at least one Scenario Search Folder.
• Fixes to Vanilla BIC to Conquests BIQ conversion process (see below).
• Small fix to make updates to one tab available to all others as soon as you leave the first tab (cases where this was noticeable before were rare, and saving to disk was not affected).
• The editor can now exit properly if its civ3editor.ini file is read-only (either the file itself, or due to being on read-only media like a CD-R).

Civ Color Editing is on the CIV tab; if you have at least one search folder on the PROP tab and click the Edit Civ Colors button (below where colors are set for a specific civ), the editor will now offer to copy the Firaxis files for you. This improvement was inspired by Ozymandius's thread asking about Rhye's palette.pcx.

The BIC to BIQ conversion improvements particularly affect converting units properly; Vanilla actions are now converted to PTW/Conquests actions appropriately, in particular. Conquests worker actions (Airfield, Radar Tower, etc.) are also automatically added, with prerequisite techs set if the default prerequisites are present in the BIQ.

The last two fixes are pretty niche, but the first one is the one Blue Monkey encountered, and should now be working. Both that fix as well as the copying-Firaxis-PCX-files change have been tested on a Mac.

Finally, this update does still support the old operating systems (98/Tiger and newer); the features that will require XP/Mountain Lion or newer are not yet finished.

 

[timerover51]

Hmm, so I had better download 0.97 now for my older Mac then. Got you, and thanks again for all of your efforts.

 

[Blue Monkey]

The new version finds the correct path now. My Civ files are installed on a second drive, not in the Applications folder, so it's a good test. On to the map work.

 

[Blue Monkey]

There are now a full 16 "basic" terrains, as well as 20 more "advanced terrains", which cover (unless I've missed some) all land-based terrains in Civ3 as well as the water option. All Landmark options are in Advanced Mode.

I want to make a "palette" of all terrains so that as I make map images they will already be in the proper colors to convert. Something like what I did for BMP2BIC. On the TERR tab there are 14 terrains listed.With the LM versions that's 28 vs. the 36 in the quote. I can't think what the others might be. There are the separate graphics files, such as snow/forest mountains & plains/grassland forests, but afaik those are not treated as distinct terrains - only as visual variations. Hope this doesn't sound nitpicky. I know during that phase of the development we were all trying to work out what terrains were possible, even theoretically. I just want to make a palette guide that will hopefully be of general use.

 

[Blue Monkey]

Sorry - been so long since I looked at or thought about this. There's the terrains as far as the values used in the game & the terrains as far as the graphics files & the map appearance in game. Not precisely the same list.

Really what i want to know is the list of terrains the editor is assigning colors to when converting a bmp.

 

[Quintillus]

So, the editor's BMP import functionality assigns each color a terrain that's based on the graphics file that will be used, and also supports the landmark version of those. The idea being that if you have different colors for pine forests vs. regular forests, it would be nice for the editor to be able to pick up on that even though they're technically the same terrain (just different variants thereof) in game.

The complete list is:

"Water"
"Grassland"
"Plains"
"Desert"
"Tundra"
"Forest"
"Jungle"
"Hills"
"Mountains"
"Marsh"
"Volcano"
"Flood Plain"
"Plains Forest"
"Tundra Forest"
"Pine Forest"
"Tundra Pine Forest"
"Plains Pine Forest"
"Snow-Capped Mountains"


"LM Water"
"LM Grassland"
"LM Plains"
"LM Desert"
"LM Tundra"
"LM Forest"
"LM Jungle"
"LM Hills"
"LM Mountains"
"LM Marsh"
"LM Volcano"
"LM Flood Plain"
"LM Plains Forest"
"LM Tundra Forest"
"LM Pine Forest"
"LM Tundra Pine Forest"
"LM Plains Pine Forest"
"LM Snow-Capped Mountains"

So there's the option to have the editor distinguish between regular forest, forest-on-plains, pine forest, pine-forest-on-tunda, and so forth, even though these are all technically just "Forest" on the terrain tab. It is possible to only assign colors to "Forest" and get all forest-on-grassland and reassign them yourself if need be, or if you don't have different colors for different types of forest... but the option to be more specific is there if you do have source material that distinguishes that.

Also of note is "Water". The way the algorithm works is that all "Water" that borders land is coast; after that, all "Water" that borders only other water and coast is Sea, and finally all water that borders only other water and sea is ocean. There isn't currently a way to specify that a large area of water should all be coast or all be sea when importing from a BMP (though it can be edited to reflect that after the import).

Finally, the first 16 in the list above are the "Basic" mode; the rest turn on when "Advanced" is enabled (including all the landmark options).

Let me know if you have more questions - I have used this process for creating a map (though not with all 36 of the terrains mapped to colors), so I can go through an example too.

Hmm, so I had better download 0.97 now for my older Mac then. Got you, and thanks again for all of your efforts.

You're welcome! 0.98 does still work on the older Macs. I tested it on a Power PC Mac running OS X 10.4, which is the oldest version that the editor has ever supported. I've been meaning to start adding some features that will require a newer version, but haven't gotten around to making them ready for release yet.

Which version of OS X does your older Mac use? Currently, when I do get around to finishing the newer-tech features, they'll probably require 10.8 (Mountain Lion), although 10.7 (Lion) is a possibility if there are people using it. Even after that point there probably will be smaller updates for older versions, but without the new features. I'm looking forward to using some of the newer programming language options, both for the benefit they provide, and because I would get some benefit career-wise from being more familiar with them, so I do expect to transition to them at some point. Currently it's still slower working with them though, because of the lack of familiarity, so they those features aren't moving along that quickly.

 

[timerover51]

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.

 

[Kestrel18]

Great Editor !

One Minor Bug Report. Not sure if it has already been reported (with 28 pages of replies so far, it probably has) so apologies if I am double-reporting.

In the Option "Export to CSV" the "Prerequisites" column, when "Include Technologies" is ticked, the export only displays multiples of the first tech required for that subsequent tech advancement - For Example ;

Tech Name........ Era.............. Prerequisites

Mathematics......... Ancient Times.... Masonry and Masonry
Map Making.......... Ancient Times.... Writing and Writing
Horseback Riding.... Ancient Times.... The Wheel and The Wheel
The Republic.........Ancient Times.....Philosophy and Philosophy
Monarchy............ Ancient Times.... Warrior Code and Warrior Code
Construction.........Ancient Times.... Iron Working and Iron Working
Chivalry............ Middle Ages...... Monotheism and Monotheism
Invention............Middle Ages...... Feudalism and Feudalism
Democracy............Middle Ages...... Printing Press and Printing Press


...and so on.

For Mathematics (in standard 'vanillla' Civ 3 Conquests) it should be ; Masonry and Alphabet.

Cheers.

 

[Kestrel18]

Following on from my last post above, about the Export to CSV feature minor bug.

One enhancement I would LOVE to see (in the fullness of time and if you ever feel so inclined) would be an "Import from CSV" feature for units.

This would enable modders to export the units statistics for an existing mod-pack/scenario biq, import the CSV to Excel, and then (for example) double all the Attack and Defence and Bombard stats (so as to allow greater nuance in creating and inserting new units), export again to CSV and then re-import into the biq with all the changed numeric values in one step.

It could also be used to modify any of the other numeric values currently exported by the editor (movement, hitpoint bonus, cost etc.)

The only other way I currently know to do this would be to change each and every numeric setting, step by step for each and every unit. (Does anyone know of another, more efficient way ?)

In the old Civ2, the statistics for units were held in a text file, so it was easy to perform such a global change with a bit of minor massaging.

An 'item' by 'item' editor such as was provided with Civ3 always seemed to be to be a bit of a backward step, even though the interface was prettier.

 

[Blue Monkey]

So, the editor's BMP import functionality assigns each color a terrain that's based on the graphics file that will be used, and also supports the landmark version of those. ... the option to be more specific is there if you do have source material that distinguishes that.

Thanks for the list & thorough explanation! I'll be making a little graphic table with my chosen colors. Eventually I want to update my old map-making tutorial with it, info about your editor, and some other streamlining of the process. In the meantime I could post the chart here if people would find it of use as an example.

... The way the [editor] works is that all "Water" that borders land is coast; after that, all "Water" that borders only other water and coast is Sea, and finally all water that borders only other water and sea is ocean. There isn't currently a way to specify that a large area of water should all be coast or all be sea ...

Automating initial water placement is well worth the freedom and range gained in mapping other terrains. I usually end up "paintbrushing" the water types away from the coast anyway.

 

[Blue Monkey]

worked out a palette, used it on a map wip, imported, associated terrains with colors, map creates just fine. I didn't like some of the distortions caused by the conversion - I need to think about proportions differently for this editor vs BMP2BIC. So I reworked the image - made sure the new version was indexed. This is what I get for the color assignment dialogue:

Spoiler :

Not good.
Tried -

• quitting & restarting editor. Same result
• trashing the temp files such as the bmpcolor txt, the log, the autosave. restart editor. same result.
• re-indexing the image. restart editor. same result.

EDIT: While doing further experimentation, went bck and opened another bmp that had worked before. It was fine, so must be something about how I indexed that particular image, not with the editor.

working with GIMP 2.8.10p2 under OSX 10.9.5

 

[Blue Monkey]

Decided to try a 16 color bmp, since the map had fewer terrains. An unexpected result -

Tundra color chosen in palette dialogue resulted in Desert on created map. It's important to note that the colors were very different pastel violet vs. orange-yellow:

Spoiler :

Also, tried a trick that should be helpful in editing. Left "Ocean" & "Coast" both as Water, but made "Sea" LM Water. Usually paintbrush the water in broad strokes anyway, so the LM markers will serve as a guide. First change LM to Sea then everything next to coast to Coast.

Spoiler :

not sure how well a biq survives zipping - just in case it's useful Dinotopia WIP

 

[Quintillus]

Don't you love it when you type up a nice detailed response, and then your browser crashes and swallows your reply? Sorry if the retyped replies are somewhat shorter! I also plan to edit this post to add to it so that I won't lose all the replies if it crashes again.

Decided to try a 16 color bmp, since the map had fewer terrains. An unexpected result -

Tundra color chosen in palette dialogue resulted in Desert on created map. It's important to note that the colors were very different pastel violet vs. orange-yellow:

Spoiler :

Also, tried a trick that should be helpful in editing. Left "Ocean" & "Coast" both as Water, but made "Sea" LM Water. Usually paintbrush the water in broad strokes anyway, so the LM markers will serve as a guide. First change LM to Sea then everything next to coast to Coast.

Spoiler :

not sure how well a biq survives zipping - just in case it's useful Dinotopia WIP

I took a look at the BIQ (which survived just fine!). I suspect what's happening is related to the plains nearby, and tundra not being allowed to border plains. The bmp-import process does have code to avoid any illegal-in-Civ3 neighboring terrain. I can likely provide a more exact answer with the BMP and the color-mapping to run through with breakpoints.

Was the larger desert to the southeast supposed to be desert, or tundra? If that was also supposed to be tundra it suggests that perhaps the tundra-in-illegal-area algorithm needs tweaking; that's a larger desert and while I can see smaller areas not becoming tundras, one that large should have at least some tundra if that's what it was supposed to be (although still perhaps less than expected due to the plains).

It is possible to get tundra to show up, and I've done so with Earth-based maps, but since it can't broder desert or plains in Civ3 it can be somewhat more difficult than other terrains.

worked out a palette, used it on a map wip, imported, associated terrains with colors, map creates just fine. I didn't like some of the distortions caused by the conversion - I need to think about proportions differently for this editor vs BMP2BIC. So I reworked the image - made sure the new version was indexed. This is what I get for the color assignment dialogue:
Spoiler:

Not good.
Tried -
quitting & restarting editor. Same result
trashing the temp files such as the bmpcolor txt, the log, the autosave. restart editor. same result.
re-indexing the image. restart editor. same result.

EDIT: While doing further experimentation, went bck and opened another bmp that had worked before. It was fine, so must be something about how I indexed that particular image, not with the editor.

working with GIMP 2.8.10p2 under OSX 10.9.5

It looks like I need to either add a scroll bar to the color-mapping window, or add a limit on the number of colors, or both. It appears that the file in that screenshot really did have 256 colors; it's possible to limit the palette to a number between 16 and 256 in GIMP, and that's what I generally recommend and have been doing. I think I wrote up how to do that somewhere in this thread; I'll look it up.

Edit: Found it. 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. This is in GIMP 2.8; the location in the menus is different in 2.6 and 2.4.

Thanks for the list & thorough explanation! I'll be making a little graphic table with my chosen colors. Eventually I want to update my old map-making tutorial with it, info about your editor, and some other streamlining of the process. In the meantime I could post the chart here if people would find it of use as an example.

Improved documentation is always welcome. I used your BMP2BIC documentation when learning how it worked, and deciding what I wanted to do similarly and differently in this program.

Following on from my last post above, about the Export to CSV feature minor bug.

One enhancement I would LOVE to see (in the fullness of time and if you ever feel so inclined) would be an "Import from CSV" feature for units.

This would enable modders to export the units statistics for an existing mod-pack/scenario biq, import the CSV to Excel, and then (for example) double all the Attack and Defence and Bombard stats (so as to allow greater nuance in creating and inserting new units), export again to CSV and then re-import into the biq with all the changed numeric values in one step.

It could also be used to modify any of the other numeric values currently exported by the editor (movement, hitpoint bonus, cost etc.)

The only other way I currently know to do this would be to change each and every numeric setting, step by step for each and every unit. (Does anyone know of another, more efficient way ?)

In the old Civ2, the statistics for units were held in a text file, so it was easy to perform such a global change with a bit of minor massaging.

An 'item' by 'item' editor such as was provided with Civ3 always seemed to be to be a bit of a backward step, even though the interface was prettier.

Good idea, it makes sense to me. (And, welcome to the thread!) 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. But I can't remember whether you can quickly edit them there, and I'm getting a .NET error when trying to open a scenario in Steph's editor on my computer currently (was searching for it when I got the afore-mentioned crash). Thus, I'm currently unable to check.

Great Editor !

One Minor Bug Report. Not sure if it has already been reported (with 28 pages of replies so far, it probably has) so apologies if I am double-reporting.

In the Option "Export to CSV" the "Prerequisites" column, when "Include Technologies" is ticked, the export only displays multiples of the first tech required for that subsequent tech advancement - For Example ;

Tech Name........ Era.............. Prerequisites

Mathematics......... Ancient Times.... Masonry and Masonry
Map Making.......... Ancient Times.... Writing and Writing
Horseback Riding.... Ancient Times.... The Wheel and The Wheel
The Republic.........Ancient Times.....Philosophy and Philosophy
Monarchy............ Ancient Times.... Warrior Code and Warrior Code
Construction.........Ancient Times.... Iron Working and Iron Working
Chivalry............ Middle Ages...... Monotheism and Monotheism
Invention............Middle Ages...... Feudalism and Feudalism
Democracy............Middle Ages...... Printing Press and Printing Press


...and so on.

For Mathematics (in standard 'vanillla' Civ 3 Conquests) it should be ; Masonry and Alphabet.

Cheers.

Thanks! And... whoops. You're right, it is repeating the first tech when there's more than one prerequisite. I'll take a look at that, and it ought to be fixed with the next version (probably in November, though updates come at irregular intervals depending on how much I've changed in a given time).

 

[Blue Monkey]

I suspect what's happening is related to the plains nearby, and tundra not being allowed to border plains. The bmp-import process does have code to avoid any illegal-in-Civ3 neighboring terrain. ... Was the larger desert to the southeast supposed to be desert, or tundra?

You're right on both counts. I can redo the smaller area with grass surrounding. I often use tundra as a placeholder for unusual terrain - my fault for forgetting the limitation. & the larger area was desert.

It looks like I need to either add a scroll bar to the color-mapping window, or add a limit on the number of colors, or both. It appears that the file in that screenshot really did have 256 colors; it's possible to limit the palette to a number between 16 and 256 in GIMP, and that's what I generally recommend and have been doing.

The bmp was meant to have 256 colors. Double-checked that when reindexing. But as stated in the edited comments - there may be a problem with the file since other bmps indexed from the same selection of colors both before and after worked fine.

I'm happy with the way you've steadily improved the mapping functions. As I have time to get back into the groove I'll be better able to distinguish what are user errors vs. shortcomings with the editor. Prepping for work on a couple of maps with a lot of LM terrain. Thanks, Quintillus, for your ongoing efforts.

 

[Blue Monkey]

Update on Palettes

• There was a problem with the palette of that particular file- it indexed to a weird number of colors for some reason. The dimensions of the image were off as well - wonder why the editor even accepted it.
• Experimentally tried indexing a known working image to 36 colors, saving the palette, importing to editor. Good results.
• Used the saved palette to index a couple of other images - including the one that had been a problem (re-scaled). The editor successfully converted all of them to maps.

After a little more testing I should be able to provide a chart of the colors used: a set that are easily distinguishable but visually pleasing & sensible (except for the pale purple marshes ) . Could also post the palette itself I guess, if there's any interest. Pretty sure GIMP can export a palette.

 

[Blue Monkey]

speaking of image dimensions - made a small spreadsheet to compute pixels for any given number of tiles. I use OpenOffice but could export it to xls (xlm ?) if anyone wants it.

 

[Quintillus]

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 have added a scroll bar for the palette-to-terrain mapping page, so that should work better with large numbers of colors going forward (with version 0.99 and later).

I'd be up for seeing the palette, as well as the dimension spreadsheet. Going forward one of the things I'd like to do is improve the documentation in the editor with graphically-rich examples. With the current version of Java, the built-in web browser used for documentation would have been state of the art about 20 years ago, but it is super-outdated now - hence why the documentation is text-only. However, once there's a version running on a newer version of Java, the web browser can be compatible with modern sites (it has the same underpinnings as Safari, and is thus also very similar to Chrome and Opera), so it would be easy to have a help topic link to a CFC post, or multiple posts. These would both fit in with that ability.

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 probably should link in the BMP Size Calculator from the Import From BMP window - that is after all where it would be most handy.

XLS, XLSX, or CSV would all be readily accessible to nearly anyone. ODS is actually supported natively in Excel 2010 and later as well, so that would also work for a lot of people. I still mainly use Excel myself, but have LibreOffice on one of my machines. It's come along fairly well over the past 5 years.

Glad to hear the mapping improvements are being noticed! I know the ability to paint multiple tiles at once was one that had long been requested. I still have a few ideas up my sleeves, too, although not all of them relate to maps.

 

[Blue Monkey]

Update on the "Tundra" Problem

Used "stroke selection" to make sure there was grass all around the tundra. Looking at the unhappy result, realized that it was converting the tundra to grass not desert (check the image below) - but why?

The solution is something for map-makers to keep in mind, nothing needs to be changed in the editor afaik.

Thinking it through, more dust blew off the part of my brain that used to do the mapping Got to think of tiles as pixels. One tile = one terrain = one color.

Any area of color that's too small just disappears in translation. Sort of knew that - reason I use the "splattery" effect to get "random" boundaries between terrains - just hadn't thought it through as it applies here. Given the image proportions the editor needs, one tile equals a 64x32 pixel chunk of any source image. The illustration in the spoiler has some 64x32 magenta oblongs for comparison to a section of the bmp.

Spoiler :

It's easy to see that some mountain regions are not 64x32 but are substantial enough to register. OTOH, thin strips of green/grass, just like many of the small regions of all colors, might as well not be there. Leaving the editor to cope with forbidden terrain contact.

Note to self - use a big brush.