Vic, any chance of adding WebSocket support as a module to PRISM and making it available too the Plugins in the same way we offer the InSim Packets?

Quote from Victor :

Quote from three_jump :

Quote from Victor :

[...] and I'm aiming to introduce the first version very soon.

(I'm very sorry Vic, but I just couldn't resist )

I realised it when i wrote it, but as i've taken some time off of other work to work on this stuff, I dared saying it

I'll keep the pitch forks handy, UNLESS you want to take a stab at adding WebSockets support to PRISM. I understand that you have a solution that's awesome that you use here on this site.

You are never going to get help if you're going to be a dick.

Looking at the qualifying session for F1 this year, and it looks like the F1 overlays should be quite easy to recreate 1 for 1 in LFS using the InSim button system we already have. The F1 website has also done a pretty good job of making this information accessible in a HTML5 format, making it much more accessible then their previous Java effort.

Now that we are waiting for an incompatible patch, is there any chance we can get some InSim Changes implemented?

[RFC] InSim Language Information
[RFC] Insim - variable size IS_MSO
[RFC] Make IS_PLC Two Way
[RFC] IP Address Information In InSim

Quote from GAVD999 :

Quote from Dygear :

Rule out bad RAM, run MemTest86 to be sure it's not a fault there. It sounds to me like a RAM issue. I had something similar with my computer no to long ago. Good news is, if they are Corsair sticks you can RMA them as they are covered for life.

Thanks Dygear, ran that and no errors at all. Have just completely reinstalled a fresh LFS and then tried G3 again and it seems to be working fine now.. Guess something was just bugged when I patched my old install?

Error's happen, in transit, on disk, or in memory. Looks like it was one of the other two this time.

Quote from Scawen :

Quote from GAVD999 :

Re booted, swapped back to G3 again and it is still giving me that crash then starting up fine.

That is strange! I can't think what to say! Haven't heard of anything like that before...

Rule out bad RAM, run MemTest86 to be sure it's not a fault there. It sounds to me like a RAM issue. I had something similar with my computer no to long ago. Good news is, if they are Corsair sticks you can RMA them as they are covered for life.

Odd bug that I can't reproduce. I choose SO6X, on the BF1 and start my lap. I get a false start of 30 seconds and do a whole lap with that (never going below 100FPS BTW, So nice work there). I get to the end of the lap and Ctrl + S, spectate. I then do not have my skin (The default BF1 skin of the BMW Sauber race car) is no longer there. I load back into the race, inside the cockpit I see the inside of the skin, outside of the cockpit, I change view to the race TV camera, and I don't have a skin it's just white. I Ctrl + S again, and the skin is back.

Tried to reproduce this, and I can't. Might of been a fluke.

Quote from PoVo :

I see that pyinsim 3.0.0 is in the repository but the latest released version is 2.0.5. Does anyone know if the 3.0.0 version works okay?

I have no idea, try it out and let us know! I would think it's in an alpha state, I seem to recall a conversation with DarkTimes about it from _quite_ a while ago.

How is it going, Scawen?

Crazy talk, Black and Silver with Orange lipstick are a drop dead gorgeous combination.

Unfortunately, the GPL is insidious by design. This is part of the reason why I use the MIT license on my projects.

Scawen, now that the VAT MOSS crap is behind you guys, how is the patch coming along?

Regarding the new pathing system, what exactly is the plan here? It's possible to have multiple paths from multiple sections of track? The path files themselves would be updated on a some what regular basis based on the current WR hot lap path on a per car basis? I'm grasping at straws here because I really have no idea what I'm to expect from this system. I already have a pth file parser, so I'm wondering what I'm going to have to do to it to get this new information, and how often.

The same old advice of "Simply learn how to program." is not really good advice for most people. Myself, and I'm sure many of the other InSim Add-on Devs have done a lot of work to decrease the barrier of entry into getting an InSim instance up and running on any given server, but it's still quite complex for someone who is not in the know.

I would say that PRISM would offer the least amount of work to go from Source Code too Running InSim Instance. What we could do is a video series of how to setup each of the InSim instances, and how to make basic code adjustments. The goal would be teaching a man to fish (eats for a lifetime), vs giving a man a fish (eats for a day).

IF I should get some time in the next 48 hours, I might be able to do that for you, but that's a pretty big if. It should include to be helpful, installation of the runtime environment installation of the InSim instance and any configuration changes that must be made to the LFS config files. From there, it would give short instructions on how to setup a plugin and modify it.

Vic, can we get a glyph map for the LFS Font?

Do you have anything pressing that needs to be added also into the patch, if so, I guess now is a good time to do it.

As far as I'm concerned T3, your running this show.

To many InSim instances connected to that server, I would think.

I guess you could make a quick plugin for PRISM that would count the number of LAP packets you get for each PLID, and just don't reset it until the session is over. That would tell you the true number of laps done by each player. But if that is the case, you'd might as well also throw out the timing and scoring board as well, because only the application would know the true number of laps done according to your own rule set, and thus you might run into a situation on a 1000 lap race, where some clients are truely doing more laps that then because of a reset. That would effectively change the order of the cars for the finish position as well.

It would be nice if we could ping scawen and make him pay attention to these threads.

That's interesting, I did not know that anyone could add their own language files. I figured that what was on the screen to the right side when you first start the game was the only options. I'm thinking if this is the case, we would need an official set of languages (the ones shipped with the game) as the canonical set. Then if people want to add to their own translations later they could use the same mechanisms within our InSim applications. This pretty much means that it's going to have to be a string, and therefore will not fit into the NCN packet in it's current form. I very much wonder what Scawen will make of all of this.

Quote from cargame.nl :

Well.. Hmm.. If language revelation can be something to bully/racist about then there could be an option "do not reveal this to online servers" somewhere? If the InSim don't get this info it can go to any default mode?

Something like language not disclosed or 0. Defaulting to English is not that great, it could give a false assumption that somebody understands English while it's not the case.

I was going to put this up for a vote, then I realized that there still are two open questions.

We still have to discuss what to do when a person does not want to disclose their information. For this I propose that the first value within the Language ENUM is LANG_UNDISCLOSED. Making it the first item in the list just makes it easier should we add more languages to support later on. Within the UI, a checkbox asking if they want this information disclosed to the server (that is unchecked by default) should be made available.

On the other hand, why even consider this? Is there ever going to be a point in time, where you want the game's UI to show information in one language, and the InSim Application to show the information in another? So, I think that's kind of a moot point.

My second question is too Scawen, and how does the game internally store the user's Language information? Is it a ENUM, or is it a string, or something else? Ideally, for your code base, you'd simply just bolt on that too the NCN packet.

This is the area you wanted to post in, buddy. And you can get S2 by going to the Licensing Page

FYI, I'm going to put this up for a vote in a few days, the vote will last for two weeks. If anyone has any comments, please make them now.

Quote from DANIEL-CRO :

Quote from Dygear :

I guess my point is, does it add unnecessary complexity to the packet parser for no real world benefit.

Every insim which is written by the specification of InSim (TCP) will handle it with no problems.
First byte of every insim packet is Size (Header), so you should simply always remove Size number of bytes from buffer.
In my opinion there isn't even 'c' of complexity ...

In PRISM we peek a headers first, then read the packet based off the header's signature. There are currently two types of string parsers in the PRISM code base that handle packing and unpacking of the string into the packet because of how they are handled when it comes to packet length requirements and NULL termination vs no NULL termination. Anything that brings that code base down into a more generic form is better for me as it would be able to handle it in a single master class that could be inherited too the other packet classes.

That's the verbose way of saying, +1, I'm for it. But I wonder if other programming languages would be benefited or not from this?

Did you include the requisite for padding up to a length that is divisible by 4 on the packet length by padding the text field? Although a drop by over 50% is impressive is there a situation where this is needed, edge connections running an InSim client?

I guess my point is, does it add unnecessary complexity to the packet parser for no real world benefit.

[Edit] I guess from a parser standpoint, having all of the Text and Msg fields parsed by the same bit of code would be a nice homogenization from a code stand point.