UnityHQ Member
  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Barto

  • Rank
    Agent in Training

Profile Information

  • Gender
    Not Telling

Previous Fields

  • NOLF games played
    NOLF & NOLF2
  1. Oh, I thought with my weird setup that I was the only one having this issue. I'm actually running the game on my Linux machine through wine-staging (wine is a compatibility layer to run Windows software - or at least trying to run them; staging is a set of experimental patches for wine) in its separate environment. I'll get into the settings and set an older version of Windows there when I'll have time, exams are coming so fast. It reminds me that last time I checked, I was not able to run NOLF2 properly, maybe I'll also give it a second shot too. Trust me, sometimes it works without any tinkering :-p
  2. From kotaku: "We were about to commit a large chunk of development time in making sure that No One Lives Forever 1 & 2 were 100% compatible with Windows 8 64, Linux, OSX, had a full complement of Steam features, achievements, working multiplayer, dedicated servers…" As a happy Linux user, seeing this - even knowing System Shock 2 was using some Windows wrappers - makes me cry even more. Sad to see the inaction of big companies here just to ruin other people's job... Time to ask a weird question: why has anyone continued to maintain an open source port of the current source code of NOLF2 that is freely available? Has anyone tried to convert the game for being able to compile with gcc or clang with a Makefile or any other build alternative?
  3. Thanks Eliteone for the link, it's clear that Microsoft decided to make a free (as free beer would a few bearded guys say) version of visual studio called community edition but I really doubt it will work entirely as we would want because there might be some compatibility issues. Notice I have not tested since my windows version is lacking some space to install it . I think they also decided to change the syntax of the project files and converting to what the latest version uses was not working as one would expect (cmake anyone?). @FireFox-: You're right (because it's written on wikipedia page of lithtech - well that's not the best justification I could do) that microsoft was heavily involved. Lithtech - as I imagine - was also a way to expose DirectX 8 to the public. Not surprising they used as much tech from microsoft as possible. @Larry: Let me do an allegory to explain you the heap. It might not be entirely correct but I try to get the best idea out of it. You're tinkering something with wood. You are firstly bringing the wood from the shop. It's long to go there and you cannot really carry a lot in your car. Mostly like the hard drive. Then, to store your stuffs you are working with more efficiently, you put everything on a shelf when you start to work. But when you are done, you clean it for the next day. Compare this to the actual RAM in your computer. It is faster to get your piece of wood, but there is less volume than what the shop has. Finally, for each bit of work you need to do, you have your working bench where you can stick all your tool and the plank you are working with. This is the stack, it's really fast and it's where you do the actual job. You have your blueprints (program), your planks and your current work. The heap could be compared as the space you would put your current work and your planks on the bench. So to explain what FireFox-'s problem was, he was simply out of space to put planks on his bench. As a sidenote, I have seen 2 repos on github about the lithtech engine that tried to do some work in it. I guess both project failed to materialize sadly...
  4. I guess the docs recommend to compile the whole with the compiler shipped with Visual Studio .NET 2003 (msvc 7 then?). You may look into that direction. Just realise that the game got published when Windows XP was one year old and back then, rights managment was just nonexistent on Windows. Expect a lot of stuffs to be working only with admin rights. Meanwhile, I'm dreaming to see a port of this code that uses g++ or clang++ and not their weird compiler with their weird solution files. But since I had a small look into the code, I can tell you there is a lot of #ifdef specific between msvc 6 and 7; so porting this would be a nightmare I guess... Even worse those whole uses MFC and not some classic posix standard library.
  5. Oh, that's right, my method only works if there is a hard link between the server state and the nolf binary (which is - here - not the case). I took too much habbit about how quake based servers are running I guess
  6. Oh, and while driving back home from studies this evening, I thought a bit more about it and I realized you could maybe check in a better way if the server is running. I have not tested it but I guess it should. Just do this mostly: 1. echo $$ > /tmp/lock-nolf (mostly creating a lock file with your pid in /tmp/ if it does not exists, stop here if it there is already this file) 2. start nolf server 3. rm /tmp/lock-nolf (beware you should also do this when you recieve a signal - handled with the trap command) With this you would only check if the server is running if and only if the file exists (if [ -f /tmp/nolf-lock ]; then command; fi). This avoids the tricky "grep -v grep" in your previous code. I can name many other softwares doing the same to check if they are open or if they have a specific file open. "2>&1 /dev/null" is mostly redirecting the output numbered 2 (stderr) into output numbered 1 (stdout) which is then put into /dev/null. I mainly use it when I want to keep some compilation logs on my machine. Just a random question from curious me this time, do you currently store any server's log this way or not? Oh, it seems I found a systemd hater Usually init scripts is just sh files and it is widely supported among many distributions (even systemd can run those file as far as I recall - my archlinux machine has systemd-sysvcompat package for that matter). But hell, the good old crontab is still doing the awesome job and I do not complain about it Have a good evening
  7. I have a bunch of remarks when I read your scripts. (don't be mad that I try to polish it a bit) Why /bin/bash ? I'm pretty sure you could run this via /bin/sh. Advantage? No shellshock and sh might be a bit faster to boot. Debian has it's own posix shell but many other distro just link sh to bash. You can then change gameserver to have sh as the user default shell even by purism. sh is more portable than bash, that's why everyone should use it and not fallback to bash directly ) Why this double redirections? You can simply redirect the output by using "command > /dev/null 2>&1" and avoid to write twice /dev/null. One last question: Is there a specific reason not to use the classic init/systemd daemon manager to do the job but - instead - fallback on crontab?
  8. Let me pop in this discussion with absolutely no knowledge about the subject. So my tips might be totally wrong then, who knows? :-p Here is a list of things I would attempt to make the game work: - move the game in a more right-friendly folder (not "Program Files" but in your home folder instead) - set windows XP as a compatibility mode os version - try to launch the game via cmd.exe and see if something is printed from the game (maybe this way we could get an error message) - is the game up to date? Personally, I would not attempt to run the game in a vm. (If so, do not forget to get into the BIOS and enable intel virtualization technology and intel VT-d feature - at least this is required on my machien) I don't know if this is still the case, but running stuffs on your GPU with virtualization is quite a mess. Most of the time, my GPU is not detected and I do have only the classic CPU to do the calculations... which is horribly slow since it was not built for that manner. Plus you need an old windows cd/dvd image under your elbow...
  9. Welcome to the forums Barto :)