Quote from nesrulz :

Cool.

That's amazing! Nice job Victor!

[edit] Waaiiit a minute! That means that Victor made an OpenGL render for Live For Speed. Hey. hey! Things are lookig up!

Last edited by Dygear, Sat, 6 Sep 2014 17:15.

Yeah, I'm also having the issue where it emails me for no apparent reason. I've not logged into the website in a few days and this was the only thread I've replied too. Now every like 12 hours, I get an update on what's going on, in this thread for no apparent reason. I don't want that. I did not even subscribe to it. Second question. Is this running vBulletin in the background, or is this Vic's code?

Quote from dawesdust_12 :

I couldn't log in at first. Had to reset password.

Dito, had the same issue. But nice job Victor, very nice job.

Thank you! Nice to see you active again!

Welcome back!

Scawen, if you get the time, could you look at some of the changes requested for InSim. We've made a thread regarding it in the Programmer's Forum. When you get around to it, we'd be glad to have the discussion with you there.

Quote from Dygear :

Here's an InSim packet that I'd like to see. IS_TRE (Tire)

struct ISP_TRE
{
byte Size; // 8
byte Type; // ISP_TRE
byte SubT; // Always 0
byte PLID; // Player ID of Client in Question

// Followings Byte's Value is From Contact Patch Defines;
byte DSF; // Driver Side Front
byte DSR; // Driver Side Rear
byte PSF; // Passenger Side Front
byte PSR; // Passenger Side Rear
}

#define TRE_TARMAC 0; // 0 - sent by the layout loading system only
#define TRE_OOB 1; // 1 - Tire is out of track bounds.
#define TRE_RUMBLE 2; // 2 - Tire on Rumble Strip.
#define TRE_GRASS 4; // 4 - Tire is on Grass.
#define TRE_SAND 8; // 8 - Tire is on Sand.

This packet would only be sent when there is a change of state. Could use useful for making a smarter lap invalidation system within an InSim application, outside of checking the client's cords being in the track's path. Mainly also useful on X and Y configs where there are no paths by default, we can then use this information as a backup.

Here is a copy of my proposal.

Quote from cargame.nl :

Quote from Dygear :

Here's an InSim packet that I'd like to see. IS_TRE (Tire)
Whats the difference with IS_HLV?

And to answer your question cargame, HLV invalidates laps, but does not give us information about the tires. Many times in this season of F1, they are talking about the number of tires going over and beyond the defined track limits (white lines). This packet will allow us to get that information and allow leagues to decide node by node (effectively better then corner by corner) what they wish to allow.

Quote from DarkKostas :

Or for more compact, it could be bitwise

Ah, I'm an idiot. I did not define them correctly, they were meant to be bitwise from the start. As you see in the comments, 1, 2, 4, 8, ect.

Here's an InSim packet that I'd like to see. IS_TRE (Tire)


This packet would only be sent when there is a change of state. Could use useful for making a smarter lap invalidation system within an InSim application, outside of checking the client's cords being in the track's path. Mainly also useful on X and Y configs where there are no paths by default, we can then use this information as a backup.

Hah! What are the odds that you happen to find a huge booth using LFS without a license!

Now that I'm a Certified Emergency Vehicle Operator Instructor (CEVO-I), I can tell you hands down, that racing in LFS helped me be a better driver, and helped me be a better racer and helped me be much calmer behind the wheel when I first got into an ambulance.

It's not going to happen for a very long time. Scawen has said it's going to happen after S3 is shipped, so that's awesome and I would LOVE to add my home town to LFS so that people can learn how to drive my Fire Districts on a Sim (Saves Gas, Saves Money, Saves Time) and we can even do drills with getting to the scene of an alarm as fast, but also as safe as you can.

I would LOVE to do this right now as I'm now the Chief of the Department and I can make this happen overnight if I could only get some more information about the game track format. I looked over the files in the past, and it should be possible to get 6.5 square kilometers into a file without overflowing the 32bit type limit. That would fit the north side of my Fire District no problem. Scawen if any of this interests you, please let me know. I would love to collaborate on this project. It could even be sold to other departments and make some money.

Quote from THE WIZARD DK :

thank you very much for that info

and thank you for this aswell

Yep, those instructions need to be sticked and wiki'd.

Quote from T3charmy :

Wrong kind of website... but I can make one of those too! Just give me a few days. :P

Edit: What exactly would you like on the website? One thing I thought about was server stats such as X amount of PRISM instances running on Y amount of LFS servers. various examples as well as a function list and how they're used. Also various things that can be done with PRISM etc.

I've shied away from doing documentation, because the API is not solid until 1.0. (I'll just wait for cargame to make a comment on how that will never happen.) I like the idea of the number of running instances that PRISM has running. I guess we could make a pingback plugin that gives us this stats, log information like Host Name, IP address, number of clients on the sever. It can update this information as client's leave / join.

Quote from T3charmy :

Also in other news... after going through my flash drive and finding multiple PRISM backups... I'm happy to say I found the new website that I made for PRISM a while back!

Oh! I own the domain PRISM.IO, send it over what you have and I'll put it on my web server. I'll give you SSH access once I'm setup.

Quote from T3charmy :

[including ability to use images]

Oh hell yes!

Quote from T3charmy :

Changes have been merged to repo. ZIP is ready for download: https://www.lfsforum.net/showt ... php?p=1843407#post1843407

You sir are awesome, thanks for merging them into my master branch as well!

Quote from DANIEL-CRO :

char PName[24]; // nickname

Oh yeah, you nailed that part tho.

Quote from DANIEL-CRO :

There wont be any insim changes in 0.6F.

1. You probably mean renaming by UCID, and playername is [24]. Would be nice in leagues and such, but thing that admins can rename players could often be abused.

2. +1

No, by PLID. You can't rename a client because their UName is set by their LFSW profile. But you can rename a Player that's spawed from a client.

Quote from cargame.nl :

And why? I think thats a bad idea. Controlling somebody else's name is not nice.

Tag protection, instead of kicking the client, you could rename them. If they have an offensive name, you can rename them. Bring everyone in line to a common format according to league rules.

Quote from DarkKostas :

What i'd like to see is a

struct IS_STC { //SeTCoordinates

That would be AWESOME!

Last edited by Dygear, Sat, 21 Jun 2014 15:42.

Before Scawen finishes up the E patch levels, does anyone want any changes to the InSim interface?

Being able to change the client's PName would be nice.


As would forcing a control scheme onto a client.

Last edited by Dygear, Sat, 21 Jun 2014 15:41.

T3, do you wanna hotfix this as .3?

No one is interested in this, huh? Oh well.

So, I've decided to learn how to program in SWIFT, Apple's new programming language. I think that the best way to learn about this new language and all of it's features is to program an InSim Application that will allow me to remotely administer LFS servers with a Remote Console. Effectively, it would give you the same view of the server that LFS' Dedicated Server window would give you. It would parse color codes, and correctly display them to the terminal and everything else that you would expect. I think that it should support connections through the LFS relay as well. Just wondering if anyone would want to learn SWIFT along with me. I'm going to setup a GitHub repo soon and start hacking away.

Pre-Recs:

• Must have an Mac OSX Developer Account
  • Must have access to Yosemite on your Mac.
  • Must Install XCode6
• Must have a GitHub Account

Last edited by Dygear, Tue, 10 Jun 2014 09:58.

The physics loop, if I remember correctly, runs at 2000 Hz.

[EDIT]

Quick search of the forums, says my memory is correct.

Quote from Scawen :

One example in LFS is the spring above the wheel which is supported by a tyre below. The wheel is light compared with those two large spring effects and can easily cause instability. That is the reason for LFS's high update rate of 2000 Hz in the sub-updates, which avoids the cars jumping up and down all on their own due to jumping wheels! You saw in the google video, at one point, in a crash when some vertices went a bit wrong.

What happens is you have some very stiff springs for the chassis members, supporting a node which let's say is 10 kg. The physics engine finds out in one update that the springs are stretched by 5 cm. Now the super string spring applies a force of [A LOT] to that 10 kg mass. So in the next update you find that 10 kg mass has gone maybe 10 metres away or whatever, when really it should only have moved a mm or so.

The update time steps must be small enough so that large force acting on the small mass at the node, doesn't push the node too far away.

Last edited by Dygear, Mon, 2 Jun 2014 09:56.

This whole thing is a terrible idea. You already have a user name, and you should never send passwords in clear text. You're going too have to do that because there is no way to obfuscate a password in the InSim protocol, outside of gaming through a VPN connection to your server and having all of your other clients as well.

Basically, this is only useful in one situation. When you have clients that are account hoping because they are getting banned for hacking / on cracked server and need a fresh account to get into the game.

That's kinda cool, keep it, even if it's a bug.