Cross-Platform Editor for Conquests now available! 1.51

[Quintillus]

I know that it's not exactly what you want, but there is another way to make "foreign" units: make troops cost population. The created unit will take the nationality of the used pop, and be free of maintenance in the process.

Not related, but the editor allows me to place barbarian units directly into cities. At least, on those with no other garrison. Surprisingly, it didn't crash immediately upon load. The normal editor doesn't show them, and you can't really tell with this one. I only realized when doing a bug hunt for unrelated reasons. I attach a test file.

With further testing, this is what I found:
- The barbarian unit won't sack the city, but rather fortify in place.
- Attempts to create units on that city units fail.
- Buildings are created normally.
- If done with units of another civilization, the city will be destroyed with no warning. No ruins either.
- In this case, the normal editor tries to change ownership of the city.
- Changing the ownership of the city on the editor fixes the mismatch.
- Destroying the barbarian city allows a return to normalcy.
- Renaming cities can sometimes remove the anomalies in game, but not in the editor. Also, the game will star to ignore some setting, like debug and reveal map. (TEST_2)
- It tricky to set up. The city need to be a player, not a civ. Otherwise, it corrects itself in some way (either one is deleted, or it changes ownership)

As far as I can tell, if you try to place a unit of X nationality and then select a city and immediately add a unit, the nationality remains at whatever was chosen before. It seems true for both Player and civilization mode.
Test_1 has a city with a barbarian garrison
Test_2 has a partially corrupted file due to the weird interaction this causes.

Interesting. I downloaded the test BIQs, and have been able to confirm that there is a unit there that the Firaxis editor does not display. Still have some investigation to do, though; I've documented it in the bug tracker to ensure it doesn't get forgotten. I am curious what the process was to create the barbarian unit, beyond that the city needs to be owned by a player. Any units placed on a city tile should have the same owner as that city, so it is rather puzzling.

Been a while...and its now 2020 (saw my earlier post...)! Looks like I'm going to be doing some modding again on one of the mods I had 95% finished back in 2017. An issue I never fixed was one relating to how I incorporated my "events" and I needed a hacked editor for the method I was using. But I can't seem to open my mod into your editor. Seems to be the Java issue, but the link you provided doesnt seem to be working anymore? I looked back at posts and I havent seen an update on the status, so I assume Java 11 is still a major issue for the editor?

I'm currently using the most updated java for my Java classes at college, so don't think I can downgrade though.

Unfortunately, I think that Java 8 is the magic number.

The Oracle/OpenJDK Java 11+ builds are not compatible. However, I have had good success running the Liberica Java builds. If you choose the "Full JDK" (if you need developer tools) or "Full JRE" package, it includes JavaFX (which the editor requires, and was removed in the Oracle Java 11 build), and the editor should work out of the box; I have verified this with their Java 13 build.

Alternately, the Windows XP Build includes a bundled Java 8, that the editor will use but will not be a system default. If going that route, the jre1.8_111 folder, Editor_XP.bat file, and (optionally) XP_laucher.vbs file can be copied over to a download of a newer version to have them also use Java 8, independent of your system Java version.

There also is a macOS build for Java 11. This is a one-off so far, however, as there hasn't been further demand for it. I also have only tested the editor on Macs through High Sierra (which is what my 2010 Mac Mini runs), and cannot guarantee Catalina compatibility.

It has been a couple years since Java 11 came out, and at the time it proved to be a huge pain to get the editor working with both Java 8 and Java 11; the one-off custom-built Mac version was the only success of that effort, and it looked like success would require building on all OSes (Mac, Windows, Linux) separately rather than just once and having it run anywhere, which would add considerable overhead to a project that is already a bit low on development time. Since at the time Java 8 was still receiving updates, and not auto-updating to Java 11, I decided to go back to focusing on Civ-related features until it came up on the radar again. It might be time to revisit it and see if there is a less painful way forward now than when I last looked at it.

It does look like my hosted download links broke after I combined a few virtual private servers earlier this summer. I've added a note to update those.

Has anyone tried putting Settler into the advanced barbarian unit slot? Would that result in barbarian cities producing certain units that the player makes available to barbarian chiefdoms?

I have not. I have explored barbarian cities a little bit, and there are a few threads in C&C discussing them... and it looks like I was able to find the most recent one here.

 

[Civinator]

Quintillus, thank you very much for your detailed answers and I´m glad, that things are going better for you now again.

The first question mark is now known to be the useExactCost variable; which controls whether "8" in the unit cost means 8 shields, or 80, for example. A value of 7 means "use the cost literally"; I don't remember what value means "multiply it by 10"

The explanation in the Civ 3ConquestEdit shows, that the multiplayer of 10 is used as the cost multplayer for buildings built by the human player. Edit: May be I have missunderstood this and meant is a number that stands for the multiplayer by 10.

I don't expect that they would correspond to nationality, because that would mean that all units of that PRTO type would be of a particular nationality.

Quintillus, the handling of enslaved units, listing their original nationality in brackets shows, that all units of the PRTO type are of a particular nationality. They have the nationality of the civ that did build that unit. I attache two screenshots from a CCM2 game, showing the original nationalities of units that were enslaved to workers (among them a barbarian unit that was enslaved to a worker) and of units that were enslaved to Great Artists. So I think this is an argument that these values have to do with the nationality. The program must be aware about the nationality of each unit, as only units with a foreign nationality can be sacrificed (and each unit can be enslaved to an unit that can be sacrificed).

 

[Ozymandias]

I know that it's not exactly what you want, but there is another way to make "foreign" units: make troops cost population. The created unit will take the nationality of the used pop, and be free of maintenance in the process.

Not related, but the editor allows me to place barbarian units directly into cities. At least, on those with no other garrison. Surprisingly, it didn't crash immediately upon load. The normal editor doesn't show them, and you can't really tell with this one. I only realized when doing a bug hunt for unrelated reasons. I attach a test file.

With further testing, this is what I found:
- The barbarian unit won't sack the city, but rather fortify in place.
- Attempts to create units on that city units fail.
- Buildings are created normally.
- If done with units of another civilization, the city will be destroyed with no warning. No ruins either.
- In this case, the normal editor tries to change ownership of the city.
- Changing the ownership of the city on the editor fixes the mismatch.
- Destroying the barbarian city allows a return to normalcy.
- Renaming cities can sometimes remove the anomalies in game, but not in the editor. Also, the game will star to ignore some setting, like debug and reveal map. (TEST_2)
- It tricky to set up. The city need to be a player, not a civ. Otherwise, it corrects itself in some way (either one is deleted, or it changes ownership)

As far as I can tell, if you try to place a unit of X nationality and then select a city and immediately add a unit, the nationality remains at whatever was chosen before. It seems true for both Player and civilization mode.
Test_1 has a city with a barbarian garrison
Test_2 has a partially corrupted file due to the weird interaction this causes.

Interesting. I downloaded the test BIQs, and have been able to confirm that there is a unit there that the Firaxis editor does not display. Still have some investigation to do, though; I've documented it in the bug tracker to ensure it doesn't get forgotten. I am curious what the process was to create the barbarian unit, beyond that the city needs to be owned by a player. Any units placed on a city tile should have the same owner as that city, so it is rather puzzling.

Interesting - I'd highly recommend keeping this as a feature. Consider: It allows a mod or scenario to begin with cities in revolt.

 

[Quintillus]

The explanation in the Civ 3ConquestEdit shows, that the multiplayer of 10 is used as the cost multplayer for buildings built by the human player. Edit: May be I have missunderstood this and meant is a number that stands for the multiplayer by 10.

Quintillus, the handling of enslaved units, listing their original nationality in brackets shows, that all units of the PRTO type are of a particular nationality. They have the nationality of the civ that did build that unit. I attache two screenshots from a CCM2 game, showing the original nationalities of units that were enslaved to workers (among them a barbarian unit that was enslaved to a worker) and of units that were enslaved to Great Artists. So I think this is an argument that these values have to do with the nationality. The program must be aware about the nationality of each unit, as only units with a foreign nationality can be sacrificed (and each unit can be enslaved to an unit that can be sacrificed).

Ah; based on your initial post, I had book looking at the Unit (PRTO) tab when discussing the multiplier. On that tab, useExactCost behaves as I described it. This can be shown by starting the Firaxis editor, enabling custom rules, editing units, and seeing that the Jaguar Warrior costs 15 shields, which is meant literally. I believe Firaxis introduced the "literal cost" option when they decided that for balance purposes, some units needed to have a shield cost that ended in a 5, rather than a 0. On older BIQ/BIX/BIC files, a unit that cost 20 shields would have its cost listed as "2", rather than "20", and would not have useExactCost set to 7.

For buildings, I believe what you have posted is correct. I should not that the Palace seems to have special logic where the cost is at least partially dependent on the size of the empire; I have not determined what the factor is for that, but as it appears to be algorithmic, it would not be something that could be set in a BIQ (though the base cost, which that factor would multiply, can be set).

As for the PRTO types being of a particular nationality, I believe this is an area where the difference between the SAV and the BIQ is applicable, and the difference between PRTO and UNIT (units on the map) definitely is applicable. PRTO is the "prototype" for a unit - e.g., an Archer always has 2 attack, 1 defense, etc. UNIT is a specific unit - e.g. an Archer that is located at 37, 45, is owned by Japan, and perhaps has the name "Tokyo's Finest". The BIQ fields for UNIT are fully documented at Apolyton:

UNIT SECTION

  4    char        "UNIT"
  4    long        number of units

  For each unit:

    4    long        length of unit data
    32    string        name
    4    long        owner type (0=None, 1=Barbarians, 2=Civ, 3=Player)
    4    long        experience level
    4    long        owner (RACE ID, Player# (0=Player1 and so on) or Barbarian Tribe)
    4    long        PRTO#
    4    long        AI strategy
    4    long        X
    4    long        Y
    57    string        PTW name (replaces name)
    4    long        use civilization king

The owner refers to the actual owner - e.g. perhaps the Tokyo's Finest archer (PTW name) is in Korean territory, but it is owned by Japan. This can be set up in the BIQ.

However, I believe what you are highlighting in terms of Nationality is only visible in the SAV, where the fields available for each UNIT may be expanded. The BIQ has no way to trace the original nationality of a unit - but the SAV may do so.

The scenario editor (currently, at least) is limited by the realm of what the BIQ may specify. To enable SAV fields to be modifiable, I believe the editor would have to not only be able to understand and save all SAV fields (which it does not currently), but would also have to be able to generate a SAV file for every civilization that should be playable for a scenario (versus one BIQ that could be played by all civilizations).

This is a somewhat intriguing possibility. Realistically, this probably isn't going to happen unless I start working full-time on the editor for some reason. But that is probably what would be needed for "original nationality" to be recognized in the initial setup of a scenario.

Interesting - I'd highly recommend keeping this as a feature. Consider: It allows a mod or scenario to begin with cities in revolt.

This is an area I am still investigating. I have determined that there is a bug where if a BIQ has a custom map, but default rules, and has units placed, the scenario cannot be loaded in this editor, and that should be fixed. But I suspect that may not be the only interesting thing going on in Arcangelus's BIQ... and I agree, it may be worth keeping this as an option (although I'm still a little bit unclear on how exactly to reproduce the situation).

 

[Civinator]

Quintillus, thank you very much for your deep explanation. Now I understand much better, what you are meaning by PRTO-units.

However, I believe what you are highlighting in terms of Nationality is only visible in the SAV, where the fields available for each UNIT may be expanded. The BIQ has no way to trace the original nationality of a unit - but the SAV may do so.

The scenario editor (currently, at least) is limited by the realm of what the BIQ may specify. To enable SAV fields to be modifiable, I believe the editor would have to not only be able to understand and save all SAV fields (which it does not currently), but would also have to be able to generate a SAV file for every civilization that should be playable for a scenario (versus one BIQ that could be played by all civilizations).

A different capacity for the biq and for save files - yes, this explains a lot about nationality.

When reading your post, I started a test by using the multiplayer tool to open some save files of the same game, that I used for the screenshots some posts above. I set all civs in the save to be playable by the human pIayer and started a search for different unit nationalities in all civs in that game. I didn´t find any other unit with a different nationality compared to the nationality of the civ (so there should be tons of them) - with the exception of the civ, that was played by me for hundreds of turns. I think this really speaks for the concept, that a SAV file holds additional information about units for every civilization played by the human player.

Units with a different nationality, that I created by enslavement for each of those civs, that now were playable by the human player, did show up in the game with the additional listing of their original nationality, as I showed it in the screenshots some posts ago.

Different nationalities for citizens in conquered cities always were shown for each civ, that was played by the AI and than switched with the multiplayer tool to be played by the human player - so it seems, this is always registered in the save file format - even for AI civs.

For buildings, I believe what you have posted is correct.

That text in the Civ 3ConquestEdit was written by Firaxis.

 

[Lord Malbeth]

@Quintillus, I have a quick question for ya. I've been using this editor to tinker with LM terrain that is normally off-limits in the main editor. I can adjust them and place them accordingly in your editor, but if I open up my .biq in the OG Civ3Editor, it'll crash. Do you have any idea what is going on, or if there are certain "best" practices" that I should do to avoid these crashes?

 

[Quintillus]

@Quintillus, I have a quick question for ya. I've been using this editor to tinker with LM terrain that is normally off-limits in the main editor. I can adjust them and place them accordingly in your editor, but if I open up my .biq in the OG Civ3Editor, it'll crash. Do you have any idea what is going on, or if there are certain "best" practices" that I should do to avoid these crashes?

After some one-by-one testing, it looks like Landmark Marsh is the one that causes the Firaxis editor to crash. I tested volcanoes, tundra, ocean, coast, and jungle, with the Firaxis editor working as intended after adding a little bit of each one, but it crashed after I added some LM Marsh.

So I suppose the "best practice" would be to avoid LM Marsh. I will be doing some further testing to see if Civ3 itself handles LM Marsh all right or not, and if not, will remove that option altogether.

 

[Civinator]

Quintillus, please don´t remove that option from your editor as it is working great and those additional LM terrains can do a great job in future scenarios. In my eyes there is no need to remove this option.

1. There is no need to use the Firaxis editor, when your much better editor is available.
2. If a Firaxis editor should be used to edit a biq set before with your editor, the modder should use the Firaxis editor 1.00 and not that bugged editor 1.03.

I made a quick test with an experimental biq I had created with your editor and a combination of the next version of CCM2.50 and the Giant Earth map. In that biq all additional LM terrains were enabled with your editor. I used an easy to identify marsh terrain tile and set it with your editor without any problems to a LM Marsh terrain and saved that test biq.

Than I opened that test biq with the Firaxis editor 1.00 without any problems. The LM Marsh terrain was shown in the Firaxis editor and the biq was closed in the Firaxis editor without any crash. Here is a screenshot of the test biq opened with editor 1.00.

I started a game with that test biq without any crash and the LM Marsh terrain was shown in the game, too.

Quintillus, may be that error is in the buggy Firaxis editor 1.03 and not in your great editor.

 

[Lord Malbeth]

After some one-by-one testing, it looks like Landmark Marsh is the one that causes the Firaxis editor to crash. I tested volcanoes, tundra, ocean, coast, and jungle, with the Firaxis editor working as intended after adding a little bit of each one, but it crashed after I added some LM Marsh.

So I suppose the "best practice" would be to avoid LM Marsh. I will be doing some further testing to see if Civ3 itself handles LM Marsh all right or not, and if not, will remove that option altogether.

I did a test, too, and for me the LM marsh worked fine. It was the LM flood plain that was causing issues. It's not a huge deal; I just took the LM flood plain out of my mod. Thanks for the quick reply, though!

 

[Quintillus]

Interesting, I am not well-versed in the differences between versions of the Firaxis Conquests editor. I have also verified that LM Marsh doesn't cause a crash in-game, although on my machine it is using Volcano graphics for some reason (maybe related to not having custom rules enabled?). I've also verified that LM Flood Plains aren't causing the game to crash.

My current philosophy is that if something causes the game to crash, it shouldn't be enabled in the default configuration of the editor (in some cases, the Safety Level concept allows disabling the guardrails for those who want to test the bounds themselves). But if it doesn't cause the game to crash, and only has issues with the Firaxis editor - in this case, specific versions thereof - it should remain, perhaps with a warning that it will cause incompatibilities for those who prefer to use different editors for different tasks.

 

[Lord Malbeth]

Interesting, I am not well-versed in the differences between versions of the Firaxis Conquests editor. I have also verified that LM Marsh doesn't cause a crash in-game, although on my machine it is using Volcano graphics for some reason (maybe related to not having custom rules enabled?). I've also verified that LM Flood Plains aren't causing the game to crash.

My current philosophy is that if something causes the game to crash, it shouldn't be enabled in the default configuration of the editor (in some cases, the Safety Level concept allows disabling the guardrails for those who want to test the bounds themselves). But if it doesn't cause the game to crash, and only has issues with the Firaxis editor - in this case, specific versions thereof - it should remain, perhaps with a warning that it will cause incompatibilities for those who prefer to use different editors for different tasks.

Ah, it ain't a huge issue. I'm just soooo thankful for the increased capabilities of your expanded editor. Mad props, dude!

 

[Lord Malbeth]

Update: Did a little more tinkering, and it looks like modded LM marshes do indeed crash things. Wah wah. Not a huge issue overall, but I was wondering why my game kept blowin' up without a warning message.

 

[Quintillus]

It's been a few months since I had the motivation to work on the editor (or any other programming-related side project) at home. Working remotely saps my energy more than working from the office.

However, I've done a small update to the front page, fixing the Java download links, adding archived versions of external links on sites such as apple.com that may not live forever, and adding improved information on how to run the editor with recent versions of Java. This includes putting advanced details in sub-spoilers, so the common use case is easier to find and follow.

I've also done a bit of research on whether the editor would work on Apple's new processors (the "m1" chips), and the answer is "not yet". Microsoft is helping lead an effort to support Java on the new Macs, which means that some day it likely will be possible to run the editor on them. But for now, if you are a Mac editor user and thinking of picking up one of the new Macs, keep your old machine around too. It may be possible to install Java and thus use the editor using Rosetta 2, but I have not found any reports of anyone having tried to run Java that way yet. If you do try, please report back and state how it went; I don't plan to pick up one of those machines but am curious from a technical standpoint if it will work.

 

[Quintillus]

Version 1.36

Version 1.36 is now available. This update contains a mix of small feature updates and bug fixes.

Feature

- You can now set which tribe owns barbarian camps (138)
- The editor auto-fills the current name of an item when renaming to make edits easier
- The forest/jungle hill/mountain/volcano PCX files are now used to make the map more complete and close to the in-game map. (168)
- The editor now supports BIQs with a custom map that has units on it, and no custom rules. (172)

Bug Fix

- The map no longer errors out when a scenario starts in the Future Era and there are forts or barricades on the map. (165)
- If you add/remove a Wall (or equivalent) building to a city, it now properly appears/disappears on the map right away. (164)
- When you add a barbarian camp, the tribe ownership is properly set to random
- The tile preview in the right-side pane of the map tab is now tall enough for mountains and hills to be displayed.
- An error is no longer thrown when menus are enabled and the zoom is changed
- Fixed UI issues when menus are disabled (169)
- The SAV Actions menu is now only enabled when a SAV has been opened

Miscellaneous

- Significant revamp of the graphics subsystem
- Add benchmark of graphics performance
- Add automated tests to ensure that the editor UI can open various scenarios (notably the custom map with units, but no custom rules) in all future releases.

The numbers in parenthesis can be used to read up on additional details in the issue tracker; as an example, you can view detailed info on item 138 at https://todo.sr.ht/~adj/civ3_cross_platform_editor/138 .

The main thrust of the update is the changes to the graphics system, and many of the bug fixes were discovered or prioritized due to evaluating that code, much of which hadn't seen a fine-toothed comb in 8-10 years.

The next update will likely be in Q1 2021. Ideas for improvements are always welcome, but much like the year 2020, what I will find the time and motivation to work on is unpredictable.

 

[Vuldacon]

Quintillus... Thank You for your Hard Work and Efforts to make the Editor Better and Better!
This Version 1.36 has some Great additional Features. Great Holiday Gift!

You are Very Much Appreciated for all you have done. I wish you Happy Holidays and Good Health.

 

[Kirejara]

Thanks again for your good work, Quintillus!

It is nice to see, that you took my suggestion for renaming units.

But the save game actions are greyed out now. Is this intented or did I something wrong (just dropped the new files into the existing folder)?

 

[Ozymandias]

(You know: the usual )

 

[Quintillus]

Thanks Vuldacon, Kirejara, and Ozymandias!

Thanks again for your good work, Quintillus!

It is nice to see, that you took my suggestion for renaming units.

But the save game actions are greyed out now. Is this intented or did I something wrong (just dropped the new files into the existing folder)?

If you mean the menu that lives to the right of "Options" and to the left of "Help", it is intentional, as its actions only make sense if you have opened a SAV (versus a BIQ). Once a SAV is opened, it will be enabled. Kind of like how the Map menu starts out disabled, and some of its actions remain disabled if you open a BIQ that doesn't have a custom map.

Opening SAVs is still in early stages; uncompressed saves (often autosaves) of relatively "vanilla" games are the most likely to be openable.

 

[Kirejara]

If you mean the menu that lives to the right of "Options" and to the left of "Help", it is intentional, as its actions only make sense if you have opened a SAV (versus a BIQ). Once a SAV is opened, it will be enabled.

I am confused now.

In the former version one opened the savegame with this menu "SAV actions".
This is currently the most used feature of your editor to adjust the rules to the current technological progress in game.

If I try to open a savegame in the new 1.36 under the menu "File" nothing happens and the "SAV actions" are still greyed out.

Did I miss something (I am still not a native english speaker )

Thanks!

 

[Quintillus]

I am confused now.

In the former version one opened the savegame with this menu "SAV actions".
This is currently the most used feature of your editor to adjust the rules to the current technological progress in game.

If I try to open a savegame in the new 1.36 under the menu "File" nothing happens and the "SAV actions" are still greyed out.

Did I miss something (I am still not a native english speaker )

Thanks!

A picture is worth a thousand words. I see what you mean now. Nope, you didn't miss anything... I forgot that one of the SAV actions could be used without opening a SAV. Looks like it's time for a small 1.37...

I'm also happy to hear that you're making good use of that feature. It can be tough to predict which features sound cool versus which ones will be used a lot in practice, so it's good for me to know when a feature is getting use.