livemap2.js has issues when running a replay in loop or perhaps between 2 races too,
that the track and results table is not cleared correctly,
so that after the 2nd start occasionally some additional players still shown on track and list from the end of the race before.

As suggested by @gu3st.

i.e. xi4n config . launches web app that can read and write config.yaml's.

As title.

Karl:

I've IRC'd you.. but I thought it's easier if I do something more proper.

If you (or me) create an app that requires MCI packets and Outgauge packets.. we will only ever receive Outgauge packets.

This is becuase if a UDP port is not set, LFS will send MCI to the TCP connection, however if a UDP port is set (for Outgauge).. the MCI packets are sent there where Outgauge is totally unprepared to handle them (as one would expect).

I was having these issues the other day with MCI packets (as you know).. and I've uncovered as to why this is happening.

Unfortunately, upon first glance.. this doesn't seem like a really easy fix (as it's kinda core to how LFS does everything).

Livemap2.js needs to support DNFs, IS_RES, etc.
By extension, should this really be supported by state.js? Probably.

There is a packet decoding failure that gets spammed to the log. Unknown packet.

There should be a config.d directory to allow multiple configuration files, which are auto-included and merged. This allows for better packaging.

For plugins

LFS relay support is needed.

Final version(s) of tv.js and tv2.js require this so I can do a proper head-to-head video on the 2 competing ideas.

The config the client loads is selective. We probably dont want to do that.

Re-parses, but does not update correctly.

I'm going to go fix all the lack of braces around single-line if's. It drives me fucking crazy when looking at any of the code and hinders readability.

👅

JSON files are hard for typical users. YAML?

Current plugin architecture does not easily permit per-connection settings or multiple instances of the same plugin, without the plugin having to resort to managing it's own settings in an overly complex manner.

i.e. 2 instances of livemap running on different ports, or multiple versions of a track rotation plugin with different sets of stuff.

Proposed fix:
Plugins should return a function object that a new object can be created for each set of settings.

Pros:

• Each plugin automatically gets it's own space to save state and options
• Plugins can still be associated with multiple connections

Cons:

• Requires all plugins to be updated
• Plugins become more difficult to write

Hi Karl:

A bit of a oblong way to send a message (hard to PM someone without an active LFSF account!, and Github doesn't have a good method to send a PM).

A NodeJS Insim thing is really cool. I looked at the (outdated) video on the forum.. and it looks really cool. I've recently had the pleasure of starting to learn Javascript seriously (not as a basic rollover scripting language as most people use it as) due to my job. I am really impressed with it!

Dustin

Would be nice to be able to embed livemap into other sites. Jsonp/CORS?

livemap2.js is already a pain in the bum to maintain. angular.js would be my preferred client side MVC.

Occasionally outputs the wrong track name (usually a number), and has issues with racers.
This breaks livemap2.js and the tv.js prototypes.

Hi!
When you install XI4N by npm you get 0.0.4 version which don't have many new features. Can you see what happened? I know that few days ago there were problems with npm, registry wan't working.

xi4n can pass through an incorrect prefix in the IS_ISI packet.

Having the ability to setup a socket to Node with Outgauge data being streamed would be really nice. Especially now that I have a nice pretty iPad, coding a web app gauge thing would be nice.

No documentation written yet. Needs to cover:

• Installing
• Customising config
• Updating
• Installing plugins
• Customising plugins
• Writing plugins

For example:

• Admin password
• MCI interval
• UDPPort
• IName

Relies on #10

When using a custom (i.e. not install) config path, some of the plugins don't work. This is due to their dependance on some of the core xi4n modules.

Either the Y coordinate needs to be flipped, or the SVG needs to be rotated (for laziness sake).

See for additional information:
http://www.lfsforum.net/showthread.php?p=1714954#post1714954

Master is broken, it shouldn't be. Development should be in branches, doooh :(

Allow to check for xi4n versions, max number of clients, etc. to prevent plugin and xi4n version related breakages.

Nodejs now supports ArrayBuffers, Dataviews, etc. This makes it feasible to get rid of jspack and switch to jspack-arraybuffer which uses native Dataview.

Depends on jspack-arraybuffer being tested and packaged for node.

package.json specifies *. This installs 3 now. Should probably fix that.

I manually installed xi4n 0.1.0 globally (I'm a daredevil I know) and are unable to use init.

I get a directory that looks like a weird hybrid of a boilerplate and an init. It has a plugins folder, but it doesn't have a config file.

It's bizzare.