DGM gives SDS0004 on "coreship.shi_" because of date missmatch.

from Stardock Forums
I think it is time to start a separate thread on this problem ---

I got this on both 0.66.83 and 0.66.84 with all the "temp" folders I could find related to drengin empty. Here is the data from the debug file:
----------------------------------
********************
Install Game: gc1
************
InstallGame gc1
Debug Message: Retrieving LocalXMLFileList
Debug Message: FileSum
Debug Message: Fetching Files

-------------------------
GetFile: CoreShips.SHI_ 658 bytes 08/27/2002 16:19:29
-------
Debug Message: Clear Http Header
Debug Message: SetHttpProperties
FileDoesNotExists:
Chunk size:658
GetRange 0 - 658
Add Header: Range: bytes=0-658
GET RANGE REQ HEADERBEFORE:
Range: bytes=0-658
HTTP BLOCKED: False
Bytes Retrieved: 658
State: 0
Status: 206
StatusText: Partial content
Created: C:\WINDOWS\TEMP\drengin\gc1\Base\Data\CoreShips.SHI_
SetSYSTEMTIME: 08/27/2002 16:19:29
SetSYSTEMTIME: Second: 29
SetSYSTEMTIME: Second: 29
A: SetFileDate() - FileDate: 08/27/2002 16:19:29
a: Day0
B:29
C:SetFileDate() - FileDate: 08/27/2002 16:19:29
c: Day0
D:29
E:29
e: Day2
SetFileDate() - FileDate: 08/27/2002 16:19:29
SetFileDate() - SYSFileDate: 08/27/2002 16:19:30
SetFileDate() - FSOFileDate: 08/27/2002 09:19:30
GetRange() - SYSFileDate: 08/27/2002 16:19:30
GetRange() - FSOFileDate: 08/27/2002 09:19:30
GetFileA() - SYSFileDate: 08/27/2002 16:19:30
GetFileA() - FSOFileDate: 08/27/2002 09:19:30
File Exists
FileSize: 658:658
Date: 08/27/2002 16:19:30
File size or date is not correct: C:\WINDOWS\TEMP\drengin\gc1\Base\Data\CoreShips.SHI_
Deleting File CoreShips.SHI_

GETFILE FAILED
-------------------------
Error: SDS0004 - Could not find file CoreShips.SHI_ on server http://scripting.stardock.com/
--------------
I also went into "E:\Drengin.net\data\gc1" and looked at the file gc1.xml for other clues. This file shows an old date (08/18/2002) so it can not be for the latest build of GalCiv (beta 1z). Shouldn't DGM have deleted this file and gotten a new copy?

Cheers,
Jack

245 views 10 replies
Reply #2 from Stardock Forums Top
same here

Paul.
Ashes of the Singularity II
Reply #3 from Stardock Forums Top
Probably similar problem here, but I got only stop statament encountered window... I cannot find that debug file you mentioned...
Reply #4 from Stardock Forums Top
Hate to say this but Same here. :(
Reply #5 from Stardock Forums Top
Peter and Grog,

You have to add the /d switch to the properties of your Drengin startup shortcut.

Cheers,
Jack
Reply #6 from Stardock Forums Top
I have been trying different date formats to see if that will get me past this problem. A while ago I had changed my date format to mm/dd/yyyy. I have now tried mm/dd/yy and m/d/yy. Then I noticed that some of the times in the debug file are in 24 hour format. I think I found where to change this on my PC some time ago and did so, now I can't find where it was to try changing it back to 12 hour format. Does anyone have any idea where this would be on WinME?

Thanks,
Jack
Reply #7 from Stardock Forums Top
John,

The problem you are experiencing is pretty interesting. I have about two others I know of for sure that have the exact problem. If you will notice the file dates the time is off by once second. Which is causing the files not to compare properly so the code thinks something failed with the download of the file.

I just posted a new update about 10 minutes ago that address other date/format problems. I am curious to see if it fixes this problem as well.
Reply #8 from Stardock Forums Top
T-Man,

Saw the update on the other thread and downloaded and installed it. Didn't work. I will continue this dialogue on the other thread.

If anyone knows where the toggle is on WinME for the time format (12/24 hour) please post here.

Thanks,
Jack
Reply #9 from Stardock Forums Top
Go into your Control Panel and Open Regional Settings.
For the Time you would change the format from HH:mm:ss tt to HH:mm:ss
Reply #10 from Stardock Forums Top
If there is anyone still having this problem the thread "DGM Updated - 0.66.083" contains a pointer to DGM 0.66.86 which has solved my problem.

Cheers,
Jack