lol this is definitly a new one my Patcher for the game the short cut in which i clicked to launch decided it was no longer usefull or something and would only give me an option of removing it.
So I clicked it ......
Now I, have no access to the game for some odd reason O.O .
This just happened to me as well. I clicked the launcher to log in, and it threw up a little window saying something along the lines of 'Trying to connect to launcher. Please be patient. Attempted 1 times.'
After about 10 minutes, I lost my patience, and closed the window. When I tried to open it again, the launcher exe was gone, and when I try to launch directly from the game client, it can't connect to the login server.
This just happened to me as well. I clicked the launcher to log in, and it threw up a little window saying something along the lines of 'Trying to connect to launcher. Please be patient. Attempted 1 times.'
After about 10 minutes, I lost my patience, and closed the window. When I tried to open it again, the launcher exe was gone, and when I try to launch directly from the game client, it can't connect to the login server.
If you look in the install folder, what files do you see?
This is a recent problem, as well. I've been playing off and on most of the day without problems. I logged off about 2 hours ago, so the problem arose between then and now.
The only other exe I see in that folder is uninstall and cryptic error
Yeah, sounds like it was what I thought. The auto-update system for the launcher basically runs the following steps
Download the new launcher into memory.
Rename its own executable to Star Trek Online.exe.deleteme.
Write the new launcher from memory to Star Trek Online.exe.
Run the new Star Trek Online.exe.
Exit.
The first thing the new launcher does is delete the deleteme file normally, so this should be fairly transparent. If close it between the rename and the write finishing, you get this. Just rename the .deleteme back to .exe or run the small installer and you will be fine.
I believe you need to make a Stickie as if this were to happen again to were people can find and re-install the Launcher again should this become necessary....
Knock on wood.... hoping I, don't have to re-install the launcher again.
Okay, that fixed the original problem. The launcher starts to run now, but the little window pops up like it did in the beginning, but it doesn't just hang there for 10 minutes now. It now gives another popup saying that a file was unable to rewrite, and closes itself
Okay, that fixed the original problem. The launcher starts to run now, but the little window pops up like it did in the beginning, but it doesn't just hang there for 10 minutes now. It now gives another popup saying that a file was unable to rewrite, and closes itself
Check the permissions on the launcher and the install folder. You may need to run it as Administrator (right click -> Run as Admin) depending on your install folder.
If it happens to more than two people I can look at improving it (though barring MS finally making Transactional NTFS it will never be error-proof).
There's enough in NTFS as of Vista to make this work reliably. The only part that is remotely tricky is the fact that you can't delete a locked file (like your own executable), like you would be able to on any non-windows platform.
This rough algorithm should do the trick (I'm sure you can fill in the details):
1. Download the new launcher to ${exename}.tmp.exe
2. Invoke the new launcher, and exit
(now in the new launcher...)
3. Wait for the old launcher to finish exiting (important - we can't touch it until that process is gone)
4. Rename ${exename}.tmp.exe to ${exename}. Use MoveFileTransacted with MOVEFILE_REPLACE_EXISTING to get atomic-overwrite semantics.
Since this is an atomic rename operation, ${exename} is always a complete copy of either the old or the new launcher. This is stable even across power failures at any point. It's approximately the standard algorithm used on unix systems for handling this sort of thing (where rename() has the correct semantics to make it work).
For XP compatibility, use MoveFileEx instead of MoveFileTransacted. That's not atomic (XP doesn't have any atomic filesystem operations, for no good reason), but the only failure case is power/hardware/filesystem failure during the syscall, which is a lot more robust than what you currently have.
There's enough in NTFS as of Vista to make this work reliably. The only part that is remotely tricky is the fact that you can't delete a locked file (like your own executable), like you would be able to on any non-windows platform.
This rough algorithm should do the trick (I'm sure you can fill in the details):
1. Download the new launcher to ${exename}.tmp.exe
2. Invoke the new launcher, and exit
(now in the new launcher...)
3. Wait for the old launcher to finish exiting (important - we can't touch it until that process is gone)
4. Rename ${exename}.tmp.exe to ${exename}. Use MoveFileTransacted with MOVEFILE_REPLACE_EXISTING to get atomic-overwrite semantics.
Since this is an atomic rename operation, ${exename} is always a complete copy of either the old or the new launcher. This is stable even across power failures at any point. It's approximately the standard algorithm used on unix systems for handling this sort of thing (where rename() has the correct semantics to make it work).
For XP compatibility, use MoveFileEx instead of MoveFileTransacted. That's not atomic (XP doesn't have any atomic filesystem operations, for no good reason), but the only failure case is power/hardware/filesystem failure during the syscall, which is a lot more robust than what you currently have.
Biggest problem with that is you have to run it once as a different filename which will confuse things like firewalls. That could be fixed with a second restart once the executable name is correct, but thats kind of annoying too. Given how rare issues are, I think I'll just stick with the simple system ;-)
Comments
After about 10 minutes, I lost my patience, and closed the window. When I tried to open it again, the launcher exe was gone, and when I try to launch directly from the game client, it can't connect to the login server.
re-downloading the patcher again :mad:
I found it by pure coincidence O.O
Files: Cryptic error, game client, d3dx --- (3 of them) , fmod_xx (2) , fmode (2), msid, nvtt, nxcooking, Physcore, physxcudert, physxloader, steam_api, xinpu1, xinput9
Folders: .patch, cache, localdata, logs, piggs, Microsoft.vc80, prepatch, screenshots
--
Nevermind, figured out the screenshot and saved as a bmp, but how do I attach it to a forum post?
Star TrekOnline.exe.deleteme
The only other exe I see in that folder is uninstall and cryptic error
other then exe files nope. not that i can tell but i'm happy long as the game is working.
The first thing the new launcher does is delete the deleteme file normally, so this should be fairly transparent. If close it between the rename and the write finishing, you get this. Just rename the .deleteme back to .exe or run the small installer and you will be fine.
Knock on wood.... hoping I, don't have to re-install the launcher again.
Also, thank you for your time, coderanger. Much appreciated.
There's enough in NTFS as of Vista to make this work reliably. The only part that is remotely tricky is the fact that you can't delete a locked file (like your own executable), like you would be able to on any non-windows platform.
This rough algorithm should do the trick (I'm sure you can fill in the details):
1. Download the new launcher to ${exename}.tmp.exe
2. Invoke the new launcher, and exit
(now in the new launcher...)
3. Wait for the old launcher to finish exiting (important - we can't touch it until that process is gone)
4. Rename ${exename}.tmp.exe to ${exename}. Use MoveFileTransacted with MOVEFILE_REPLACE_EXISTING to get atomic-overwrite semantics.
Since this is an atomic rename operation, ${exename} is always a complete copy of either the old or the new launcher. This is stable even across power failures at any point. It's approximately the standard algorithm used on unix systems for handling this sort of thing (where rename() has the correct semantics to make it work).
For XP compatibility, use MoveFileEx instead of MoveFileTransacted. That's not atomic (XP doesn't have any atomic filesystem operations, for no good reason), but the only failure case is power/hardware/filesystem failure during the syscall, which is a lot more robust than what you currently have.