C:\Program Files (x86)\Steam\steamapps\common\Sid Meier's Civilization IV Beyond the Sword\Beyond the Sword\Mods\AdvCiv-SAS\CvGameCoreDLL\CvCity.cpp
10089,26: "TXT_KEY_AIR_UNIT_SCRAPPED" : "TXT_KEY_AIR_UNIT_MOVED").GetCString()));
C:\Program Files (x86)\Steam\steamapps\common\Sid Meier's Civilization IV Beyond the Sword\Beyond the Sword\Mods\AdvCiv-SAS\CvGameCoreDLL\CvCityAI.cpp
10742,32: // K-Mod. (cf. conditions for scrapping units in AI_doTurnUnitPost)
11286,94: // <!-- custom: note: all values here are linked to their counterpart/equivalent in the canScrap function e.g. to know which is the max (decisions to scrap or not are not directly symetrical to what we do here to produce them (e.g. don't produce naval units at war on land, but don't scrap exist ones though), but may often be or not, in all cases please refer to each function to see the link between them if i may say but anyways etc -->
11286,153: // <!-- custom: note: all values here are linked to their counterpart/equivalent in the canScrap function e.g. to know which is the max (decisions to scrap or not are not directly symetrical to what we do here to produce them (e.g. don't produce naval units at war on land, but don't scrap exist ones though), but may often be or not, in all cases please refer to each function to see the link between them if i may say but anyways etc -->
11286,287: // <!-- custom: note: all values here are linked to their counterpart/equivalent in the canScrap function e.g. to know which is the max (decisions to scrap or not are not directly symetrical to what we do here to produce them (e.g. don't produce naval units at war on land, but don't scrap exist ones though), but may often be or not, in all cases please refer to each function to see the link between them if i may say but anyways etc -->
11289,121: // <!-- custom: add our pre-checks to help improve the naval dementia of overproducing naval units and pangea or/and scrapping them as well possibly, then being invaded and losing top city while having spent needlessly hammers on 20+ mix of galleons/privateers on pangea, fixing the overproducing part of the issue here by setting sanity gates / pre-checks before we push the final order, and so we can control here all order if i'm not mistaken but anyways etc -->
11816,519: ⟪ 318 characters skipped ⟫are better and it would just bankrupt us or increase unit costs / reduce unit costs efficiency (i.e. maintenance gold per turn for the military units i mean but anyways etc)) anyways etc; note: don't scrap existing ones, they'll die fighting or maybe be upgraded eventually or be useful for some other purpose if hopefully not too numerous but anyways etc, but don't produce anymore if beyond this new cap after the very early game if i am not mistaken in my thinking (i think i am not as this is a good idea i think (but check if accurate or is but anyways etc) but anyways etc) -->
11853,283: // <!-- custom: let's limit certain types of naval units by map type (less on land heavy ones like pangea, more in naval heavy ones like archipelago, anyways etc), to help the known issue as of now 53 of having an AI player have 20+ galleons/privateers, yet producing them +/- scrapping them (dementia/insane like behvaiour if may say but anyways etc.., but not its fault, it just wasn't told better, so hopefully we can help AI have saner unit limits, and we'll ahndle the seemignly naval units scrapping elsewhere as we did in known issue as of now 52 for many units but anyways etc), so for now a few of the combat naval unit AIs (like max iNumCities per AI player seems very sane on pangea, possibly * 2 for naval heavy maps, no need to overproduce beyond that, nor to scrap before that potentially risking crazy loops but anyways etc, we hopefully maybe also save computation by implementing our check here before code is executed but anyways etc) ; code added with the help / thanks to chatgpt 5 as well, check if accurate (and check mine too i mean but anyways etc) anyways etc -->
11853,502: // <!-- custom: let's limit certain types of naval units by map type (less on land heavy ones like pangea, more in naval heavy ones like archipelago, anyways etc), to help the known issue as of now 53 of having an AI player have 20+ galleons/privateers, yet producing them +/- scrapping them (dementia/insane like behvaiour if may say but anyways etc.., but not its fault, it just wasn't told better, so hopefully we can help AI have saner unit limits, and we'll ahndle the seemignly naval units scrapping elsewhere as we did in known issue as of now 52 for many units but anyways etc), so for now a few of the combat naval unit AIs (like max iNumCities per AI player seems very sane on pangea, possibly * 2 for naval heavy maps, no need to overproduce beyond that, nor to scrap before that potentially risking crazy loops but anyways etc, we hopefully maybe also save computation by implementing our check here before code is executed but anyways etc) ; code added with the help / thanks to chatgpt 5 as well, check if accurate (and check mine too i mean but anyways etc) anyways etc -->
11853,779: // <!-- custom: let's limit certain types of naval units by map type (less on land heavy ones like pangea, more in naval heavy ones like archipelago, anyways etc), to help the known issue as of now 53 of having an AI player have 20+ galleons/privateers, yet producing them +/- scrapping them (dementia/insane like behvaiour if may say but anyways etc.., but not its fault, it just wasn't told better, so hopefully we can help AI have saner unit limits, and we'll ahndle the seemignly naval units scrapping elsewhere as we did in known issue as of now 52 for many units but anyways etc), so for now a few of the combat naval unit AIs (like max iNumCities per AI player seems very sane on pangea, possibly * 2 for naval heavy maps, no need to overproduce beyond that, nor to scrap before that potentially risking crazy loops but anyways etc, we hopefully maybe also save computation by implementing our check here before code is executed but anyways etc) ; code added with the help / thanks to chatgpt 5 as well, check if accurate (and check mine too i mean but anyways etc) anyways etc -->
12288,282: // <!-- custom: let's limit certain types of naval units by map type (less on land heavy ones like pangea, more in naval heavy ones like archipelago, anyways etc), to help the known issue as of now 53 of having an AI player have 20+ galleons/privateers, yet producing them +/- scrapping them (dementia/insane like behvaiour if may say but anyways etc.., but not its fault, it just wasn't told better, so hopefully we can help AI have saner unit limits, and we'll ahndle the seemignly naval units scrapping elsewhere as we did in known issue as of now 52 for many units but anyways etc), so for now a few of the combat naval unit AIs (like max iNumCities per AI player seems very sane on pangea, possibly * 2 for naval heavy maps, no need to overproduce beyond that, nor to scrap before that potentially risking crazy loops but anyways etc, we hopefully maybe also save computation by implementing our check here before code is executed but anyways etc) ; code added with the help / thanks to chatgpt 5 as well, check if accurate (and check mine too i mean but anyways etc) anyways etc -->
12288,501: // <!-- custom: let's limit certain types of naval units by map type (less on land heavy ones like pangea, more in naval heavy ones like archipelago, anyways etc), to help the known issue as of now 53 of having an AI player have 20+ galleons/privateers, yet producing them +/- scrapping them (dementia/insane like behvaiour if may say but anyways etc.., but not its fault, it just wasn't told better, so hopefully we can help AI have saner unit limits, and we'll ahndle the seemignly naval units scrapping elsewhere as we did in known issue as of now 52 for many units but anyways etc), so for now a few of the combat naval unit AIs (like max iNumCities per AI player seems very sane on pangea, possibly * 2 for naval heavy maps, no need to overproduce beyond that, nor to scrap before that potentially risking crazy loops but anyways etc, we hopefully maybe also save computation by implementing our check here before code is executed but anyways etc) ; code added with the help / thanks to chatgpt 5 as well, check if accurate (and check mine too i mean but anyways etc) anyways etc -->
12288,778: // <!-- custom: let's limit certain types of naval units by map type (less on land heavy ones like pangea, more in naval heavy ones like archipelago, anyways etc), to help the known issue as of now 53 of having an AI player have 20+ galleons/privateers, yet producing them +/- scrapping them (dementia/insane like behvaiour if may say but anyways etc.., but not its fault, it just wasn't told better, so hopefully we can help AI have saner unit limits, and we'll ahndle the seemignly naval units scrapping elsewhere as we did in known issue as of now 52 for many units but anyways etc), so for now a few of the combat naval unit AIs (like max iNumCities per AI player seems very sane on pangea, possibly * 2 for naval heavy maps, no need to overproduce beyond that, nor to scrap before that potentially risking crazy loops but anyways etc, we hopefully maybe also save computation by implementing our check here before code is executed but anyways etc) ; code added with the help / thanks to chatgpt 5 as well, check if accurate (and check mine too i mean but anyways etc) anyways etc -->
12303,174: // <!-- custom: note: as of now unhandled unitais here mean free production or let AI decide, the more the better: military land units, air units but anyways etc, see canScrap function for the handling of these produced units anyways etc -->
C:\Program Files (x86)\Steam\steamapps\common\Sid Meier's Civilization IV Beyond the Sword\Beyond the Sword\Mods\AdvCiv-SAS\CvGameCoreDLL\CvPlayer.cpp
6728,43: human players selling them lots of tech scraps.)
C:\Program Files (x86)\Steam\steamapps\common\Sid Meier's Civilization IV Beyond the Sword\Beyond the Sword\Mods\AdvCiv-SAS\CvGameCoreDLL\CvPlayerAI.cpp
521,53: int iCostPerMil = AI_unitCostPerMil(); // used for scrap decisions.
647,50: if (gUnitLogLevel > 2) logBBAI(" %S scraps %S, with %d exp, and %d / %d spending.", getCivilizationDescription(0), pLoopUnit->getName(0).GetCString(), iExp, iCostPerMil, AI_maxUnitCostPerMil(pLoopUnit->area(), 100));
648,22: pLoopUnit->scrap();
650,28: what extra work scrap() wants to do for us? */
20057,22: logBBAI(" %S scraps '%S' %S, at (%d, %d), with value %d, due to financial trouble.", getCivilizationDescription(0), szAITypeString.GetCString(), pDisbandUnit->getName(0).GetCString(), pDisbandUnit->getX(), pDisbandUnit->getY(), unit_values[iDisbandCount].first);
20060,19: pDisbandUnit->scrap();
28976,73: // <!-- custom: update issue is now solved by patching globally the canScrap, and below approach didn't solve anything, so i'll comment it out, enable it if need or want and see for related info known issue as of now 52 anyways etc -->
28977,55: // // B) Patch AI_disbandValue to strongly de-prefer scrapping new combat units & live garrisons
28979,14: // // Don’t scrap fresh combat units (prevents “we built one, ended with fewer”).
28984,14: // // Don’t scrap a unit actively defending one of our city tiles.
C:\Program Files (x86)\Steam\steamapps\common\Sid Meier's Civilization IV Beyond the Sword\Beyond the Sword\Mods\AdvCiv-SAS\CvGameCoreDLL\CvTeam.cpp
3673,9: u->scrap();
C:\Program Files (x86)\Steam\steamapps\common\Sid Meier's Civilization IV Beyond the Sword\Beyond the Sword\Mods\AdvCiv-SAS\CvGameCoreDLL\CvUnit.cpp
622,20: pCapturedUnit->scrap();*/
2181,10: if (canScrap())
2276,4: scrap();
3246,20: // <!-- custom: we scrap way too many military units in particular, as i have noticed it in the early game (+/- turn 40-50 but anyways etc, could and most likely happens in other circumstances but didn't check check to be sure and if i'm not mistaken anyways etc), so after we produce a unit we end up with 1 less, so this would mean we scrapped 2. Especially crippling early when barbarians are stronger, our military weak, and rivals dangerous as well potentially. Try to reduce scrapping with this tentative code change but anyways etc, while also not overdoing it in case it collapses our economy, here or/and in other places, see known issue as of now 52 for details anyways etc; also code provided by chatgpt 5 thansk to my prompts and code samples i fed it and or such, check if accurate, anyways etc -->
3246,338: // <!-- custom: we scrap way too many military units in particular, as i have noticed it in the early game (+/- turn 40-50 but anyways etc, could and most likely happens in other circumstances but didn't check check to be sure and if i'm not mistaken anyways etc), so after we produce a unit we end up with 1 less, so this would mean we scrapped 2. Especially crippling early when barbarians are stronger, our military weak, and rivals dangerous as well potentially. Try to reduce scrapping with this tentative code change but anyways etc, while also not overdoing it in case it collapses our economy, here or/and in other places, see known issue as of now 52 for details anyways etc; also code provided by chatgpt 5 thansk to my prompts and code samples i fed it and or such, check if accurate, anyways etc -->
3246,482: // <!-- custom: we scrap way too many military units in particular, as i have noticed it in the early game (+/- turn 40-50 but anyways etc, could and most likely happens in other circumstances but didn't check check to be sure and if i'm not mistaken anyways etc), so after we produce a unit we end up with 1 less, so this would mean we scrapped 2. Especially crippling early when barbarians are stronger, our military weak, and rivals dangerous as well potentially. Try to reduce scrapping with this tentative code change but anyways etc, while also not overdoing it in case it collapses our economy, here or/and in other places, see known issue as of now 52 for details anyways etc; also code provided by chatgpt 5 thansk to my prompts and code samples i fed it and or such, check if accurate, anyways etc -->
3247,96: // <!-- custom: the changes in CvPlayerAI::AI_doMilitary did not change the seemingly cyclical scrapping behaviour of new ancient macemen many turns on a row, so as advised by chatgpt 5 (genius idea it got, it may not seem to clean but great way to solve it xd thanks! But anyways etc), implementing our logic here as well, check if accurate anyways etc -->
3248,45: // Why here? Anything that eventually calls scrap() must pass canScrap() first. With this guard, your land combat units won’t be culled every other turn in the early game or under threat, matching the pattern you observed (6→5→6→5).
3248,66: // Why here? Anything that eventually calls scrap() must pass canScrap() first. With this guard, your land combat units won’t be culled every other turn in the early game or under threat, matching the pattern you observed (6→5→6→5).
3249,57: // <!-- custom: update!!! Tremendously fixed!!! No more scrapping and painful losing of these ancient macemen, will reduce handicap now to accomodate these and make sure we don't run abnkrupt at leats early, else i don't care too much or as much, and give AI best chances anyways etc, see known issue as of now 52 for details anyways etc; in short we only aded some more prechecks here as we usually do, in an attempt to help improve AI efficiency or/and correct or help improve significant AI flaws, so hopefully AI is now stronger as such and we have to adjust some things to match these but anyways etc, see known issue mentionned here in these code comments for details but anyways etc, and we otherwise kept function the same anyways etc -->
3250,17: bool CvUnit::canScrap() const
3257,97: // <!-- custom: update: the danger and not before turn 100 and other conditions anyways etc no scrapping gating here worked extremely great and solved the scrapping issue, see known issue as of now 52 for details anyways etc; now doing a less going overboard xd approach if i may say but anyways etc, we can just disable scrapping entirely and not waste computation, or in other cases tune it to be selectively disabled or such anyways etc, commenting-out this old code we added at first for that end since we don't need to check these now so kept as is commented-out in case if need (and note: untested or barely tested once in this case i mean but anyways etc), may remove it if uneeded, anyways etc -->
3257,157: // <!-- custom: update: the danger and not before turn 100 and other conditions anyways etc no scrapping gating here worked extremely great and solved the scrapping issue, see known issue as of now 52 for details anyways etc; now doing a less going overboard xd approach if i may say but anyways etc, we can just disable scrapping entirely and not waste computation, or in other cases tune it to be selectively disabled or such anyways etc, commenting-out this old code we added at first for that end since we don't need to check these now so kept as is commented-out in case if need (and note: untested or barely tested once in this case i mean but anyways etc), may remove it if uneeded, anyways etc -->
3257,323: // <!-- custom: update: the danger and not before turn 100 and other conditions anyways etc no scrapping gating here worked extremely great and solved the scrapping issue, see known issue as of now 52 for details anyways etc; now doing a less going overboard xd approach if i may say but anyways etc, we can just disable scrapping entirely and not waste computation, or in other cases tune it to be selectively disabled or such anyways etc, commenting-out this old code we added at first for that end since we don't need to check these now so kept as is commented-out in case if need (and note: untested or barely tested once in this case i mean but anyways etc), may remove it if uneeded, anyways etc -->
3258,21: // // only allow scrapping if actually over budget or burning gold
3268,324: // <!-- custom: no disband at all regardless, as well, for land military units (found by our preferred/corresponding unitais as as of now below but anyways etc), they are likely to be valuable one way or another at some point, unlike naval units or perhaps scouts or workers to a lesser extent, but what i mean is do not scrap them at all, hopefully fixes low midgame AI output or enhances it (handicap and such will be adjusted to match these changes as well but see for details or/and updated info known issue as of now 52 or other related docs anyways etc)
3297,46: // <!-- custom: as for naval units, do not scrap them at all, we had the workboat infinite loop issue in known issue as of now 23 if i'm not mistaken that we fixed, but then in known issue as of now 53 i noticed a privateer loop and AI dying because of it. Since we now handle properly max naval units among other units being produced, we don't fear overproducing them too much, at least not too hard, but we i.e. i xd but anyways etc fear invisible scrapping. There should almost never be good cases where scrapping is worth, and these should be handled as exceptions rather than the main rule. Just in known issue as of now 52, removing scrapping greatly improves AI military efficiency and performance, and it didn't go bankrupt at all (they can't produce that much units anyway, allowing to reduce handicap so they produce less units so they are less likely to be bankrupt and so they also nicely have a bit of buff and buffer (no pun xd but anyways etc). Really, i feel or it seems to me like scrapping should be handled as an exception not as a "i don't know what to do with this weird unit let's just scrap it xd". "No! Don't scrap it xd, figure out what to do with it, most often the risk of loop or such far outweigh having 1 or 2 extra units anyway i think but anyways etc), if fearing financial trouble or such, please implement it in your code, as for me as of now i consider/assume assume AIs develop well and build these formulas based on iNumCities or such for scaling but anyways etc, the benefits seem to far outweigh the risks/costs but anyways etc, and please read if i may say but anyways etc known isue as of now 53 for details anyways etc ; also, since we are only adding pre checks and not changing the logic otherwise, should be fine but anyways etc -->
3297,453: // <!-- custom: as for naval units, do not scrap them at all, we had the workboat infinite loop issue in known issue as of now 23 if i'm not mistaken that we fixed, but then in known issue as of now 53 i noticed a privateer loop and AI dying because of it. Since we now handle properly max naval units among other units being produced, we don't fear overproducing them too much, at least not too hard, but we i.e. i xd but anyways etc fear invisible scrapping. There should almost never be good cases where scrapping is worth, and these should be handled as exceptions rather than the main rule. Just in known issue as of now 52, removing scrapping greatly improves AI military efficiency and performance, and it didn't go bankrupt at all (they can't produce that much units anyway, allowing to reduce handicap so they produce less units so they are less likely to be bankrupt and so they also nicely have a bit of buff and buffer (no pun xd but anyways etc). Really, i feel or it seems to me like scrapping should be handled as an exception not as a "i don't know what to do with this weird unit let's just scrap it xd". "No! Don't scrap it xd, figure out what to do with it, most often the risk of loop or such far outweigh having 1 or 2 extra units anyway i think but anyways etc), if fearing financial trouble or such, please implement it in your code, as for me as of now i consider/assume assume AIs develop well and build these formulas based on iNumCities or such for scaling but anyways etc, the benefits seem to far outweigh the risks/costs but anyways etc, and please read if i may say but anyways etc known isue as of now 53 for details anyways etc ; also, since we are only adding pre checks and not changing the logic otherwise, should be fine but anyways etc -->
3297,510: // <!-- custom: as for naval units, do not scrap them at all, we had the workboat infinite loop issue in known issue as of now 23 if i'm not mistaken that we fixed, but then in known issue as of now 53 i noticed a privateer loop and AI dying because of it. Since we now handle properly max naval units among other units being produced, we don't fear overproducing them too much, at least not too hard, but we i.e. i xd but anyways etc fear invisible scrapping. There should almost never be good cases where scrapping is worth, and these should be handled as exceptions rather than the main rule. Just in known issue as of now 52, removing scrapping greatly improves AI military efficiency and performance, and it didn't go bankrupt at all (they can't produce that much units anyway, allowing to reduce handicap so they produce less units so they are less likely to be bankrupt and so they also nicely have a bit of buff and buffer (no pun xd but anyways etc). Really, i feel or it seems to me like scrapping should be handled as an exception not as a "i don't know what to do with this weird unit let's just scrap it xd". "No! Don't scrap it xd, figure out what to do with it, most often the risk of loop or such far outweigh having 1 or 2 extra units anyway i think but anyways etc), if fearing financial trouble or such, please implement it in your code, as for me as of now i consider/assume assume AIs develop well and build these formulas based on iNumCities or such for scaling but anyways etc, the benefits seem to far outweigh the risks/costs but anyways etc, and please read if i may say but anyways etc known isue as of now 53 for details anyways etc ; also, since we are only adding pre checks and not changing the logic otherwise, should be fine but anyways etc -->
3297,642: // <!-- custom: as for naval units, do not scrap them at all, we had the workboat infinite loop issue in known issue as of now 23 if i'm not mistaken that we fixed, but then in known issue as of now 53 i noticed a privateer loop and AI dying because of it. Since we now handle properly max naval units among other units being produced, we don't fear overproducing them too much, at least not too hard, but we i.e. i xd but anyways etc fear invisible scrapping. There should almost never be good cases where scrapping is worth, and these should be handled as exceptions rather than the main rule. Just in known issue as of now 52, removing scrapping greatly improves AI military efficiency and performance, and it didn't go bankrupt at all (they can't produce that much units anyway, allowing to reduce handicap so they produce less units so they are less likely to be bankrupt and so they also nicely have a bit of buff and buffer (no pun xd but anyways etc). Really, i feel or it seems to me like scrapping should be handled as an exception not as a "i don't know what to do with this weird unit let's just scrap it xd". "No! Don't scrap it xd, figure out what to do with it, most often the risk of loop or such far outweigh having 1 or 2 extra units anyway i think but anyways etc), if fearing financial trouble or such, please implement it in your code, as for me as of now i consider/assume assume AIs develop well and build these formulas based on iNumCities or such for scaling but anyways etc, the benefits seem to far outweigh the risks/costs but anyways etc, and please read if i may say but anyways etc known isue as of now 53 for details anyways etc ; also, since we are only adding pre checks and not changing the logic otherwise, should be fine but anyways etc -->
3297,1001: // <!-- custom: as for naval units, do not scrap them at all, we had the workboat infinite loop issue in known issue as of now 23 if i'm not mistaken that we fixed, but then in known issue as of now 53 i noticed a privateer loop and AI dying because of it. Since we now handle properly max naval units among other units being produced, we don't fear overproducing them too much, at least not too hard, but we i.e. i xd but anyways etc fear invisible scrapping. There should almost never be good cases where scrapping is worth, and these should be handled as exceptions rather than the main rule. Just in known issue as of now 52, removing scrapping greatly improves AI military efficiency and performance, and it didn't go bankrupt at all (they can't produce that much units anyway, allowing to reduce handicap so they produce less units so they are less likely to be bankrupt and so they also nicely have a bit of buff and buffer (no pun xd but anyways etc). Really, i feel or it seems to me like scrapping should be handled as an exception not as a "i don't know what to do with this weird unit let's just scrap it xd". "No! Don't scrap it xd, figure out what to do with it, most often the risk of loop or such far outweigh having 1 or 2 extra units anyway i think but anyways etc), if fearing financial trouble or such, please implement it in your code, as for me as of now i consider/assume assume AIs develop well and build these formulas based on iNumCities or such for scaling but anyways etc, the benefits seem to far outweigh the risks/costs but anyways etc, and please read if i may say but anyways etc known isue as of now 53 for details anyways etc ; also, since we are only adding pre checks and not changing the logic otherwise, should be fine but anyways etc -->
3297,1111: // <!-- custom: as for naval units, do not scrap them at all, we had the workboat infinite loop issue in known issue as of now 23 if i'm not mistaken that we fixed, but then in known issue as of now 53 i noticed a privateer loop and AI dying because of it. Since we now handle properly max naval units among other units being produced, we don't fear overproducing them too much, at least not too hard, but we i.e. i xd but anyways etc fear invisible scrapping. There should almost never be good cases where scrapping is worth, and these should be handled as exceptions rather than the main rule. Just in known issue as of now 52, removing scrapping greatly improves AI military efficiency and performance, and it didn't go bankrupt at all (they can't produce that much units anyway, allowing to reduce handicap so they produce less units so they are less likely to be bankrupt and so they also nicely have a bit of buff and buffer (no pun xd but anyways etc). Really, i feel or it seems to me like scrapping should be handled as an exception not as a "i don't know what to do with this weird unit let's just scrap it xd". "No! Don't scrap it xd, figure out what to do with it, most often the risk of loop or such far outweigh having 1 or 2 extra units anyway i think but anyways etc), if fearing financial trouble or such, please implement it in your code, as for me as of now i consider/assume assume AIs develop well and build these formulas based on iNumCities or such for scaling but anyways etc, the benefits seem to far outweigh the risks/costs but anyways etc, and please read if i may say but anyways etc known isue as of now 53 for details anyways etc ; also, since we are only adding pre checks and not changing the logic otherwise, should be fine but anyways etc -->
3297,1136: // <!-- custom: as for naval units, do not scrap them at all, we had the workboat infinite loop issue in known issue as of now 23 if i'm not mistaken that we fixed, but then in known issue as of now 53 i noticed a privateer loop and AI dying because of it. Since we now handle properly max naval units among other units being produced, we don't fear overproducing them too much, at least not too hard, but we i.e. i xd but anyways etc fear invisible scrapping. There should almost never be good cases where scrapping is worth, and these should be handled as exceptions rather than the main rule. Just in known issue as of now 52, removing scrapping greatly improves AI military efficiency and performance, and it didn't go bankrupt at all (they can't produce that much units anyway, allowing to reduce handicap so they produce less units so they are less likely to be bankrupt and so they also nicely have a bit of buff and buffer (no pun xd but anyways etc). Really, i feel or it seems to me like scrapping should be handled as an exception not as a "i don't know what to do with this weird unit let's just scrap it xd". "No! Don't scrap it xd, figure out what to do with it, most often the risk of loop or such far outweigh having 1 or 2 extra units anyway i think but anyways etc), if fearing financial trouble or such, please implement it in your code, as for me as of now i consider/assume assume AIs develop well and build these formulas based on iNumCities or such for scaling but anyways etc, the benefits seem to far outweigh the risks/costs but anyways etc, and please read if i may say but anyways etc known isue as of now 53 for details anyways etc ; also, since we are only adding pre checks and not changing the logic otherwise, should be fine but anyways etc -->
3304,102: // <!-- custom: note: all values here if any are linked to their counterpart/equivalent in the canScrap function e.g. to know which is the max (decisions to scrap or not are not directly symetrical to what we do here to produce them (e.g. don't produce naval units at war on land, but don't scrap exist ones though), but may often be or not, in all cases please refer to each function to see the link between them if i may say but anyways etc -->
3304,161: // <!-- custom: note: all values here if any are linked to their counterpart/equivalent in the canScrap function e.g. to know which is the max (decisions to scrap or not are not directly symetrical to what we do here to produce them (e.g. don't produce naval units at war on land, but don't scrap exist ones though), but may often be or not, in all cases please refer to each function to see the link between them if i may say but anyways etc -->
3304,295: // <!-- custom: note: all values here if any are linked to their counterpart/equivalent in the canScrap function e.g. to know which is the max (decisions to scrap or not are not directly symetrical to what we do here to produce them (e.g. don't produce naval units at war on land, but don't scrap exist ones though), but may often be or not, in all cases please refer to each function to see the link between them if i may say but anyways etc -->
3357,142: // <!-- custom: since we now already handle in CvCityAI::AI_chooseUnit when to produce them and how much, no need to worry too much about scrapping enough units. However, as shown in known issue as of now 53 but anyways etc, it seems scrapping still happens for privateers or such, although i am not sure and AI may have just been overproducing and i didn't check too much, still generally scrapping benefits should now far outweigh costs/risks, which include infinite loop of missing a unit we just created and/or such, and as happened in known issue as of now 23 as well with workboats in the past. It seems much simpler to disable scrapping altogether for most if not all, and see what happens and if we go bankrupt or not. By meeting our quotas sooner, we can then move on to other units or buildings or anything much more efficiently/effectively than scrap reproduce again, and 1-2 lone units are not a big problem vs the global risk of scrapping messing up, so disabling it at least for these units but anyways etc; chatgpt 5 also likes this change if i may say at least it said so so the change seems fine to it at least if not more but anyways etc -->
3357,238: // <!-- custom: since we now already handle in CvCityAI::AI_chooseUnit when to produce them and how much, no need to worry too much about scrapping enough units. However, as shown in known issue as of now 53 but anyways etc, it seems scrapping still happens for privateers or such, although i am not sure and AI may have just been overproducing and i didn't check too much, still generally scrapping benefits should now far outweigh costs/risks, which include infinite loop of missing a unit we just created and/or such, and as happened in known issue as of now 23 as well with workboats in the past. It seems much simpler to disable scrapping altogether for most if not all, and see what happens and if we go bankrupt or not. By meeting our quotas sooner, we can then move on to other units or buildings or anything much more efficiently/effectively than scrap reproduce again, and 1-2 lone units are not a big problem vs the global risk of scrapping messing up, so disabling it at least for these units but anyways etc; chatgpt 5 also likes this change if i may say at least it said so so the change seems fine to it at least if not more but anyways etc -->
3357,394: // <!-- custom: since we now already handle in CvCityAI::AI_chooseUnit when to produce them and how much, no need to worry too much about scrapping enough units. However, as shown in known issue as of now 53 but anyways etc, it seems scrapping still happens for privateers or such, although i am not sure and AI may have just been overproducing and i didn't check too much, still generally scrapping benefits should now far outweigh costs/risks, which include infinite loop of missing a unit we just created and/or such, and as happened in known issue as of now 23 as well with workboats in the past. It seems much simpler to disable scrapping altogether for most if not all, and see what happens and if we go bankrupt or not. By meeting our quotas sooner, we can then move on to other units or buildings or anything much more efficiently/effectively than scrap reproduce again, and 1-2 lone units are not a big problem vs the global risk of scrapping messing up, so disabling it at least for these units but anyways etc; chatgpt 5 also likes this change if i may say at least it said so so the change seems fine to it at least if not more but anyways etc -->
3357,638: // <!-- custom: since we now already handle in CvCityAI::AI_chooseUnit when to produce them and how much, no need to worry too much about scrapping enough units. However, as shown in known issue as of now 53 but anyways etc, it seems scrapping still happens for privateers or such, although i am not sure and AI may have just been overproducing and i didn't check too much, still generally scrapping benefits should now far outweigh costs/risks, which include infinite loop of missing a unit we just created and/or such, and as happened in known issue as of now 23 as well with workboats in the past. It seems much simpler to disable scrapping altogether for most if not all, and see what happens and if we go bankrupt or not. By meeting our quotas sooner, we can then move on to other units or buildings or anything much more efficiently/effectively than scrap reproduce again, and 1-2 lone units are not a big problem vs the global risk of scrapping messing up, so disabling it at least for these units but anyways etc; chatgpt 5 also likes this change if i may say at least it said so so the change seems fine to it at least if not more but anyways etc -->
3357,860: // <!-- custom: since we now already handle in CvCityAI::AI_chooseUnit when to produce them and how much, no need to worry too much about scrapping enough units. However, as shown in known issue as of now 53 but anyways etc, it seems scrapping still happens for privateers or such, although i am not sure and AI may have just been overproducing and i didn't check too much, still generally scrapping benefits should now far outweigh costs/risks, which include infinite loop of missing a unit we just created and/or such, and as happened in known issue as of now 23 as well with workboats in the past. It seems much simpler to disable scrapping altogether for most if not all, and see what happens and if we go bankrupt or not. By meeting our quotas sooner, we can then move on to other units or buildings or anything much more efficiently/effectively than scrap reproduce again, and 1-2 lone units are not a big problem vs the global risk of scrapping messing up, so disabling it at least for these units but anyways etc; chatgpt 5 also likes this change if i may say at least it said so so the change seems fine to it at least if not more but anyways etc -->
3357,946: // <!-- custom: since we now already handle in CvCityAI::AI_chooseUnit when to produce them and how much, no need to worry too much about scrapping enough units. However, as shown in known issue as of now 53 but anyways etc, it seems scrapping still happens for privateers or such, although i am not sure and AI may have just been overproducing and i didn't check too much, still generally scrapping benefits should now far outweigh costs/risks, which include infinite loop of missing a unit we just created and/or such, and as happened in known issue as of now 23 as well with workboats in the past. It seems much simpler to disable scrapping altogether for most if not all, and see what happens and if we go bankrupt or not. By meeting our quotas sooner, we can then move on to other units or buildings or anything much more efficiently/effectively than scrap reproduce again, and 1-2 lone units are not a big problem vs the global risk of scrapping messing up, so disabling it at least for these units but anyways etc; chatgpt 5 also likes this change if i may say at least it said so so the change seems fine to it at least if not more but anyways etc -->
3358,25: // asymmetric: don’t scrap existing boats
3364,296: // <!-- custom: as for settlers, see what happens but don't risk a loop of produce destroy again and again, very costly on city growth. Some code comment mentionned settlers confuse AIs; possibly, but we'd need to test to be sure, there is a risk AI overproduces them in the middle game then scrap and repeat. I didn't see it so far although i didn't see too much, but better not risk, disable scrapping and keep 1 lone extra settler and be done, and see what happens ingame anyways etc if needs adjustment or not (not sure i'd always be here ot make them hehe but i hope the comment helps raise awareness/info about this idea/concern i has if i may say but anyways etc) -->
3364,398: // <!-- custom: as for settlers, see what happens but don't risk a loop of produce destroy again and again, very costly on city growth. Some code comment mentionned settlers confuse AIs; possibly, but we'd need to test to be sure, there is a risk AI overproduces them in the middle game then scrap and repeat. I didn't see it so far although i didn't see too much, but better not risk, disable scrapping and keep 1 lone extra settler and be done, and see what happens ingame anyways etc if needs adjustment or not (not sure i'd always be here ot make them hehe but i hope the comment helps raise awareness/info about this idea/concern i has if i may say but anyways etc) -->
3388,37: // <!-- custom: similarly, avoid scrapping for these, prefer having a few extra than risking infinite loops of produce scrap, or other issues we may not be aware of if i am not in my assessment in this case i mean but anyways etc ; also if we happen to have a few extras for some reason, (hut, unit gifted, etc), do not mind it, assume it is not excessive and don't complexify logic for a few extra units that ultimately won't change hopefully game outcome but anyways etc (note: we may want though to add a preventive patch against gifting abuse if i may say but anyways etc, say if we are above limit, scrap any gifted unit to us, but may be a bit tedious or/and i don't know how, we'd need to scrap the unit received if worse than ours else one of ours if ours are worse etc, ideally would be very nice, but maybe leave it as such if not overboard may be fine and not worth the effort if i may say, although again would be very nice, but hopefully this note/reminder helps if someone other than me (or possibly me but less likely i'd do it again but who knows but i may very well not do it though, may or not not guaranteed, anyways etc) gets the idea from this or something but anyways etc) -->
3388,123: // <!-- custom: similarly, avoid scrapping for these, prefer having a few extra than risking infinite loops of produce scrap, or other issues we may not be aware of if i am not in my assessment in this case i mean but anyways etc ; also if we happen to have a few extras for some reason, (hut, unit gifted, etc), do not mind it, assume it is not excessive and don't complexify logic for a few extra units that ultimately won't change hopefully game outcome but anyways etc (note: we may want though to add a preventive patch against gifting abuse if i may say but anyways etc, say if we are above limit, scrap any gifted unit to us, but may be a bit tedious or/and i don't know how, we'd need to scrap the unit received if worse than ours else one of ours if ours are worse etc, ideally would be very nice, but maybe leave it as such if not overboard may be fine and not worth the effort if i may say, although again would be very nice, but hopefully this note/reminder helps if someone other than me (or possibly me but less likely i'd do it again but who knows but i may very well not do it though, may or not not guaranteed, anyways etc) gets the idea from this or something but anyways etc) -->
3388,608: // <!-- custom: similarly, avoid scrapping for these, prefer having a few extra than risking infinite loops of produce scrap, or other issues we may not be aware of if i am not in my assessment in this case i mean but anyways etc ; also if we happen to have a few extras for some reason, (hut, unit gifted, etc), do not mind it, assume it is not excessive and don't complexify logic for a few extra units that ultimately won't change hopefully game outcome but anyways etc (note: we may want though to add a preventive patch against gifting abuse if i may say but anyways etc, say if we are above limit, scrap any gifted unit to us, but may be a bit tedious or/and i don't know how, we'd need to scrap the unit received if worse than ours else one of ours if ours are worse etc, ideally would be very nice, but maybe leave it as such if not overboard may be fine and not worth the effort if i may say, although again would be very nice, but hopefully this note/reminder helps if someone other than me (or possibly me but less likely i'd do it again but who knows but i may very well not do it though, may or not not guaranteed, anyways etc) gets the idea from this or something but anyways etc) -->
3388,700: // <!-- custom: similarly, avoid scrapping for these, prefer having a few extra than risking infinite loops of produce scrap, or other issues we may not be aware of if i am not in my assessment in this case i mean but anyways etc ; also if we happen to have a few extras for some reason, (hut, unit gifted, etc), do not mind it, assume it is not excessive and don't complexify logic for a few extra units that ultimately won't change hopefully game outcome but anyways etc (note: we may want though to add a preventive patch against gifting abuse if i may say but anyways etc, say if we are above limit, scrap any gifted unit to us, but may be a bit tedious or/and i don't know how, we'd need to scrap the unit received if worse than ours else one of ours if ours are worse etc, ideally would be very nice, but maybe leave it as such if not overboard may be fine and not worth the effort if i may say, although again would be very nice, but hopefully this note/reminder helps if someone other than me (or possibly me but less likely i'd do it again but who knows but i may very well not do it though, may or not not guaranteed, anyways etc) gets the idea from this or something but anyways etc) -->
3420,27: // <!-- custom: don't scrap before renaissance anyways etc -->
3439,28: // <!-- custom: don't scrap existing unit just because we won't produce them (e.g. at war with some other conditions as of now but anyways etc), however track our max in all circumstances and scrap excess as game goes on but anyways etc -->
3439,198: // <!-- custom: don't scrap existing unit just because we won't produce them (e.g. at war with some other conditions as of now but anyways etc), however track our max in all circumstances and scrap excess as game goes on but anyways etc -->
3443,53: // <!-- custom: inferior or equal, as we don't scrap if just at max as nicely noted by chatgpt 5 thanks anyways etc (and despite it being superior or equal in the chooseUnit function hehe if i understood it correctly but anyways etc) -->
3448,80: // <!-- custom: else i.e. if we have too much units, go with the code and scrap if all goes as intended later before final order but anyways etc -->
3461,32: // <!-- custom: then do not scrap any unit at all before turn 150 (at normal game speed), the surplus is likely to be useful, if we go to war or get invaded, then numbers would dim at that time anyways etc -->
3481,63: // // <!-- custom: we already return false and never ever scrap land military units so no need to add them here inefficiently and most importantly unneededly if i may say but anyways etc -->
3502,24: // // We *disallow scrapping* during any of these conditions.
3520,26: // <!-- custom: do not scrap anything carrying units, nice idea by chatgpt 5 i didn't even ask this but just some ideas and it found this thanks. Also nice thing is but anyways etc this is compatible i think if i'm not mistaken but anyways etc with mod mods, if some weird weird xd but anyways etc mod makes swordsmen carry cargo, then don't delete the swordsman (it has ants or ant soldiers xd (not in our mod but maybe but anyways etc), so i find this sanity check very nice if it doesn't break anything, may uncover or/and solve unknown issues too maybe hopefully or prevent some maybe who knows so i like this very much if i may say but anyways etc thanks anyways etc -->
3521,12: // Never scrap anything carrying cargo
3529,40: // <!-- custom: sanity check: do not scrap great persons (hopefully doesn't happen but who knows, don't kill the great prophet or general or scientist or such anyways etc) -->
3544,40: // <!-- custom: sanity check, do not scrap ICBM (just in case but anyways etc), hopefully doesn't cause issues and helps (maybe solves unknown ones but in all cases anyways etc) but anyways etc -->
3562,14: void CvUnit::scrap()
3564,10: if (!canScrap())
C:\Program Files (x86)\Steam\steamapps\common\Sid Meier's Civilization IV Beyond the Sword\Beyond the Sword\Mods\AdvCiv-SAS\CvGameCoreDLL\CvUnit.h
106,10: bool canScrap() const; // Exposed to Python
107,7: void scrap();
C:\Program Files (x86)\Steam\steamapps\common\Sid Meier's Civilization IV Beyond the Sword\Beyond the Sword\Mods\AdvCiv-SAS\CvGameCoreDLL\CvUnitAI.cpp
2624,64: //FErrorMsg("advc.test: Just to see how frequently the AI scraps settlers"); // hardly ever
2625,6: scrap(); //may seem wasteful, but settlers confuse the AI.
2934,40: if (plot() != NULL) // May have been scrapped
3256,5: scrap(); // Don't let it stand around indefinitely
3307,52: scaled rLoadProb = 0; // advc.113: Needed for the scrap decision
3349,39: rLoadProb = 0; // advc.113: OK to scrap
3360,34: /* <advc.113> Want to base the scrap decision on the working city. Try retreating
3361,10: before scrapping if there is none. */
3378,30: not at all a reason to scrap. But having way too many
3394,68: // advc.113: Add 1 b/c e.g. 2 have, 1 needed shouldn't lead to scrapping
3402,15: // Never scrap if safe / new / still useful
3407,20: // Also avoid scrapping when we don't exceed need:
3415,10: /* Scrap eventually b/c the worker could be stuck in this area,
3417,14: scaled rScrapProb(iTotalHave, std::max(1, iTotalThresh));
3418,7: rScrapProb -= 1;
3419,7: rScrapProb *= rScrapProb;
3419,21: rScrapProb *= rScrapProb;
3420,15: // Don't scrap if waiting to load
3421,7: rScrapProb *= scaled::max(0, 1 - 3 * rLoadProb);
3422,11: if (rScrapProb > 0) // to save time
3425,8: rScrapProb *= per100(100 - std::min(iFinancialTroubleMargin, 85));
3427,27: if (SyncRandSuccess(rScrapProb))
3429,7: scrap();
6263,6: scrap();
7412,105: // <!-- custom: update: actually, as discussed with chatgpt 5, i think it's really maybe better to not scrap, we waste hammers doing so, but instead telling the AI not to produce these workboats if it judges it has enough but anyways etc -->
7413,265: // <!-- custom: it seems the needed vs existing workboats (sea workers but anyways etc) logic is (seemingly but looks fine although i didn't check but anyways etc) handled fine already in CvCityAI::AI_chooseProduction so no change needed there, don't worry about scrapping, and so just let AIs produce the unit as they want i mean but anyways etc, and then when produced but anyways etc, they would assess if they want one again, don't scrap a yet to be produced unit that tries to be produced again next turn endlessly or almost (few dozen turns oftentimes or such), if i understood enough of this bug correctly anyways etc -->
7413,438: // <!-- custom: it seems the needed vs existing workboats (sea workers but anyways etc) logic is (seemingly but looks fine although i didn't check but anyways etc) handled fine already in CvCityAI::AI_chooseProduction so no change needed there, don't worry about scrapping, and so just let AIs produce the unit as they want i mean but anyways etc, and then when produced but anyways etc, they would assess if they want one again, don't scrap a yet to be produced unit that tries to be produced again next turn endlessly or almost (few dozen turns oftentimes or such), if i understood enough of this bug correctly anyways etc -->
7425,9: // scrap();
7431,8: // scrap();
7515,9: bool bScrap = true;
7524,6: bScrap = false;
7528,8: if (bScrap)
7530,4: scrap();
8139,5: scrap();
8140,46: return; // advc.001: Always return after scrap
8268,38: // (advc.017b: Moved the transform/ scrap block down; try nearby exploration first.)
8310,55: // Moved the obsoletion test; now only required for scrapping
8369,5: scrap();
8395,4: scrap();
9278,26: // upgrade to galleons. Scrap galleys, switch unit AI for stuck Carracks.
9295,7: scrap();
20531,12: scaled rScrapOdds = per100(GC.getDefineINT(CvGlobals::
20533,28: // Be more reluctant to scrap expensive units
20534,5: rScrapOdds *= 50; // production cost baseline
20535,5: rScrapOdds /= kOwner.getProductionNeeded(getUnitType()) /
20537,25: if (SyncRandSuccess(rScrapOdds))
20539,5: scrap();
C:\Program Files (x86)\Steam\steamapps\common\Sid Meier's Civilization IV Beyond the Sword\Beyond the Sword\Mods\AdvCiv-SAS\CvGameCoreDLL\CyUnit.cpp
117,17: bool CyUnit::canScrap()
119,31: return m_pUnit ? m_pUnit->canScrap() : false;
C:\Program Files (x86)\Steam\steamapps\common\Sid Meier's Civilization IV Beyond the Sword\Beyond the Sword\Mods\AdvCiv-SAS\CvGameCoreDLL\CyUnit.h
49,10: bool canScrap();
C:\Program Files (x86)\Steam\steamapps\common\Sid Meier's Civilization IV Beyond the Sword\Beyond the Sword\Mods\AdvCiv-SAS\CvGameCoreDLL\CyUnitInterface1.cpp
38,12: .def("canScrap", &CyUnit::canScrap, "bool ()")
38,32: .def("canScrap", &CyUnit::canScrap, "bool ()")
C:\Program Files (x86)\Steam\steamapps\common\Sid Meier's Civilization IV Beyond the Sword\Beyond the Sword\Mods\AdvCiv-SAS\CvGameCoreDLL\WarUtilityAspect.cpp
4467,16: NB: The AI scraps Settlers eventually if it can't use them;