You make a good point on the native types. The marshalling backwards and forth were a little bit unnecessary and tbh did cause a little bit of lag on slower PCs.
Sooooo, I reimplemented jspack into using the native typed arrays/arraybuffers whilst maintaining the same API (https://github.com/theangryangel/jspack-arraybuffer) and then updated lfswsrelay.js. It's much faster
I also implemented a way to register packets from other files...
I was bored this afternoon
Just need something useful to do with this now...
Sooooo, I reimplemented jspack into using the native typed arrays/arraybuffers whilst maintaining the same API (https://github.com/theangryangel/jspack-arraybuffer) and then updated lfswsrelay.js. It's much faster
I also implemented a way to register packets from other files...I was bored this afternoon
Just need something useful to do with this now...
Last edited by the_angry_angel, .
I've started throwing together an implementation for the relay over websockets - and popped the initial version onto github with an example of usage. The example only outputs to the console at the moment (and only supports 3 packets), but I'll put something better together tomorrow/wednesday night 
I'm happy to receive patches, etc. Competition is also welcome 
The major downside (in my opinion) is that there's a fair bit of marshalling between different array types, which could potentially use a bit of memory in a long running app. That said it could easily be ported to use the native types without changing the API at all, but I'm lazy
@dustin the idea of a modular API sounds interesting.. Were you thinking of registering packets after an instance of the client has been created? Or before?
I'm happy to receive patches, etc. Competition is also welcome The major downside (in my opinion) is that there's a fair bit of marshalling between different array types, which could potentially use a bit of memory in a long running app. That said it could easily be ported to use the native types without changing the API at all, but I'm lazy
@dustin the idea of a modular API sounds interesting.. Were you thinking of registering packets after an instance of the client has been created? Or before?
Last edited by the_angry_angel, .
Take a look at jspack. It doesn't use any of the new typed buffers, and thus isn't as efficient, but it does give you a very graceful API to work with and it's reliable. It means you can concentrate on making your actual app work
Admittedly I am a little biased on advocating jspack - I use the node-ified version in xi4n and also in the client side MPR parser demo
Admittedly I am a little biased on advocating jspack - I use the node-ified version in xi4n and also in the client side MPR parser demo
I don't really have the time to devote to help out with this (I wish you luck), but I do have a pile of MPR parsing code written in javascript (for the browser) that you're totally free to use (uses the HTML5 filereader API and jspack to pick it apart). It's unlikely I'm gonna finish what I had planned as I've had it sitting around for a while. I've cleaned it up and put it up on https://github.com/theangryangel/lfs-mpr-js-parser (A very quick video demo at http://youtu.be/u_seAK2rmuo).
The benefit here would be that you'd only have to send the data you need from the MPR, rather than the whole thing (so a few hundred KB, rather than a few MB - the larger the race the larger the MPR, but you still only want the header!). The negative is that only modern browsers support the FileReader API 
The only warning I probably need to give you is that the example is written with Angularjs, so it might be a little tricky to follow. The main magic is in js/controllers.js and lib/mpr.js
The benefit here would be that you'd only have to send the data you need from the MPR, rather than the whole thing (so a few hundred KB, rather than a few MB - the larger the race the larger the MPR, but you still only want the header!
). The negative is that only modern browsers support the FileReader API The only warning I probably need to give you is that the example is written with Angularjs, so it might be a little tricky to follow. The main magic is in js/controllers.js and lib/mpr.js
Last edited by the_angry_angel, .
You can sent a IS_TINY with the subtype set to TINY_NCN to re-request the connections (and therefore the usernames) at any time.
I'd suggest you look at InSim.txt in your LFS/docs directory, or http://en.lfsmanual.net/wiki/InSim.txt which details the underlying packets that pyinsim manages for you.
Relay will work with any server registered with the relay. I believe you can set up your server for relay via lfsworld.net. Bear in mind that the relay must be able to talk directly to your server in order to work correctly.
I'd suggest you look at InSim.txt in your LFS/docs directory, or http://en.lfsmanual.net/wiki/InSim.txt which details the underlying packets that pyinsim manages for you.
Relay will work with any server registered with the relay. I believe you can set up your server for relay via lfsworld.net. Bear in mind that the relay must be able to talk directly to your server in order to work correctly.
What language are you working with? Any particular packet you're having issues with?
Could anyone who has patched or fixed an issue in this version of PRISM you either PM me a list of stuff you've had to patch or pop them into this thread, or add them as issues in github and I'll try and test the problems, patch the offending code in my copy (if needed) and submit pull requests to get them into the next version. That way everyone benefits from the fixes.
Last edited by the_angry_angel, .
Cool. You want them individually per feature/fix, or are you happy as a bulk and cherry-picking?
The diff added that function..
I just moved the constructor code into it's own function (visual diff attached), so if that's the case then the constructor has always been broken and needs fixing in of itself!
Not many people using PRISM and those that are, probably aren't using restrictions much
Certainly not something I've played with whilst writing InSim stuff over the years... 
@Dygear - what's going on with PRISM? You still accepting pull requests, etc.? Don't wanna waste time if not..
I can't run PRISM & LFS from work to test this, but I can't see any other immediate reason for it (might be missing something between sandwich bites).
The monkey patch below should sort it (again, not tested as I can't do that here). Copy into your PRISM root and apply using git apply onNPL.patch
Edit: Forgot to say, this patch is against github's master branch.
Last edited by the_angry_angel, .
I could do it tomorrow, maybe about 19:00 UTC - today is a bit tricky tho
I dunno, there's plenty of scope for hiding then
It might make the first few infections take a few minutes, but the rate would probably increase until the last 1 or 2 This could be tackled with a time limit though Part of the original idea I have scribbled down is to give uninfected the ability to place a certain number of AutoX objects (via InSim). Uninfected could create barricades, etc. Yeah, but that's boring
Plus if someone comes rushing towards you, you really want to know if they're running away from an infected or if they're infected themselves InSim button interface would work, but where the fun in that?I've got a distant dream of writing a re-implementation of the server (and have had for quite a while) written in such a way that you can do way more than you can with InSim. I've started reverse engineering the protocols, but put the whole thing on hold until after the current round of test patch(es).
Donated Concepts & Ideas
Part of my problem in life is focusing on a project. I've got so many of them on the go and new ones squeeze out the old ones quite quickly. However, some of them could be really interesting to;
Wishlist: Some of the ideas above would be really augmented if the server could force certain things on the player - like setups, temporary name changes, prefixing the name (such as "^2*INFECTED*^9") or skin changes to an infected skin.
- Implement (we bit twiddlers all love a challenge)
- Provide to the community as a server/network of servers, and ultimately result in (a brief) boost in player numbers
- Infected: An open circuit is chosen at the start of a round. One person is selected to be the Patient Zero (first infected). All other players get a 10 second head start to go where-ever they like around the map. The infected can infect other players by hitting them. The winner is the last uninfected person. Bonus awesome for a live website that shows player positions, current infected, etc. (ala xi4n's livemap, but specifically for infected mode - so cooler infected icons for players, etc.)
- Last Racer Standing: Just like any FPS where you can player Last Man Standing. Gives great opportunities for custom layouts. Problematic is the reasonable determination of who the killer and victim are if you use IS_CON packets. You could do some ridiculous faux gun system, but it wouldn't work very well in my opinion.
- Hillclimb: A weekly rolling hillclimb layout, is selected. At the end of the week the fastest person "wins". There's a half-arsed xi4n plugin on github, that needs better persistence (was gonna swap out for juggledb), an a web gui.
- Rally Cross World Tour: There's not enough RallyX, lets be honest. It's ridiculously fun when you're not worried about your "safety rating". My original thought was a really low point-based license system to prevent blatent ramming, and to ensure that racers have some experience with the tracks at low speed, but such low requirements that they only take 3-5 races to gain the points to ensure that players can race with the vehicles that they want quickly.
Wishlist: Some of the ideas above would be really augmented if the server could force certain things on the player - like setups, temporary name changes, prefixing the name (such as "^2*INFECTED*^9") or skin changes to an infected skin.
No love for twitch? I'll check it out <3
I'll check it out <3Having moved work's colocated gear ~100 miles to a new DC last Sunday I hope that your move goes better than ours did.
Turns out that the old DC allows anyone onto the floor (news to me) and the other tosser who shared the other half of our rack apparently thought it was acceptable to use ridiculously lengthed cables. Glad we were moving after seeing that, but it was a pain to unrack between what can only be described as a cable waterfall.
On the other end our new provider had an inexperienced member of staff that was our only point of contact for 3 excruciating hours. They weren't properly prepared for our custom setup imho. Additionally 1 server planar board died - either in transit or from the power off - somehow
Great way to spend 12 hours working I'm sure I don't need to teach you, Victor and Eric how to suck eggs, but just incase lowered DNS TTLs a day before the move can help a lot
A very easy solution is to modify your buttons based GUI to send fewer buttons. Not perfect, but it's definitely an option....
Well that's crap =( I've had a brief look at PRISM's main loop and I'm not seeing an obvious patch - I'd have to fire up xdebug which I can't do right now.
I suppose an inline call to usleep in your button sending function is a possibility, the issue with that being obvious (backing up the main loop - although if you're not using positioning packets that may not even be an issue). Without re-architecting PRISM I can't see an immediate workaround if a low stream_select timeout is causing you issues, sadly
I suppose an inline call to usleep in your button sending function is a possibility, the issue with that being obvious (backing up the main loop - although if you're not using positioning packets that may not even be an issue). Without re-architecting PRISM I can't see an immediate workaround if a low stream_select timeout is causing you issues, sadly
Last edited by the_angry_angel, .
If I recall correctly PRISM has a timer capabilities - is that not suitable?
Very cool Would be nice if it kept the text un-squished, but having played with buttons I totally understand the issues with that :<
Anything else us non-cruisers may have missed being innovated? (That's not sarcasm, genuinely wondering)
Would be nice if it kept the text un-squished, but having played with buttons I totally understand the issues with that :<Anything else us non-cruisers may have missed being innovated?
(That's not sarcasm, genuinely wondering)Very cool Nice work dude 
Nice work dude Damn those crafty cruisers, stealing the very core concepts of slmbr. I am outrage!!!1111oneoneoneoneeleven
Edit: I wrote this at the end of a long, shitty shift. I apologise if it comes across as short and argumentative. That wasn't the intention.
In your example code you weren't using a named argument to refer to UCID (note the difference between 255 and the "Hello?" in the below quote, now checkout insim.py and look at the __init__ definition)
Therefore you are refering to ReqI since it's the first argument in the definition of IS_MTC. I assumed it was actual code you were using, I apologise. I should've read your mind.
In your example code you weren't using a named argument to refer to UCID (note the difference between 255 and the "Hello?" in the below quote, now checkout insim.py and look at the __init__ definition)
Therefore you are refering to ReqI since it's the first argument in the definition of IS_MTC. I assumed it was actual code you were using, I apologise. I should've read your mind.
Last edited by the_angry_angel, .
FGED GREDG RDFGDR GSFDG