MongooseMod SDK Stuff

MongooseSDK 1.8

Based on Warlords 2.0.8, with BetterAI 2/12 fully integrated

http://forums.civfanatics.com/downloads.php?do=file&id=5984


NEW

SurfaceCombatFix (CvUnit.cpp, CvUnitAI.cpp, CvGameCoreUtils.cpp, CvGameCoreUtils.h)

Applies floating point precision to the damage calculation portion of the main combat engine (doesn't affect collateral or air strikes), and the corresponding odds generator. The difference is small and doesn't usually change fight outcomes, but for an example take a 2-vs-1 fight such as a promotionless warrior attacking a wolf: in vanilla the odds are 99.1%, and with this fix they are 98.0% (a more accurate and correct number).

Makes a small code improvement to an internal odds calculator only used by AI players to determine courses of action. The fix involves an integer division not being postponed til all multiplications in the same line are done as SDK code usually does, and may or may not have a very small effect on gameplay (it's hard to test).

Makes one final change that could be considered a mod and not a fix, but I threw it in here anyway since it affects surface combat and is hard, imo, to object to: if two defending units have exactly the same defense strength for a fight (and either both are Great-General'd or neither are), it will now pick the lower-experience one instead of the higher-experience one to take the fight. This has two advantages: since promotions get further apart the higher you go it helps get more promotions faster; and if the defender loses the fight, the player loses a lower-experience unit which is always preferrable.

CastleBypassFix (CvPlayer.cpp)

Allows buildings to still be constructed after they go obsolete if they provide a defense bonus and thus still serve a purpose. This only affects castles currently, and restores their old behavior before they got a bonus trade route that forced a tech expiration. Don't worry, they still do nothing but provide more physical defense if you build them in this manner (ie everything about them that should obsolete still does).

FortifyOnWaterMod (CvUnit.cpp)

Allows ships to fortify. Not particularly realistic but still a good gameplay improvement imo. Currently hardcoded to use 40% of the land fortify strength, so that ocean defense goes from 0% to 10% and coast defense from 10% to 20% as fortify is built up. In the future I may try to block this for ocean that's not inside your own borders.

SplashDamageMod (CvUnit.cpp)

Changes how splash (collateral) damage is handled. Actual damage done is now (global constant * output power * unit strength ratio) and splash limits are now (normal limits * Drill/Morale protection). Before, not counting dampening which I removed seperately, unit strength ratio affected the limit and Drill/Morale protection affected the damage.

RetreatMod (CvUnit.cpp, CvGameTextMgr.cpp)

I didn't feel like adding a new XML tag this time so I added functionality to the vanilla <iWithdrawalProb> one instead. It allows negative values, which have the effect of increasing the retreat chance of units that attack this unit. I currently use this with the Ironclad, which provides some survivability for people who still have wooden warships. It also makes ironclad vs ironclad battles more likely to end in withdrawal as happened historically.

BombardLimitMod (CvInfos.cpp, CvInfos.h, CvGameTextMgr.cpp, CvUnit.cpp)

In my ongoing quest to make bombardment and defense more meaningful I've installed limitations on how far certain units can bombard defenses, which shows up in-game on unit mouseovers. This mod also adds seperate tracking for physical (walls and castles) and cultural defense damage, which fixes some problems and allows the bombard limits to work correctly in all cases. Currently requires the <iBombardLimit> tag to be installed in all UnitInfos.xml entries after the <iBombardRate> tag; I will try to make it an optional tag in the future.

ShrineMod (CvCity.cpp)

Makes gold received from shrines scale with map size. It will now scale from 100% of normal on Duel, down to 50% of normal on Huge (at -10% per map level basically). This constitutes a much-needed nerf imo, as the total number of cities in the world tends to get very high on large maps.

UnitStringMod (CvGameTextMgr.cpp)

Significantly improves both versions of the unit mouseover text (there's one for Pedia/TechTree and one for actual units): things are listed in a more consistent order and text has been shortened to fit on one line in most cases. It is significantly more readable while maintaining the original format.

Also adds new information that had been sorely missing to the player, such as splash damage output power, number of targets, and limit, and air strike damage limit.

NotificationMod (CvPlot.cpp)

Event hook for displaying an in-game turnover message when a player's tile improvements upgrade. This is in addition to the highly useful city growth turnover message, and highly dubious but still fun pirate transport retasking message, that I added, all in Python.


UPDATED

MPCameraFix (CvUnit.cpp)

Removed, was being very glitchy in practice with not resetting the camera to normal after a combat.

FirstStrikeFix (CvUnit.cpp)

Removed, due to being included in the Warlords 2.0.8 official patch, without giving me credit (grr). Yes I know I've been a turkey about this but it's my call how I feel about it. Anyway, RIP my friend.

PirateModExtension (CvGame.cpp, CvTeam.cpp)

Changes the XML Difficulty Setting min-turns-before-barbs-start requirement to be different for land and sea barbs. Specifically, the latter is now defined to be 1.5 times the value of the former. This proved necessary with TheLopez's PirateMod, at least when combined with a higher-than-vanilla barb-ship-density XML setting, as the pirates dropped out of ships proved vastly more numerous and dangerous than standard land barbs and the players (AI's included) needed more time to prepare for it.

New: Preliminary attempt at getting barb ships to spawn in ocean tiles. I thought it might be working based on my current game but unfortunately I just tested it and it's definitely NOT working. This has gotta be possible, darnit... give me a few more days.

Not included but related: Rather than attempt to detect transport unload events I just wrote a Python loop that checks all barb ship transports at the end of each turn and changes their mission back from ASSAULT to ATTACK if they're not carrying anything anymore. Prevents huge numbers of empty Galleys, Kogges, Galleons and Transports from piling up in barb cities and slowing the game down, as well as having more barb ships that attack players. May try to change to the more efficient unload event detection method in the future, and will probably start including my Python in the future too for things like this, but at the moment I'm just trying to get this posted.

CityStringMod (CvGameTextMgr.cpp, CvDLLWidgetData.cpp)

Significantly improves the health and happiness mouseovers in city view: things are listed in a better, more sensible order; positive building health has been seperated into two lines for buildings and wonders (continent+global); positive building happiness has been collapsed into two lines for buildings and wonders (continent+global), with the latter no longer repeating the same text; positive building happiness has had the leading word "Some" removed to avoid running onto a second line; the two "Total Happiness" lines match the format of everything else now; the Charismatic leader effect has been given a more sensible description than "OH YEAH!", with the city.getExtraHappiness() effect seperated out and remaining on "OH YEAH!" in case it ever shows up (I don't think it's used currently but I'm not positive). The XML file with the necessary supporting text tags is included.


FIXES

TransportUpgradeFix (CvUnit.cpp)

Kicks carried units to nearest valid tile if upgrading a transport to a unit with different, incompatible cargo capabilities (if any).

InterceptDomainBlockingFix (CvUnit.cpp)

Allows things like SAM Batteries or AEGIS Cruisers with a greater-than-zero Intercept Range to still intercept things passing through their range but over a different domain type (SAM covering water tiles, AEGIS covering land tiles).

FloodPlainsFix (CvCity.cpp)

If a city is built on a flood plain and later razed, the tile will remain a flood plain rather than becoming a desert.


COMBAT MODS

DamageDampeningRemovalMod (CvUnit.cpp)

Removes the damage dampening effect from Collateral and Air Strike combat. This effect weights the strength ratio of attacker and defender by the average of the two strengths, with the end result being that a tank and warrior are far closer in relative strength than imo they should be for the above combat types.

The dampening remains in place for normal surface combat, as removing it has numerous serious consequences (first strikes become too powerful on high strength units and too weak on lower strength ones; combat odds approach zero and 100 far more quickly with any difference in strength between attacker and defender which is no fun at all; the corresponding damage to gameplay and balance suffered from that; etc).

AirLethalityMod (CvUnit.cpp, CvUnit.h, CvInfos.cpp, CvInfos.h, CyInfoInterface1.cpp, CvGameTextMgr.cpp)

Seperates damage, and thus lethality, from interception probability. In vanilla code the damage done by an intercept is based on the interception chance (actually the square of the chance if I remember correctly), which really sucks. With this mod you can specify the two independently in XML, which allows for things like WW2 fighters, battleships, and flak cannons doing a lot less damage than missile-based units while still having a high enough intercept chance to be useful, and finer tweaking of air combat stats in general. The additional stat is also displayed in the unit mouseover in-game.

The relevant tag is called iInterceptionLethality, just below iInterceptionProbability. Here are some example values and their effects. Note, values below -99 and above 100 are invalid.
-99: Intercepts do a random amount of damage between 1% and 99% of the target's max health, and can be fatal if and only if the target did not start at full health.
-50: Same as above, in range 1% to 50%.
0: Intercepts never do any damage, but still force incoming aircraft to turn back.
50: Intercepts have a 50% chance of being fatal outright; if this does not occur, a random amount of damage between 1% and 99% of the target's max health is dealt instead (which can still prove fatal as above).
100: Intercepts are always fatal.

AirCombatMod (CvUnit.cpp)

Largely untested, highly experimental attempt to implement an air superiority mission that fakes the AI players into using it *intelligently* without requiring modding of the AI itself (something which is still beyond me, though I'm hopeful I can learn enough from BetterAI to pull it off). There is no new mission; rather it changes the way air strike missions work when using air units with interception ability (generally fighters).

SiegeMod (CvCity.cpp, CvCity.h, CvPlayer.cpp, CvPlayerAI.cpp, CvUnit.cpp, CvUnitAI.cpp, CyCity.cpp)

Changes bombardment to do a fixed, absolute amount of damage rather than a % of the city's max defense in damage. City healing of bombardment damage remains percent-based so that it doesn't take forever for 100-125% defense cities to heal back from zero.

Just for reference, in the XML of my full mod (not provided) I have cities set to heal 10% per turn, land siege ranging from 3% (Catapult) to 8% (Mechanized Artillery) bombard strength with two levels of Accuracy promotion (2% each) available to land units only, fighters ranging from 0-4%, bombers ranging from 6-10%, and ships ranging from 2-10%. These constitute *very* heavy nerfs from vanilla stats, but if anything I feel bombardment is *still* too easy and fast. Oh well.


MISC MODS

UpgradeCostTraitMod (CvInfos.cpp, CvInfos.h, CvGameTextMgr.cpp, CvUnit.cpp)

Allows putting a unit upgrade cost modifier in traits like you already can with civics. I currently use this with Financial.

ExperienceNeededCappingMod (CvUnit.cpp)

Stops the experience gap between promotion levels from continuing to grow past a certain point, making further levels unreasonably and impractically expensive. That point is currently and arbitrarily set, by me, to be 145 exp and beyond, where the gap reaches a fixed 25 exp. I had had it set much lower in the past but changed my mind; this way it's still useful once in a while at least, and remains a steady comfort just knowing it's there.

PillageOwnTerritoryMod (CvUnit.cpp)

Allows you to pillage roads and railroads in your own territory. Tile improvements were/are fair game without this mod -- apologies for the slightly misleading title. Serves no real purpose most of the time, but useful for those of us who like to have roads only inside city working radii from a vanity standpoint.

AnimalMod (CvGame.cpp, CvUnitAI.cpp)

Makes animals unlikely to leave their TerrainNative and/or FeatureNative tiles, unless attacking something. In vanilla these XML tags just specify where the animals will spawn, and doesn't attempt to restrict their movement.

Prevents animals from instantly de-spawning everywhere when barbarians start. There will still be no new animals spawning after this point.

Changes the condition for the animal-barb switchover point from "total number of cities in the world times 1.5", to "times 3". XML Difficulty Setting min-turns-before-barbs-start requirements are still enforced as well.

CityTileCommerceMod (CvPlot.cpp)

Makes city tile commerce additive rather than an enforced minimum. This is mainly so that players will not be penalized for building cities on rivers, but also lessens the hit for building on resources that give commerce naturally (without their improvement). Food and hammers are still treated as enforced minimums.

LakeSizeMod (CvArea.cpp)

Makes the definition of a lake scale with map size. With an XML Globals value of 4 which is what I use, lakes will become inland seas when greater than 4 tiles in size on Duel, up through greater than 16 tiles in size on Huge.

StatisticsMod (CvUnit.cpp, CvPlayer.cpp)

Additional event hooks for my version of the StatsMod, not currently available. Will be rewritten when I do my big expansion update to move StatsMod data storage from Python to C++.


INTERFACE MODS

UnitNameMod (CvUnit.cpp)

Removes the base type in parens after renaming a unit. Designed for use with my Python code, which names things "Warrior #1", "Warrior #2", etc.

TextColorMod (CvGameTextMgr.cpp)

Adds seperate XML tags for Team Project, World Project, National Wonder and Great Wonder name colors. The XML file with the colors I'm using is included.

FlyingModExtension (CvGameTextMgr.cpp)

Allows for display of bIsFlying ability on unit mouseover in-game. Made independently and around the same time as Mexico's version, apparently.


OTHER PEOPLE'S WORK

12monkeys TeleportingIntoLakeFix (CvUnit.cpp, CvCity.cpp, CvCity.h, CvPlot.cpp, CvPlot.h)

If a naval unit is forced to "teleport to the nearest valid tile", it doesn't wind up in a lake where it will usually be stuck.

12monkeys UUTrainingValidityFix (CvPlayer.cpp)

Prevents an exploit whereby it's possible to acquire the unique units of Civs other than your own.

RogerBacon CameraZoomFix (CvUnit.cpp)
RogerBacon FlyingMod (CvInfos.cpp, CvInfos.h, CvGameTextMgr.cpp, CvUnit.cpp, CvUnitAI.cpp, CvPlot.cpp, CvPlot.h, CyInfoInterface1.cpp)
Chalid SlowCulturalBordersMod (CvCity.cpp)
TheLopez PiratesMod (CyUnit.cpp, CyUnit.h, CyUnitInterface1.cpp)
TegNavanis UnitStatisticsMod (CvUnit.cpp)
Blake/Iustus BetterAI (too many to list)


TO-DO LIST

* Rewrite barbarian tech-acquisition process so they gain techs at a fixed (and controllable) rate, and possibly in a fixed sequence as well.
* Rewrite the surface combat engine entirely, to roll a single random to determine the outcome of the fight as well as whether a retreat happens or not. Damage suffered on non-dead units afterward will have to be computed seperately using a curve that scales between exponential, linear, and logarhythmic depending on the odds going in (greater than, equal to, or less than 50%) using the existing vanilla odds generator.
* See if it's possible to revert the random functions to their pre-Warlords behavior of actually locking the random seed in multiplayer like they're supposed to. Single player works fine but in MP games you can still reload to change the outcome of a fight, or anything else, as much as you want. I mention this now because until recently I just assumed the random functions were low level and inaccessible to us modders.
* Support for some invisible units (specifically sea mines) triggering combat when their tile is entered by a hostile non-detecting unit. Currently they behave like submarines and are simply pushed aside without fighting, so I have to use visible mines for now and rely on their cheapness to make them worth building.
* Support for giving Caste System the effect I want.
* Support for requiring factories to build battleships (idea from another mod) and related changes. Currently this works but blocks civs with unique factories (ie Germany) from ever building battleships, which is obviously no good.
* Possibly adding a global promotion cost reduction modifier for AI players that would be used by higher difficulty settings. Probably unnecessary but still cool.
* Try to automate the air recon mission so it keeps scouting the same tile each turn until told to stop. May be added for me in the expansion will have to see.
* Things mentioned in the above descriptions that still need doing.
* Learn AI programming.

Wow a lot of changes *thumbsup*

Indeed, this is some serious work you've done here.

NOW what happens is, if you go in on a bomb or strike mission with a fighter, and the enemy's best defending interceptor is an air unit, an air battle (probably) ensues. (The actual chance is max(yourIntercept, theirIntercept), which I did b/c intercept chances universally go up with the technology level of the plane, and it seems logical the one with the better plane, be it attacker or defender, would want to push the air fight to happen rather than try to avoid it.) In an air battle (which can only be some form of fighter on some form of fighter), if the planes are equal then the odds are equal; if not the better plane has a higher-than-50% chance, proportional to the strength difference, of being the winner. The winner then acts like interceptions normally do: there's a chance it damages you and a chance it kills you.

Click to expand...

I'm not entirely clear on how this is different from the vanilla implementation. As far as I can see you just changed the way the game determines whether there's an interception or not but I don't see how it's different from simply modifying the percentages (of that) themselves. Unless of course the old system didn't take the strenght/tech level of planes into effect, is that it?

FloodPlainsFix *snip*

Click to expand...

Hmm that's interesting. I never knew that floodplains were removed on city founding (I thought they were terrain, like plains/desert, not feature, like forests). That's why I've been loosing all those emperor games

Thematically I think it actually makes sense that they are removed. You can't really build a city on a flood plane as there's not enough solid soil. But that's not to say I'm against this change, quite frankly I'm not expert enough on civ to know if this is good or bad (bad being that it might be unbalancing, who knows).
What I'm curious about, does it apply to all features. I.e. would a forest stay if you build a city on it. And if it doesn't, then I think it would be interesting to implement a system where there's an XML tag that controls whether a feature should be removed on founding or not. Something similar to how certain imporvements can be built w/o removing features (I think camp can be built in jungles w/o removing them).

Animal mod *snip*

Click to expand...

This actually gave me an idea. Do animals really need to be barbarians? Maybe in the early game that's fine, but I think it would be interesting to perhaps implement a minor civ that will be peaceful to everyone and have animals belong to it, after the "barbarian" animals disappear. I.e. until that condition where animals stop spawning is met, they're barbarians and hostile. But once it does, new animals still spawn (as long as there's un-owned land) but this ones are peaceful, and just roam the landscape

Anyway, lots of interesting changes. Maybe you should consider joining the CCP team.

Rabbit said:

I'm not entirely clear on how this is different from the vanilla implementation. As far as I can see you just changed the way the game determines whether there's an interception or not but I don't see how it's different from simply modifying the percentages (of that) themselves. Unless of course the old system didn't take the strenght/tech level of planes into effect, is that it?.

Click to expand...

The vanilla system doesn't take the attacker's intercept chance into account for trying to push an air fight to happen.

When an air fight does happen in vanilla, the defender is about 5 times more likely to win than the attacker is. (For jet vs jet, in vanilla the defender wins approximately 70% of the time and the attacker wins exactly 14% of the time.) In MY mod, if there's a biplane defending (50%) and you send a modern fighter in (90%), your fighter uses its intercept to successfully pick a fight 90% of the time (and it will usually win too). This clears out a pesky defender that still had a 50% chance of damaging or killing any non-stealthy bombers you wanted to send in (for example I have a unit called the heavy bomber, uses Snafu's B52, much stronger than the B2 but has no stealth). The changes basically enable an "air superiority pseudo-mission mechanic" that allows you to offensively clear defending fighters if you want, by going in with fighters under the pretense of bombing/striking. This wasn't practical in vanilla unless you had 5 times more planes than your opponent. I would've preferred to create a whole new air mission for it (Civ3 had a seperate air superiority mission), but that would require changing the AI code to actually use it (which I don't know how to do yet). This system, with fighters given Attack_AIs in XML, has a solid chance of fooling the AI into using the new mechanic accidentally but effectively, without changing the AI code.

Finally, the lethality (chance an intercept will be fatal to the aircraft being intercepted), was strictly based on the intercept chance of the intercepting unit in vanilla. It was literally converting a jet fighter's 70% into something like: "roll a random between 0 and (4 * 70) = 280, that's the percent damage, if it's over 100 it's fatal". I've seperated the lethality random bound out so it can be set seperately. This allows you to, for example, set up a battleship to have a very low intercept chance via its big guns (say 5% or 10%), but for it to be highly fatal if it hits. (In vanilla, low intercept chance means low damage dealt.)

At the *moment* it uses a bunch of if-else statements in the C code to map specific intercepts (and thus specific units) to specific lethalities, but it's probably better to make a new XML tag for this (for a couple reasons). I'll do so when I have time.

Rabbit said:

Hmm that's interesting. I never knew that floodplains were removed on city founding (I thought they were terrain, like plains/desert, not feature, like forests). That's why I've been loosing all those emperor games

Click to expand...

They should've been terrain, imo. For a while after Civ4 came out I just assumed they *were* terrain.

Rabbit said:

Thematically I think it actually makes sense that they are removed. You can't really build a city on a flood plane as there's not enough solid soil. But that's not to say I'm against this change, quite frankly I'm not expert enough on civ to know if this is good or bad (bad being that it might be unbalancing, who knows).

Click to expand...

With either the vanilla city tile values (2/1/1) or mine (2/2/1), you're just increasing the food output of a city's center tile by 1 (from 2 to 3). That can't possibly be too unbalancing. You can, all else being equal, just lay the city one tile away anyway and still get the extra food (b/c you're not removing the flood plain); why penalize players for building on rivers?

Rabbit said:

What I'm curious about, does it apply to all features. I.e. would a forest stay if you build a city on it. And if it doesn't, then I think it would be interesting to implement a system where there's an XML tag that controls whether a feature should be removed on founding or not. Something similar to how certain imporvements can be built w/o removing features (I think camp can be built in jungles w/o removing them).

Click to expand...

The vanilla code removes all features when laying a city. I modified it to make an exception for flood plains. So no, forests and everything else are still removed normally. I could see fantasy mods wanting to keep forests for certain civs, but for the normal game it should imo stay as I have it. That's because all the other features really ARE features; flood plains as I said before should really have been terrain. (Only reason to remove a flood plain would be if a mod added a terraforming-type ability to manipulate rivers.)

Rabbit said:

This actually gave me an idea. Do animals really need to be barbarians? Maybe in the early game that's fine, but I think it would be interesting to perhaps implement a minor civ that will be peaceful to everyone and have animals belong to it, after the "barbarian" animals disappear. I.e. until that condition where animals stop spawning is met, they're barbarians and hostile. But once it does, new animals still spawn (as long as there's un-owned land) but this ones are peaceful, and just roam the landscape

Click to expand...

I thought of that, actually. And it could be done. The problem is, unless you define new, stronger types of animals for the later stages, they can easily be farmed for free experience by any Medieval or later type unit. (You always get a minimum of 1 exp for winning a fight.)

Rabbit said:

Anyway, lots of interesting changes. Maybe you should consider joining the CCP team.

Click to expand...

If they ask, I might. The problem is, other than 12monkey's bugfixes and two of Impaler's trait effects (one of which Firaxis is doing anyway for the expansion), there wasn't really anything in the CCP I wanted to use personally. So I've been applying my stuff to vanilla SDK code rather than CCP code, which makes it simpler and easier to update, and probably makes it run slightly faster (though that's speculation, and yeah I know CVS solves the updating issue, I just prefer to avoid CVS when possible). Basically it would mean working on two versions simultaneously, which takes more time which I don't have any of right now heh. So far everything I've done is pretty simple code-wise, and the CCP folks are more than welcome to use anything they want from here.

Thanks for your vote of confidence though.

LunarMongoose said:

The vanilla system doesn't take the attacker's intercept chance into account for trying to push an air fight to happen.

When an air fight does happen in vanilla, the defender is about 5 times more likely to win than the attacker is. (For jet vs jet, in vanilla the defender wins approximately 70% of the time and the attacker wins exactly 14% of the time.) In MY mod, if there's a biplane defending (50%) and you send a modern fighter in (90%), your fighter uses its intercept to successfully pick a fight 90% of the time (and it will usually win too). This clears out a pesky defender that still had a 50% chance of damaging or killing any non-stealthy bombers you wanted to send in (for example I have a unit called the heavy bomber, uses Snafu's B52, much stronger than the B2 but has no stealth). The changes basically enable an "air superiority pseudo-mission mechanic" that allows you to offensively clear defending fighters if you want, by going in with fighters under the pretense of bombing/striking. This wasn't practical in vanilla unless you had 5 times more planes than your opponent. I would've preferred to create a whole new air mission for it (Civ3 had a seperate air superiority mission), but that would require changing the AI code to actually use it (which I don't know how to do yet). This system, with fighters given Attack_AIs in XML, has a solid chance of fooling the AI into using the new mechanic accidentally but effectively, without changing the AI code.

Finally, the lethality (chance an intercept will be fatal to the aircraft being intercepted), was strictly based on the intercept chance of the intercepting unit in vanilla. It was literally converting a jet fighter's 70% into something like: "roll a random between 0 and (4 * 70) = 280, that's the percent damage, if it's over 100 it's fatal". I've seperated the lethality random bound out so it can be set seperately. This allows you to, for example, set up a battleship to have a very low intercept chance via its big guns (say 5% or 10%), but for it to be highly fatal if it hits. (In vanilla, low intercept chance means low damage dealt.)

At the *moment* it uses a bunch of if-else statements in the C code to map specific intercepts (and thus specific units) to specific lethalities, but it's probably better to make a new XML tag for this (for a couple reasons). I'll do so when I have time.

Click to expand...

Ah I see now. In that case this is a great change and yeah, it'd be even better to have that XML tag for intercept critical chance.

LunarMongoose said:

I thought of that, actually. And it could be done. The problem is, unless you define new, stronger types of animals for the later stages, they can easily be farmed for free experience by any Medieval or later type unit. (You always get a minimum of 1 exp for winning a fight.)

Click to expand...

Well, if they're peaceful you can't attack them, and since they're not represented as a full blown civ you also can't declare war on them. And besides, this is not an MMO, there are no XP whores here

Anyway, good stuff. Hopefully you get the full mod out the door soon.

Edit: Oh no! I totally went over 1000 posts and didn't even notice. Damn it, i was gonna treat mysefl to a cookie but now it's too late.

LunarMongoose said:

Mongoose LakeSizeMod (CvArea.cpp)

This one's really simple, it changes the maximum number of tiles a lake can be before it turns into an "inland sea" from 9 to 15. Personal preference here given that I almost always play Huge maps.

Click to expand...

You don't need an SDK mod for this. It's stored in GlobalDefines.xml (modify it in GlobalDefinesAlt, of course) as LAKE_MAX_AREA_SIZE.

Rabbit said:

Ah I see now. In that case this is a great change and yeah, it'd be even better to have that XML tag for intercept critical chance.

Click to expand...

Don't forget the special "Zeppelin Effect" that lets you fatalize a percentage of otherwise non-fatal intercepts on certain defenders.

It's a combination of the lethality thing, and the air superiority + unlimited intercepts per turn thing (which tries to outright change mechanics)... if the latter doesn't work out I'll still keep the former.

Rabbit said:

Well, if they're peaceful you can't attack them, and since they're not represented as a full blown civ you also can't declare war on them. And besides, this is not an MMO, there are no XP whores here

Click to expand...

How'd you know I was an MMO junkie?

Err, so yeah, by "peaceful" I thought you meant "won't attack you, but you can still attack them". You mean just having them around as decoration then. I suppose that'd be fine, just not sure why you'd want to.

Zurai said:

You don't need an SDK mod for this. It's stored in GlobalDefines.xml (modify it in GlobalDefinesAlt, of course) as LAKE_MAX_AREA_SIZE.

Click to expand...

Wow. You're a genius. Seriously. (Or maybe I'm just an idiot.) You know, I've edited GlobalDefinesAlt.xml (and looked at GlobalDefines.xml) a million times and it never occured to me that's where that stuff was stored. ... Thank you so much, very helpful to know.

But it'll still have to be an SDK mod to make it variable based on map size, which I was planning to do, so, err, yeah.

LunarMongoose said:

But it'll still have to be an SDK mod to make it variable based on map size, which I was planning to do, so, err, yeah.

Click to expand...

That's certainly true, and there's value in it, so code away!

We would be glad to have more Moders in the CCP, our rules on "no change without explicit activation" mean many of these mods would need to be altered if they were going to be included. The upside is ofcorse the Universaly aplicable DLL that can be used with any current Mod to give it new functionality.

I'm glad you liked my new Traits (I think I will also be making my interpritation of Imperialistic (more of a zergish warmonger) as well and maybe someday a Cuning (super espionage)). The next release we will be trying to include a whole bunch of Python work by SimCutie, new Eventmanagers, MainScreen, Ingame Custom Options (changes your mod config files) and Custom Buttons plugin.

You can ofcorse sign up and look around, our private forum is a good place for trouble shooting and debugging a project of your own. I recomend CVS, I personaly had never used it before this project and now sware at it (I mean BY it!! ). If your mods are well recived by the public and we get requests for them to be included I will probably snag them up, Building the mods on a current CCP version will ofcorse make it far more likley to get included as I can just WinMerge it in.

Top post updated. Of interest are all components given a 1.1 version, the air lethality stuff which was made its own component, the new fix, and the new second paragraph under DamageDampeningRemovalMod.

I also updated the lethality component to 1.1a just now. It occured to me the distribution on the damage if non-fatal was still flat with the >100 bound, all-in-one-roll approach, which meant I was taking a more complicated as well as less preferrable (due to rounding errors) solution when a simple one (two seperate rolls) would do. Also improved the bounds-checking code on the XML tag.

Now I'm (finally) going back to working on the regular full mod, damnit.

Good Mod...
We'd like to incude some bug fixes of your mod into our Civ4CCP project. May we?
Especially.....
Mongoose TransportUpgradeFix 1.0
Mongoose MPCameraFix 1.0
Mongoose FirstStrikeFix 1.0
Mongoose InterceptDomainBlockingFix 1.0

LunarMongoose said:

Mongoose FloodPlainsFix 1.0 (CvCity.cpp)
......
I should point out that my code for doing this is clunky, and if anyone knows a way to directly call the int value for FEATURE_FLOOD_PLAINS from within C++, let me know; I tried a couple different things and couldn't get it to work, which forced me to use "NO_FEATURE + 4" (where flood plains is the 4th entry in the XML file with the feature definitions).

Click to expand...

Use (FeatureTypes)GC.getInfoTypeForString("FEATURE_FLOOD_PLAINS") to get ID value of the flood plain feature.


Opinion on InterceptDomainBlockingFix :
How about this?
This checkes <iAirRange> value to the target plot for non-air unit to non-valid domain target plot.

Top post updated again. I'm doing away with the letters in the version numbers (sorry for the confusion). Changes this time around:

-- FloodPlainsFix uses the correct means of referencing the feature type.
-- AnimalMod changed so that if both TerrainNative *and* FeatureNative are true, it no longer double-counts them value-wise (and thus treats them like their own super-native type, which it would never leave once found).
-- TegNavanis' UnitStatistics 1.4 added to the DLL.

SimCutie said:

Good Mod...
We'd like to incude some bug fixes of your mod into our Civ4CCP project. May we?

Click to expand...

Well I did already say you could (in two places even, woot! ), but thanks for asking anyway (nicely even, woot! ). Use whatever you like, I'm glad you're interested. I just don't have time to actively maintain a seperate version of this stuff in your codebase right now (ie, join the team), but for the most part the changes are pretty small and self-contained anyway.

SimCutie said:

Especially.....
Mongoose TransportUpgradeFix 1.0

Click to expand...

Though a bit different, this is redundant with 12monkeys' version which you're already using; are you sure? Just checking.

SimCutie said:

Use (FeatureTypes)GC.getInfoTypeForString("FEATURE_FLOOD_PLAINS") to get ID value of the flood plain feature.

Click to expand...

Thank you for this. It's been changed.

SimCutie said:

Opinion on InterceptDomainBlockingFix :
How about this?
This checkes <iAirRange> value to the target plot for non-air unit to non-valid domain target plot.

Click to expand...

Unnecessary; canAirDefend() was not intended to perform distance-checking or it would've done so originally (and with air units too). It is called in two places: canAirPatrol(), which requires an air unit on the first line so the issue is moot, and bestInterceptor(), which already does the same check -- "plotDistance(plot, pPlot) <= airRange" -- for all units (surface and air) that get to that inner if statement. This is true of vanilla as well, ie I didn't change that part of the function even though it's inside the AirCombatMod comments.

Edit -- It suddenly occurs to me, in thinking about the code, that the game doesn't check for interceptors anywhere along an attacking plane's flightpath, just at its destination. So you could fly right over a SAM Battery on your way to bomb something and it wouldn't do anything. That kinda sucks, but I'm not sure there's an easy way around it. Would have to write a function that finds the shortest distance between you (point A) and the line between points B (attacker origin) and C (attacker destination), and then use that. I suppose a simple pythagorean will do it... hmm. Next time.

Mongoose, just so you know some issues were found with my Diplomacy trait code, Civs were reciving zero votes and the Popup was not taking into account the incressed total vote quantity when reporting what you need to win.

Theses should be resolved now but I am not shure if your code included these most resent fixes.

Impaler[WrG] said:

Mongoose, just so you know some issues were found with my Diplomacy trait code, Civs were reciving zero votes and the Popup was not taking into account the incressed total vote quantity when reporting what you need to win.

Click to expand...

Err... you did that too didn't you. Carp (yes carp, the fish)... by "diplomacy" I meant your trait that gives a passive bonus to relations, not the U.N. vote thing. Edited to clarify. Thanks for the warning though.

Mongoose FirstStrikeFix 1.0 (CvUnit.cpp)

Found a new bug, and squashed it. The vanilla combat code was failing to do "+ 1" in the parens at the end of "FirstStrikes + SorenRand(FirstStrikeChances)", which made it so if a unit had "1 First Strike Chance" it would never get it, "2 First Strike Chances" could give at most one, "4 First Strike Chances" could only result in 0, 1, 2, or 3 additional first strikes... etc. The guaranteed ones, from abilities like "1 First Strike", were unaffected and worked fine. So yeah, GG on pulling a typo with the Soren bounds, Firaxis.

Click to expand...

Please clarify where exactly this is. It will be affecting my mod as well.

Dale

Dale said:

Please clarify where exactly this is. It will be affecting my mod as well.

Click to expand...

Clarify? No offense, but would it really have been that hard to d/l the zip, open the included CvUnit.cpp (which was mentioned to be the relevant file, it's even in your quote of me), and search for the string "FirstStrikeFix" (since I said everything was commented with the same names as in the top post)...

Sigh. Second to last line (edit: of the first big if block) of the following function, which is near the bottom of CvUnit.cpp:
void CvUnit::setCombatUnit(CvUnit* pCombatUnit, bool bAttacking)

Mongoose MPCameraFix 1.0 (CvUnit.cpp)

A very simple change that removes the code that was preventing the camera from jumping to combats as they happen in Simultaneous-Turn MP games (like it does normally in all other types of games). I dunno if Firaxis put this restriction in for a good reason or not, but if they did I can't figure out what it was based on my MP experience.

Click to expand...

I was wondering if this also fixes this issue for hotseat games? I always hate not seeing battles for anyone except the last human player. Don't know if this fix would apply to that at all, but am just wondering.

Nice job all around, some good fixes.

LunarMongoose said:

Clarify? No offense, but would it really have been that hard to d/l the zip, open the included CvUnit.cpp (which was mentioned to be the relevant file, it's even in your quote of me), and search for the string "FirstStrikeFix" (since I said everything was commented with the same names as in the top post)...

Sigh. Second to last line (edit: of the first big if block) of the following function, which is near the bottom of CvUnit.cpp:
void CvUnit::setCombatUnit(CvUnit* pCombatUnit, bool bAttacking)

Click to expand...

Actually, it would've been hard to d/l the zip and take a look. When I wrote that I was at work, and downloading of files is not possible.

LunarMongoose:

I've taken a look at the code, and I'm not sure your working out is correct for the first strike fix. I'd like to know how you worked it out.

The vanilla code:

setCombatFirstStrikes((pCombatUnit->immuneToFirstStrikes()) ? 0 : (firstStrikes() + GC.getGameINLINE().getSorenRandNum(chanceFirstStrikes(), "First Strike")));

Where:
firstStrikes() == the maximum of: 0 OR (Civ4UnitInfos.xml iFirstStrikes + promotion first strikes)
chanceFirstStrikes() == the maximum of: 0 OR (Civ4UnitInfos.xml iChanceFirstStrike + chance of promotion first strikes)

Therefore, I can only conclude that if a unit has a first strike from either the xml or a promotion that firstStrikes() will be greater than 0, and the chanceFirstStrikes() is still dependant on the xml setting.

Also, looking at getSorenRandNum(..) indicates that if a number > 0 is pushed in then the calculation core is number / another number, thus causing a result greater than 0, as steps are taken to ensure that denominator is greater than 0 to avoid a divide by zero error.

So if units are not receiving their first strike I would look at the xml file iChanceFirstStrikes settings for that unit.

Though if I'm wrong please tell me where. I only took a quick brief look at the code.

Dale

Dale said:

Actually, it would've been hard to d/l the zip and take a look. When I wrote that I was at work, and downloading of files is not possible.

Click to expand...

Ah. Pesky work. I keep forgetting restrictions like that can exist, being unemployed and all. Sorry.

Dale said:

Therefore, I can only conclude that if a unit has a first strike from either the xml or a promotion that firstStrikes() will be greater than 0, and the chanceFirstStrikes() is still dependant on the xml setting.

Click to expand...

You can also get first strike chances from promotions, but yes, I was never claiming there was a problem with the collection of the number of each there should be, only in how chances (and not full first strikes) were applied.

Dale said:

So if units are not receiving their first strike I would look at the xml file iChanceFirstStrikes settings for that unit.

Click to expand...

The fix wasn't applied based on a conclusion that first strike chances weren't showing up when they should be. The UI display is correct. The numbers going into the combat engine are correct. It was what at least looked like a bug in the code that does the combat and decides the result of a fight. There would be no way to see if it was wrong other than running a large number of tests and seeing if the results are off a little %-wise (one fs chance is not very powerful).

Dale said:

Also, looking at getSorenRandNum(..) indicates that if a number > 0 is pushed in then the calculation core is number / another number, thus causing a result greater than 0, as steps are taken to ensure that denominator is greater than 0 to avoid a divide by zero error.

Click to expand...

I hadn't actually looked at the code for this function. All the documentation I have read up to this point says getSorenRandNum(x) returns a number in the range (0 to x-1). It is highly reasonable to assume it will continue to do so when passed special values, specifically that Soren(1) can only return zero and Soren(0) can also only return zero. If all this is true, then my fix is correct. I'll take a look at the Soren code itself shortly, but I don't expect to find anything.

Again, please keep in mind, while my issue with the vanilla combat code is in this line:

setCombatFirstStrikes((pCombatUnit->immuneToFirstStrikes()) ? 0 : (firstStrikes() + GC.getGameINLINE().getSorenRandNum(chanceFirstStrikes(), "First Strike")));

It is only the final part of it. Specifically,

GC.getGameINLINE().getSorenRandNum(chanceFirstStrikes(), "First Strike")

Assume zero full first strikes. If you have 5 fs chances, you should have a nonzero chance of actually getting all 5. But Soren(5) can only return (0 to 4). At least that's what all the documentation says.