Questions regarding accounting and money

[Zutty]

I ran into a bit of a problem yesterday. My AI's pathfinder uses AIAccounting and AITestMode to estimate how much each section of a path will cost. It then uses this estimate to figure out how much money to borrow in order to build that path. The problem is that this isn;t always spot on and occasionally it will underestimate and run into the red (This isn't the part I'm concerned about). When this happens though the AI goes berserk and all construction grinds to a halt. I tracked down the source of this bug to the fact that AIAccounting::GetCosts() returns zero and raises and error if the AI can't afford to build something.

This seems like a bit of a chicken and egg problem to me. The AI can't build something without knowing how much its going to cost (in order to borrow enough to cover it), but at the same time the AI can't figure out how much something is going to cost if it can't already afford it.

Based on this, I have some questions....

• Since my AI's strategy is to estimate cost first and THEN take out a loan, it needs to know how much something is GOING to cost regardless of whether or not it can afford it at the time. Perhaps this isn't a strategy the devs originally intended, but a human player can see how much something will cost by holding down Shift (or is it Ctrl?!) regardless of his current balance. I think an AI should have the same ability.
  
  I can think of a couple of ways to address this...
  • Change AIAccounting::GetCosts() to always return the real cost regardless of bank balance.
  • Create a new AIAccounting::GetCostEstimate() or something that returns the real cost regardless of bank balance.
  • Leave AIAccounting as it is but have a option in AITestMode that fabricates a temporarily 'infinite' bank balance.
  Should this be a new feature, or am I missing something?
• Any construction command throws a ERR_NOT_ENOUGH_CASH error if it can't afford to build something. This causes a problem though as the AI might be able to afford that later when it increases its loan, but I'm not 100% sure if that means that the construction was still valid or not. Does this error STRICTLY take precedence over case-specific construction errors? For example, if I tried to build a bridge that ends on a water tile with a bank balance in the red, will I get ERR_NOT_ENOUGH_CASH or ERR_BRIDGE_CANNOT_END_IN_WATER?
  
  I suppose this isn't a big deal for road construction, but bridges and tunnels are a different matter. Its doesn't make much sense to me for the AI to have to keep aside a large amount of money (even conservatively it would have to be like £20k ~ £30k) just so that it can test for any bridge or tunnel that it might need.
• Is it safe to convert a Money type to a 32-bit integer so that I can work with it? I know most individual costs will be well under £1m, but what about those crazy tunnels that go across the whole map and cost ~£400bn? If I tried to convert that to an int would it overflow?

Thanks very much

[TrueBrain]

(..)

• Since my AI's strategy is to estimate cost first and THEN take out a loan, it needs to know how much something is GOING to cost regardless of whether or not it can afford it at the time. Perhaps this isn't a strategy the devs originally intended, but a human player can see how much something will cost by holding down Shift (or is it Ctrl?!) regardless of his current balance. I think an AI should have the same ability.
  
  I can think of a couple of ways to address this...
  • Change AIAccounting::GetCosts() to always return the real cost regardless of bank balance.
  • Create a new AIAccounting::GetCostEstimate() or something that returns the real cost regardless of bank balance.
  • Leave AIAccounting as it is but have a option in AITestMode that fabricates a temporarily 'infinite' bank balance.
  Should this be a new feature, or am I missing something?

It is a known problem and on the TODO list.

[*]Any construction command throws a ERR_NOT_ENOUGH_CASH error if it can't afford to build something. This causes a problem though as the AI might be able to afford that later when it increases its loan, but I'm not 100% sure if that means that the construction was still valid or not. Does this error STRICTLY take precedence over case-specific construction errors? For example, if I tried to build a bridge that ends on a water tile with a bank balance in the red, will I get ERR_NOT_ENOUGH_CASH or ERR_BRIDGE_CANNOT_END_IN_WATER?

All other errors are returned first, before NOT_ENOUGH_CASH is triggered. It is one of the last things that is checked for.

I suppose this isn't a big deal for road construction, but bridges and tunnels are a different matter. Its doesn't make much sense to me for the AI to have to keep aside a large amount of money (even conservatively it would have to be like £20k ~ £30k) just so that it can test for any bridge or tunnel that it might need.

For now it is your only way.

[*]Is it safe to convert a Money type to a 32-bit integer so that I can work with it? I know most individual costs will be well under £1m, but what about those crazy tunnels that go across the whole map and cost ~£400bn? If I tried to convert that to an int would it overflow?[/list]

Why would you need to worry about that? That is on the C++ end, and your AI should only worry about Squirrel end. There all conversion is done for you, and is all made sure to stay within limits.

[Zutty]

It is a known problem and on the TODO list.

Ah, great stuff.

All other errors are returned first, before NOT_ENOUGH_CASH is triggered. It is one of the last things that is checked for.

Good to know. I'll wikify that.

For now it is your only way.

Oh well. Assuming the TODO above can be fixed, I'll stick with a place-holder solution for now then.

Why would you need to worry about that? That is on the C++ end, and your AI should only worry about Squirrel end. There all conversion is done for you, and is all made sure to stay within limits.

Not being a C++ person I didn't really know what to expect here. I take it I can treat a Money quantity as would any other int without worrying about overflows etc..

Thanks very much TrueLight