The International Simutrans Forum

 

Author Topic: Simutrans Experimental [Original thread]  (Read 51496 times)

0 Members and 1 Guest are viewing this topic.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18502
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Simutrans Experimental
« Reply #70 on: February 17, 2009, 10:38:56 PM »
Comrade,

thank you for trying Simutrans-Experimental, and thank you even more for posting a bug report :-) Feedack is very welcome indeed. Also, welcome to the forum - I notice that that was your first post.

This bug is proving a little difficult to track down, so please bear with me. I have, however, downloaded your save game, and have succeeded in reproducing the bug. The odd thing is that the bug only appears in the release build, not the debug build. That means that, either there is an assertion with a side effect (possible, but I scoured the code recently to try to remove all of those), there is some undefined behaviour being relied on somewhere that is predictable with optimisations turned off but goes wrong when optimisations are turned on, or there is some bug in the optimisation part of the compiler (unlikely but not impossible).

The most likely of those three options is the second. However, I notice that Prissi in an earlier post reported that he had the unloading bug with Isidoro's version of the code (i.e., with just the depot frame). That is a little odd, since I did not think that Isidoro's code had anything to do with freight loading , but it is not impossible that it affects freight loading somewhere. What I am going to do is download Isidoro's version of the executable and see whether I can reproduce the problem there, and report back afterwards.

Thank you again for the bug report :-)

Update: Trying the saved game with Isidoro's patch only would not work because the save game files have been reversioned in the trunk since Isidoro's initial code was written. Also, an odd bug appears with Isidiro's binary patch causing a crash to desktop whenever one uses the info tool on an industry (it might encompass more than this, but this is all that I have tested so far). I am hoping that Isidoro produces a Git-friendly version of his modification at some stage to make re-integration more easy; my view at this stage is to wait until the next version of the replacement patch is brought out, and try to re-integrate it then and see whether there are any further problems. Meanwhile, I'd be grateful if Isidoro and/or Prissi (or anyone else who's tested it and not had it crash to desktop before being able to do anything) can confirm whether the vehicle unloading patch is present in the Isidoro's version of the modified code, or whether it is unique to Simutrans-Experimental.
« Last Edit: February 17, 2009, 11:15:41 PM by jamespetts »

Offline isidoro

  • Devotee
  • *
  • Posts: 1128
Re: Simutrans Experimental
« Reply #71 on: February 18, 2009, 12:24:36 AM »
James, I understood it the opposite way:

I've tested with the executable you linked earlier (http://simutrans-germany.com/~patches/download.php?file=sim-wingdi-replacing-r2260.zip) - the replacement does work with that one. Just to be sure, I started another game with your Experimental executable and the replacement still didn't work as described above. Did you try it for yourself with your executable?

Just remember that the binary is for r2260-like games.  If tried with newer files there can be odd effects.  I'll merge with an updated version if it is decided to go to trunk.  Otherwise, I see no point in spending time on it.

I'm sorry to tell you that I will not install git.  I'm happy with svn and don't feel like learning another one.  But there is a thing I don't understand.  Patching has nothing to do with the versioning software you are using, has it?  Once you have a working copy, apply the patch, solve the failed hunks and that's all.  Nevertheless, if you encounter any problem adapting it to ST-Exp, please ask.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18502
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Simutrans Experimental
« Reply #72 on: February 18, 2009, 08:34:54 AM »
Isidoro,

hmm, perhaps the problem is incompatibility with the merged code, then. Although, with the binary in that link, I get a crash to desktop whenever I use the inspect tool on any factories.

As to merging with an updated version, it will go into the trunk of Simutrans-Experimental unless some currently unforeseen and irresolvable issue prevents it from doing so, so your work on this will not go unused. The patches will only work in conjunction with SVN because there needs to be some software somewhere that knows what the "base" is so that it knows which bits to change with the patch. The tool used for applying patches is Tortoise Merge, which specifically compares with the SVN base as well as the local files before merging. This is necessary so that applying the patch does not overwrite bits of the code that have been changed in comparison to the version against which you wrote the patch. There is no equivalent for Git. The difficulty will be in applying an updated patch, and working out what has changed between that and the previous patch. One thing that might work is if I use the .diff tool to compare the two patch files (the one that I used and your latest one), and then manually update in the code only those parts that have changed.

Offline isidoro

  • Devotee
  • *
  • Posts: 1128
Re: Simutrans Experimental
« Reply #73 on: February 18, 2009, 01:48:18 PM »
When doing that with factories, the saved game is one belonging to r2260, without any patches?

Regarding the second point, when I merge I use the "patch" command, which doesn't even belong to svn.  It is as simple as a lighter.  For each chunk, it looks for context lines and insert/delete the appropriate lines.  If it can't (because the context lines have been modified by another patch), that chunk fails.  Of course that if you want to apply a new version of the patch, you must revert the old one and then apply.

In you case, perhaps the best approach is to get a fresh working copy and apply there for each new version or wait until the last version is there and do all the work then.
 

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18502
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Simutrans Experimental
« Reply #74 on: February 19, 2009, 08:21:40 PM »
Isidoro,

it was not just on saved games that this problem occurred - it happened with new games that had never been loaded from saved files. As to waiting for the last version - any idea when that will be? ;-)

Offline isidoro

  • Devotee
  • *
  • Posts: 1128
Re: Simutrans Experimental
« Reply #75 on: February 20, 2009, 12:30:21 AM »
It may be a defect of the crosscompiler.  I've tried the exe with wine and it gives a huge amount of production in the window information of factories.  The same patch in the Linux version works ok.  Please check with a fresh version from r2260 in trunk, patch applied and compiled in Windows.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18502
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Simutrans Experimental
« Reply #76 on: February 20, 2009, 01:17:34 PM »
Hmm, that really looks like it is an uninitialised variable, actually: if it crashes sometimes, gives an unexpected and very large number other times, and works other times still, then those are all the hallmarks of an uninitialised variable somewhere.

Incidentally, I have tracked down the cargo unloading bug, which is also an uninitialised variable - the problem is that, at a stop, the program would iterate through the list of all the contained cargo, checking whether it is equal to a particular item of cargo. Adding origins involved re-coding the overloaded == operator, but, because origins are not yet saved, when vehicles are reloaded, the origins would be undefined. The behaviour when calling that == operator is therefore unpredictable: sometimes it works, sometimes it produces odd results, and sometimes, I suspect, it crashes (I suspect that this might be what is causing Z9999's crashes).

I have not fixed it yet, but will do for the next version.

Offline Spike

  • *
  • Posts: 1361
  • First Simutrans Developer and Graphics Artist
Re: Simutrans Experimental
« Reply #77 on: February 20, 2009, 01:21:21 PM »
Valgrind can help to find uninitialised variables.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18502
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Simutrans Experimental
« Reply #78 on: February 20, 2009, 10:56:53 PM »
Hajo,

thank you for the tip - although, the difficulty is that Valgrind is only available on Linux, and I develop on Windows...

Offline isidoro

  • Devotee
  • *
  • Posts: 1128
Re: Simutrans Experimental
« Reply #79 on: February 21, 2009, 04:32:55 AM »
I have discovered what happens.  I has nothing to do with my patch.  In simfab.cc:1257:
buf.printf("%s %li %s\n", translator::translate("Durchsatz"), get_current_production(), translator::translate("units/day"));


get_current_production() returns a sint32 and there is a %li in printf.  When crosscompiling with mingw, that produces the strange number and a buffer overflow.  When patches.simutrans-germany.com is up again, I'll upload a version with %i instead of %li for you to check.


Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18502
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Simutrans Experimental
« Reply #80 on: February 21, 2009, 11:43:06 AM »
Isidoro,

thank you - I have modified that line in my copy of the code, too. It is always good to flush the bugs out!

Offline HeinBloed

  • *
  • Posts: 79
  • Languages: DE, EN, FR
Re: Simutrans Experimental
« Reply #81 on: February 21, 2009, 11:48:57 AM »
I take it that buffer overflow bug most likely also caused the bug observed by me that a convoi marked for replacement never enters the depot (even though it's already empty)...? I'm looking forward to the fixed executable. :)

Offline isidoro

  • Devotee
  • *
  • Posts: 1128
Re: Simutrans Experimental
« Reply #82 on: February 21, 2009, 06:11:37 PM »
I've just uploaded version 11.  I don't know if this is really a bug or a bad compiler/library implementation.  Should I file it for trunk?

@tttron:  the bug would only appear with my binary and if you open a factory details window.  I'd appreciate very much if anybody with Visual C++ and Windows could get r2260 from trunk, apply the patch and see if that error happens or not.

If you experience problems with the new version, please post your game and I'll try to see what happens.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18502
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Simutrans Experimental
« Reply #83 on: February 21, 2009, 07:25:32 PM »
Isidoro,

I have just integrated your version 11 into Simutrans-Experimental on my computer (not uploaded yet). I do not get the industry query crash. I do, however, get the bug to which tttron referred - when marked for replacing, vehicles do not enter the depot unless "go to depot" is selected. When that is selected, however, the correct behaviour re: automatically emerging or not, etc., is observed.

Offline isidoro

  • Devotee
  • *
  • Posts: 1128
Re: Simutrans Experimental
« Reply #84 on: February 21, 2009, 09:10:50 PM »
If I understand you well, that's intended.  The button "Mark for replacement" is intended to mark replacements only.  Imagine a very complicated line with several depots.  You want to replace but to manually sent the vehicle to depot whenever it is near the desired depot.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18502
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Simutrans Experimental
« Reply #85 on: February 21, 2009, 09:26:27 PM »
Ahh, unfortunately, I get that behaviour when I select "full replace", not just when I select "mark for replacement". It seems to occur specifically when the convoy has no capacity, actually, rather than specifically rail vehicles: I was testing it with railway locomotives with no carriages. Adding carriages makes them go to the depot properly, although now I get an access violation in koord3d.h, which seems to result from a null pointer to a vehicle being passed in simconvoi.cc at the line:

Code: [Select]
dep->append_vehicle(self, veh, false);

Edit: I have traced the access violation to some of my own code, so do not worry about that; but the bug relating to zero capacity vehicles remains.

Offline isidoro

  • Devotee
  • *
  • Posts: 1128
Re: Simutrans Experimental
« Reply #86 on: February 21, 2009, 10:00:23 PM »
Ok.   The alone locomotive is the good example.  Working on that... Thanks.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18502
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Simutrans Experimental
« Reply #87 on: February 22, 2009, 08:37:38 PM »
Update:

A new version has been uploaded, including bugfixes (see the opening post for details: the main bugs recently identified by users have, as far as I can discern, now all been fixed), and a new feature: improved debt handling. Isidoro's replacing patch is also fully updated to the latest version - thank you, Isidoro.

There are three essential features of the new system: (1) bankruptcy is now optional (and disabled by default); (2) debts accumulate interest (at a customisable rate; 10% per annum by default); and (3) there is a credit limit, beyond which players cannot buy new capital items. Interest is added monthly based on the total debt at month's end. There is not currently a graph showing historical interest payments, as this would require reversioning the save file, but this might well be added in the future. The credit limit is a varying amount, based on the player's assets and profits over the last year. The minimum (and starting) credit limit is 10,000 Simucredits. The credit limit is displayed in the finances window.

Capital expenditure can be made only within the credit limit. For example, if a player has a 100,000c bank balance and a 100,000c credit limit, the player can purchase capital items to the value of up to 200,000c. Beyond that, the player can purchase no further capital items until the cash balance or credit limit increases. Items that are placed in the map view will give an error message telling the player that the credit limit is exceeded if the player tries to purchase them in excess of the limit. Vehicles in the depot will show a new colour when the player cannot afford them: orange. (Red is still shown for vehicles that cannot be bought as part of the current convoy in any case). For the new vehicle replacement system, players can select orange items (as the resale value of the existing vehicles might enable the new ones to be bought, even if there is currently not enough in the bank), but the window will give the "That would exceed your credit limit" error message if the total net cost of the entire replacement cycle is in excess of the credit limit. The one exception to the credit limit is the remove tool: it can be used no matter how great the player's debt. This is to enable players who get into trouble to remove unprofitable parts of their network to get themselves out of the difficult.

The credit limit can optionally be disabled, reverting the game to the original behaviour. The credit limit system is also ignored in freeplay mode (although, strictly, freeplay mode is now redundant because the same effect can be had by altering the debt settings in simuconf.tab.).

There are some new simuconf.tab settings to customise each of the three features. An excerpt from the new simuconf.tab file shows the settings and the explanation for them:

Code: [Select]
# Insolvency and debt settings
#
# These settings allow what happens when the player runs out of money and goes
# into the red to be customised.
#
# "interest_rate_percent" is the annual interest rate (charged monthly) on all
# overdraft debt (i.e., on all negative account balances). It can be between 0
# and 255.
#
# "allow_bankruptsy" determines whether, when the player is deemed to have been
# insolvent for more than a certain period, the player should be declared
# bankrupt and the game over. 0 = no, 1 = yes.
#
# "allow_purchases_when_insolvent" determines whether, if the player's bank
# balance falls below the player's credit limit (shown in the finance window),
# the player will be unable to spend any new money on capital items (excluding
# bulldozing) until the player has come back within the credit limit again.
# 0 = no, 1 = yes.
#
# To revert to the behaviour of Simutrans standard, set interest_rate_percent to
# 0, set allow_bankruptsy to 1, and set allow_purchases_when_insolvent to 1.

interest_rate_percent = 10
allow_bankruptsy = 0
allow_purhcases_when_insolvent = 0

The reasoning behind this patch is that, with the current standard version of Simutrans, the handling of debt is a little too crude: players face the ostensibly extreme sanction of bankruptcy after only three months of debt (or three months of debt over a certain limit, in newer versions), but can easily bypass it by closing the "new map" window and carrying on. Meanwhile, players are free to run up as much debt as they please. That uneasy combination leads to players who have put a great deal of effort into their games but who have ended up insolvent facing a stark choice between, on the one hand, accepting the bankruptcy and losing all of their work, or, on the other hand, just closing the window and continuing; but the latter will often feel very unsatisfying. The idea of the new system is to introduce a softer but more effective disincentivisation for insolvency, by not allowing players to buy new things after they become insolvent. Players can then continue, and try to turn their transportation company around (without immediately losing all of their work), or sink into the mire of inescapable debt if they do very badly, and realise that starting again would be the best option all around. From a psychological and gameplay perspective, my view is that the new system is more satisfying. The interest is also there to introduce an element of cost to maintaining the debt: without it, there would be no point in having a separate credit limit, since the player's effective cash would be the player's actual cash plus the credit limit.

As ever, feedback (including Simutrans-Experimental specific bug reports) is always welcome.

Offline z9999

  • Devotees (Inactive)
  • *
  • Posts: 848
Re: Simutrans Experimental
« Reply #88 on: February 23, 2009, 05:41:34 PM »
... (I suspect that this might be what is causing Z9999's crashes).

I have not fixed it yet, but will do for the next version.

Unfortunately, new version still crashes.
But currently I don't have a time to play simutrans, so it's ok.

Quote
Simutrans-Experimental.exe caused an Access Violation at location 00401be0 in module Simutrans-Experimental.exe Reading from location 000002a8.

Registers:
eax=0013e4e8 ebx=00000000 ecx=00000000 edx=000002a8 esi=00000028 edi=00000057
eip=00401be0 esp=0013e4c4 ebp=0013e4c8 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000206

Call stack:
00401BE0  Simutrans-Experimental.exe:00401BE0
00485621  Simutrans-Experimental.exe:00485621
004A24F5  Simutrans-Experimental.exe:004A24F5
004A408F  Simutrans-Experimental.exe:004A408F
00450AF6  Simutrans-Experimental.exe:00450AF6
00450DF5  Simutrans-Experimental.exe:00450DF5
0047D8BF  Simutrans-Experimental.exe:0047D8BF
00471F00  Simutrans-Experimental.exe:00471F00
00431AB9  Simutrans-Experimental.exe:00431AB9
7C817067  kernel32.dll:7C817067  RegisterWaitForInputIdle

Quote
Simutrans-Experimental.exe caused an Access Violation at location 0040924a in module Simutrans-Experimental.exe Reading from location 000002e4.

Registers:
eax=00000000 ebx=00000000 ecx=00000000 edx=00be6070 esi=0000007a edi=00000dee
eip=0040924a esp=0013e4f4 ebp=0013e4f8 iopl=0         nv up ei pl nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202

Call stack:
0040924A  Simutrans-Experimental.exe:0040924A
004A2361  Simutrans-Experimental.exe:004A2361
004A408F  Simutrans-Experimental.exe:004A408F
00450AF6  Simutrans-Experimental.exe:00450AF6
00450DF5  Simutrans-Experimental.exe:00450DF5
0047D8BF  Simutrans-Experimental.exe:0047D8BF
00471F00  Simutrans-Experimental.exe:00471F00
00431AB9  Simutrans-Experimental.exe:00431AB9
7C817067  kernel32.dll:7C817067  RegisterWaitForInputIdle

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18502
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Simutrans Experimental
« Reply #89 on: February 23, 2009, 11:43:03 PM »
Z9999,

thank you for your bug report - sorry that it's still crashing. May I ask - in what circumstances does it crash? What do you do immediately before it crashes? Is this after you load a saved game, or does it also crash if you start a new game? What pakset are you using? How long after loading/starting a game does it crash? Does anything in particular happen in the game just before the crash that you have noticed?

Hopefully I can track down what is causing the problem - at least the message is clear that the problem is an access violation. Has anyone else had any problems, may I ask?

comrade

  • Guest
Re: Simutrans Experimental
« Reply #90 on: February 24, 2009, 12:47:54 AM »
Hi! Thanks for the new version :)

So far it has worked fine for me, no game-breaking bugs or crashes.

Minor things I noticed:

1. Weight limit for rail tracks still resets to 999 on game load.
2. The speedbonus modification works as it should, but the "list of all goods" still shows the old speedbonus, is that intended?

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18502
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Simutrans Experimental
« Reply #91 on: February 24, 2009, 03:51:38 PM »
Comrade,

thank you very much for your feedback - it is always much appreciated :-) The resetting track weight limit is a known limitation with the current version; changing that would require reversioning the saved game files, which I will get to, but I want to do it all at once so that I do not need to specify a large number of different saved game file versions.

As to no. 2, the table would need to be made somewhat more detailed to deal with the new system, as the speed bonus applies differentially depending on the distance travelled, which would require an overhaul of the GUI. Because I am planning on changing the revenue system entirely to abolish the speed bonus, I do not intend to make that change, because it would quickly be rendered obsolete. Thank you for spotting it, however :-) (The table is still valid in that it shows the correct speed bonus for longer distance travel).

Thank you very much for testing Simutrans-Experimental - do post again if you have any further issues or comments :-)

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18502
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Simutrans Experimental - screenshots
« Reply #92 on: February 25, 2009, 10:40:04 PM »
Below are some screenshots of some of the new Simutrans-Experimental features. Depicted are: (1) weight limits; (2) the new vehicle replacement tool (by Isidoro; with orange bars under the vehicles that cannot be afforded); and (3) message showing the what happens when the user tries to build things in excess of the credit limit.

Offline Fabio

  • Devotee
  • Administrator
  • *
  • Posts: 2898
  • The Pak128 Guy
    • Visit me on Facebook
  • Languages: EN, IT, RO, FR
Re: Simutrans Experimental
« Reply #93 on: February 25, 2009, 10:46:45 PM »
wow, impressive!

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18502
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Simutrans Experimental
« Reply #94 on: February 25, 2009, 11:36:39 PM »
Thank you! Have you tested Simutrans-Experimental yet?

Edit: Of course, much of the credit for that middle screen shot goes to Isidoro...

Offline Fabio

  • Devotee
  • Administrator
  • *
  • Posts: 2898
  • The Pak128 Guy
    • Visit me on Facebook
  • Languages: EN, IT, RO, FR
Re: Simutrans Experimental
« Reply #95 on: February 25, 2009, 11:59:02 PM »
well, actually the only simutrans time i have ATM is for painting and writing dats. I test my paks in game, but only the way they look :(
but i promise that one of my first real simutrans games (in a future) will be with experimental, i really look forward to use it!

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18502
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Simutrans Experimental
« Reply #96 on: February 26, 2009, 12:08:53 AM »
Excellent - and I shall look forward to your feedback!

Offline z9999

  • Devotees (Inactive)
  • *
  • Posts: 848
Re: Simutrans Experimental
« Reply #97 on: February 26, 2009, 03:43:17 AM »
This is more impressive, isn't it ?  ;D

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18502
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Simutrans Experimental
« Reply #98 on: February 26, 2009, 08:36:14 PM »
Z9999,

LOL! I take it, then, that you managed to get it to run without crashing? ;-)

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18502
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Simutrans Experimental
« Reply #99 on: February 26, 2009, 10:34:08 PM »
Update: I have uploaded a new version to-day, (1) fixing a bug which would cause a crash to desktop in some cases; and (2) implementing the latest developments from the main Simutrans code, including the recent bugfixes and refactoring of the collection classes.

Z9999, I think that this should solve the crash that you were having with the opening screen (default save game) of Pak96.Comic. Please let me know whether it works for you.

Offline z9999

  • Devotees (Inactive)
  • *
  • Posts: 848
Re: Simutrans Experimental
« Reply #100 on: February 27, 2009, 06:03:29 AM »
I couldn't download zip file from your site.
I downloaded it but it was empty 4.15MB file.

Can you upload the file to another site ?
I don't like such a site because of security thing. Thanks.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18502
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Simutrans Experimental
« Reply #101 on: February 27, 2009, 07:41:03 AM »
Z9999,

hmm, I'm not sure what the problem is. I prefer to use files.simutrans-germany.com, but it was down last night, and is still down. Can you suggest an alternative?

Offline Dwachs

  • DevTeam, Coder/patcher
  • Administrator
  • *
  • Posts: 4564
  • Languages: EN, DE, AT
Re: Simutrans Experimental
« Reply #102 on: February 27, 2009, 07:50:52 AM »
there are still problems with subdomains, you can use direct links as in Frank's post:

http://forum.simutrans.com/index.php?topic=1264.msg12208#msg12208

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18502
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Simutrans Experimental
« Reply #103 on: February 27, 2009, 11:44:19 PM »
Dwachs,

ahh, excellent, thank you! Re-uploaded here. Hope that that helps :-)

Offline z9999

  • Devotees (Inactive)
  • *
  • Posts: 848
Re: Simutrans Experimental
« Reply #104 on: February 28, 2009, 06:58:09 AM »
Thank you, I could downloaded it.
Unfortunately result was the same, but thank you for trying it.