VOGONS


Terminator Skynet problem

Topic actions

Reply 80 of 117, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

There's no way the modification I made could have such an effect. It's not guesswork, the patch only does anything when the crash is about to happen.

The modified executable is for the US release patched to version 1.01 and might not work with other releases or versions.

Reply 81 of 117, by Osprey

User metadata
Rank Member
Rank
Member

It's definitely having that effect. I'm switching back and forth between the two executables, using the same DOSBox build and same dosbox.conf, and the original v1.01 US executable works for me while the fixed one crashes, and before I can get anywhere near a door. This is using 0.74 with pretty much standard settings (ex. all cpu settings on auto, all memory settings on true) on Windows 10 x64 with an AMD CPU and AMD GPU, if it matters. I just tried DOSBox SVN Daum, as well, and similar behavior happens with it.

Last edited by Osprey on 2017-08-03, 09:40. Edited 1 time in total.

Reply 85 of 117, by Osprey

User metadata
Rank Member
Rank
Member

I now understand why. I just re-installed the game from CD, patched it to v1.01 and experienced the same DOSBox crashing. So, I was never able to use the plain v1.01 without this crashing. I remember now that I had replace my skynet.exe with a different one, one hacked to fix SVGA (though it also fixed crashing in VGA for me). Apparently, it also fixed the door bug, since I don't get that.

Last edited by Osprey on 2017-08-03, 14:43. Edited 1 time in total.

Reply 86 of 117, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

That's the executable modified by SysGOD from earlier in this thread. It's a crude hack, and I'm not sure what it tries to fix, but it's not related to SVGA, although the problem may have occurred more often when using the 640x480 resolution. Doesn't target the door crash at all, and certainly doesn't fix it for me. The door crash is related to speed, and you may be immune to it due to the speed of your host system.

Edit: I think SysGOD's modification was for an issue in 0.74 and earlier that causes seemingly random crashes in SkyNET. It's fixed in SVN, so that old hack shouldn't be needed with an SVN build.

Reply 87 of 117, by liqmat

User metadata
Rank l33t
Rank
l33t
ripsaw8080 wrote:

That's the executable modified by SysGOD from earlier in this thread. It's a crude hack, and I'm not sure what it tries to fix, but it's not related to SVGA, although the problem may have occurred more often when using the 640x480 resolution. Doesn't target the door crash at all, and certainly doesn't fix it for me. The door crash is related to speed, and you may be immune to it due to the speed of your host system.

Edit: I think SysGOD's modification was for an issue in 0.74 and earlier that causes seemingly random crashes in SkyNET. It's fixed in SVN, so that old hack shouldn't be needed with an SVN build.

I tried that SysGOD hack exe and it did nothing for me. Still crashed at second entry on buildings. The ripsaw8080 exe is the first clean solution to this problem for me. Thanks again ripsaw.

Reply 88 of 117, by Osprey

User metadata
Rank Member
Rank
Member
ripsaw8080 wrote:

That's the executable modified by SysGOD from earlier in this thread. It's a crude hack, and I'm not sure what it tries to fix, but it's not related to SVGA, although the problem may have occurred more often when using the 640x480 resolution. Doesn't target the door crash at all, and certainly doesn't fix it for me. The door crash is related to speed, and you may be immune to it due to the speed of your host system.

Edit: I think SysGOD's modification was for an issue in 0.74 and earlier that causes seemingly random crashes in SkyNET. It's fixed in SVN, so that old hack shouldn't be needed with an SVN build.

It's definitely still needed with SVN builds. I've tried several, including a couple right now.

I'm pretty sure that sysGOD wasn't the one who modified it. It's dated 5 years before he attached it. I think that he just got it from elsewhere (it is on a few sites, which is where I found it) and offered what he was using because he wasn't having the same issues as others.

As it turns out, I do have an older computer, so it definitely could be a CPU generation thing. Perhaps I would've suddenly started having the same crashes as you guys once I finally upgraded. Fortunately, none of your edits interfere with those made to the other file so it's possible to have the best of both worlds: both fixes in one. I hope that you don't mind that I went ahead and did that.

Here's a Skynet.exe with the original crash fixes (that sysGOG shared) and your door/speed fix... and I even threw in extended polygon rendering distance (because why not). If it's all right with you, ripsaw, I'd like to write up a little documentation (with credit given to you), upload it over at PCGamingWiki, where it can have a permanent home, and link it on the game's page there so that people can discover these fixes easily.

EDIT: Please see my post on the next page for the link to a newer version that includes a few more improvements and documentation.

Last edited by Osprey on 2017-08-27, 03:43. Edited 2 times in total.

Reply 89 of 117, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Well, make sure the SVN builds you are trying are vanilla SVN, and that you're using default settings. Some refer to Daum as an SVN build, but it is not representative.

In my case, I have not seen any of the random crashes on my newer and older Windows systems since the fix was committed. IIRC, the issue became worse when the root directory of the emulated C: drive has many subdirectories. When I first noticed the issue years ago, I had several hundred games installed for testing, so that many subdirs off the root.

Reply 90 of 117, by Osprey

User metadata
Rank Member
Rank
Member

I just checked with EmuCR v4025 and that crashes just like the rest. Also, I mount just the individual game directories, so too many directories isn't the issue.

Perhaps the fix that you committed relies on newer instruction sets. I'm still using a Phenom II and it can't even do SSE 4.1, I think. Anyways, it doesn't seem to really matter anymore. It seems that one fix works for older CPUs and one works for newer. Good job on your fix, even if I don't need it yet. I'll probably appreciate it when I replace my computer.

Reply 91 of 117, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

It seems that you have a different issue than the directory cache issue that was fixed. Although it's likely to be slow for you, does the core=normal setting on a vanilla SVN build help with the crashing? The normal core should be less affected by host CPU quirks. However, I wouldn't be surprised if slow is as problematic as fast for this game...

BTW, you should mount a directory below game directories. It's not a normal situation for games to appear to be installed in the root directory of a drive, and doing so can lead to problems.

Reply 94 of 117, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

I'm curious about this other crash. Does a DOS4GW error message appear on the screen that says page fault, or some other kind of error?

In order to eliminate "ordinary" differences, what are ALL of the commands you are using to run the game? And do you use a frontend, manual commands, [autoexec] section of conf, batch files, etc.

Reply 95 of 117, by Osprey

User metadata
Rank Member
Rank
Member

There's no DOS error because DOSBox, itself, freezes or crashes. Sometimes, I get a standard Windows error that "DOSBox has stopped working." Other times, it just closes without error. Other times, it just freezes and I have to close the window.

I'm not using any frontends, any batch files and no manual commands or autoexec entries other than mount/cd/c:/etc. My dosbox.conf is pretty default and the problem happens even when I delete it. I have everything as simple as they can absolutely be. The issue isn't anything with what I'm doing.

I enabled logging in SVN Daum (don't give me grief; it's the one that I know how to enable logging in) and it reports a succession of page faults and then a page fault queue overrun error:

DOS_AllocateMemory(blocks=0x0080) = 0x0863-0x08e2
DOS_AllocateMemory(blocks=0x0021) = 0x08e4-0x0904
DOS_AllocateMemory(blocks=0x0040) = 0x0906-0x0945
DOS_AllocateMemory(blocks=0x0100) = 0x0947-0x0a46
DOS_AllocateMemory(blocks=0x0030) = 0x0a48-0x0a77
DOS_AllocateMemory(blocks=0x0204) = 0x0a79-0x0c7c
DOS_AllocateMemory(blocks=0x0100) = 0x0c7e-0x0d7d
Warning: PAGING_NewPageFault() more than one level, now using level 2
Warning: PAGING_NewPageFault() more than one level, now using level 3
[...]
Warning: PAGING_NewPageFault() more than one level, now using level 79
Warning: PAGING_NewPageFault() more than one level, now using level 80
E_Exit: PF queue overrun.

That's what it crashes at. To be absolutely sure, I also logged the same test with one of the executables that doesn't crash and the log is the same except without the Warnings and the E_Exit.

Reply 96 of 117, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Please list the commands you're using. Let me decide for myself if they're of no consequence. For all I know you could be creating or changing environment variables.

Regarding permutations of installation: Are you using a small, medium, or large installation of SkyNET? With or without System Shock? What sound configuration?

Daum is of little diagnostic value; moreso the version incorporating code from DOSBox-X that you appear to be using. If you consider that giving you grief then so be it.

Logging to file is easy, just put a filename on the logfile= setting in a debug build of current source.

Reply 97 of 117, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Okay, I've figured out this other crash. SkyNET crashes, probably on purpose, with page faults if the configured cdrom drive reports any free space. In other words, it's a nasty kind of cd-check. The executable uploaded in this thread years ago by SysGOD has a no-cd hack, but my door crash fix executable does not include the no-cd hack. At least it all makes sense now.

This kind of thing has happened before with Ecstatica; so I guess it's what tends to happen with cd-checks that don't play nice.

Reply 99 of 117, by Osprey

User metadata
Rank Member
Rank
Member

I don't have any CD-ROM drive configured in DOSBox when I run the game, but I suppose that the page fault could still happen for that reason, if it is a CD check, after all. CD checks that don't actually tell you that they're CD checks--they just leave you guessing at what the problem is--are nasty.

liqmat, no. It happens within the first 30 seconds of playing and, if you're playing in 640x480, usually before you even get into the mission. If you're mounting the game's ISO in DOSBox, though, and the game really is looking for free space on the CD, you're probably satisfying the check, so you're avoiding the issue.

ripsaw, do you have any idea why the main menu buttons often don't work after launching the game and why a simple right-mouse-button click fixes it? I imagine that I'm not the only person that this happens for, since it happens with every DOSBox build and setting that I've tried (including autolock true and false). It's really simple to workaround once you know how, but I can imagine how frustrating it is for others who haven't figured it out yet.

EDIT: Ah. The mouse bug happens only when dismissing the Bethesda logo vid with the left mouse button, not when dismissing it with the spacebar. I wonder if the game is handling the mouse button down event, but not the up event, so it's not ready for a new left click when the menu appears and it takes a right click to reset it.

Last edited by Osprey on 2017-08-05, 21:22. Edited 3 times in total.