I had made an example long time ago, im sure it can be improved and optimised, but you can give it a try.

https://www.lfsforum.net/showt ... php?p=1651859#post1651859

I have this replay for over a month but i always was doing something and forget about that. His nickname is/was V-Tec Steve and it looks like he had more horse power or something. His throttle is in the middle and he still accelerates faster.

Funny thing is that i was the only one who noticed he was cheating! Replay in attachment.

I think you mean Players.Count, but still this wouldn't be accurate as when i player goes in pits, he will still have a player id. What you can do is to store X and Y and check

Players.Count which Player.X and Player.Y != 0

Quote from dawesdust_12 :

LFS only allows the developer of an Insim application to register a single-character prefix at connection time (I believe), which from that point on will be sent to application and not displayed.

You are not able to block arbitrary messages or messages from one specific user. LFS does it automatically with your chosen prefix.

The thing is that if a user isn't using a prefix, but you want to mute it, there's no way to do this. And this was the first thing i suggested when client-server chat messages introduced into the last version. A mute command or something like %% for prefix where it would accept all messages and then developers will make their own chat using /msg.

LFS/docs/insim.txt

This file contains all packets and documentation on what each returns so you can easily find out how to use them.

From the file:

One more thing i noticed. If your LFS is NOT using VSync, then screen turns black and you can barely see the background of the process. Everything works properly though, you can still click on buttons, for example Exit to close the program.

Frame Limiter doesn't change anything, so there has to be something with VSync and Full screen. Cause windows mode works with no issues at all even with VSync off.

Tried it yesterday and it looked just unbelievable! I started working on a project called Drift Profiler which (at least i aim for) to be similar with this GUI
http://www.youtube.com/watch?v=-7Bl-mNBlXs#at=57s
An animated user image including nickname, number and some extra info.

I noticed you said that it's no longer necessary to have the files in LFS root folder. The funny thing is that yesterday i didn't read the rest of the thread but just downloaded it and the only thing i didn't like was this!

Also a small suggestion. Is it possible to make the /ext folder more "dynamic"? Like choosing your own .png files, maybe the folder as well.

Are you planning on releasing your new version soon? I'd love to continue working on my project using your last version.

Awesome work once again

Quote from Bose321 :

Those rims. Remove them from your HDD. Now.

I like them. But i noticed it wasn't shiny at all, but just black after the render which took 2h46m(On my 2core cpu. I wonder how much would do on my 6core fx6100). So i was bored to redo it. I like the style of it, but the material was really wrong.

Found this showcase and wanted to make a similar in 3DS Max.
http://farm2.staticflickr.com/ ... 85569450_df056d4a8c_z.jpg
And here is the result. Everything modeled by me, except the XRT
http://i.imgur.com/1i6HAeT.jpg

My first scene, so be gentle

#define ISF_MSO_COLS 8 // bit 3 : keep colours in MSO text
@
ISI Flags.

I'll post this here as i see there are some differences in the way host works(for example skins and connecting packets).

Yesterday when i was doing some tests with an Insim. I noticed that even when you are in the pits, you are still sending MCI packets (X and Y position values were 0, didn't have enough time to check the others). Is this neccesary? I know that the 'player' slot is still there unless you go to spectators, but if you are in pits, i believe there's no need to send more MCI info, so i guess this will make the bandwidth work a bit better as well if it gets removed.

_players[TOC.PLID].UCID = TOC.NewUCID;
_players[TOC.PLID].PName = _connections[TOC.NewUCID].PName;

This is the code i use for Take Over Control packet.

Quote from MadCatX :

Because the previous attempt to get to the bottom of this has been unsuccessful, I uploaded a modified version of the testing tool.

- It is now possible to set the delay as low as 1 msec
- The tool can now use DirectInput as well as raw access. DirectInput accesses the wheel in the same manner as the G27LEDs mod.

See the original post for download link.

Looks like we've got some progress
Using DirectInput and setting the right delay(i think it's the RPM one as it's under the rpm states) under 16, makes the wheel accept only the first ffb effect(go left) and then it keeps staying there idle. While still running, if i increase it by one click from 15 back to 16, it makes the FFB work again.

Good luck!

It still worked, even without having any leds on.
Also it was possible to set custom patterns, for example having only the 3rd led on. This looked so cool!

I can't seem to understand what exactly the problem is. But i'm sure it's something similar to that. At least for LFS. Because whenever my rpm was low, so i had no leds on, i had no ffb as well.

Quote from MadCatX :

In an attempt to fix the force feedback issue some users reported I created a simple tool to test if the problem is triggered by the control commands being sent too fast.

Usage:
- Download VC++ 2012 libraries here (unless you have them already)
- Download the tool itself here.
- Launch the tool and set up the periodic effect and LEDs. Default settings should be fine for a first test.
- Click "Start", your wheel should begin to periodically turn left and right and the LEDs should start to blink in the pattern you have set.
- Try decreasing the "Update delay" values for both the FFB effect and LEDs and see if you can duplicate the problem.
- "Update delay" values can be edited on the fly, effect parameters and LED patterns cannot, you have to restart the effect.

This tool bypasses the Logitech drivers and sends raw commands to the wheel. Although they are believed to be fine, I take no responsibility for any hardware damage this tool could theoretically cause.

I've set delay(both delays cause there are 2 for a strange reason) to 8 and it was still working.

I guess it's like that because you also send the force feedback effect. But in LFS you only send RPM effect.

Also as i have said, if there are no RPM leds on, there's no FFB on as well. So maybe you have to somehow make the wheel "accept" FFB effect even when you are not sending the RPM one. But this is weird because with FPS limit at 100 fps, everything was working fine...

EDIT: I had to install x86 libraries even though i have x64 bit windows.

Quote from MadCatX :

Is the FFB problem in any way similar to this or this? If the problem became considerably worse with 1.99 versions, I have a theory why this could happen. It might be interesting to see if limiting framerate in LFS to say 50 makes any improvement.

After reading both topics it seems that,

If i have FPS Limit and VSync off, FFB only works at least when the first green led is ON. So if there are no leds on, FFB is also off.

But if i use FPS Limit, even on 100 which is the max LFS can go, FFB works nicely.

Good luck on fixing it

Finally back on my pc

The problem i had with the strange FFB Effects still exist... Like keeping the wheel at the left side or having less force in transfers between left and right.

RPMs are working nicely same with the pit limited thing. Still i'd love to have the program "portable" though!

So, is it a cone, or a BF1? And since when is it a cone? Also wouldn't it have correct collision(possible uphill) if you replace it with a solid object like a barrier/ramp/armco/banner?

Quote from MadCatX :

Although that would be much more reliable solution than version string matching, it still has all the major disadvantages I dislike about the previous approach.

Like having to find all the car and rpm addresses? Because i liked it just having a dll and can run lfs through external sites, like lfsw.

Anyway, i tested the new version and it worked perfectly. It looks like the password was causing the problem.

As always though there is a big BUT. I noticed some strange FFB effects especially after you leave pits for ~3 seconds, but i think some of them still existed after that.

Quote from MadCatX :

It is not as simple is it looks because even the LFS version string doesn't have a fixed position in the memory. If the OutGauge buffer becomes allocated dynamically at some point, it will make the whole thing even more obnoxious. Current approach is universal and it will work with anything as long as the OutGauge packet format remains unchanged. It will operate as seamlessly as the previous version did once it's finished.

I've been thinking again about this and i found a solution. What if you MD5 the LFS.exe ? And have each MD5 as a version number.

Quote from MadCatX :

My guess would be that the crash on the first attempt left the network sockets open which is why the controlling app couldn't connect to LFS. Can you try again after a reboot please?

This was and is happening each time i run the program. First time it crashes and the rest ones lfs works, but leds are frozen to either full lit or flashing.

Quote from MadCatX :

It is not as simple is it looks because even the LFS version string doesn't have a fixed position in the memory. If the OutGauge buffer becomes allocated dynamically at some point, it will make the whole thing even more obnoxious. Current approach is universal and it will work with anything as long as the OutGauge packet format remains unchanged. It will operate as seamlessly as the previous version did once it's finished.

I see...Well then an update with the 0.6E addresses(rpm and car) would be enough for me.

Quote from Flame CZE :

Whoops, sorry. I have no idea why I thought it had been fixed. I fixed the title

You've got confused because this was fixed for MPRs, but it's still working on SPRs.

Quote from MadCatX :

Can you reproduce the crash every time?

After the first crash, LFS runs fine.

It's still not working but now the problem seems to be the outgauge port(yes my ports are fine, 30000 for outgauge). The led lights stay frozen to either "all lit" or to "flashing".

In this log i've run the game 3 times, 1st with crash and 2nd, 3rd that run ok.

Quote from MadCatX :

Using InSim or OutGauge from within the proxy DLL is rather problematic which is why I decided not to go this way. The plan is to make the controlling application launch LFS automatically, but I need to sort out all possible problems before I begin with implementing some extra functionality.

Making it work like it was before would be good, you could simply make a "list" with each version's reversed address and load the correct one based on lfs version.

Quote from MadCatX :

Thanks. I reuploaded the mod and now it links only to files available in the MSVS 2012 redistributable package.

Installed MSVC 2012 and program now runs(before i had missing DLL)

BUT

Once i click at Run LFS, game crashes instantly

EDIT: Is it possible to make standalone version without the Helper app again?

Quote from josemspain :

It's not a crash report, but...
My last LFS version was 0.6B, updated to 0.6E.
I went to single player, tried to join the track and i got a CAR ERROR. I went to available cars and i saw that i just could take xfg, xrg or fbm.
So, "i'm at demo licence!" i thought. I took the XFG car, joined the track, made a few laps an recorded the replay.

What i get if i try to replay it is replay OOS ERROR

Once you updated your LFS, your license reverted back to demo, you have to re-activate it. That's why you got your error because your last used car was other than demo ones.