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.

That's not a bad idea. I like flexibility in general.

One thing, for every new idea, it should be in it's own thread with the title [RFC] and then a one line description of the idea.

Your other option is single player, and that's where I do most of my practicing.

OutGauge is only for local information. You'd have to have every client on the server route their OutGauge packet information to your OG / InSim client. This _can_ be done, however, it most cases setting up OutGuage is not a part of the expected setup for a race. The best bet would be a IS_CSC packet for CarStateChange, where it could notify the server of a change to the car such as break bias or traction control turning on / off.

Something along the lines of the OutGuage Packet into a InSim Packet.

Last edited by Dygear, Sat, 4 Oct 2014 06:35.

24 fps is the minimum that anyone can watch and get the sense of continuous motion, going from 24 to 30 fps is not that much better, but from 30 too 60 fps is a pretty big leap in visual fidelity for me at least. Going from 60 too 120 is pretty much perfect as to what my eyes can perceive and I've not noticed any change to an image generated from 120 too 144hz and I've not seen any true 240 hz screens with 240 hz content so I can't say much about that.

Max: 1001 FPS
Avg: 975.022 FPS
Min: 749 FPS



When you say you've maxed everything? Does that include the DSR (Dynamic Super Resolution) setting, what is that set to? I would love to know if your rendering at 4k but then downscaling too 1080p. If your getting that FPS with the DSR setting on, that would be amazing. What's the rest of your system specs for reference?

IP Address discussion has been moved to the following thread ... [RFC] InSim IP Address Information

Quote from Scawen :

About language, would anyone not want their language revealed or can we just forget about that? I guess if they don't want to reveal their language, they'd better select English before joining a host.

Host doesn't know guest's language in any way at the moment so it's not just as simple as adding a byte, Guests will need to transmit this info to host on connection. Not hard but just saying, it's not a 1 minute job.

Last edited by Flame CZE, Thu, 2 Oct 2014 12:20.

Victor, can you please fix tabs being stripped out within the [code] tags. It's making quite a bit of my code look ugly. (Besides the code it's self looking ugly, ergo it needs all the help it can get.)

Quote from Flame CZE :

In general, it's better to post the bugs into the Bugs - Websites section, as they usually get lost or forgotten among other posts in this thread.

Thank you for the reminder.

Quote from cargame.nl :

Do you have an option to split or do I need to remove some text and create new topic?

// I have to say I am not that good in making good introduction postings.

I've requested Moderator power for the Programmer Forum, hopefully I'll be able to do it. Otherwise I'm hoping that a current mod will pick up the change. And I should be able, built the next RFC regarding getting IP address from Scawen's remarks now that we have a direction.