Minkata Shard Update December 14th, 2015 (Build 82, updated to Build 88)

[Mac_Fife]

[D'Lanor] Add additional confirmation to perform an Avatar delete
Suppose you want to quit MOULa but instead of the quit button you hit the delete button by mistake? (which after all is only a few pixels away) You see a confirmation dialog but since you are under the impression that you are quitting you confirm without reading it... And oops, there goes the avatar that took you many days, even months, to build.
--> this works great and is really not possible to go unnoticed anymore unless someone would do that quite 'blindly', means e.g. while talking to someone else etc ...

Out of interest, when you deleted the avatar, did you find a short delay (a few seconds) after clicking the final "yes" before you got back to the avatar selection screen?

[janaba]

Out of interest, when you deleted the avatar, did you find a short delay (a few seconds) after clicking the final "yes" before you got back to the avatar selection screen?

Yes, it took a while before you were returned to that selection screen, I had the time to ask myself 'Hmmm, did it work?' lol ...

[charura]

@charura: I just looked at the logs, and yes -- your client is trying to obtain files for the dat/ folder in your Minkata installation from our shard server.

We aren't allowed to provide downloads for those files, which is why you need to copy them from an existing up-to-date MOULa installation. Try doing that again (overwrite any files in dat/ with the MOULa versions) and then run the Minkata launcher.
_R

I have done that on all three attempts....I will try again. I delete the three folders (avi, dat, sfx) re-copy from UruLive and paste to Minkata Shard folder where my UruLauncher Application file is....

Fourth attempt....same as two and three

Fifth attempt after shut down and re-start.... same as 2-3-4

[D'Lanor]

Yup. The three weird uru tmp processes (most recently labelled uru2E40.tmp) won't delete, so I reboot to get rid of them. I discovered just now that they appear in task manager (in the list of processes) a couple of minutes after the launcher gets to work. I assume they are signs that the launcher is trying to do something but failing.

Hmm, that is new. So you are saying that Windows is running the tmp file as a process? Strange.

I still think this is a variation on the "Failed to delete old patcher executable", except that this message somehow fails to pop up.
What you can do to fix this is renaming the most recent tmp file to UruLauncher.exe (but make a backup of the old UruLauncher first). Can you try that next time?

On a possibly related note, I found an unexpected behavior in the Minkata shard client. The proper way to start the game is by running UruLauncher.exe. However, when a user accidentally starts up UruExplorer.exe it should correct this error by launching UruLauncher.exe and quitting itself. This no longer happens with the latest Minkata client. Instead I get an error message "Failed to launch patcher" while UruLauncher.exe exists in the same folder.

[rarified]

On a possibly related note, I found an unexpected behavior in the Minkata shard client. The proper way to start the game is by running UruLauncher.exe. However, when a user accidentally starts up UruExplorer.exe it should correct this error by launching UruLauncher.exe and quitting itself. This no longer happens with the latest Minkata client. Instead I get an error message "Failed to launch patcher" while UruLauncher.exe exists in the same folder.

Interesting... I can't think of what may be happening, I may have to trace it out. Right now building a debug client under VS 2003 .NET is messed up, the solution files were not kept in sync over some changes.

Thanks,
_R

[rarified]

Fifth attempt after shut down and re-start.... same as 2-3-4

Well, don't waste any more time doing the same thing. Let me look at the log, and I will give you the name of a particular file that I would like you to check the properties on (both in the UruLive folder and the Minkata folder).

_R

[D'Lanor]

[Mac_Fife] Fix for forgotten logins when removable media attached
--> As one of those affected by this I can report that MOULa now remembers my account name and password!

[Treehugger]

Hmm, that is new. So you are saying that Windows is running the tmp file as a process? Strange.

Yup. I can see the launcher in "applications" and it claims that it is running, but the icon is the black and white rectangle with dots at the top right, rather than a proper Uru icon. Under the processes tab, I see the launcher and the three tmp processes listed.

I still think this is a variation on the "Failed to delete old patcher executable", except that this message somehow fails to pop up.
What you can do to fix this is renaming the most recent tmp file to UruLauncher.exe (but make a backup of the old UruLauncher first). Can you try that next time?

Ok, I'll have a go and report back.

On a possibly related note, I found an unexpected behavior in the Minkata shard client. The proper way to start the game is by running UruLauncher.exe. However, when a user accidentally starts up UruExplorer.exe it should correct this error by launching UruLauncher.exe and quitting itself. This no longer happens with the latest Minkata client. Instead I get an error message "Failed to launch patcher" while UruLauncher.exe exists in the same folder.

Interesting! You know, I am quite likely to have clicked Explorer in the past, since both sit in the folder with the same icon and I do wonder sometimes which to use. But I'm more likely to have done this recently for Gehn than for Minkata. However, I have been having problems with Gehn too. If the Gehn shard client is doing the same thing as what you've discovered Minkata doing, then maybe I may have caused something to be hidden somewhere that survives reboots but which is stopping both shards from working.

On a different tack but just in case it's relevant, here is a post I made a few hours ago, over on the GoW forums - no reply yet. It's flagging an error message I'm getting with Gehn, but not with Minkata. However it may be a red herring.

Hi, I'm having all sorts of trouble with both Gehn and Minkata - in neither case is the launcher working. I've tried a clean Gehn installation from a recent download, but it hangs on "launching". The window also shows the message "SSL certificate problem: unable to get local issuer certificate".

Both shards used to work on this laptop. So I don't know if it's a problem with a recent Win7 update, something to do with Avast, or there is something in common to both Shards' most recent updates that's causing my problems.

For Gehn, Task Manager shows no applications are running, but in "processes", I have urulauncher.exe*32 and three urulauncher.exe.tmp*32. The only way of clearing these is a restart (which I do every time). I have tried the Gehn repair program - which first time round downloaded quite a lot of files but ended in the same result, it gets to "launching" but no further. The installation is still showing version 20 so I haven't got to subsequent updates.

The failed Minkata launch sticks too and I also get the three urulauncher.exe.tmp processes, but I don't see the same message about SSL certificates. However I wondered if this was the cause of both sets of problems and if so, how I can solve it.

If this SSL certificate message is a red herring then I'd love to have any other ideas.

MOULa is still working - so far.

[Treehugger]

I still think this is a variation on the "Failed to delete old patcher executable", except that this message somehow fails to pop up.
What you can do to fix this is renaming the most recent tmp file to UruLauncher.exe (but make a backup of the old UruLauncher first). Can you try that next time?

Ok, I'll have a go and report back.

Ok, so I renamed the tmp file, rebooted, then tried to launch. It didn't launch, nothing shows in "applications", the UruLauncher.exe appears in "processes", but interestingly, shortly afterwards, two more UruLauncher.exe processes appeared in "processes", making three in all - just like the three tmp versions I previously saw. Each uses no processor and the same 104k memory. (The "true" launcher uses 4000k memory, when it's listed in applications but is failing to launch - clearly this didn't happen this time.)

I'll now put things back the way they were - hope you learned something, D'Lanor!

[Mac_Fife]

Out of interest, when you deleted the avatar, did you find a short delay (a few seconds) after clicking the final "yes" before you got back to the avatar selection screen?

Yes, it took a while before you were returned to that selection screen, I had the time to ask myself 'Hmmm, did it work?' lol ...

Exactly. It's the temptation to click again that is a slight concern (not that it does any harm). We're not sure why there's a delay at all - maybe it's a MOSS thing. I don't think I ever deleted an avatar on Minkata before, so have nothing to compare against.