Unofficial Patch for 3.19

That only works for a UP-loader. Those without the latest UP won't be able to open saves from those with it.

And yes, the one about trading with WEs before meeting them also sounds good.

if (uIFlag > 0)
read->pStream(miValueWhatever);
else
read->pStream(miValueWhatever / 100);

or create a new variable that stores the value times 100 and use it if the uIFlag is > 0, and load the other one if it isn't.

I just made that up on the spot, but you get the point. It's feasible.
 
No, maybe I wasn't clear. When someone using the UP saves their game, it will save each city's GPP as a value "times 100" to hold the fraction. Sure, it can write a different uiFlag to signal other DLLs that it did so.

Now someone using a vanilla DLL loads the game . . . and chokes. First, let's assume it can get past the uiFlag being different from what it expects. But it cannot know that the GPP values are times 100. So suddenly every city will have 100 times its actual GPP.

There's no way to make previous DLLs aware of and handle this change. The only way would be to have a "save as non-UP" method, but then mods would need to make this possible and people would need to remember to save games they post that way.
 
No, maybe I wasn't clear. When someone using the UP saves their game, it will save each city's GPP as a value "times 100" to hold the fraction. Sure, it can write a different uiFlag to signal other DLLs that it did so.

Now someone using a vanilla DLL loads the game . . . and chokes. First, let's assume it can get past the uiFlag being different from what it expects. But it cannot know that the GPP values are times 100. So suddenly every city will have 100 times its actual GPP.

There's no way to make previous DLLs aware of and handle this change. The only way would be to have a "save as non-UP" method, but then mods would need to make this possible and people would need to remember to save games they post that way.
Just check the uIFlag for a specific vanilla value, and if it is that value, divide the GPP values by 100.

I guess I'm not understanding why my solution won't work. Can't you use the flag to detect vanilla versions, do one thing, else, do the other?
 
I no longer have any idea what you guys are talking about but if EF says Fractional GPP break savegames at least in one direction, I can only believe.

My last suggestion for the UP today is a modification of one that was posted once by NotSoGood:
Allow Bombardment of Enemy Forts
Both human and AI can only bombard an improvement on an unowned tile if it gives defense bonus or acts like a city AND at least one unit of an enemy team (isAtWar()) is present on that tile.
The AI should give the mission the same value as if the tile was actually owned by the enemy.
 
The uiFlag is a value that is written into the saved game that allows future DLLs to detect saved games written by older DLLs and change how they read the file.

Say version 1 of the DLL writes the treasury of every player as a signed 2-byte value. This allows a maximum of 32767:gold: per player.

Well, clearly this will not suffice. So after some play-testing the designers decide to make a new DLL version 2 that writes a 4-byte value allowing for 2.147 billion :gold: per player.

To allow the version 2 DLL to read version 1 DLL saved games, they change the uiFlag to 2 when writing new saves and put this into the code that reads the treasury:

Code:
int m_iTreatury;  // 4 bytes

...

if (uiFlag < 2) {
    // old saved game detected
    short iTreasury;  // 2 bytes
    read(pStream, &iTreasury);    // read 2 bytes
    m_iTreasury = iTreasury;
}
else {
    read(pStream, &m_iTreasury);  // read 4 bytes
}

Okay, so that takes care of version 2 DLLs reading a version 1 saved game. No problem.

Now, here's the version 1 DLLs read code for this same part:

Code:
short m_iTreatury;  // 2 bytes

...

read(pStream, &m_iTreasury);  // read 2 bytes

D'oh! As you can see, the coders of version 1 did not anticipate that the future game would allow four bytes for the treasury. Now, they could rewrite the version 1 DLL to handle this easily enough, but that of course requires rewriting the version 1 DLL.

Code:
short m_iTreatury;  // 2 bytes

...

if (uiFlag < 2) {
    read(pStream, &iTreasury);  // read 2 bytes
}
else {
    // new saved game detected
    int iTreasury;  // 4 bytes
    read(pStream, &iTreasury);  // read 4 bytes
    m_iTreasury = (short) iTreasury;  // truncation, too bad!
}

If we could force everyone to use a new DLL that we wrote that didn't have the UP changes but did have code to handle reading in the new GPP values, that would be grand. But that's just not feasible, and so we are left with no way for older DLLs to read in UP saved games.
 
The uiFlag is a value that is written into the saved game that allows future DLLs to detect saved games written by older DLLs and change how they read the file.

Say version 1 of the DLL writes the treasury of every player as a signed 2-byte value. This allows a maximum of 32767:gold: per player.

Well, clearly this will not suffice. So after some play-testing the designers decide to make a new DLL version 2 that writes a 4-byte value allowing for 2.147 billion :gold: per player.

To allow the version 2 DLL to read version 1 DLL saved games, they change the uiFlag to 2 when writing new saves and put this into the code that reads the treasury:

Code:
int m_iTreatury;  // 4 bytes

...

if (uiFlag < 2) {
    // old saved game detected
    short iTreasury;  // 2 bytes
    read(pStream, &iTreasury);    // read 2 bytes
    m_iTreasury = iTreasury;
}
else {
    read(pStream, &m_iTreasury);  // read 4 bytes
}

Okay, so that takes care of version 2 DLLs reading a version 1 saved game. No problem.

Now, here's the version 1 DLLs read code for this same part:

Code:
short m_iTreatury;  // 2 bytes

...

read(pStream, &m_iTreasury);  // read 2 bytes

D'oh! As you can see, the coders of version 1 did not anticipate that the future game would allow four bytes for the treasury. Now, they could rewrite the version 1 DLL to handle this easily enough, but that of course requires rewriting the version 1 DLL.

Code:
short m_iTreatury;  // 2 bytes

...

if (uiFlag < 2) {
    read(pStream, &iTreasury);  // read 2 bytes
}
else {
    // new saved game detected
    int iTreasury;  // 4 bytes
    read(pStream, &iTreasury);  // read 4 bytes
    m_iTreasury = (short) iTreasury;  // truncation, too bad!
}

If we could force everyone to use a new DLL that we wrote that didn't have the UP changes but did have code to handle reading in the new GPP values, that would be grand. But that's just not feasible, and so we are left with no way for older DLLs to read in UP saved games.

When are Read/Write called? Just when saving, I presume. Then, just store the value /100. Sure, it truncates, but maybe it only truncates once every 100 turns, or 500 turns. That's a LOT more accurate then every turn.
 
Write() is called for every save--auto and manual. But it doesn't reread what was saved until you actually load a game. So yes we could truncate on save, but if you play short game sessions you'll get slower GP rates. :(
 
Write() is called for every save--auto and manual. But it doesn't reread what was saved until you actually load a game. So yes we could truncate on save, but if you play short game sessions you'll get slower GP rates. :(

Still faster than doing nothing at all though. ;)
 
Still faster than doing nothing at all though. ;)

Sure, but for an Unofficial Patch, I don't like that it's affected by how short your play times are. Keep in mind that the UP is used by a lot of mods, including BUFFY for competitions. Sure, I would leave that part out for BULL, but it just doesn't feel UP-worthy to me.
 
I no longer have any idea what you guys are talking about but if EF says Fractional GPP break savegames at least in one direction, I can only believe.

My last suggestion for the UP today is a modification of one that was posted once by NotSoGood:

NotSoGood's suggestion is not showing up as I quote you, but how would you determine which fort or city is bombarded when you press the bombard button. Does it give you a tile select after pressing bombard?

At the moment, the issue rarely arises because cities are always 3 tiles apart minimum.

That said, I just had the thought, since you can settle cities 2 tiles apart if they are on separate landmasses, how does the game decide which city to bombard if you stick a frigate (for example) in between two such cities, and press bombard? I am guessing it will bombard the upper left most one first because that seems to be the way tile searches are done.
 
I was talking about allowing Air Bombard missions against improvements on unowned tiles, either always or at least when an enemy is gaining a tactical advantage from it (as suggested by NotSoGood); not landbased siege units' city defence reducing bombard action.

edit: Here is the link to NotSoGood's suggestion
 
There are a number of things I've already fixed for a future 1.5 release, but from the last few pages of discussion I have added the following to the list to address for 1.5 for sure:

- Barb passive tech fix (from MongooseSDK)
- Fixing target city valuation (from MongooseSDK)
- Fix trading with worst enemies of civs you haven't met
- Look at issues with air bombing of unowned territory

I'm also going to take a long look at game speed scaling for some diplomacy related things and figure out what makes sense for UP 1.5 versus BBAI, etc.

Thanks everyone for posting your ideas and the discussion.
 
I'm not 100% confident the "Look at issues with air bombing of unowned territory" is a "bugged" behaviour. I read somewhere (I think it was in the thread for a modcomp called Route Air Bombing which allows bombing of roads including in unowned territory) that it's very difficult to make an AI intelligently bomb anything outside of culture borders. The AI could end up wasting valuable fighter turns bombing useless stuff instead of defending cities or bombing more important strategic/tactical targets, if a change there is not done carefully.

I would suggest in the very least having a look at the code for that modcomp.

Link: http://forums.civfanatics.com/showthread.php?t=345900

I haven't actually looked at it myself yet but I intend to.
 
That's why restricting bombing unowned improvements to those that are strategically beneficial to an opponent the active player is at war with would be a really good idea.

I assume you mean tactical benefit. How serious a threat can a fort in neutral territory be to an AI?

I think it's a bit of an overstatement to call it a really good idea. It's going to be very marginal IMO. I'm sure jdog or you wouldn't mess it up if you changed the code but I don't see how much it's going to change things. Maybe I'm being shortsighted.
 
Given the way movement works in CIV, I'd say there's generally very little incentive to bomb roads. Unless it is accomplished on a massive scale, preventing the player from quickly reinforcing a city/area that the AI is targetting, I don't think the AI should be preoccupied with roads (railroads are perhaps slightly more attractive to take out). I don't think we're anywhere near that level of strategic thinking on the AI's part anyways. The *ONLY* situation I can think of that might be of benefit to the AI, is if it can shut down some of the players strategic resources - and keep the pressure up using air forces on those resources. Currently, the AI is able to remove the improvements, but removing roads also will obviously increase the benefit to the AI. This might be possible, and very desirable.
 
No one is talking about bombing roads in UP.
A fort in neural land however can by used as airbase by an enemy, at least human players can, not sure if AIs do that too. A human can also use forts to block chokepoints.. though in that case it doesn't matter if fort or not, the AI will walk around it, or fail if it can't (iirc)
 
No one is talking about bombing roads in UP.
A fort in neural land however can by used as airbase by an enemy, at least human players can, not sure if AIs do that too. A human can also use forts to block choakpoints.. though in that case it doesn't matter if fort or not, the AI will walk around it, or fail if it can't (iirc)

AFAIK forts only provide the city defensive benefit if in friendly or own territory--not neutral. Can it be used as a port and airbase in neutral territory still? I thought not.
 
AFAIK forts provide defence bonus in nomansland too.
Everything there is to know about forts in BtS!
(lots of stuff)

} Forts in enemy territory do not provide any benefit to you, not even the +25% defense bonus. To you, the enemy fort may as well not exist unless the enemy is using it! Equally, forts in your territory cannot be used by your enemies. Obviously, a fort in neutral territory benefits whoever controls it.

(more stuff)
I'm not so sure about the airbase thing anymore though (actually that was probably wrong), as forts in neutral land can't be used as channels either.
 
With the AI not being able detect and attack chokepoints afaik, the issue is probably only relevant to human players who want to destroy a fort on neutral land because an enemy is controlling it.
Leaving the inability to bomb it as it is actually looks like a valid option the more I think about it, since neutral land forts are likely to be of very little value anyway. So much for that.

With this I retract my suggestion for neutral fort air bombing.
 
Top Bottom