Cross-Platform Civ3 Editor

Cross-Platform Editor for Conquests now available! 1.48

I had only run version 0.51 of the editor. I tried version 0.52 and it fails for me as well. I guess Quintillus has an error somewhere in his MacOS X path logic in version 0.52. I can't find a download link for the previous version, and am reluctant to post it myself. I suggest you wait for him to appear.

On my system, the log entry is more disturbing, as it appears his code is using a Windows routine to look for my file.
...

[UPDATE] It looks as if the findFileWindows routine is used if the civInstallDir is defined as /Applications/Civ III Complete., which is what the Editor sets it to if you follow the instructions to tell it where Civ3 Compete is installed. If I change the civInstallDir path to include /Civilization 3 Game Data, then it uses findFileOSX.It still fails, though.


Thank you kindly for taking the time to help me try and figure this out. Reassuring to know that I'm not simply mucking up the process.
 
It turns out there was a logical error, in the generic findFile routine. It was checking and calling the findFileOSX method, but rather than ending after a successful findFileOSX call, it kept on going. Thus, AlanH's log indicates that the findFileOSX routine was successful, but due to the bug, it kept on going and tried to use the findFileWindows method instead.

Thanks for posting both logs; without the seemingly contradictory behavior I probably wouldn't have spotted where the bug was tonight.

Version 0.53 will be posted soon, and includes both a more precise definition of which folder to select on OSX, and notification (including to the user in the program, outside of the log) of what file it last tried before failing to find a file, amongst other changes.

I've gone ahead and answered some of the remaining questions as they are good questions.

BTW, old versions (except 0.50, which I uploaded to a different directory) can be downloaded at quintillus.cfc.googlepages.com/ConquestsEditor0.51.zip (changing the version as needed). 0.50 is here.

I am getting the "Could not find pcx file ntp00" message when attempting to load any of the default scenarios. That particular file is located in /Civ III Complete/Civilization 3 Game Data/Art/Units/Palettes/ntp00.pcx

My ini file reads:

openDir=/Civ III Complete/Conquests Game Data/Scenarios
civInstallDir=/Civ III Complete
firstRun=false


And my installation directory is /Civ III Complete

That is the correct setup for version 0.52. For version 0.51 and earlier, AlanH's post gives the correct setup. I changed this as it made more sense both to have the actual install directory specified, and to have the Conquests directory right below the install directory.

The log file gives a warning that the biq file is not the proper version. I am running C3C 1.22, if that's relevant in any way.

In my experience, version 12.07 has worked, but I am don't know what the difference is between 12.07 and either 12.06 or 12.08, and thus haven't added it to the whitelist of versions. Presumably there is at least one difference, and thus at least one possible version 12.07 BIQ that wouldn't open. Conquests 1.22 is the Conquests version I test with, but the actual Conquests version shouldn't matter.
 
Version 0.53 is now up. This is primarily a bugfix and performance improvement release. Changes:

  • Fix to the bug where the OS X file-finding functionality wasn't being properly invoked.
  • Made the setup query more precise about which folder it needs on OS X
  • Added more detail on error messages should the editor fail to find a file it needs
  • Added configuration options for the amount of logging performed and the number of processors used when inputting file (more detail below/to be added to the online documentation).
  • Proper deletion of temporary files created when uncompressing a BIQ. You may find a ._tmp.biq file in the folder where version 0.52 ran if you used it on any uncompressed files. If so, running 0.53 in the same folder should delete it as soon as you open an uncompressed file, or the file can be manually deleted.
  • Added notification to the user if a file fails to open due to inadequate memory. This shouldn't be an issue even with 362x362 maps, but in case it is, you'll now know about it.
  • Expanded dualthreaded input of TILE objects to infinite threading. This should improve file opening performance on triple-core or higher PCs, most notably with large maps.
  • Extended multithreading to a few map sections beyond TILE.

I expect that the new configuration options will mostly be of use in testing and debugging, but as they may prove useful to end-users, their descriptions follow:

  • You may add "debugLevel=???" to your civ3editor.ini file to increase or decrease the amount of logging. The options for ??? are "trace" (very verbose), "debug" (verbose), "info" (the default), "warn" (only warning messages and errors), and "error" (only errors, no warnings). The default "info" level is recommended.
  • You may add "numProcs=???" to your civ3editor.ini file to set the number of processors used when inputting a .BIQ file. By default, the program will use as many processors as it sees that you have, which will usually give optimal performance. However, you may override this if for whatever reason the default is causing a problem. The program has been tested with 1, 2, and 3 processors extensively, and 17 and 81 occasionally (by setting this parameter - note that you can set it to more processors than you have, but this will slightly decrease performance).

Let me know if the fix doesn't work. As a note, I do have e-mail from members and admins turned on to an account I regularly check, so should I not reply for a week or more, that's always an option (although in such a circumstance, I may well be either extremely busy or without access to the Internet). It seems like it's been a lot longer since your post, Rufus, than it has, due to the number of posts in a short time.
 
Thank you for the fixes and the additional information. The editor is now loading without incident, and I am eager to delve into it.

Your dedication and support are much appreciated.


And I apologize if my rapid-fire posting feels a little insistent. I just happen to have a lot of free time on my hands at the moment :lol: I'm exceedingly grateful that you've put such a project together.

[Updated]

I've switched to Conquest Editor 0.50 with success, including the successful editing and playing of the initial scenarios. I was running into a problem when trying to add a building, and leaving that out has allowed for some success.

It has raised an additional question: What steps do I need to take to allow for a functioning building? Simply using the 'add' function, and trying out a bunch of variables has not consistently led to errors.

I'm going to give 0.53 another shot, as well.
 
Over the next week or so there's going to be intense work for the whole staff with the affect of Civ 5's release on the forum. But when things calm down I hope to get to trying this out. In the meantime I'm following the thread.
 
RufusTranquilus found another bug two bugs, this time in the export section. That bug has since been corrected, and a test (on the development side) has been added to help ensure such a bug does not show up again.

Corrections:
  • Correction of failure to output BIQ file bug introduced in version 0.53
  • Correction of inability to add buildings due to unmodifiable Building Description field, and addition of code to help prevent similar occurences from appearing on other tabs.

Download from here.

Thank you for the fixes and the additional information. The editor is now loading without incident, and I am eager to delve into it.

Your dedication and support are much appreciated.


And I apologize if my rapid-fire posting feels a little insistent. I just happen to have a lot of free time on my hands at the moment :lol: I'm exceedingly grateful that you've put such a project together.

[Updated]

I've switched to Conquest Editor 0.50 with success, including the successful editing and playing of the initial scenarios. I was running into a problem when trying to add a building, and leaving that out has allowed for some success.

It has raised an additional question: What steps do I need to take to allow for a functioning building? Simply using the 'add' function, and trying out a bunch of variables has not consistently led to errors.

I'm going to give 0.53 another shot, as well.

Don't worry about the posting - I'm glad you're running the program through the paces! You actually managed to catch two bugs in that post - one before the edit, and another after the edit. The pre-edit one, about the saving not working correctly, I meant to correct before finishing 0.53 but forgot :)blush:). More sleep should help prevent that in the future. The second is about adding functional buildings. You were being foiled by the unused (and currently not modifiable) Building Description field. It had no value, and there was no way to give it a value, so when the program tried to export your new building, it tried to export the value-less Building Description and failed. I've gone through the program and I think I've spotted all the places where something similar could happen (including on other tabs), and I'll be adding more rigorous tests to help ensure that problem is corrected across all tabs as well.
 
When you have time it might be worth editing the OP to include whatever the current version of the editor is as the link. Makes it easier for the reader than searching through an increasingly long thread.

The link actually goes to the CFC downloads page, and I'm changing the URL that the CFC downloads page points to every time I upload a new version. Thus the first page link will always point to the "current" version. The links in posts about new versions are to the same page as the one on the first page - just so users who click the "latest post" button don't have to go back to page 1 for the download.

But it isn't clear that the link on the first page is the newest version, so I've added the version and date to the first post next to the download link.

The link was down for a couple hours tonight after I realized the output bug in version 0.53, but before I fixed it, as I didn't want that bug to spread.
 
I've been running into some (as far as I can tell) un-patterned glitches while working in under the 'PLYR' tab. There have been occasions in which the dropbar fields (Government, Civilization, Initial Era, Difficulty, Player Color) will remain static and incorrect as far as the rules of the .biq are concerned. I believe when this happens, it corrupts something, as I have had issues with C3C reading files as corrupted. The UNIT and BLDG editing are working quit wonderfully, and I'd like to again express my gratitude.

[EDIT]
Non-issue
 
Version 0.55 is live. It includes the major requested feature of being able to merge the map from one BIQ with the rules from another. At present, the user is responsible for making sure there are no conflicts between the BIQs in items present on the imported map (most notably, that the resources are the same on the BIQs, but also possibly including units and buildings), and, while a valid BIQ MAY be produced if such a conflict exist, the behavior is undefined.

As such checks are desirable, and will be added sometime after this weekend, this is a "light" version of this feature, and not a full Version 0.60. However, it has been shown to be able to produce the intended merged BIQs well when the conditions are right, and thus is being released.

Change list:

  • Added initial support for merging the rules from one BIQ with the map from another.
  • Added a small number of tooltips for the primary interface buttons.

Step-by-Step of How to Merge Two BIQs
1. If the there are resources on the map of the "map" BIQ, VERIFY that the two BIQs have the same resource sections. Especially critical is that the number of resources is the same, but if the order is different, or the icons are different, you won't see what you expected on the finished, merged BIQ. If there are no resources on the map of the "map" BIQ, it doesn't matter if the resources sections are the same.
2. Repeat step one, for units, buildings, and civilizations, as pertinent (civilizations will be if cities or units exist, as they own units or cities).
3. Open the editor, and open the "rules" BIQ.
4. Click the "Import Map" button after the "rules" BIQ loads, and open the "map" BIQ (note that this BIQ does not need to have custom rules). You will get a warning about doing step 1 and step 2, just in case you jumped in without reading the directions.
5. You should receive a Success! notice. If so, you can go ahead and save the new BIQ and you should have your merged rules and map! If you receive an error notice, make sure you followed (1) and (2), and if so, post a bug report here.

Note that PLYR sections are NOT currently imported, so if you import a map WITHOUT cities into a BIQ whose original map had NO default starting units, your new BIQ will give your civilizations neither cities nor starting units by default. Thus, you may have to play around with your PLYR section some to get a reasonable starting position for your BIQ.

Importing the PLYR section will be possible someday, but importing it would require that your ERAS, GOVTs, DIFFs even, to be the same between the BIQs or be set to "Any" for all players in the source map. Requiring almost everything to be the same rather defeats the point of this, and adding helper functionality for merging is beyond the scope of this weekend.

Initial tests do show that a BIQ with that gives neither cities nor starting units for the human civilization lets the human simply watch the game in an "observer" type mode (if there isn't fog of war/undiscovered territory), with no interaction with other civilizations. This in itself may be useful for testing pure AI-AI interactions.
 
Version 0.56 is now up. This is a feature release.

Changes:

  • Added support for displaying unit icons (the 32x32 ones) on the unit/PRTO tab.
  • Back-end fixes to PCX file support to enable proper display of unit icons.

This works with custom unit icons as well as the default. Load times will be slightly longer than without PCX loading, but the difference is slight even when a scenario allows for thousands of unit icons.

Download from the Downloads Database here.
 
Version 0.57 is now up. This is a combination bugfix and minor feature release.

Changes:

  • Support for non-standard-width units_32.pcx files has been added. Some scenarios use these.
  • The editor now will create a configuration file on its own if one is not present. As a result, the editor no longer ships with a blank config file, and is no longer in a .zip file. Just download it, run it from wherever you download it to, and it'll work.
  • More accurate measurements of the time to open a file. This will help in figuring out where bottlenecks are to improve performance.
  • Support for Civ3-style PCX transparency. This is visible on the unit tab, where the unit icons no longer have a magenta background, but appear smoothly over the gray background.

The last change is, of course, necessary for the eventual map to look correct. Tonight was the first time I'd looked at code for the map since at least April (I think December or January, but have no definite records that far back), so it's getting some attention. Still doesn't do anything, but the wheels of progress for it are beginning to turn again.

Download link (same as always).

Edit: I've begun working on the map section in more detail, and hit upon a fairly significant snag, to do with whether hills/mountains form a chain or not. AlanH encountered this same problem in mid-2004, and despite searching both here, on Apolyton, and on Google, I wasn't able to find a solution. However, after a fair amount of :wallbash:'ing while trying unsuccessful attempts, I hit upon one tack that gave repeatable results. I've yet to figure out the formula for hill/mountain ranges, but I think I know which way to pursue an answer now. If anyone else is interested in trying to figure this out, head over to my post at 'Poly, and ideally read up on post 42 and later of that thread first. I'll be trying to figure it out again before long, but it's time for a break now after all that :wallbash:'ing.

Edit2: Apolyton and CFC have different tags for :wallbash:. :wallbash:. Another one of those inconvenient elements of a rivalry!
 


Still much to be worked out but it looks like this is going to be feasible. With a few things (such as forests and mountains) not always matching up with the in-game graphics.
 
By "not matching up" do you mean that the numbers are correct, but the display is not? Maybe you can post an editor/in-game side by side to show what you mean.

Good idea! By "not matching up", I mean that the actual type of terrain is correct, but the graphics aren't necessarily the ones that appear in Firaxis's editor (and thus in-game). Here is a comparitive screenshot from Firaxis's editor:



Spoiler Original from my editor again :


The forests don't match up, as I was not able to discover the pattern for which forest graphic is used (the forest between the two lakes is an example). Neither do all the mountains (take the one NW of Oslo), although some do (such as the one N of Oslo - I only discovered half of the mountain pattern). Finally, irrigation seems to follow the same pattern as mountains, so some of the irrigation tiles probably don't match up either, although I'm having a hard time spotting irrigation that doesn't match in this screenshot.

There are various other descrepancies, too, beyond the obvious things I haven't added to my editor yet. In Firaxis's editor, only rails are shown if rails exist; I'm currently displaying both roads and rails if both exist. I'm also doing my rendering for all mountains, then all irrigation, etc., whereas Firaxis appears to be doing it for everything on one tile, then everything on the next tile, etc., which accounts for some of the other differences (shouldn't be a huge change). I also haven't implemented the "hill/mountain" borders.

One difference is intentional - the border colors. The borders consist primarily of two colors, one being the civ's color, the other being a forest green in the editor, and a semitransparent forest green in-game. I've made the semitransparent version the default, although it will be switchable. The "civ color" border color still seems a bit too light in mine, so I may have to tweak that a bit.

Also, the "1" in the Firaxis version on a forest tile is an artifact of my search to find patterns in the forests. I haven't switched back all my PCX's yet.

There's also a discrepancy between my editor and Firaxis's in the realm of tile ownership (and thus borders) when a tile has multiple, equidistant, nearest cities,
and they all have exactly the same culture (and influence the target tile at least a minimal amount).

So far none of these items has been fixed. Rather, I decreased the time taken to calculate the nearest cities to a tile by 98-99+% (depending on the scenario), and the time to load graphics by 33%. Showing that algorithm choice and implementation really is important. Still not up to Firaxis's speed, though. I'm curious how close I can get, and how much of a handicap Java will be in that department. O'course, with multithreading, I might actually be able to make it faster, but only given sufficiently multithreaded hardware.
 
There are various other descrepancies, too, beyond the obvious things I haven't added to my editor yet. In Firaxis's editor, only rails are shown if rails exist; I'm currently displaying both roads and rails if both exist.
I'd leave it that way :)
 
I'd leave it that way :)

I could make that an option.

Just a suggestion: perhaps the absence of cities and rivers in your editor explains the differences

Obviously, those haven't been done yet :p. Rome wasn't built in a day, neither are all the graphics done in a night. The preview is meant to show that it looks like this is going to be feasible (if with a couple of aberrations such as for forests), not that it's complete.

I'm also aware that the BLDG tab is currently hidden. Not to worry, it'll reappear.

The aesthetic differences are not so important as being able to map. We all need to check graphics in-game anyway. Keep up the good work.

I will probably go ahead and do the rest of the graphics (resources, cities, etc.) before fixing the aesthetic issues. A wider variety of testing (especially on mods with custom graphics) also will probably come before the aesthetic issues.

After that comes the design of the interface for changing the map. This is where suggestions for improvements over Firaxis's editor will be valuable. Already I'm planning to significantly revamp the city page, the unit section in particular. Why you can only view one unit at a time in Firaxis's editor (instead of seeing all the units on a tile), and then can only change the properties of one at a time (instead of, for instance, making all the units veteran) has always been a design choice mystery. I'll also probably make it possible to select the unit experience along with type when you set the brush to units, so that you won't have to manually change the skill level of every single non-regular unit if most of your units are veterans/elites/conscripts. But improvements on the map section of Firaxis's editor in general are welcome. Many of you are much more experienced in creating scenarios, and probably much more aware of the Firaxis map editor's shortcomings.
 
Top Bottom