Review Of British Miracle

[HurstLlama]

A firend of mine tried out the version3 of British Miracle downloaded from the link in the Map Archive on his machine (4gb RAM, a humngus graphics card on which he can run every game on max settings without a problem and XP rather than Vista) and it froze sold in October 1837 - the same problem, but a much earlier time than I have had on my rig.

We went back to the January auto save and let the game run on very fast without me doing anything. It froze again at the same point. However, as we sat chatting through what might have caused the problem the game suddenly came to life again after about ten minutes. Sadly when we tried again it never did come back to life.

The difference in the times of the problem between when I play it on my machine (between 1846 and 1851) and yesterday's attempt (1837) perhaps indicates that there is some event within the game that is the cause. What that could be is impossible to guess and I think the game would have to be running with in debug mode to find out. I very much fear that this version of this scenario, using the version of the map posted on this site, is actually broken. Furthermore, I really think it should be removed from the archive until it is fixed, or at least the cause of the problem is known.

[Hawk]

The fact that others have played this scenario without the problems you're having tells me that there's no need to remove this from the archives.

It could be due to playing the map in 1.06.

It could be the humongous graphics card. A lot of old games don't play well with the latest, greatest video cards.

It could be a Vista issue. Do you have RT3 installed in the default directory on the Vista rig?

[MisterHinton]

This might be seem like "duh" but since it wasn't mentioned- many game threads note problems with older software on multi-core computers- you need to set things to use just one core- google around, I don't recall the exact fix, and I'm a P4 single-core XP loyalist anyway ("I shall remain true to the old ways, and die out with them if needs must" as one bard wrote). BTW just started latest version British Miracle this weekend; if I have a glitch I'll report back. EDIT: Actually if I don't have a glitch, I'll restart it in 106, (I have both versions separately).

[Blackhawk]

This might be seem like "duh" but since it wasn't mentioned- many game threads note problems with older software on multi-core computers- you need to set things to use just one core- google around, I don't recall the exact fix, and I'm a P4 single-core XP loyalist anyway ("I shall remain true to the old ways, and die out with them if needs must" as one bard wrote). BTW just started latest version British Miracle this weekend; if I have a glitch I'll report back. EDIT: Actually if I don't have a glitch, I'll restart it in 106, (I have both versions separately).

I don't think RT3 matters if you have a single or dual core. I'm not sure about a quad core. But if you do a search on setting the affinity you can probably find some directions on how to only run on 1 core. I think one method was to start up the program, then go into the task manager and right click on the "Process" running that you want to run under only 1 core. (ex. RT3.exe) and click on set affinity.

[Hawk]

I run and AMD 64X Dual Core 4600+ and I don't have any problems with RT3. Maybe because it's an older dual core.

[MisterHinton]

Beats me- I play a wide variety of pc games and multi-core is a critical issue for many, especially with graphic intensive items. Not my area but I see many others discussing it when a mystery glitch, crash or no-start occurs. The other thing is running with background tasks enabled, or not disabled (same thing), especially security. A lot of people don't have problems (probably more accurate to say, "don't notice the problems the software is having") with more robust systems so maybe that isn't as critical as it used to be either, but it's what comes to mind to suggest. Good luck.

[Hawk]

'Bout all I play is RT 2 & 3, Rollercoaster Tycoon, and Carnivores. All old games.
The first two versions of Carnivores don't play well on this rig without a little tweaking, but it doesn't take much. I'm running XP by the way.

I do indulge in some 3D modeling for MSTS and Railworks, but not as much as I used to. Been too busy with web site work.

[MisterHinton]

And the preliminary results are in- this smelled like a video glitch to me- or graphics/video might be more accurate. It's one of those little leftover PopTop gremlins that roll over and die without warning, whenever just the right (wrong?) circumstances hit. I ran a total of 11 times, so far all under classic 1.05. All but two glitched and froze (those two because I fixed it). Like HurstLama and his buddy the glitches were solidly reproducible, and in a different place. The screen went frozen at the shank end of October 1841 every single time. I'm willing to stick out my neck and say that, in this case, this is not an event-derived problem. Now the fun part- this came with a pre-glitch without which it didn't freeze:

Continental Lines (the ferry from "Europe") kept popping messages about connecting to Copenhagen. That's odd because Copenhagen is a pre-build. The third time I saw it I checked the line and saw it had built two more (total of 3 with the pre-built) water towers between Copenhagen and Hamburg (No "maintenance sheds" though). Ledger lists it, trains run there normally, but at the end of the month AI-decision point, this one "forgets" Copenhagen is already connected; Continental never buys industry in this mode, by the way. That may be the "freeze"; on my laptop (not bad for specs but a laptop ATI Radeon card loses a lot of frame-rate on overbuilt or late scenario maps; like the very end of the unification of Germany campaign, for example), I usually see a bit of a pause just before the AI action messages unfurl, (anything from a tenth of a second to a few seconds near some endgames), when the AI's are making up their minds. I think as time goes on Continental's AI is going into a mind-numbing (his and ours), recursive loop that may or may never unglitch depending on the exact factors; I've waited these out before (having lots of experience with the game CIVILIZATION esp. 3 and 4), and didn't see it unstick here after 18 minutes at the longest; so in this case I think that's what's going on. It's gone Sybil on us.

As to why? I think there is a graphics glitch where the station/track is located. When this area got built, the station or track connection models may have hit just the right pixel or the wrong vertex, or something; this happens with many games, not just RT3. Nobody's fault, just the risks that come-with, and fortunately rarely. Worst case the city may need to be deleted and replaced, but I doubt it. I'm betting on the models. I haven't tried this, my temp fix is more prosaic.

Remembering that this is something that happens to very few players, if the borkedness is vid/graphic related, tweak the configuration. Your results may vary with brand and so forth. This is what I did: well, actually I tried a lot of combinations before this one came up- I went to settings and turned off the Color Mouse Cursor. A fresh game ran through 1843- which is to say through the glitch area most sensitive to the graphics configuration on my system. I knew it was working when Continental's messages came up buying industry and not about connections. Since this setting change doesn't require a restart, I tested an on-the-fly fix second: I started a fresh game with Color cursor on, and Continental starts connecting Copenhagen and building extra towers as before; in 1838 I set Color Cursor off and Voila: no more odd messages and the game ran through 1943 without the end-of-October 1841 glitch.

If you have Color Cursor off and it glitched, try it on, but uncheck acceleration (I know, the game says the B&W cursor is auto accelerated, but don't let that get in your way- try it anyway). My trials included switching size, windowed or non, transform lighting on/off, etc, etc. As I say, your glitch-fix may vary, but I'm pretty sure graphics config is the way to go.

The permanent map fix may be to edit Copenhagen, bulldoze and rebuild (if I knew the editor cheats I would have tried it first myself). It may need to be flattened. Or maybe it's too flat and needs a few lumps above sea level. Possibly if the tower between Hamburg and Copenhagen were a tower-and- maint. facility-pair as the AI expects between most stations, that would help...?

That's -30-

EDIT: Considering that this happens only with rare system configurations it might be less of a pain in the neck (and I don't mean neck) for the designer just to include a readme citing the video config fix for those few who encounter this glitch. It would be different if everybody had it. Look at the smoke over Tehran in Persian Electric (TM)= some map-embedded bugs may not be fixable on a particular map, so also consider it may not be worth the sweat to bother with a physical fix, in a case like this; just some sort of advisory.

[HurstLlama]

I think MisterHinton has put his finger on the root cause of the problem because I have noticed messages about connecting to Copenhagen (I thought them odd at the time but paid no real attention to them).

However, I have tried various combinations of video settings without success. Probably there is at least one combination I haven't tried but the number of permutations with five binary options and two muti-choice settings is exceedingly large.

I don't know how common this glitch is but the fact that it has occurred on the two machines I have tried it on (very different computers with differing processors, graphics and operating systems) makes me think that it might not be that rare.

Given the length of time a player has to invest in this scenario before it terminally bombs, at the very least it should carry a health warning to the effect that it may freeze on some computers after hours of play but that the problem has been known to be resolved by changing the graphics settings in the game panel. To leave it up on this site with a known problem and no warning is, I feel, being unfair to the innocent gamer, who like me, may spend many hours playing an engrossing and challenging scenario only to find it was time wasted.

[Hawk]

Instead of applying a warning to just one map because some people have a problem with it, maybe it would be easier for those people to apply that warning to all maps, because until the problem shows up on the minority of systems, we don't know which map is going to be problematic.

Then again, I could post a warning at the top of every page stating something like

'Those with newer systems and/or the latest video cards may experience problems with some maps.'

[MisterHinton]

Hawk: I agree- and disagree (see below);
HurstLama: you put your own finger on the overarching problem by using that filthy four-letter word: Permutations. I make no secret of having been "in the business"; I did good and I did bad, and making up the bad karma I become somewhat zealotous when the subject of player-screwing comes up. That said, even the biggest pro-companies all, as a rule, end up their games with a long Readme listing of "unsupported" video cards because the number of permutations between card-driver coders and software coders' programs is just mind-boggling, and at some point they either don't know why they won't play-nice together or just "cut their losses" and don't pursue the million-and-one fixes needed. Your complaint points are true and well taken, and I agree with them in principle. Unfortunately, when dealing with this map-error-embedding, like several other problems with the RT3 base code, PopTop coders and betas aren't around any more to carry off to the public stocks. I know what it's like, as you say, to "spend many hours playing an engrossing and challenging scenario only to find it was time wasted." I play hundreds of games a year. As a result, I have a certain "perspective" to any single session or one title.
Hawk: I think that a generic disclaimer is a good idea , although I think the proposed one is too short; possibly as a link to a Readme that gives a short paragraph of examples, like the above, of the more bone-headed PopTop legacies with which we all have to deal. Nothing long, but I'm saying probably longer than is convenient to slip over the top of the current map pages, but including some necessary generic advice.. Games from the threshold of, or before, multi-core and hyper-threading,( two of the newer flashy bits that caused most players the most fits), or OS problems like (gods, another filthy word:) Vista, or vid/graphics glitches- fiddle the in-game settings/ fiddle the card settings- for some it works, for some, they don't. Things like that. Someone who has centuries of experience knows all this (but a reminder never hurts), while someone for whom that old RT3 jewel case disk from Target, bought last week, is his first PC game ever, is totally borked (and I don't mean that in a fun way). A little down home advice can go a long away, and puts everybody on an even playing field, not feeling like they are twisting alone in the wind. "These are the problems; welcome to the club" type of thing. But not quite that long.

Where I disagree is the specificity issue- and NO, (sorry HurstLama), I don't think Hawk should be put to the task of issuing "disclaimers" on a scenario-by-scenario basis. He has enough headaches. Nevertheless, as I mentioned above, I do think that this should happen, but by the scenario designer in his attached Readme when necessary, which can be tailored to address such warnings. The designer knows his map and events inside-out, he has tested them and probably released for beta/playtest and received back comments and corrections and knows any seemingly unsolvable problems first hand. If a problem will arise one time in a million and three million people participate, three of them are getting a bum deal. Of course, Murphy's Law kicks in and if it happens that those three are in the first six who play it, the situation might appear a bit nasty... - - - which is exactly what we have here IMHO; graphics/video card glitches are endemic to the computer game industry. It's the one area where every user still needs to get "under the hood" of their own machine, once in a while, annoying though it is.

That's enough philosophizing for me for one day.

HurstLama: you can temp fix by sucking the scenario into the editor and bulldozing Copenhagen station and possibly track back to the Hamburg junction; then take, either, the "ocean" brush and sink that end of the island to prevent Continental AI from rebuilding to Copenhagen and re-enabling the embedded bug, or delete the city itself. Depending on what it brings to the scenario (I haven't looked around at the underpinnings that much- trying to avoid spoilers myself for now) this may or may not be a minor inconvenience, only.

The real fix (OK not fix- more like "patch") I would have tried if I knew the editor cheats ( ahem...Developer tool codes). The in game cheats are well known and well-listed, but I'll be darned if I can find the often mentioned additional "editor cheats" around here- I see someone mention these but not actually say what they are- like how do you change the on-screen player to control of the AI/AI company you want to pre-build- Geez-louise! Do you need a secret handshake or what! -(sorry, off topic)

Anyway, on a suggested work-around:

EPH: a PM to you.

That's my 2 cents. (OK, more like $2 and 2 cents; sorry. Just one of my more endearing faults; or, perhaps, a less endearing virtue...?)

[Blackhawk]

Where I disagree is the specificity issue- and NO, (sorry HurstLama), I don't think Hawk should be put to the task of issuing "disclaimers" on a scenario-by-scenario basis. He has enough headaches. Nevertheless, as I mentioned above, I do think that this should happen, but by the scenario designer in his attached Readme when necessary, which can be tailored to address such warnings.

I would suggest that a scenario maker use a separate file for known errors in the scenario. As often much of the information in the readme is already in the scenario, it would not surprise me if many people didn't read the readme file. (I know there are some scenarios which I don't read the readme or just skim over it quickly) But if you have a file named WARNING or KnownErrors, then when someone goes to unzip the file they'll think twice about starting to play the scenario without reading the warning, which catches more attention than just "readme." Of course you could always put it in a separate file to catch attention and the readme file.

[MisterHinton]

I second the motion.

[Hawk]

I'm curious; How is a creator to know if there will be an issue with his map if his system doesn't produce any issues?

[MisterHinton]

Well, that's why above I mentioned

The designer knows his map and events inside-out, he has tested them and probably released for beta/playtest and received back comments and corrections and knows any seemingly unsolvable problems first hand. If a problem will arise one time in a million and three million people participate, three of them are getting a bum deal. Of course, Murphy's Law kicks in and if it happens that those three are in the first six who play it, the situation might appear a bit nasty...

If a designer doesn't hold open playtest it will depend on someone reporting it after release; and if the 999,997 play first- no problem; but I agree with your implication: no designer should get sideswiped for something they don't know- In those cases, the KnownErrors file (I like that ) will have to happen when an error is reported after the fact, and only then tested to be sure it is real...like the way this thread herein worked for example. No worries if no one actually reports a problem. 'natch.

Edit: oops, sounds like I'm condoning something I'm not- throwing untested maps to the wind...but lets extrapolate the best case- the open playtest doesn't show up anything either. Same answer.

[Hawk]

Well, rally the scenario creators behind you on this idea. After all, they're the ones that make the maps.

[Blackhawk]

Well I broke down and figured I'd try the map myself, despite not really being much of an RT3 player and focusing mainly on TM. Around 1838 it freezes for me. I can actually watch the train attempt to cross the sea into Hamburg and watch it freeze. So I went into the editor and bulldozed the Y in the track and attempted to rebuild. Of course a message then popped up on the screen saying RT3 crashed at this point.

So I decided to try and see if it was okay to edit that area on the original map file. This time I could edit it without any errors.

I loaded several saved games along the way. The first couple years I could edit the area. But a few years in, once Continental had built 3 water towards by Copenhagen, I tried again. And at this point it crashed again. I also noticed that Continental no longer had any trains going from Hamburg to Copenhagen. Early on in the game they had a train going between the two cities, but at the point where a crash was going to occur, they were all London Docks to Hamburg (at least in my games.)

In a final edit, I decided to load the game from just seconds before it would crash and see if I could build a work around without triggering a crash. I bulldozed the Y section of track next to Hamburg, and bulldozed all the track towards Copenhagen. I then turned more water into land, and built West of Copenhagen into the "water" and eventually met up with the original Continental track. I then reconnected Hamburg to this new "spur" forming a new Y connection. So far so good, no crashes with the editing, and the game didn't freeze when the train that was previously causing it to freeze entered the "land" area by Hamburg. I checked Continental's trains and they all switched to London Docks to Copenhagen instead to Hamburg. So I then reconnected a "land" route between Copenhagen and Hamburg, trying to avoid the area the previous Y junction was at. And so far so good. The AI now has trains between Copenhagen and Hamburg as well as these cities and the London Docks.

I figured I'd repeat what I did in my last attempt. I bulldozed all track on the "land" region of Europe, as well as the water towers and shed. Then I was able to rebuild the track and connect it back to the Continental line. I may have also rebuilt the Hamburg station, I can't remember. But for those that run into an issue with the game freezing, rather than attempt to change graphic settings, it's probably a better idea to go into the editor and edit the map to fix the issues on Continental's line by Copenhagen/Hamburg.

On occasion over the years I've had a few times where I've been building track and the track doesn't build correctly and a locomotive gets stuck on it, or the locomotive just loops between a glitched piece of track and some other point, and when you go to the editor to demolish it/rebuilt in the area it often crashes.

[Wolverine@MSU]

How about having a "sticky" for each scenario in the "Reviews" forum where specific problems with a scenario could be posted?

[MisterHinton]

I believe this is a final result, at least for me. I think the gremlin is dead. I did about 17 runs- after I had the solution I did a few confirmatory tests and lost track of the number somewhere above #14. Remember these are partials (not over 14 years). I'll spare the details. The interesting thing will be to see if anyone else has some feedback on the following findings.

Now, mind you, I started by searching the threads to find out how to get into the AI company in the editor. . I finally found Blackhawk telling danielches how in Rt3/Letters to the Editor/Scenario Writing thread. So I sucked the scenario into the editor and ctrl-clicked on an empty portrait and VOILA- there is the mouse-over note at the bottom of the page explaining how to do it. Thanks for telling me guys. Really, I always prefer my embarassments in public. It just makes me stronger! !

OK... I tried something simple like just adding a maintenance shed to pair with the nearby water tower in case that was a problem; it shouldn't be- the AI isn't smart enough to add them when it takes over a resigned or fired chairmans empty company so I didn't think that was a big factor. I tried moving the station and the city to different places to no avail; bulldozing most of the island and building new ones as well ("islands", not islands; forgot the ocean bridge wasn't available yet.). No go.

I noticed later that whenever I did this, I placed the city over the station (not directly but close enough) rather than the other way around (which meant that I had to change the station name to match- in this case, Copenhagen). This glitched every single time. When I placed the city first and then the track and station, (no matter where- on the continent, on an "island" etc) TA DAAA: the glitch vanished. (Does anyone else put stations first and then the city, and have you noticed any weird effects?) Remember my home maps never did this because I just now learned how to get into the AI heads, so I've never done it that way before either, and I don't know if that's how EPH did this particular one: track/station first, or city placement first?

At any rate, I decided to try a simple test- do nothing but trash the station and rebuild it- nothing else.

<This is the fix-->When I replaced the station and held the station one or two trackslengths (a little less than a full tile) away from the end-of-line, the glitch vanished completely. (I then reset the station name from Copenhagen Junction to Copenhagen). I ran out of energy or I would have tried nipping off the endmost track-segment; but I wouldn't recommend it without further testing. In fact, I have an itch on the back of my neck - so I'm going to run a few more tests, just in case.

However, when I replaced the station dead up against the end of the line the glitch re-appeared. The game went past the old Oct.1841 stopping point, but around that time the framerate crashed to single numbers, bottoming out at 0.3, (!) before coming to a completely solid freeze in Feb. 1843. In positioning the station against the last track segment, which itself is very close to the city pylon, the glitch was present but it took slightly longer for the AI to lose its mind; that is, after the replacement of the original station.
So...it looks something like the station model tore it's pantleg texture on a bit of vertex that was in a bad place due to the end track segment interaction with the city pylon. Or some such doublespeak. It would be interesting to see if city pylon/track interactions have reproducible glitchy properties- just for the purpose of avoiding same in future, of course. (Thank you PopTop... )


In the meantime, I had stupidly sent EPH a time wasting suggestion (I only now realize that; and have just now retrieved and replaced it with the real fix), then I remembered Hawk's obvservation:

I'm curious; How is a creator to know if there will be an issue with his map if his system doesn't produce any issues?

which also has a corrollary: if the designer's system won't trigger a particular glitch, then he can't tell when it's fixed either, and there's no point in suggesting he try anything; he needs a testor who's machine reacts to the glitch, and can tell when it is fixed, to do that thing. And in recompense, I humbly submit this is it. Sorry EPH. My bad.

BTW:

But for those that run into an issue with the game freezing, rather than attempt to change graphic settings, it's probably a better idea to go into the editor and edit the map

I totally agree- in principle, but that depends on the experience/comfort level (and carefulness) of a particular user in the editor. A lot of players are just "players", and there's nothing wrong with that. And most gamers dont have that option with most games, unlike this one (thank you PopTop ), so, industry-wide, the grab-the-graphic fix is often the only one available. We do have it pretty good in that regard.

To recap the fix: trash the station and rebuild it- nothing else- AND (this is very important) hold the station one or two track-lengths (a little less than a full tile) away from the end-of-line point. (You will need to add 200,000 to the co.cash for this).

Let's see if that works for everybody.

[MisterHinton]

How about having a "sticky" for each scenario in the "Reviews" forum where specific problems with a scenario could be posted?

That seems like something that would take up too much space and just leaves a duplicate list of things to search- a searcher looking for problems looks for the thread title with the scenario name in it already.

However, if there is a way to sticky a "KnownErrors" post by the designer at the top inside of the existing thread, that he could edit from time to time, that would be useful for finished projects; then again the similar suggestion discussed above makes the most sense when attached to the archive map itself, and this might be duplicative.