It took me a few extra days to get around to putting together a demo of what xi4n is exactly, and what it can do right now.

I figured since I'm not running it against a populated server at the moment I'd video something.

http://www.youtube.com/watch?v=U_SiwqAuzFw

Excuse the quality of the voice over. I don't like "public speaking", even pre-recorded and over the internet.

The entire xi4n install and livemap plugin, plus a few connected people weighs in at about 10-20MB of ram usage total, depending on the node garbage collection. Of that, about 4MB is the node environment. So it's reasonably slim for a 100% live tracker, in comparison to running your InSim client plus apache/nginx/IIS/whateveer and PHP/python/whatever and some form of database/RPC to communicate between the two.

Obviously what I've demo'd isn't 100% feature complete. I need to write some iconv stuff to deal with LFS' codepage nonsense and so forth, etc.

A couple of other things I'm interested in working on is a re-implementation of the LFSW relay that you can run yourself and allow anyone to connect in but not send destructive commands. I'm also interested in arsing about with a live control panel which may be an extension of the livemap plugin.

Epic TAA fail. Boooo. Thats what happens when I don't pay attention

Cheers for running the cargame servers dude I really do enjoy playing on them, it's been a fun few weeks

Quote from cargame.nl :

Eehhh.. What does it do?

Basically it's a multi-connection insim library written in javascript, but one you can also choose to run by pointing it at a directory with a config file and bunch of plugins.

It runs on nodejs which is a platform built on Google's (chrome) v8 javascript engine "for easily building fast, scalable network applications".

What xi4n does is it gives you a basic framework of socket maintenance, packet parsing, etc. and exposes an API that allows you to write plugins without worrying about how InSim really works - you just say what packets you want and what function(s) to call when that packet comes in - pre-parsed into an easy to use javascript object.

Once I've finished work for the day I'll try and write some documentation tonight and give a quick demo somewhere

The main benefit that I see over things like PRISM and pyinsim is that it's non-blocking by default, meaning you dont have to worry about yielding, or threads and the sync issues you get. By default all plugins can support as many servers as you've got in your config file. This combined with the other features that nodejs supports out of the box means you can very easily write things like an entirely in-memory live tracker (i.e. no DB, ActiveMQ, or other message queue or RPC), including InSim connection(s) and HTTP server, all in less than a few hundred lines of plugin That's the bit I find really cool

The other interesting thing, is that as its written in javascript it would be possible to do a little fiddling and port it to use websockets, which means given a sufficiently modern browser, you can get an insim connection directly from your browser, to your server. Could be very interesting for a control panel, perhaps (something I hadn't thought about.. hmmm).

I've got the nodejs bug at the moment after using it for a demo project at work and wanted something to play with at home

Ladies and gents,

I present the first stable-ish, but not-yet-complete, version of the eXtensible InSim client 4 Nodejs. As usual I'm throwing it out there early partly incase any other ****er has been working on it, and partly because it may be interesting to someone else.

It maybe used as a standalone "executable" (still requires nodejs) or as a library. Theoretically if the node sockets are swapped out, for socket.io it could also be used within a web browser - altho that would mean it leaks your admin password in a very public way.

Call it a "developer preview" rather than a finished product.

It was my 2 days off between Christmas and New Year project, but it's kinda grown a bit

I still plan on working on it for a bit as it's proving to be a useful distraction from work in the evenings at the moment.

As a bit of background, it's much like luaLFS was with "subscriptions" or hooks to functions, but more complete at this point. It also takes some inspiration from the awesome PRISM, but with some Javascript orientated bits slapped on top.

README has a lot of info it in at the moment, including some basic usage. I've not documented much other than that yet. If you are planning on playing with it at this stage that main thing not mentioned is that I take explicit advantage of being able to manipulate "this" when plugins functions are called, giving easy access to the client connection, insim packet definitions, and the logger.

I just wanna say a quick bit of thanks to the guys who run the cargame.nl servers as I've been testing xi4n locally whilst connected to that, and doing 90 second sprints of furious debugging between races Also thanks for reminding me how much fun LFS can be

Quote from Dygear :

I wonder if we can use the HTML5's File-API and JavaScript Typed Arrays to read the data directly from the PTH file.

Should be feasible, but impractical given that not all browsers support either very well/at all.

The main problem I had with using a full pth file (after translation to json) was the sheer number of nodes caused the browser to go mental for a while. I will admit I didn't bother investigating whether that was down to d3 translating the points, or if it was parsing the JSON or something else. I just cut down the number of nodes and moved on to more interesting things.

Given how few live trackers there seem to be outside of LFS remote, which is flash based, I figured it may be useful to someone else. Think I actually spent more time writing the comments cogently, than anything else tbh.

If anyone wants to play further I'm not gonna stop them, but it's done what I wanted at the time and I'm probably not going to do much more on this until I've finished playing with the "other (related) project" - if at all

Last edited by the_angry_angel, Fri, 6 Jan 2012 17:51.

Quote from mcgas001 :

Hey Karl, good to see your still fiddling with LFS.

Blame the lack of work over the winter holiday and wanting to shut myself away from the world First time I've even touched LFS since I got rid of the wheel a few years ago really. Glad to see the forums haven't changed from their normal bitchy nature

Quote from mcgas001 :

How you been?

Not bad, nowt interesting since we last spoke. Just lots of work and a mostly other non-LFS side projects here and there

How are you? Well?

Good afternoon chaps,

This winter holiday season I've been playing a bit of LFS and fiddling with nodejs and insim (another project). As part of making that project useful I've also been playing with d3.js, which can be used to draw and manipulate svg data.

The basic premise of this afternoon was that I wanted to draw a rough interpretation of a LFS track. The link below is the fruits of my work.

https://github.com/theangryangel/LFS-.pth---d3.js

I'm using it in conjunction with the nodejs insim client I'm fiddling with to produce a basic ajax based live tracker. Figured someone else might have a use for it as well.

If you do intend on using it, please be aware that I've not included d3.min.js (available from http://mbostock.github.com/d3/) and there are a couple of caveats, most notably:

• Track doesn't match the same orientation as LFS - could be acheived reasonably easily using a transform
  
• Doesn't take into account the actual track width - only uses the center coordinates
  

Despite these draw backs, I think it's good enough for my purposes, and hopefully good enough if anyone else wants to use it.

I've included my own converted pth files, and the implementation I used to convert them. The converted pth files are at 1/6th the "resolution" of the originals as I found that there were just too many data points.

Example image of what it looks out, out of the box, attached.

Last edited by the_angry_angel, Mon, 2 Jan 2012 15:46.

Unfortunately I haven't gone looking for the server package yet, but I'll see what I can dig up I believe that the rcon protocol hasn't changed, so that documentation should still be fine. But, I've not tested it so don't take that as gospel

Assuming it's not moved by the time you see it - http://static.cdn.ea.com/dice/ ... s_ServerAdministrator.zip The file you care about most is probably "BF3 PC Server Remote Administration Protocol.pdf" and the corresponding changes file

Have thought about it a few times. Specially in the context of nodejs, rather than web browser based though. However architected right the same library could be used anywhere javascript runs.

Regardless https://github.com/pgriess/node-jspack might be interesting if someone is considering taking this somewhere and is familiar with perl/php's pack/unpack.

I've got a couple of other bits and bobs that I'd squirreled away as notes, but I cannot seem to lay my hands on them right this second

There's another option as well, which would compliment a bayesian-style points/training system, and that's one of waiting until the end of a race, then looking at each lap time.

You then compare each racer's average lap time against the average for all racers, across the entire race. If we suspect them of cheating by being an order of magnitude faster than the average you could drop in a sanity check, by looking at their LFSW stats.

A racer with lots of races under the belt, and consistently fast times across all tracks, are less likely to cheat than newer players with fewer races. It also gives you a benchmark as to their prior performance.

It's a bit simplistic and it allows the cheaters to potentially cheat throughout the race, however at the end they could/will be banned for life/x days/whatever. You/we/I could probably do a nice mathematical model on it, based on how much you expect a racer to beat another racer, store that info, and so on. However I'm afraid that's a bit beyond my 'saturday brain', this morning.

The only large issue is the long standing problem of the subtle cheater, but tbh I'm not sure if a subtle cheater is someone you're ever going to be able to reliably catch.

Or the other option is that the server becomes more authoritive over the max acceleration, governs collisions, etc.

I assume I'm right then

My perspective on the problem is that the fire alarms were tripped on the UPS floor. Power was suspended and the fire department called. I've been told that 3 out of the 5 UPS' failed to take the load, resulting in the loss of power to the data floors. Generators kicked in later. There was probably a good 30 minutes-1 hour of downtime going by my own boxes.

The UPS manufacturer is/was on-site and I believe they've diagnosed 1 of the UPS' as having a fault. Smoke from that UPS caused the fire alarm to trip.

They may still be on generator power, but I've not had anyone confirm that. I don't know any more than that.

Long and short, it wasn't the fault of 500servers. A lot of businesses were affected by this, a lot more pissed off than you guys. Trust me.

I'm not sure if Franky still has his boxes with the same people that he used to, however if he does the DC that they're hosted in are currently experiencing power issues.

Quote from GeForz :

readme.txt?

Quite. Totally missed that in the wall-of-text somehow

I had the need for ANSI colours under Windows this week on another project. Rather than do anything too funky I've cheated and used ANSICon (see https://github.com/adoxa/ansicon) with the "-p" argument.

The only problem is the license. It's classified as "freeware" but I've not managed to verify anything about redistribution rights, etc. It may help.

Sounds a bit like popularity-contest - awesome idea

Their (facebook) change notification for the APIs is shite. As soon as you finish a project the ****ers change things and X or Y is broken. Personally I wouldn't bother on a personal project ever again, but thats just me

Who knows, maybe they've decided to have a stable API for something longer than 10 minutes in the last few months.

Quote from KassadGLA :

my friend Dalmako have the same problem, he ask a simple question and nobody help

I've just done a search posts made by Dalmako under LFS Programmer Forum and child forums.

2 threads, both with responses. Saying he got no reply isn't entirely valid. I won't dispute that it may not be the answer he was asking for though.

• http://www.lfsforum.net/showthread.php?t=60820
  
• http://www.lfsforum.net/showthread.php?t=60748
  

You're right that not every request for help gets an answer, but don't forget that:

1. The people who reply aren't being paid to help
   
2. The people who reply are generally not LFS developers (you may occasionally get help from the devs, but it's relatively rare outside of PRISM and the the LFSWorld API)
   

My point is that the people who are answering are almost always doing it own time, for free. Many of which don't visit the forums every day. Some only visit every few days.

The other reason you may not have been given an answer is because you've only provided partial snippets of code. It's all well and good if your code is doing the right thing, provided your variables are all in the right scope, etc. which you can't tell from very small snippets without the surrounding code.

I'm not being nasty. All I'm trying to say is that the expectations of help are a bit unreasonable sometimes.

More to the point, if everyone posted their solution there would be a lot fewer of the same questions over and over and over and over and over and over..

Quote from Victor :

So, do not make the players object a property of the clients (connections) object. That won't work. You want a separate list for both connections and players. One reason for this is that a connection can have multiple players.

It may be helpful to plugin writers, especially, if the core were to have a cross reference between the two.
i.e. connection object has a variable and methods to get the player id, or player object and vice versa.

Could be a bit of a pain in the bum to keep in sync sometimes (takeovers for example), but it is very easy to use and determine if a connection is an active player...

Or possibly PRISM abstracts the concept of player and connections totally. Not entirely sure on where I'm going with this as I'm just off to bed and its just popped into my head as I'm typing this, but there could be something very elegant hiding away, if its even remotely sane (which is entirely tenuous given the time and the day I've had so far)

Last edited by the_angry_angel, Mon, 20 Sep 2010 22:54.

Don't forget that CPU load on *ix doesn't equate directly to utilisation as windows understands it Load is more to do with how much stuff is waiting rather than how much work the CPU is actually doing, if that makes sense?

However, using the COM extension (http://uk3.php.net/manual/en/book.com.php) you could query the WMI without using exec(), and just barf if the extension isn't loaded (http://uk.php.net/extension_loaded), although most windows versions of PHP should have it by default, unless it's been custom compiled


That'll work fine if you're using a regular user account like you would be with PRISM (well, tested with a w2003 box, I've not got a w2008 box spun up right this second, but I don't see why it wouldn't work - I'm not aware of any changes in the default perms for WMI under that).

However, if you want to run that as your webserver user, unless you're running your webserver with access to the WMI it'll fail like a bastard. For example, using IIS with an anonymous user the WMI root/cimv2 permissions would need the IUSR_MACHINENAME or IUSR account added with remote enable permissions.

There are, naturally, possible security problems in making your webserver able to poke at WMI

Quote from Fire_optikz001 :

oh :3 ok

*fluffles* Just a reminder Fire_optikz001 you're using something very bleeding edge - although it's good to be involved early on with projects (wish I could lend some time to this tbh ) Although I'm sure you know this, and I apologise with a galactic heap of... something nice.. Kitties? - keep in mind that the api will almost certainly change relatively rapidly and things could be very b0rked I'm not trying to discourage you, infact quite the opposite. I salute you Sir!

Dygear, etc. regarding the function/class arguments, might be worth checking out and adopting how the Zend Framework, Symfony, Doctrine, and many other high profile PHP projects deal with that problem, and basically that's 2 ways - argument #1 can generally be an instance of SomeClassName_Config or an associative array. In both instances you can make a simple loop that iterates over the "named" arguments and assigns or transforms them as necessary Very effective and easy to deal with, and very quickly generalised, as well as lightweight.

Last edited by the_angry_angel, Tue, 7 Sep 2010 21:55.

Might be worth adding /reinit to the admin flags.

Here's my understanding - if I'm wrong I'll love to be corrected. However, until that point it's analogy time That's right kids.

Think of a LFS server being controlled by PRISM as an IRC channel. In a channel each user can be assigned a bunch of flags, such as +o for oper, +v for voice, and so on. The flags that Dygear's put in the first post are the equivilent flags for a user in a LFS server.

PRISM will then have an internal record, like an IRC server, of what flags each user (or in this case LFS connection - not player) and the appropriate functions will have ACL checks built into them.

Hmm, the way I'd read that it sounds like whoever wrote that doesn't appear to understand the difference between copyright and source code licensing. I do understand what was probably meant by the statement tho I apologise for suggesting something that doesn't fit the request

Maybe worth contributing to http://www.racer.nl/. I have no idea what the state of the code is, however I am led to believe that the lead is employed by an F1 team and that the core of the code is used by the same F1 team.