This project is read-only.
1

Closed

Not Windows7 Compatible Code

description

Hi
 
Great job!
 
I'm busy creating a windows service around PartyCraft and stumbled upon some code that is bound to create problems on vista/windows7.
 
In the MultiPlayerServer.cs there is code to generate a logfile without any path. When running as a service it results in a path deep inside windows\system32.
 
So i changed to code a bit so the logfile end up in a subdirectory of %appdata%
 
In the Start() method i changed the server.log file creation to:
 
//! veg: Added better location for LogFile (%appdata%\PartyCraft).
        String path = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData), "PartyCraft");
        if (!Directory.Exists(path))
        {
            Directory.CreateDirectory(path);
        }
        String log = Path.Combine(path, "server.log");
 
        if (!File.Exists(log))
            File.Create(log).Close();
        logFile = new StreamWriter(log, true);
 
When I'm ready with the server I'll create a patch. It already runs but is headless, so i changed the xmlsettings and settings.xml a bit to allow predefined operators.
 
wvd_vegt
Closed Jan 30, 2012 at 12:25 AM by sircmpwn

comments

sircmpwn wrote Jan 27, 2012 at 7:28 PM

I agree that this is an issue, but I don't agree with how you addressed it. As an alternative, I've changed LibMinecraft to only provide a packet log when compiled with DEBUG, and changed PartyCraft to use the RELEASE build of LibMinecraft.

wrote Jan 27, 2012 at 7:28 PM

wvd_vegt wrote Jan 27, 2012 at 8:16 PM

Hi

Ok, I fine. I just fixed it so it works, and does not crash. Changing the DEBUG level to RELEASE is a bit supressing sympthomes, not curing a potential fatal bug. But it's your code, I can only advise.

As I run the service in a DEBUG mode I will still encounter this buggy code. Problem is that services are hard to debug and just crash on startup with code like this enabled.

Btw the same issue arises with the settings.xml. When running as a service the current directory is somewhere inside c:\windows\system32\wbem too. In my service I moved this file to %appdata%\PartyCraft too.

sircmpwn wrote Jan 27, 2012 at 9:03 PM

Resolved with changeset 87805



** Closed by sircmpwn 1/27/2012 11:28 AM

sircmpwn wrote Jan 27, 2012 at 9:03 PM

Re-opening to better resolve issue

sircmpwn wrote Jan 27, 2012 at 9:09 PM

Okay, so I've changed this so that MultiplayerServer.LogEnabled = false will disable all logging in LibMinecraft, and you can set PartyCraft.SettingsDirectory before calling PartyCraft.Run() to change where settings are found. Do you think this will solve the issue?

sircmpwn wrote Jan 27, 2012 at 9:11 PM

Also, XmlSettings already has default settings. PartyCraft.LoadDefaultSettings() handles this, though this is likely to change.

wvd_vegt wrote Jan 28, 2012 at 8:15 AM

Hi

As I copied the code from the Server,loading the defaultsettings are already in place. Making the directory a property that can be set solves that.

I adjusted the xmlsettings a bit to allow for predefined operators (got no more console user). I added a keys property to xmlsettings (will post the code) that lets me retrieve all settings starting with operators (every tag underneath is a username made op the moment they login).

As for the logging, maybe make that path a property too. I do not mind a default that has problems under certain conditions, but if the logfile is mainly for development (as I understand from previous comments) and thus for yourselve, it should be fine.

sircmpwn wrote Jan 28, 2012 at 8:57 AM

LibMinecraft logging is only intended for development, and as such will not be very customizable.
I like the addition of your Keys property, though I'd probably change it somewhat. Feel free to post a patch.

wvd_vegt wrote Jan 28, 2012 at 10:36 AM

Hi

Feel free to customize the keys property, it's important to have one code style and as project leader you should be happy with it.

I already changed my service code to incorporate your latest additions. I only have major problems with svn, so have to resort to old-fashioned copying the code (I'm just not compatible with *vn ;-).

wrote Jan 30, 2012 at 12:25 AM

wrote Feb 13, 2013 at 12:56 AM

wrote May 14, 2013 at 10:14 AM