Idea for change in credit limit.

[neroden]

I've been fighting my way through the merger of the accounting code change from standard.  This is pretty complicated.  I've incidentally cleaned up a bunch of code while I was dealing with this.

The interest code was easy.  But as I've been going through it, I've run into the credit limit code, which is somewhat annoying to convert.

And I remembered that I don't like the way the credit limit currently works.
Currently, your credit limit will shrink to zero in about 8 months from when you first go into debt.

In practice, actual companies often kept debt floating for long periods.  The crucial question was whether the interest could be paid.  (Also, interest rates went up if the company was more indebted.  I think this might be too complicated to implement just yet, but my plans would make it possible to implement it later.)

Accordingly, I'm wondering, first, what you'd think of deleting the "you've been in debt too many months, your credit limit is reduced" code.  It would make my life a lot easier.

I'm also trying to figure out how to make the credit limit code more compatible with the "you go bankrupt when your net wealth is less than zero" code.  They currently interact... poorly.

There should be a "grace period" between exceeding your credit limit (no new purchases) and going bankrupt (game shuts you down).  I think.

Here's my idea:
(1) The "hard credit limit based on interest coverage" is equal to last year's profits before interest, divided by the interest rate.
(2) The "hard credit limit based on assets" is equal to the value of assets.
(3) The "soft credit limit based on interest coverage" is equal to half of the hard credit limit based on interest coverage
(4) The "soft credit limit based on assets" is equal to half of the hard credit limit based on assets.
(5) The "credit limit" (can't buy new stuff) is reached when the negative cash balance exceeds the larger in magnitude of 3 or 4 (you get the better one).
(6) The "bankruptcy limit" (game shuts you down) is reached when the negative cash balance exceeds the larger in magnitude of 1 or 2 (you get the better one).

Allowing negative net worth may seem a little odd, but the problem is that currently buildings and track aren't counted as assets, so being shut down based on having a negative balance sheet  can happen even though you can easily cover the interest and more from profits.  If buildings and track are ever counted as assets, the credit limit based on assets will start to exceed the one based on interest coverage, and this can be changed then.

With this setup it will still be quite possible to hit the bankruptcy limit as interest accumulates, vehicles depreciate, and (most critically) as profits drop -- it will just take some time after hitting the credit limit.  Unless profits drop very fast, in which case heavily indebted companies could get caught out and go bust very quickly.   

[jamespetts]

Thank you for proposing this - this is not a bad idea. I should note that I plan - eventually - to make some more general changes to the way in which debt is handled, separating the current credit limit system (which would become an overdraft) with a new sort of fixed term loan; the idea then would be to have a smaller overdraft limit, but a larger limit for the fixed term loans, as well as smaller (or no) starting capital, forcing players to take fixed term loans at the beginning of the game, which they will then have to repay with interest. Any short-term modifications to the credit limit system should take into account this future proposed change, although I do not see anything in your suggestions that conflicts with this. One thing that I should suggest, however, is to make the soft credit limit proportions (you have specified them as half) customisable in simuconf.tab. These values should be saved/loaded if the Experimental version is greater than or equal to 11 and the Standard version is greater than or equal to 112.3 so as not to break compatibility with saved games from the last RC.

Thank you for all your work on this, incidentally: it is much appreciated.

[neroden]

Thank you for proposing this - this is not a bad idea. I should note that I plan - eventually - to make some more general changes to the way in which debt is handled, separating the current credit limit system (which would become an overdraft) with a new sort of fixed term loan; the idea then would be to have a smaller overdraft limit, but a larger limit for the fixed term loans, as well as smaller (or no) starting capital, forcing players to take fixed term loans at the beginning of the game, which they will then have to repay with interest. Any short-term modifications to the credit limit system should take into account this future proposed change, although I do not see anything in your suggestions that conflicts with this. One thing that I should suggest, however, is to make the soft credit limit proportions (you have specified them as half) customisable in simuconf.tab. These values should be saved/loaded if the Experimental version is greater than or equal to 11 and the Standard version is greater than or equal to 112.3 so as not to break compatibility with saved games from the last RC.

I'm going to set up the subroutines for a soft and hard credit limit.  May I ask you to add the customizability?  This merger is getting extremely hairy as it is.  I haven't even gotten to compile-testing.  When I do (hopefully later today), I will push the code onto my "merge-from-standard" branch.  You can branch from that and help debug if you like...

[jamespetts]

Yes, I can add the customisability.

What I was planning to do was release a new RC with your merge from Standard changes, and set the Bridgewater-Brunel server to run it with the current saved game and pakset to see how the latest code works on a server with a large game before rolling it out as an official release. During that time, I can also make further progress with the pakset. Does this seem sensible to you?

[neroden]

I'm not sure. 

You may want to issue a "last stable" release before merging the accounting changes. 
They change the save file format. 
And I strongly suspect they need a lot of debugging.
And they may lose some accounting history for previous months' interest when loading saved games from earlier versions of experimental (I think this is an acceptable loss, but still).

[jamespetts]

Hmm - I have already made changes to the save file format in the development branch, although I suppose that I could comment out the code. Alternatively, might it be better to leave the accounting changes until after the next major release (11.0)?

[neroden]

ALL RIGHT NOW!
Merge-from-standard branch (938d9e89a3eb539aff9f0004d704a5f9dd95874a) now compiles.

Most of this is the merger of the new accounting code.  This touched so many parts of the code that a number of other cleanups happened while I was there.  There is a new credit limit system.

It compiles, runs, loads, and promptly crashes in simlinemgmt_t:rdwr.

I know what's happening: I broke the process of reading old experimental savegames.  A large chunk of code for that got moved from player_t to finance_t and I haven't figured out which pieces of it I need to reproduce. 

James, perhaps you might be able to figure this out?  I suggest making your own branch from my merge-from-standard code and fixing it there.  You can compare the load/save code to what you have running in experimental right now to see what needs to be done.

Since getting this far took me over 16 hours of coding, I'm going to take a break now.

----

I think whether you should postpone the accounting changes until after the next major release, depends entirely on how soon the next major release is going to come.  Since there are still some quite serious bugs in passenger and freight movement, it might be quite a while -- or you could just push out a buggy release and move on.  :-)

If you're going to postpone the accounting changes until after the next major release, you should probably branch now into two branches, one for the release, and one for future development.

----
I may have further bugs which need to be fixed with the accounting save/load system.  It was like pulling teeth just to get the "live" portions working so I was not too careful with the save/load side of things.
-----
However, it works when starting a new game.  There are definitely some severe bugs in the graphical display in the accounting window; I messed up the alignment badly. 

Again, after 16 hours of coding I'd like to take a break.  Maybe now that I've gotten this far you might be able to debug what's left.

[jamespetts]

I was rather hoping to release fairly soon - the idea was to push out a final RC to test the latest changes and see how it worked with a server, fix any bugs found with that, in the meantime finish off the industry boost (etc.) features for the industry in the pakset, and then release version 11.0 together with the long-awaited Pak128.Britain-Ex 0.9.0, and then work on some minor features, such as maximum heights for certain types of canals and reduced speed through canal locks whilst evaluating which of the planned major features is the highest in priority (the two sets of features currently at the top of the queue are the cost balancing features, which are quite a large set of features of different sizes, and the passenger generation code). Given what you have written above, it makes sense for the present to postpone the accounting code until after the next release.

However, you mention that there are significant bugs remaining: I thought that I had dealt with all of the known significant bugs, most recently the factory station coverage and related issues; if there are bugs remaining, I shall need to know what they are so that I can work on them.

Edit: Actually, one problem with not integrating the accounting code now is this code in einstellungen.cc:

Code Select Expand


if(  file->get_version()>=112003  ) {
            file->rdwr_short( max_factory_spacing );
            file->rdwr_short( max_factory_spacing_percentage );
        }
[/quote]

This needs the new 112003 saved game number to work. We could, I suppose, downgrade the saved game number to 112.2 until the accounting code is merged, except for the network saves (using the existing feature to allow the saved game version to be higher for network games than normal games), for which we could use 112.3.

[neroden]

It's still the station coverage stuff -- very difficult to get working right, and still not working right.

See Junna's topic.  I'll see if I can reproduce the masses of freight headed for "unknown" with the very latest version but I bet I still can.

If you're changing the savefile format anyway, there's a change you should make: there's an unnecessary member variable in vehikel_t (current_revenue) which ought to be converted to a local variable passed by reference between subroutines.  I happened to fix this while I was doing the other fixes.

I think it would be wise to branch into a "release target" branch and a "development" branch; the development branch could benefit substantially from the merge from standard, which is definitely going to take a little while to debug.

---
Alternatively, we could just finish debugging the accounting code merger and go ahead with it.
The two areas I know I screwed up are:
(1) load/save of experimental games
and
(2) the actual accounting window, where I seem to have made a mess :-)

I'm actually fairly sure I got everything else right, and I *think* I cleaned out some accounting bugs (reversed signs, duplicated bookings) while I was doing so.

One point to note.  I found it impossible to retain the "next month's fixed costs for vehicles" entry, for a funny reason: because of the increase in maintenance costs for obsolete vehicles, this has to be computed fresh every month.  I think I can get it back but it can't be done the way it was being done before; it has to be done using the same code paths which give the current month's fixed costs for vehicles.

[jamespetts]

Have you confirmed that the piling up in the station bug is happening with the latest commits? I thought that the fixes in relation to factory station coverage would have fixed that: quite a number of issues were fixed with that set of changes.

I have created a 11.x branch from which to create stable releases and release candidates: the 112.x-private-car-merge branch will remain for the present as a general development branch. Into the 112.x-private-car-merge branch, I have merged your latest changes, which now compile. However, I get an error on loading the demo.sve with Pak128.Britain-Ex, which appears to be the problem to which you referred.

As to the accounting window, I imagine that you have everything in hand, but I noticed that the "credit limit" and "solvency" graphs both had the same dark blue colour, against which it is difficult to read the black text: this needs to be changed, and they need a different colour to each other.