Crashes, Bugs and Troubleshooting

[TheGeoff]

Originally Posted by kvn8907

Aye aye.

Tried turning off OpenGL. No more crash message when the game quits. Any idea what was causing that message? Also, will I notice any change in the game with OpenGL off?


Also, two more minor bugs to report.

First, with the default submarine submerged below periscope depth, if a torpedo is fired, a message is displayed saying 'Too deep to launch missiles!' despite the fact that the default sub has no missiles.

Second, when playing the game and pressing Esc, it comes up with Enter to start new game, L to load game, and escape to exit. Despite displaying incorrectly, S still saves and Enter still resumes the game.

I don't fully understand a lot of the crashes caused by OpenGL mode so I'm not sure what was causing your specific error. Maybe some process wasn't stopping properly when the game quit or something... unfortunately I don't have much control over the low-level stuff like that so I can't really test it.

OpenGL significantly improves the rendering speed of the game. The default (DirectDraw) graphics service is pretty inefficient, meaning older or low power computers (eg netbooks) often run pretty slowly when there are a lot of fires on the screen or when looking at the world map - OpenGL eliminates this problem, but very rarely results in unusual crashes like yours.

I've noticed the "Too deep to launch missiles" bug and I'll fix it for next time. The game isn't checking properly if you're actually on the missile screen before it gives the warning message.

I'll look into the menu bugs too.

Originally Posted by silverware

First: Sometimes the sub torpedoes don't appear in the correct tubes. They still show as being loaded to the correct tube in the tactical menu, but it's an annoying visual bug.

Second: When you Refit at a port, the tubes are filled up, but not marked as loaded. You then have to reload them manually, where there seems to be two options. Either the crew just touch the torps in the tubes(next reload is normal), or more often, they load a second torp over the first. So there are two shown in the tube.(Next reload they touch them in the tubes).

Third: Fast travel can be used after launching a torpedo. I am calling this a bug, because you can use it to dodge enemy attacks occasionally, as all fast travel does is increment the timer faster and make you move much faster. But I presume that proper fast-travel will come in the future.

Fourth: On subs with multiple routes to a room, the crew will not path there through the fastest, nor safest method. It usually seems random which door they take. Implementing A* or equivalent with a high tendency toward safety would be nice.

Thanks for reporting.

1. On which submarine(s) is this bug occurring? It's usually caused by an error in the objects.ini file for that particular sub.

2. Thanks for pointing this out, I'll fix it up for the next version. Should be a simple fix by the sounds of things.

3. Yeah, fast travel can basically be used to cheat your way out of a lot of situations currently. It's not real time compression, it just makes you move a lot faster. Currently fast travel is only unavailable if an enemy ship or plane is actively tracking your sub on radar/sonar, but I think I'll change this in the next version - it probably should be unavailable if enemies are nearby at all, regardless whether they have spotted you or not. Eventually I'll implement real time compression hopefully.

4. A* is already used, and the crew should always take the 'safest' path. When evaluating how dangerous a square is they will take into account the depth of water, the proximity and intensity of any fires nearby, and the presence of any objects they would have to climb over/under. They do not take radiation into account because they can't see it. They will not, however, recalculate their route if something changes after they start walking - this should probably be fixed at some point.

Are there any specific examples of poor pathfinding you can remember? The algorithm for evaluating the safety of a square might have some bugs.

[Thymo]

I found this bug a few weeks ago but didn't get to poat it yet.

Bug:
[STRIKE]The current objective (white X) cannot be viewed on the map in zoom level 1 but ot can be viewed in any other.[/STRIKE] Disregard. Bug has been adressed already.

Request:
Can you also change the dutch port. Curently it is Amsterdam but it should be Den Helder which is our naval port, it's north of Amsterdam.

P.S
Is the master arm switch in the tactical control panel going to get any functionality or is it there just as eye candy?

[TheGeoff]

Originally Posted by Thymo

I found this bug a few weeks ago but didn't get to poat it yet.

Bug:
[STRIKE]The current objective (white X) cannot be viewed on the map in zoom level 1 but ot can be viewed in any other.[/STRIKE] Disregard. Bug has been adressed already.

Request:
Can you also change the dutch port. Curently it is Amsterdam but it should be Den Helder which is our naval port, it's north of Amsterdam.

P.S
Is the master arm switch in the tactical control panel going to get any functionality or is it there just as eye candy?

Thanks for the info, I'll add Den Helder soon. The master arm switch is just decoration for now, maybe it'll do something one day though.

[silverware]

Originally Posted by TheGeoff

1. On which submarine(s) is this bug occurring? It's usually caused by an error in the objects.ini file for that particular sub.

2. Thanks for pointing this out, I'll fix it up for the next version. Should be a simple fix by the sounds of things.

3. Yeah, fast travel can basically be used to cheat your way out of a lot of situations currently. It's not real time compression, it just makes you move a lot faster. Currently fast travel is only unavailable if an enemy ship or plane is actively tracking your sub on radar/sonar, but I think I'll change this in the next version - it probably should be unavailable if enemies are nearby at all, regardless whether they have spotted you or not. Eventually I'll implement real time compression hopefully.

4. A* is already used, and the crew should always take the 'safest' path. When evaluating how dangerous a square is they will take into account the depth of water, the proximity and intensity of any fires nearby, and the presence of any objects they would have to climb over/under. They do not take radiation into account because they can't see it. They will not, however, recalculate their route if something changes after they start walking - this should probably be fixed at some point.

Are there any specific examples of poor pathfinding you can remember? The algorithm for evaluating the safety of a square might have some bugs.

1: I remember this happening on the default sub along with the December, although I haven't played in a few weeks.

4: Specifically the December, with it's many routes, I think one side may have had a tiny level of water in it. (less than enough to show up on the main view)
The crew tended to take the longer route from command to engines over a more direct one.

[hygroovy]

First up, this game is excellent! Thanks for making it, its a gem!

Most of the bugs I've come across have been mentioned already, but I just figured out how to change subs, and on the Typhoon, my crew are unable to find a path to No. 1 Reactor Coolant Pump.

I'll list any more bugs as I find them!

[Aktungbby]

hygroovy & Silverware!

[Jimbuna]

Welcome to SubSim

[ReallyDedPoet]

Welcome hygroovy & silverware

[hygroovy]

Cheers me dears!