Pseudo-nodes for open layouts (KDTrees? Grids? Thoughts?)
Hi guys,
I'm fiddling with yet another xi4n plugin (a fully automatic TV director) - but I want it to work properly on tracks without nodes (i.e. BL1X).
One problem I want to solve is how to predict when something interesting is about to happen. For that I kinda need nodes to make what I want do-able in a practical sense - calculating the distance and closing speed between close players on the track, and doing it for all racers is just ridiculous (if you're not seeing why I suggest you run the numbers of calculating the distance between every racer on a 32 slot server, assuming it's full).
So I've come up with 2 solutions thus far for creating pseudo-nodes;
1. A basic grid system that basically rounds the racers x,y,z coords to the nearest "chunk" (at the moment about 20x20 in-game units/meters) and then I query all racers in that chunk. The problem is that it's really dumb and doesn't take into account the shape of the track, or cross overs (I could make it cleverer, by making it a 3D chunk to solve). It's pretty quick, however, but the real issue is that a chunk might only have a very small amount of track in it, because it doesn't take into account the shape of the track. I've put together a quick prototype and it sort of works, but because of the shape issue it's not good enough in my opinion. Increasing the size of the chunk makes things more usable, but still suffers from the same problem.
2. A 3 dimensional KD tree, built when the track is loaded, from the relevant track or layout PTH file - i.e. I take every Nth x,y,z coord from the PTH file and use that as the center point for my node). Using this I can actually get the players nearest a particular node with minimal calculations (thats the point of a KD tree). By grouping the racers every update I can make a pretty good assumption that the racers in the same pseudo node are actually racing each other. The problem is I don't fancy writing a 3D KD tree implementation this afternoon unless I absolutely have to, plus it requires a PTH file. More over, if you're on a remote insim connection, you don't get the PTH file thats loaded, so it would need to be a manual process selecting it - this seems a little sucky. The major benefit is that you really do get a pseudo node, like you would normally, and it's reasonably quick to determine which node a player is closest to. Generating the KD tree might be a little slow, but I think it'll be acceptable since it can probably be pre-calculated, or calculated on track load.
So I ask you, if you've thought about this even a little have you considered any options that I might've dismissed?
Bear in mind I've not got a compsci degree, so I'm acutely aware that I'm lacking in some of my structures knowledge and I'm kinda expecting that I've missed something.
Or have I just got hung up trying to create pseudo nodes and I'm missing something really obvious?
I'm fiddling with yet another xi4n plugin (a fully automatic TV director) - but I want it to work properly on tracks without nodes (i.e. BL1X).
One problem I want to solve is how to predict when something interesting is about to happen. For that I kinda need nodes to make what I want do-able in a practical sense - calculating the distance and closing speed between close players on the track, and doing it for all racers is just ridiculous (if you're not seeing why I suggest you run the numbers of calculating the distance between every racer on a 32 slot server, assuming it's full).
So I've come up with 2 solutions thus far for creating pseudo-nodes;
1. A basic grid system that basically rounds the racers x,y,z coords to the nearest "chunk" (at the moment about 20x20 in-game units/meters) and then I query all racers in that chunk. The problem is that it's really dumb and doesn't take into account the shape of the track, or cross overs (I could make it cleverer, by making it a 3D chunk to solve). It's pretty quick, however, but the real issue is that a chunk might only have a very small amount of track in it, because it doesn't take into account the shape of the track. I've put together a quick prototype and it sort of works, but because of the shape issue it's not good enough in my opinion. Increasing the size of the chunk makes things more usable, but still suffers from the same problem.
2. A 3 dimensional KD tree, built when the track is loaded, from the relevant track or layout PTH file - i.e. I take every Nth x,y,z coord from the PTH file and use that as the center point for my node). Using this I can actually get the players nearest a particular node with minimal calculations (thats the point of a KD tree). By grouping the racers every update I can make a pretty good assumption that the racers in the same pseudo node are actually racing each other. The problem is I don't fancy writing a 3D KD tree implementation this afternoon unless I absolutely have to, plus it requires a PTH file. More over, if you're on a remote insim connection, you don't get the PTH file thats loaded, so it would need to be a manual process selecting it - this seems a little sucky. The major benefit is that you really do get a pseudo node, like you would normally, and it's reasonably quick to determine which node a player is closest to. Generating the KD tree might be a little slow, but I think it'll be acceptable since it can probably be pre-calculated, or calculated on track load.
So I ask you, if you've thought about this even a little have you considered any options that I might've dismissed?
Bear in mind I've not got a compsci degree, so I'm acutely aware that I'm lacking in some of my structures knowledge and I'm kinda expecting that I've missed something.
Or have I just got hung up trying to create pseudo nodes and I'm missing something really obvious?
Last edited by the_angry_angel, .
Hi guys,
Just an update. If you'd rather this in video form there's another on the youtubes. It's not necessary to watch as it's just the same as what I've written here and visually there's not much difference
Just an update. If you'd rather this in video form there's another on the youtubes. It's not necessary to watch as it's just the same as what I've written here and visually there's not much difference
- I've bumped the version to 0.0.2 because of an API change.
- I've completely rewritten the livemap plugin - the original is now gone.
- Livemap2 depends on a generic state plugin, which makes livemap2 a lot simplier
- Livemap2 now understands the concept of layouts, and should attempt to load them - I've not yet managed to test that yet, but it should work
- Livemap2 is lower bandwidth
- Really basic LFS string support (translating codepages and colours)
- Translation to UTF8 is mostly working, but there are few characters that aren't quite right - I'm working on those
- Colour support, but needs tidying massively
- I want to add multiple output types, so you can auto-colour for the web, or for the console, or strip completely
- Translation to UTF8 is mostly working, but there are few characters that aren't quite right - I'm working on those
- Livemap2 has highlightable players (pretty sure that wasn't in the original)
- There are a couple of problems with either the livemap2 or state plugin, such as it occasionally not picking up players that have left, but I'm working on them.
Cheating really. The node runtime executable for windows is kind enough to add support for the normal ANSI escape codes that work on everything else, so I basically get ANSI colour support on Windows for free.
I don't really understand why Microsoft never brought that across from Windows 9x into NT land
There is ansihack, but I don't know if it works on modern versions of Windows. There is also ansicon (also on github), which I use for a couple of other projects both personal and at work, and is still updated
Cheers for the encouragement dude
It's definitely appreciated 
The example there isn't really doing anything but translating the insim packets into javascript objects and then basically proxying them to the browser and then theres some drawing going on - it's really not that hard, but thanks for the sentiment
I'm tempted to switch away from drawing using SVG at the moment, but I'll probably save that for much, much later. Maybe when webgl is a bit less crappy.
Aah, yes, so I see - there's the layout name in IS_AXI. Hadn't noticed that
That makes life a lot easier Cheers for the pointer dude I cheat and don't use any node info - only the X an Y coordinates from IS_MCI - you still seem to get them for custom layouts still. I've not tried drawing a custom track yet, but I don't see why it would be any different.. Or at least I hope not
Tonight I've been fiddling with translating LFS' strings into utf8, which is annoyingly tricky when javascript doesn't have anything suitable out of the box, and you start not really knowing anything about multi-byte character encoding. I've more or less got that sorted (although I really do want to murder someone who was involved with character encoding right now :tilt
and I want to pop that into the packet handler so you can easily translate from LFS' munged mess to utf8 - useful for the livemap to deal with LFS' mixed character sets on the web interface in standard HTML. I've got a bit of work to get it to that stage, but the basics seem to work now, which is nice.Next on my list, is setting up a general state manager that multiple plugins can use and then I'll get the livemap ported over to use that instead. It'll be a bit lighter on the bandwidth than the current version - which will be nice
Hopefully it'll help out with the browser CPU usage too Hoping to have a couple more hours before the weekend to try and get some of that done. Hopefully in a week or so time there'll be a nice, lower bandwidth, non-buggy version that can display most of the character sets LFS supports
Last edited by the_angry_angel, .
At the moment it relies on insim's IS_STA packets to determine the track, and for a custom track that's only ever something like BL1X, but I'm sure it could be figured out some how - maybe from the IS_MSO packets when the track is loaded.. I'll see what I can do
It could be added, again not something I've done - yet
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.
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
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
I really do enjoy playing on them, it's been a fun few weeks 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
XI4N - eXtensible Insim client 4 Nodejs
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
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 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, .
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 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?
Drawing LFS tracks using pth files and d3.js (& pth's converted to json)
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:
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.
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
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, .
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
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 gospelAssuming 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
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.
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.
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.
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.
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.
Who knows, maybe they've decided to have a stable API for something longer than 10 minutes in the last few months.
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.You're right that not every request for help gets an answer, but don't forget that:
- The people who reply aren't being paid to help
- 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)
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..
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, .
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
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
<?php
$obj = new COM ( 'winmgmts://./root/cimv2' );
$pc = 0;
foreach ( $obj->instancesof ( 'Win32_Processor' ) as $p )
printf("CPU%d @ %d%%", $pc++, $p->LoadPercentage);
?>
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
FGED GREDG RDFGDR GSFDG