Pedro-NF

Enter our Steam group's game giveaways for free: http://steamcommunity.com/groups/nfservers

OK, here's the last nail on N!tmod's coffin: if you change any setting via the menus, it REWRITES your whole autoexec.cfg file with a dump of all your settings (like the etconfig.cfg file all mods create in the player's profile directory). So, if you have an organized autoexec.cfg file (like most people have or should have), with settings grouped by type, with comments, etc., it's all GONE if you change anything via the menus. I don't want to ever touch that #*@*# again and if we switch mods, silEnT will be the new mod. Sorry if I've gone off topic here, but this info might help other admins who, like me, might be trying to decide what mod to choose.

100% agreed. The ones I find essential are levlist and levinfo, the other two I've never used in Jaymod - I always edit the levels via the config files. As to the abbreviated commands, they're useful but if the way the admin system was written makes them too hard to implement, by all means concentrate on whatever your priorities are now, I don't mind typing the whole commands.

What I meant was, I like the silEnT mod trip mines, because they have real wire attached to them, the way I believe existed in WW2. I was criticizing N!tmod's trip mines, which instead of wires have laser beams, which seems unrealistic in a WW2 game. Also, they don't need to be planted by the engineer with the pliers like all mines, the way I think it should be (like silEnT made it), you just stick them to a wall and they are instantly active. Basically, I'm in favor of any additions to ET as long as they don't deface the original design and make sense within the game's WW2 context. Back to the admin commands, I noticed you can't use abbreviations for them (like !li for !list), that's very helpful.

Optional (maybe bitflagged) please, I hate both the 1st blood and the 1st headshot announcements, silly and useless. Now the other suggestion about the admin system commands for the levels is very good, actually I think the absence of those commands should be considered a flaw. Didn't get what it has to do with using RCON like Chuckun answered. The whole point of the admin system is err, to be able to admin stuff after being identified by the server according to what's defined in the levels and user databases, independently of RCON authentication. The [>NF<] Server is running Jaymod+Enhanced mod right now, but I'm considering switching to another mod (silEnT or N!tmod). silEnT is looking like the best option because I really hated what the N!tmod devs did to the flamethrower's flames model and animation, and their implementation of trip mines use... laser beams!?!?! Did that even exist in WW2? On the other hand, they claim to have eliminated the MAX_GAMESTATE_CHARS problem, which for servers with huge rotations like mine is a godsend (if it does work). Also, poison canisters and poison mines are a great addition to the game which even an ET purist like me can appreciate. Oh, and add another vote in favor of the molotovs.

Thanks for all the feedback. All files are in their correct places. When I started the server from a XP Pro 32-bit VMWare virtual machine, I didn't even copy the files over to its virtual drive, I ran it directly from my actual machine (XP Pro 64 install) through a shared folder, and the server started OK. Since gaoesa said he could start the server from a W7 64-bit machine, I created a virtual machine with W7 Ultimate 64-bit and confirmed that the server starts fine from it. The issue seems limited to XP Pro 64 - W7 64 probably loads the necessary 32-bit libraries, while XP 64 doesn't.

I run my own machine (not the server's) on XP Pro 64-bit, and found that the dll file from the silEnT mod and the N!tmod releases won't run on XP 64-bit. The mods won't load the LUA dll and I get the same error message when starting the server as if it were not there - "ERROR: BG_IndexForString: unknown token 'PPSH': (animations/scripts/human_base.script, line 22)" - and then the server shuts itself down. I tested it on one of my XP 32-bit virtual machines with VMWare and it worked fine. Never touched (and never will) VistaTrash or 7Garbage, but I'm pretty sure this is a 64-bit incompatible code issue common to all 64-bit versions of Windows. Can't say if it happens on 64-bit Linux either. Assuming that eventually many game server hosts might move to 64-bit OS's, maybe someone should compile a 64-bit friendly version of the dll (and of an .so file, if that also happens on Linux).