Each time you call recv, under UDP, you will only get a single packet, so if you get 8 at once it'll take 8 recv calls before you get them all - depending on how you process them will depend on what consequences that has, obviously 
UDP is sent a packet at a time, so unlike TCP (which is a stream) you don't have to worry about having partial packets, and having to have a global buffer, etc.
From my limited knowledge of lapper, I'm assume that what you've pasted is simply a modification to the configuration script - in which case since you're not modifying lapper as such there's no licensing issues.
However, I'd err on the side of caution of distributing a binary copy of lapper with your configuration alterations - technically if you're going to do that you should also distribute the code, or a link of where you can get the code. The simplest solution is to simply distribute the conf and provide some docs on where to find lapper itself and how to install it. This is better as it basically means you don't have to worry about licensing concerns and also that you'll never have to repackage things just because a new/bugfixed version of lapper is distributed.
This was not possible with older versions of the InSim protocol, which is why you may have seen this stated elsewhere - you are correct that it's not a relevant concern any longer.
However, I'd err on the side of caution of distributing a binary copy of lapper with your configuration alterations - technically if you're going to do that you should also distribute the code, or a link of where you can get the code. The simplest solution is to simply distribute the conf and provide some docs on where to find lapper itself and how to install it. This is better as it basically means you don't have to worry about licensing concerns and also that you'll never have to repackage things just because a new/bugfixed version of lapper is distributed.
This was not possible with older versions of the InSim protocol, which is why you may have seen this stated elsewhere - you are correct that it's not a relevant concern any longer.
The answer has been given and I'm bored of this now. If you can't think of something nice to say then don't.
There appears to be an API and a reasonable amount of documentation, so it's likely that you could integrate TCAdmin and VCOM, but I've not see anyone advertising that they've written such a thing, so if it is possible it's likely to be something you'll have to pursue.
Your output says that you can pretty much talk to the master, although somewhat slowly. What exactly are you having a problem with popzdan?
Sounds like a bullshit statement to me. Unless it's repeatable, I very much doubt that "it failed his hdd"...
You'll need to talk to the university network administrators, I'm afraid.
If it's working correctly then it should be on the master list automatically. All you need to do is have any port forwarding, firewall rules, etc. set to allow access and to tell it to use the master server in setup.cfg (which it does by default).
There's a list of track names in the first post, and the admin commands can be found in X:\Where\You\Installed\LFS\docs\commands.txt, under the second heading entitled
A rar file is a compressed like - like a zip. You can use 7-Zip or WinRAR to open them.
Unless the phone presents itself with a usable local IP (be it a local loopback or otherwise) the only way of communicating it most likely to be using Nokia's SDK - which you'll have to look into.
Make sure that the /admin setting in your dedicated server cfg (probably setup.cfg) doesn't have two /'s, only one. And also ensure that the /admin setting matches the one you set in the config for ISRM.
Your English is fine
Your English is fine
1. It'll be done when it's done
2. Like any similiar modification the final product must be put before the moderators for discussion and vetting (Bob is the most suitable candidate in this instance, I believe)
I know you're all excited, but when it's done it'll be released in the unofficial addons subforum not here.
2. Like any similiar modification the final product must be put before the moderators for discussion and vetting (Bob is the most suitable candidate in this instance, I believe)
I know you're all excited, but when it's done it'll be released in the unofficial addons subforum not here.
No.
A lot - if its an auto ban you'll get an automated warning before it happens.
pthreads has been ported to windows, which would allow you to make it still cross platform if you use those - http://sourceware.org/pthreads-win32/ (I've not really touched pthreads in my life, sadly).
There are a few other alternatives, one of which would be to use the APR (Apache Runtime) libraries, but that leads you down having to use something called "pools", which are a managed memory framework.
The other solution is to keep it all in the same process and place a timing check hook in somewhere around the insim packet parsing. It does that you can't guarantee the accuracy of the timing though, as I'm sure you're aware of...
- http://sourceware.org/pthreads-win32/ (I've not really touched pthreads in my life, sadly).There are a few other alternatives, one of which would be to use the APR (Apache Runtime) libraries, but that leads you down having to use something called "pools", which are a managed memory framework.
The other solution is to keep it all in the same process and place a timing check hook in somewhere around the insim packet parsing. It does that you can't guarantee the accuracy of the timing though, as I'm sure you're aware of...
Irish sausages? Not quite national, but often tasty.. Or how about some pork and apple sausages (any local butcher should do these)?
The other possibility is that you're trying to use drivers that aren't supported for that OS i.e. XP drivers on Vista. My suggestion would be to get the drivers direct from Logitech themselves via this webpage - http://www.logitech.com/index.cfm/441/320&cl=gb,en (assuming I've got the right model and the picture matches your hardware)
Usually you'll get that if you've tried installing a 32bit driver on a 64bit machine, or vice versa.
It was asked politely. So stop being a grumpy bastard
The same method you use to make the tweaks work should be sufficient. It's just a case of reading, not overwriting.
LFS doesn't hold a lock on the cfg files, so I assume you mean that you can't open it, which case all you need to know is that any text editor can open it. If you're on Windows notepad will do.
If you use the ubuntu's package of Wine, then it's kinda to be expected if you're running headless. Their packages are designed for servers running some sort of X server, be it an actual X server, or Xfvb, etc. One reason why I custom compiled my own...
One reason why I custom compiled my own...Your pings are erratic, which would suggest either;
1. You're using a wireless connection - bad idea as packets are scheduled and not sent as required, which produces latency (aka high pings, or network lag)
2. Your connection is a bit iffy - thats an issue with whoever provides your connection, or whoever you share you connection with
1. You're using a wireless connection - bad idea as packets are scheduled and not sent as required, which produces latency (aka high pings, or network lag)
2. Your connection is a bit iffy - thats an issue with whoever provides your connection, or whoever you share you connection with
The IP entry is irrelevant. That's only recorded if you join a LAN server.
Assuming you've checked your LOCAL firewalls (i.e. if you used the Windows firewall, remove LFS from it, then run LFS in windowed mode, and reallow LFS access when it prompts you again - use roughly the same procedure for other firewall software) - the reason for this is how firewall software identifies a program and whether or allow it access, I won't bore you with the details.
If it's not this, then I'd suggest talking to your ISP as to whether or not they changed any internal policies, such as packet mangling (throttling, blocking, etc.) before I started looking at anything else local to your machine. Given that only a small minority of people are having issues it makes more sense that it's not something related directly with LFS itself, but perhaps some combination of hardware and LFS, or simply your ISP changed something when the patch was released.
Quickest way to test that would be to download an older patch and try to join an older server. If this works it's still no guarantee that things have not altered at your ISP. IT could be that they used a way to detect LFS and exclude it from any packet mangling, and that now no longer works (unlikely as I do not believe the netcode has changed much in Z).
If that works start providing more details about your computer, turn network debugging on in LFS, and attach the debug to a post when you fail to connect.
The fact that you can talk to the master server is irrelevant, as thats only used to get a list of servers. Since you can get a list, you clearly can talk to the master.
FGED GREDG RDFGDR GSFDG