Sub Bug Fix and other Adventures in EXE Modding Release 10B

Awesome! And I agree to you, that the paradrop itself should not cost movement, for the reason you mentioned - this would mean that you suddenly have a really speedy infantry unit when not used for a paradrop.

Turns out the CD Complete is much bigger:

I think the original installation path was not in the Infogrames folder. I just moved it there at some point in time. (It was the installation folder of the original standalone Civ3 onto which I later installed the C3C expansion.)

 

I know I am late to the party, but Flintlock, what you're doing for Civ3 is starting a new modding renaissance. I salute you, sir. An exciting time to be a Civ3 modder and player. Some notes from me:

Suggestions/wishlist:

1) Is there any way to show grouped units individually (eg. when a few of the same unit type have custom names) upon clicking on the right click menu to expand a dropdown or just indent the list of grouped units?

2) It would be great if rally points would affect units autoproduced by buildings so that it wasn't necessary to manually direct these units every turn. Very useful for scenarios with capture the flag game types.

3) Also, the AI likes to sit on flag units instead of rushing them to the capital to redeem. A fix for that would be outstanding.

4) It's rather annoying that submarines are able to bombard land and city tiles, and their high bombard ratings that they're usually given make them quite effective at this. It would be great if they (or perhaps invisible sea units?) could be limited to bombarding water tiles.


Bugs:

1) It seems the magenta line civilopedia fix is not working for me for some reason.

2) Moving a unit along railroads with limited movement and road networks seem to break the calculation that displays the "Turns to" number when using the Go To movement command. It will say, eg. (2) but the unit will still be able to move upon arriving on the tile.

3) It seems stack bombard only works among units of the same type.

---

Thanks so much for your work!

 

To me seems reasonable for paradrop to cost 1 movement point, maybe with an exception for 1 movement units.
Also speaking of movement points, what is your opinion on attack/retreat thing regarding movement points, maybe enable retreat if one unit has more movement points than another, for example if mod has all foot units set to 2 movement and horse units set to 3 movement, would be nice to still have retreat mechanics working.
In original game fast unit can retreat only against slow unit which is hardcoded to have 1 movement which is a bit restricting for mods.

 

Thanks for the info. It's odd that the CD Complete EXE is so much bigger than the others, I wonder what's in there. Probably nothing useful.

First of all, thanks for the appreciation. I'll add these to the list. About your first suggestion, my goal with the unit grouping feature is to make it something you would never want to deactivate. In other words, my goal is to group units together only when they're completely interchangeable. If you want to pick out units based on their names I could change it so that units are not grouped with others that have different names. That wouldn't be difficult, it doesn't work that way right now since I never use custom unit names so it's not something I've even thought about.

1) I have no idea why it wouldn't work for you, sorry.
2) I'll look into it, thanks for reporting.
3) This is deliberate. I limited stack bombard to one unit type to make it easier to implement. When all bombarding units are of the same type the code doesn't have to account for cases where some of them can't hit the target due to limited range, some have lethal bombard and others don't, etc. I could go back and try to extend it to work across unit types, but there's a deeper problem, that I don't know what the desired behavior is in all the various possible cases. Like, it's better to attack with shorter range units first and non-lethal units first (as long as they can do damage), but if you're given the choice between short range and lethal or long range and non-lethal, there's no universally right choice as to which should attack first.

Patching the code to change how this works would probably be easy, but the hard part is finding where to apply the patch. I haven't yet looked into the unit combat code in any detail, it's not super complicated, but it's not trivial either. If this is something people really want I could make it more of a priority.

 

One more note: When I moved the C3X'd GOG-Complete EXE into my C3C folder, the lag issues completely disappeared. So perhaps it is not a problem with the exe, but rather a DLL shipped with the GOG installer.

I think linking it to invisibility is too restricting - what if someone wants a stealth ship that can do that? Also, subs don't have bombard in vanilla.
But the idea sounds good if done differently: What about a "can only bombard land" and "can only bombard sea" setting for units? That would allow not only making sea-only bombarding subs, but also allow making torpedo bombers that are strong against ships, but cannot use that strong bombard value against land units.

 

I agree with having paradrop movement as an ini/cfg option only after a drop.
Paradrop as is, is a very powerful ability air crossing otherwise impassible terrain surprising the enemy.
While the game is an abstraction of time and space inasmuch as actual movement and territory covered goes, actual paratroop operations do require re-organization after a drop to collect forces, find and unbundle gear/supplies, set up a temporary command post, hasty defense etc which is represented by having NO movement points on the same turn after a drop. And this is not to mention boarding the planes to begin with.

Also, think of it this way, Airborne operations are very risky, airborne is rolling the dice, in that unexpected enemy forces may be in and around the drop zone, unexpected bad weather blowing people off course.

For example, the airborne drop reveals a strong enemy north, so tough luck, however, if desired, the player can minimize risk with the cfg /ini option , with that movement point, you can move threatened unit immediately south after the drop. Or leave default as is, no extra movement point and take it on the chin.

 

I think this is a very good suggestion (if possible to do). At present this problem can only be handled for fixed maps by a combination of the 'deepwater harbour' setting in the Quintillus editor and giving submarines the wheeled flag while coastal terrain is forbidden for wheeled units.

About paratroopers, who can move after been dropped down: So this could be a very nice additional feature, I think in that case the pillage ability must be taken away (what is possible with the editor) as otherwise one (or a small number of paratroopers) dropped on strategic resources and pillaging them at once, can catapult a civ back into the stone age.

 

Restricting units to bombarding only land or sea should be relatively easy. The list has quite a few suggestions like this, by that I mean gameplay changes that would be easy to implement but awkward to use since they'd have to be configured in the mod's single default config file. So I'm working on fixing that first, adding the option to have a config file for each scenario. The way it will work is you'll be able to drop a file "scenario.c3x_config.ini" in any scenario's folder (same place as the Art, Text, etc. folders) and the config will be loaded & applied whenever the scenario is. I really wanted to go even further and allow for a config for each save file, but that's a complicated problem I'll leave for later.

 

The scenario based config sounds interesting. I guess with that, one could potentially implement new attributes e.g. for improvements and wonders without the need to have an editor to support them? Let's say, for example, an improvement with a new attribute "each land tile produces one extra shield", "...one extra food", and so on. I have no idea of course how hard it would be to implement such new attributes, just a thought. Btw, thanks for implementing the Corruption OFF setting to run properly, works like a charm!

 

I would like to add that it would be great to lessen dependence on 'cracked' editors like Quint's editor. I can't get his editor to work and so I can't take advantage of the expanded editor capabilities. So, anything you can keep editable strictly through a config file would be awesome.

 

Hey Flintlock, a longtime lurker here (Well over a decade now, wow) and I just wanted to chime in and say THANK YOU for your work on this! I've had my CD copy of C3C for a long time and was reluctant to move off of it, but bit the bullet and grabbed the Steam version so I could try C3X. I've been playing with it on El Justo's wonderful Age of Imperialism scenario and the stacks of artillery the AI is driving around with is staggering and has greatly increased their ability to take cities. You've really breathed new life into this game and I just wanted to say it is really appreciated.

P.S. - I don't know how I lived without stack bombard.

 

Thanks, I'm glad to hear it.

Yes, one of the advantages to using text config files is it avoids the problem of needing a special modified editor. Though there is one mod feature that requires a special editor, the free improvements from small wonders, which are specified inside the BIQ the same way that free improvements from great wonders are. But to set that you'd need a third party editor like Quintillus'. BTW when I used Quintillus' editor to test that feature I also had trouble getting it work due to some kind of Java compatibility problem so I had to use the Windows XP version.



Meanwhile, I implemented scenario configs like I described. Here's what it looks like:

This enables no-raze and limits railroad movement for the WW2 Pacific scenario. This file is loaded automatically along with the WW2 scenario and its settings are layered on top of the default config, which itself is layered on top of a hardcoded "base" config. I also added a mod info button which shows which config files are loaded. This is useful to verify that everything is working as expected. Here's what it looks like (note the button itself in the upper right):

 

Speaking of corruption settings, have you looked into Communal corruption? I was never sure if it was literally broken, or not as described, or just unbalanced.

 

Third-party, not cracked. The only "cracked" one is this one, from civ.org.pl. As that thread's creator notes, while arguably accurate for that editor that modified the Firaxis one, it has a connotation with piracy (cracking DRM), so I'd prefer not to have the term associated with my editor. It's also not accurate for my editor, as it's completely new code.

On the other hand, I may be able to provide advice on what could be causing it to not work, depending on the symptoms. If you are on Windows, the "Windows XP" version is a good recommendation to try if you are having issues - despite its name, it works on all versions of Windows later than XP as well (at least through 10). It includes Java bundled with the editor, which removes any dependency on the system Java version; in some cases, especially on older Windows installs, those can become borked.

In Conquests, it works. I've played Communist a few times; I even have a non-posted story where I play Communist. The "Off" setting for government corruption is the one that doesn't work; according to Civinator it actually causes very high corruption. (Though you can set corruption to be effectively off via the difficulty settings)

 

The config.ini files for scenarios/mods are very nice !



So for playing per example the WW 2 in the Pacific scenario with the WW 2 in the Pacific config.ini file, it seems that the loading of two config.ini files (default and scenario) is needed. Isn´t it sufficient, to load only the scenario config.ini file in that case ?

 

This is brilliant!

Can I take it for granted that if a Modder (using your patch) were to supply such a config.ini with their modfiles, to ensure that their scenario runs as they intended, this .ini file would be ignored on any machine which is not running your patch (e.g. players who are still running CD-versions of C3C)?

Or conversely, that a Modder who has spent a long time tweaking and balancing their Mod to use the unpatched .exe, could write a C3X_config.ini which would cancel out most/all of your patched-in changes, for those players who are using them?

(I had a discussion recently with @Vuldacon about the extent to which your patch [v.8] changes the gameplay of EFZI Elite, the latest incarnation of a scenario whose geneology stretches back almost 2 decades ago now, to a basic original designed for Vanilla; the previous Conquests-compatible version, EFZI 2 Complete, is already nearing its 10th birthday)

 

In Conquests it works very well. Just like the known formula suggest.

https://forums.civfanatics.com/threads/everything-about-corruption-c3c-edition.76619/

For it to be a good goverment type both courthouses and a sufficiently largy empire are needed.

 

Airdropping being free is great! Paratroopers may have a real purpose. They're supposed to land and then cause mischief right away. In stock game they had to wait a turn while every artillery piece and tank abuses infinite rail to teleport across the continent to hit them.

 

Maybe this is beyond the ability of the mod, but I would like to note that my Civ3 seems insensitive to the actual speed of the computer. There seems to be various delays that are insensitive to things like CPU speed and the use of solid state disks.

 

Only a decade! ( )

(Oz adds his voice to the Chorus )