SUBSIM: The Web's #1 resource for all submarine & naval simulations since 1997 |
|
05-23-13, 07:07 PM | #1 |
Ace of the Deep
Join Date: Dec 2012
Location: Near the Dutch mountains
Posts: 1,147
Downloads: 85
Uploads: 0
|
[OM] A victim of the "Turmumbau-desaster"
<firstpost>
Hi there, I've been lurking around subsim for a couple of months, mosty playing 1.5 stock and TMO. A few weeks ago I decided to give OM a shot and really liked it a lot. But now I'm stuck. My career as a Kaleun has turned into a three act tragedy: Act 1: Mods used: OM705, Update720, Patch5 OMEGU300, Patch7 OM-OMEGU deutsch OM Nav Map Makeover DBSM_SH4, Speech Fix Joined the 1. Flotille in Kiel, got a IIb, became the menace of the Thames estuary, IIc and IId followed, sneaked into Scapa Flow and sank some big ones. In 1941 we moved to Brest and I got a shiny VIIb and later that year a VIIc to patrol the "western approaches". Act 2: In spring 1942 I returned to Brest after a fruitful patrol and got a message saying my boat would get a new conning tower, and the upgrade was successful. Two AA platforms, but my boat would not move forward, or backwards, instead a "cannot comply" message was displayed no matter what speed I ordered. This "bug" has been described by TLAM Strike in post #2904 of the OM-thread but no solution or workaround has been posted there (yes, I have read the whole thread, all 3141 posts). A similar problem described by othr (see Post #1687 in the OM-thread for reference) has been addressed by lurker by the release of Hotfix1 for OM V715 (post #1704). Though this hotfix should be included in OM V720 it apparently does not eliminate all flavours of the "lack of propulsion" issue. Act 3: I desperately wanted to continue my career, and the only fix I could find on subsim was a very rough workaround proposed by othr (in post #1693): "Instead I made a new campaign starting in Aug 1943, copied the ActiveUserPlayerUnits.cfg from there to my save directory. Cost me my crew but at least it lets me play while you figure it out." At first glance this method seemed quite suitable: My medals, rank, tons sunk etc. were kept, my well trained crew was gone. OK. I spent a enjoyable week in the Irish Sea and got me some fat tankers, returned to Brest. Got a new objective, left the base and saved the game. But now - none of the saved games of the present patrol can be opened (ctd) - none of the saved games of the previous patrol can be opened (ctd, BUMMER) I restored the saved games from backup to exclude file corruption, deactivated all mods except the basic OM-files, reinstalled SH4 from scratch - no joy. It seems that a promising Fregattenkapitän has been put out of business, not by depth charges, shells or hedgehogs, but by a nasty bug in SH4 or OM. Two questions: Is there another workaround or fix to circumvent or avoid the Turmumbau-desaster? Has anybody managed to play a continuous career from 39 to 45 in OM? If the answer is no there is no point in playing OM for me. </firstpost> |
05-23-13, 09:47 PM | #2 |
Eternal Patrol
|
WELCOME ABOARD!
Sorry I can't help, but I've never played beyond the end of 1939. You would think after six years I would have, but it just sort of never seems to happen.
__________________
“Never do anything you can't take back.” —Rocky Russo |
05-24-13, 01:12 AM | #3 |
Watch
Join Date: Mar 2013
Location: Nova Zeelandia
Posts: 23
Downloads: 63
Uploads: 0
|
The save system in SH4 is pretty buggy. I've found that if I do new saves for each mission with no overwrites then the save-related CTDs are kept to a minimum. I've had to purge all savegames before to fix CTD issues .. but I keep the purged files so that there's a chance I can hack together a fix - as happened recently when crew injuries from a patrol were causing the next patrol to CTD when launching.
If I'm ever offered a new conning tower, I hope I get the option to keep my old one .. *edit* The furthest I've played through to in OM is to the end of 1941. I tend to get sunk by bugs.
__________________
[SIGPIC][/SIGPIC] Silence is Golden |
06-03-13, 04:14 PM | #4 | |||
Ace of the Deep
Join Date: Dec 2012
Location: Near the Dutch mountains
Posts: 1,147
Downloads: 85
Uploads: 0
|
Quote:
The post-Turmumbau-dirty-workaround-issue is different: After combining the new ActiveUserPlayerUnits.cfg with the remaining files of the original save everything is fine until the boat reaches the harbor: After starting a new patrol all saves fail to load, even those that used to be good saves. I can reproduce this problem. I can understand that the combination of data in the (new) ActiveUserPlayerUnits.cfg and data in the remaining files (old) that come from different saves can cause problems when new information is written to the files on leaving the base. What I cannot understand is how this could affect data in files from the previous patrol, but that's what's happening: Saves that used to load fine won't open anymore. Quote:
Quote:
This seems weird. OM is out for a couple of years. There must be a handful of subsimmers that have made it to 45 or at least survived the three new conning towers (2 for Typ VII, one for Typ IX) |
|||
06-03-13, 09:29 PM | #5 |
Bilge Rat
Join Date: Jan 2011
Location: Hokkaido, JAPAN
Posts: 1
Downloads: 178
Uploads: 0
|
Save system is very delicate, so,
If you change the file configurations just a little, even just one word, especially in such as "cfg-named" files, library-related files, you should save new files to restart the new situation. If you changed conning towers as System presents, older saved files are not usable. Some kinds of internal caches are also involved during saved-file loading.
Frequently save your prey in the files. |
06-05-13, 06:45 AM | #6 |
Admiral
Join Date: May 2005
Location: Berlin
Posts: 2,015
Downloads: 165
Uploads: 0
|
From what I can tell the SH4 engine will crash whenever a reference is not resolved. Or in programmer terms, they never put try / catch blocks around the referencing code.
Now, with thousands of items all with their own id's and references between them. Once you start editing files it's going to become problematic for your savegames. Or in plain words, it's really easy to **** up your installation if you mess around with cfg files. Just make 1 mistake and the game will BSOD at some point. From my experience with this engine, unless you're 1000% sure what you're doing, it's perhaps better not to change anything in the game while you're playing. Or in a way, not even the "install in port" mentality is always safe. Excluded are of course textures, sounds etc, which are always loaded on the fly, and can be installed even while the game is running.
__________________
|
06-05-13, 09:49 PM | #7 | |
Silent Hunter
Join Date: Sep 2010
Posts: 3,975
Downloads: 153
Uploads: 11
|
Quote:
You mean they could have fixed all these things? |
|
06-06-13, 04:38 AM | #8 |
Admiral
Join Date: May 2005
Location: Berlin
Posts: 2,015
Downloads: 165
Uploads: 0
|
No, that's not what I meant. Omitting exception handlers is normal practice. That way whenever an error creeps into the data, it will be instantly observed.
If you put exception handlers everywhere the program may go on after an error, but with more problems down the road. The difference is only that it looks nicer to the user, whereas Sh4 will just BSOD or CTD. Unless you manage every error, which is quite impossible. What I am saying is that there are thousands of ids to keep track of, and each mstake can make the game crash. This can happen even in port, because a surprising amount of data is still loaded by the officers desk (like submarine data etc). I've seen by changing just a few small things how quickly I can make the officers desk crash.
__________________
|
06-06-13, 04:53 AM | #9 |
Admiral
Join Date: May 2005
Location: Berlin
Posts: 2,015
Downloads: 165
Uploads: 0
|
No I think there is nothing wrong with the game crashing per se when it encounters a dangling reference (dangling as in: use type7b.tower2 ; but there is no such object).
I think the real problem is the way in which the cfg files were designed, almost nothing uses the exact same format, they seem to have started to read in simple ini-files and then by demand added more and more, until they had database-like functionality. What results is quite a mess imo, but at least it does the job. It still should have been in XML or even better, a database. Everyone who starts working with this stuff should prepare for very tedious editing of text, with many pitfalls if everything is not 100% correct. The engine does not tolerate spelling mistakes / typos or general sloppy work.. That's why I suggested a validator which tests all references in the cfg data. Such a tool would be absolutely feasible, but it'd be a lot of work with so many different formats. It's a pity no one ever wanted to do the work, I am sure the game would be extremely stable that way.
__________________
|
|
|