Lich Does Nothing Apparent, Then Exits Immediately

[Gammit]

Here's the situation. I run XP with two hard drives, my system on one (C:) and my applications on another (F:). None of StormFront, SGE and the Lich are installed to default paths. I have allowed traffic on TCP 10024 to be routed through my network. I have given the Lich server privileges on my firewall software. I also run PsiNet.

Here's the issue. When I run the Lich executable, nothing happens. I've run it from the command prompt, and no message is outputted. There's no program resident in the Windows Task Manager. The program DOES seem to generate a hosts.bak file, but nothing is modified when I check the hosts file (I presume that it changes something, then changes it back before it quits, and this is all done instantaneously enough that the change is unnoticed).

I'm assuming this has something to do with my peculiar directory structure, but I'm unwilling to give everything a default path JUST for the Lich if there is a better workaround, and if that's NOT the case, it will have been a lot of work for very little gain. So, my question is, who else has experienced this problem?

[Gammit]

On a side note, does anyone know how to make it so that the combination colon-parenthesis doesn't make a smiley emoticon?

Edit: Found it, never mind.

[Gammit]

I should also note that I had this problem before I installed PsiNet, so that's not the issue.

[Celephais]

First thing I would check would be the "Gse.~xt" that is created, by default it's created in C:\ after attempting to log in once, copy the file into your other root drive, then attempt to log in again. Does that work? (obviously not the fix, but if it works it's a point in the right direction, I haven't used Lich so I'm not so sure).

[fallenSaint]

When is the last time you downloaded the Lich installer? I know they had a recent change that screwed mine up. Also I can attest to the fact Lich doesnt care where its installed since I run mine off the ol pen drive.

[Drew]

I had a very similar problem, Shaelun really helped me out getting it running. Damned if I know what we did now though.

[Gammit]

I had this problem with 1.47, and I'm having the same problem with 1.49.

[Gammit]

Copying gse.~xt to F:\ does nothing.

[Celephais]

If you got to start/Run/Regedit and then navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Simutronics\ there are various entries for the different simu paths, I think psinet mungs this up a bit (IE has it's own entries and remaps stuff), but considering how lightweight simu apps are (SF - 10MB, WizFE - 2MB) you can move your Simu install to the default C: directories without a whole lot of hassle...

(and yes I know I'm not answering the real question)

[Gammit]

(and yes I know I'm not answering the real question) Indeed. The entire point of my question was to avoid doing that, if at all possible.

[Celephais]

Indeed. The entire point of my question was to avoid doing that, if at all possible.

Yeah sorry, can't help w/ Lich, just commenting on the "lot of work for very little gain" comment, it really shouldn't be a lot of work (short of your C:\ being your swap drive and you not having 10 MB free) to at least make the game playable w/ Lich for you in the meantime until your answer is found (like I said there is also entries for PsiNet in either an ini file or reg entries).

[Gammit]

Bump

[Shaelun]

I had this problem with 1.47, and I'm having the same problem with 1.49.

I can only assume you mean 3.47/3.49. If you really did mean 1.4x, d/l the installer from http://lich.sudolife.com/download.php -- though as someone pointed out, it doesn't matter if it's installed or not... the installer just unpacks the files and whatnot.

Use the "install to registry" shortcut and just bypass all this weirdness. For a very long time, this wasn't an option: I left the old way in, but it's a hassle and is only there for people who need it or want it for whatever unforeseeable reason (e.g., running it off of a pen drive).

BTW, the program has no "standard out" in the Windows version (stdout in C, cout in C++, STDOUT in Ruby, etc., etc..). Running it from a command-prompt doesn't change that; the only way to capture the program's output is to run the (debugging mode) shortcut, which will create a text file with the program's output.

[Gammit]

Yeah, 3.47/3.49, my mistake. I didn't notice the debugging mode shortcut, so that's good to know. I tried the "install to registry" option earlier, and it changed little, and it seems like from the documentation that it is less of an option with PsiNet, but I could definitely be wrong. I'll see what I get when I run in debug mode.

[Gammit]

There doesn't seem to be a text file outputting after running the Lich with --debug. I assume it should be in the base directory? I see no file there that has today as the date modified, so I'm reasonably sure that I'm not just missing it, unless it's somewhere I don't expect it.

[Gammit]

bump

[Shaelun]

I just checked, and the file is being created in the root directory of whatever drive it's running on. You should find "C:\lich_debug.txt" on your hard drive. That seems less than ideal... things have changed since I put it there. I'm changing it to create the file in the same directory as the Lich executable, so FYI, it'll be there in future versions.

Oh, and in response to incompatibility with PsiNet -- no, that isn't really the case. Issues can arise if you uninstall PsiNet, or conceivably if you were to update PsiNet (I don't know how Jamus handled updating, but with any luck it won't be an issue). The dilemma is that you end up with 3-4 programs (Simu's launcher, PsiNet, Lich, and possibly BlackLightning) that all end up needing to use the same registry key: so all 3-4 programs make their own copy of what the previous value was, then alter the entry. This is necessary because Simu's games launch whatever program is pointed at by that specific registry key.

Lich will respect whatever the previous value of the registry key was, making it work fine if installed after PsiNet. So long as PsiNet also works that way, things will work fine if you install PsiNet after Lich as well (and, as a side-effect, Lich scripts should then see PsiNet info just like game info -- that's untested though). I had some issues making Lich work with BlackLightning, but as far as I know, they now work fine with eachother as well. Simu's launcher is just clueless about the whole affair, so everything else has to work around its limitations.

In essence, that single registry key will be altered if you uninstall any of the 3 programs. If it's changed, the data the other 2 programs has will most likely be incorrect afterward, and things won't work right. So basically you can ignore all this mumbo-jumbo: just remember that you have to uninstall the programs in the opposite order you installed them in, or you'll end up having to re-install Simu's launcher to get the game working again.

[Gammit]

Ok, thanks for the info. Here's lich_debug.txt:

No game/front-end input found, auto-detecting... ...configuring for StormFront.
IP:port = storm.gs4.game.play.net:10024
Permission denied - C:\WINDOWS\system32\drivers\etc\/hosts
Lich:3840:in `initialize'
Lich:3840:in `heal_hosts'
Lich:3839:in `heal_hosts'
Lich:3752:in `find_hosts_file'
Lich:4752
No game/front-end input found, auto-detecting... ...configuring for StormFront.
IP:port = storm.gs4.game.play.net:10024
Permission denied - C:\WINDOWS\system32\drivers\etc\/hosts
Lich:3840:in `initialize'
Lich:3840:in `heal_hosts'
Lich:3839:in `heal_hosts'
Lich:3752:in `find_hosts_file'
Lich:4752


The key bit seems to be the "Permission denied" bit. I'll play around from that angle.

[Gammit]

Running Lich as an Administrator changes nothing, and unselecting "read-only" on the hosts file similarly does nothing. Output is the same.

[Gammit]

Bumpity buuump

[Celephais]

Wait wait... Lich works by changing the host file? That's a terrible idea... a lot of anti-virus/anti-spyware prevents the host file from changing. Are you running any Gammit?

[Gammit]

Norton Antivirus.

[Gammit]

My version of Norton is hopelessly outdate anyway, so I'm going to get something else, uninstall Norton, try Lich, and see if it works.

[Shaelun]

Wait wait... Lich works by changing the host file? That's a terrible idea... a lot of anti-virus/anti-spyware prevents the host file from changing. Are you running any Gammit?

Personally I love software that gives me choices, and Lich does exactly that for its users. There are a finite number of ways to make the program work, and they all have their pros and cons. Users are free to choose either the hosts file method (not recommended, but it's there for people who need it -- like me, everyone else running the *NIX version, and the users who play non-Simutronics games), or the registry installation method (fast, easy, the same way PsiNet and BlackLightning work, and only works for Simutronics).

It's a cross-platform program that's capable of being used with any text-based MUD (not just Simutronics' games); if you have a better way of doing things while keeping it running in BSD, Linux, and Windows and keeping it as widely compatible as it is now, I'm all ears. :)

[Celephais]

Yeah, intercept the invocation of Launcher.exe or Stormfront/Wizard.exe by replacing those EXEs with your own and parsing the command line args, then re-issuing the invocation of the exe you replaced with new command line args... no need to mess with registry or host file...

Edit to add: this effectively does the registry change except you don't need to change the registry and you won't set off any of those red flags that changing the registry sometimes cause.

There is also DLL injection/hooking methods, but that's probably a little too invasive.

[Shaelun]

Replacing the .exe files is a sloppy kludge that I just can't stomach to write in to my program (that's not meant to be as derisive as it sounds, I'm just being honest about why I didn't make that an option). Also, that would only work with Simutronics games. That and it won't fly in anything except Windows: for me, all the PE executables (for everyone not into this junk, it stands for Portable Executable, and it's what Windows-formatted .exe files are called) have to be executed in an emulated environment, which is a major issue since Wine chokes if you try to load an ELF binary. And I'll be damned if I'm going to be forced to run my own program with an emulator.

As for DLL hooks... in all honesty I've never played with hooking Windows DLL imports, so I can't claim to be an authority, but... I don't see how hooking a DLL call would do any good, since SF only uses its silly little DLL file for socket I/O, and Wizard only imports system-wide DLL functions (which I'm sure as Hell not going to try and hook -- even if Windows let me, talk about "red flags"). But beside all of that, for the front-end to be trying to import DLL functions, it has to already have been executed... which poses a problem of its own.

I actually really like the registry method: it's clean, it's effective, and it ensures that no matter what Simutronics does in the future Lich will always know what it needs to know (since it'll get loaded and passed all the relevant info).

If a few people have their antivirus or registry-protection programs or whatever pop up with a "danger, Will Robinson, danger!" thingie, I don't really see it as a problem, to be honest.

[Celephais]

No offense taken (I think we're both capable of critisim in discussion of a topic we both enjoy learning about)

GAH! just lost my post... anyway I think the only non-kludge way would be to write your own SGE (but users wouldn't like that... and Simu's login server has this F'd up issue where you sometimes have to re-send login.. kinda brute force it). Otherwise you're replacing something of Simu's, and you don't know what they could change to mess with it. (That or your own FE but... yeah no)

DLL hooking is pretty simple... basic article on it if you're interested (on hooking DirectX to replace all DX calls... once you hook the sockets you'd be golden. http://www.gamedev.net/community/forums/topic.asp?topic_id=359794

Registry replacement is certainly valid and a good approach, I just like replacing the launcher personally... SGE executes my program, my program parses the gse and either launches SF itself (which makes SF a process executing within my program, which is important for easy access to windows handles for me...) or changes the gse and launches the launcher.

Host file replacement is the only method I really think of as outright bad... host file replacement has been a historical fishing method and a LOT of things are cracking down on it (I don't want my program raising a red flag in adaware, etc).

[Gammit]

I've been moving and haven't had a chance to test out the idea of uninstalling Norton, so I don't have anything new to add in that department. I should make clear, however, that I did try the "install to registry" method the first time I was using the Lich, and had no success. Unfortunately, I have no diagnostic info from that time, either. Anyway, I'll get that set up sometime in the near future.

[Gammit]

Ok. I've just realized (much to my shame) that lich_debug.txt hasn't been modified since 5/20. I uninstalled Norton, and before installing an alternative, I tried running lich.exe, with the same behavior as I've already seen. Similarly, if I install Lich to the registry, nothing happens after I run the SGE, which seems to indicate that the requisite information is being passed to the execution of lich.exe, but then lich.exe is not doing anything.

I'm beyond confused at this point. Lich.exe isn't even generating debug data from which I could possibly find a solution. Is there any kind of check that lich performs at the beginning that would halt its execution before generating a debug file? Or, is there something that would cause execution to terminate (without generating any windows error popups, which rules out null pointers and the like)? Keep in mind that neither my Lich, nor my SF, nor my SGE directory structures are standard (on a drive other than C:, in base directories other than Program Files). Could that possibly generate any of this behavior?

[Shaelun]

Your installation locations shouldn't matter, and no, nothing should be causing the program to just exit mysteriously on its own (except manually launching it, see below). And unless I somehow managed to totally fuck the thing up, there aren't any dangling/null pointers that would cause segmentation faults. You're mentioning debug info -- there's no way to get debug info when you install it to the registry: are you manually executing that debug link before logging in? If you do that, nothing will work. Just install it to the registry and login with SGE, *never* executing Lich yourself.


To Celephais: neat link; thanks for the info. For some reason I've always disliked Windows programming... all those ridiculously long function names (which are CamelCase to boot... shudder) and Microsoft-specific mumbo-jumbo. Of course I don't think there's anything wrong with any of it, but I find I have so little interest in it that I'm always studying about POSIX systems and never choose to learn about Windows.

After you mentioned DLL hooking, I did a google search and found some really neat info on how to invade another processes address space... if I'd known how to do that 2 years ago, I probably would've figured out how to just read the Wizard's game window directly -- but alas, I was not so skilled then, heh.

[Gammit]

You're mentioning debug info -- there's no way to get debug info when you install it to the registry: are you manually executing that debug link before logging in? If you do that, nothing will work. Just install it to the registry and login with SGE, *never* executing Lich yourself.

No, I'd followed the correct procedure, I had just mistakenly developed the assumption that debug info was generated whenever the program was run (I'd completely forgotten that I'd had to invoke --debug to get the previous data in the first place, heh). I run "install to registry," then I start up the SGE, run through character selection, then when SGE exits, nothing happens (until I uninstall lich from the registry, in which case it goes to normal behavior, which is that Psinet and SF launch).

With manual execution (not installed to registry), the debug output seems to indicate that it's exiting after being denied access to HOSTS. Since the install to registry method doesn't have to modify HOSTS, I have no idea what could be causing it to (possibly? I never see a running process to be able to absolutely tell) terminate abruptly.

[Shaelun]

Hmm... then it's possible the program isn't executing at all? Interesting. Get a command prompt, "cd" into whatever directory you have Lich in, give this a try and let me know what the lich_debug.txt file says afterward (if you don't want all this info public, just email me):


lich.exe --debug C:\Gse.~xt

You may have to replace the "C:\" part with "D:\" or "E:\" or wherever the Hell SGE is sticking your "Gse.~xt" file. By the by, if that actually works, then something screwy is going on and Lich isn't ever being executed by SGE.

[Shaelun]

Oh, one more thing: try uninstalling PsiNet, then installing Lich to the registry and tell me if it works then as well. You can reinstall PsiNet right afterward if you like: it's just a troubleshooting test.

[Gammit]

The first time I tried using the Lich, I didn't have PsiNet installed. I was having the same issue, I just didn't work as hard to get it running.


Permission denied - C:\WINDOWS\system32\drivers\etc\/hosts
Lich:3840:in `initialize'
Lich:3840:in `heal_hosts'
Lich:3839:in `heal_hosts'
Lich:3752:in `find_hosts_file'
Lich:4752


That's lich_debug.txt after deleting the lich_debug.txt that was already there and running lich.exe --debug f:\Gse.~xt.

[Shaelun]

First, I haven't been ignoring you... I just haven't had the time to sign online lately. I'd let you know if I was giving up on your problem (seriously).

Here's the only thing I can think of: somehow a backup of your hosts file is hanging around, and when Lich is executed, it's noticing this and trying to repair your hosts file because it's assuming the program choked & died last run and it never got a chance to fix your system. Why it might be thinking that is beyond me, but with all the trial & error that's been going on, it's entirely possible.

Do a search for "hosts.bak" and delete any (or rename them, whatever). Then try again.

[Gammit]

That was it. All is well, now. Thanks for your infinite patience.

[Shaelun]

That was it. All is well, now. Thanks for your infinite patience.

You're welcome. Enjoy :)