Quote from hyntty :

Also file transfer can be surprisingly difficult in certain situations - for example if you are in a corporate network with a lot of workstations and user accounts. I'm not even sure how it would be done in a Windows network, perhaps some Windows network admin could tell the most efficient way.

A combination of Active Directory Groups (although you can use individual users if you want a maintenance nightmare) and NTFS Access Control Lists. It's fairly straight-forward, but the existing tools for managing large file shares are somewhat lacking, so it can be time consuming. I recently wrote a program at work to make it considerably easier.

Quote from hyntty :

[...] Linux is a fantastic OS because you have a programmable shell to use. For example, if you have a lot of source code in several folders and say you are working on refactoring it. Let's say I want to look into each of the many files and individually search them to see if they reference a particular object. And if they do let's say I want to move or copy them somewhere else. Or look into the version history of these files. Or maybe I'm on my way to a code review and want to print these particular files. I'm not convinced you could do any of that on Windows and even if you could do one thing you wouldn't be able to modify the command as versatilely.

Windows PowerShell is actually quite a powerful command-line/scripting tool, although IMO many of the commands and names are rather convoluted (but then again, "grep" is fairly meaningless unless you already know what it does). Many of the basic Linux/Unix commands have aliases to their Windows equivalents, which can be handy for the lazy (me).

As for code refactoring, if you have all the source and are using c/c++/c#, Visual Studio is pretty damn good at refactoring an entire project these days.
Find (and replace, including RegEx) can be done across many files/folders in PowerShell with the right sequence of commands.
For source/version control, git's git wherever you use it, although Visual Studio has git integration now for those less commandline savvy.


Windows even has a package manager now (OneGet, again part of PowerShell), which is based loosely on Chocolatey, but is still in development. Visual Studio has had a package manager for a while (NuGet) which has proven very popular. It remains to be seen how people will take to OneGet, it's too early to tell.


Disclaimer: I'm not a Windows fanboy, just trying to be informative. I use both Windows and Linux regularly, though it is mostly Windows at work with Linux for a few tasks where it's more suited.

Somehow I forgot to include this bit in my last post:

Quote from Scawen :

The question is more like "Does minimum sleep 0 cause problems on some computers?"

Task scheduling has improved vastly in modern OSs and further improved now multi-core is common.

The last time I remember regularly having issues was a single core CPU on XP (don't think the various LFS sleep times made any difference back then though).
Somehow Chrome still manages to make my mouse cursor lag like a trooper (movement sometimes streched over 10+s) when it's loading multiple tabs, even on a quad-core on Win8.1, but Chrome's behaviour is far from a normal application/game though so there's not much to read into that.
FWIW, my old dual-core laptop that can barely run LFS anymore (it cries at Westhill ~6fps) seems to show no obvious difference with the various sleep modes. The only difference is a small framerate improvement on other tracks when min sleep is turned to 0. 1 and above seem to behave the same. It is GPU limited in Westhill rather than CPU limited though, so may be irrelevant.

Quote from Scawen :

Or maybe I should add a new option "windowed vertical sync" as well.

I remember that being accidentally forced to be on in the early DX9 test patches - it would be a useful feature IMO.

Quote from Scawen :

Is there a standard safe setting used by other games, limiting frame rate by default in some way?

The only frame rate limiting I know of is where the engine is tied to 30/60fps due to being a crappy console port.
Any sensible limits not tied to v-sync probably vary a lot depending on specific hardware combinations and personal cooling noise preferences.

Quote from Scawen :

I would be interested to hear from anyone who knows about G-sync and Freesync monitors and how they interact with the vertical sync option.

An interesting input lag investigation with V-Sync vs no V-Sync, FreeSync vs G-Sync at different target framerates: https://www.youtube.com/watch?v=MzHxhjcE0eQ
Jump to ~ 11:40 for graphs, although there is some interesting stuff earlier in the video.

If you're looking for real-world results, do your test searches in a private browser window - google will put LFS near the top if you've searched for it before.



Back on topic, I've noticed a bug: when placing chalk, it's invisible until I optimise the layout objects.

This is currently happening in H4 on Westhill; I haven't tested H2/3 or different tracks yet, but it's showing up fine to people on H.

Quote from nacim :

DX9 isn't old and DX12 will not magicaly make Westhill at 200 FPS for everyone.

DX9 was *replaced* with a major rewrite about 8.5 years ago. The original DX9 is over 13 years old and DX9c is 11.
So yes, it is indeed old in the context of computer software/hardware.

But you're correct that simply moving to DX12 probably won't magically make LFS run significantly faster. Just like moving LFS from 8 to 9 alone made no difference.


However, afaik LFS is hardly using what even DX9 has to offer - it's just the Rift shaders, car rendering and maybe things like the Westhill fences?
Using shaders for things like shadow calculation/rendering, replacing the "alpha test" stuff etc. (which afaik was removed from DX10 because everyone used shaders for it anyway) would probably reduce CPU load and more efficiently use the GPU (even older ones designed for DX9).

Quote from Bose321 :

... I think multi-threading would give a lot more FPS actually.

We're probably at the stage where multi-threading - even relatively simple (he says) things like having a single thread each for physics, graphics calls, core game logic and texture loading/downloading/other disk access - could make a huge difference on CPU limited systems.


IIRC, Scawen said a while back he could make LFS multi-threaded in about three weeks' work. I'm not going to hold him to that timescale and things have no doubt changed since then, but that's something maybe worth looking into.

Quote from chucknorris :

It would a lot easier to do something like
/axload basic_layout
/axmerge feature1
/axmerge feature23

It is possible to replicate that exact functionality using InSim.

I wrote an offline tool to do this when open configs first came out. I've been meaning to merge it (no pun intended) into an InSim app, but haven't got around to it yet.

It depends which is the bottleneck, GPU or CPU.
I got a bigger (minimum) FPS increase by overclocking my CPU by 300MHz than getting a 3x faster GPU.

As for the GPU, it's running at ~75% core clock with barely any load.

My guess is that the CPU isn't able to send the graphics calls fast enough for the GPU to do much.

The fact that I have zero FPS difference with no AF+AA and low textures vs. max AA+AF and high res textures reinforces that. (AA especially is a very expensive operation, graphically)

Interestingly, disabling car shadows alone gives a significant FPS increase.

Edit:
FWIW, most "FPS drops" that I experience that aren't obviously down to what's being drawn on screen or driving outside the the open config path system seem to be caused by people leaving pits and skin/texture loading. Another CPU load issue?

Last edited by Degats, Sat 11 Apr 2015, 16:33.

AFAIK LFS_External only supports InSim v4, so MTC is limited to 64 chars.

You'll probably just have to split the messages across multiple lines.

Quote from cargame.nl :

NCI packet appears only when requested, as far as I know

I did some testing on my own (non-PRISM) InSim program last night.
AFAICT, NCI behaves in exactly the same way as NCN:

• When the InSim connects, you have to send a request for a batch of them by sending a TINY (I'm actually sending mine when I've received the first VER packet)
  
• When a new player joins with the InSim already connected, an NCI (ReqI 0) is received for that player after the NCN
  

Maybe something in PRISM isn't picking them all up properly?

Edit: Just to make sure, I just disabled sending the TINY and I still got the NCI when a client connects (just not when the InSim connects of course)

Quote from cargame.nl :

No it isn't mentioned because it wasn't mentioned. If you do not mention what you would like (+ arguments) then it's pretty difficult to get what you want. If IPv6 was mentioned at that stage then it maybe got implemented differently ... Or... An explanation why it's not desired. Nobody cared about IPv6 back then, it seems. Or cared about the packet in general. Quite low amount of comments.

IPv4 wasn't mentioned either, nor was a 32bit IP representation. If they had, I'm sure someone would have pointed out IPv6. It only occurred to me because I saw the 32bit representation in the actual packet.

Either way, as this is an ongoing test patch cycle, things are not final and can (more) easily be changed before it's too late and 'official'.

It's just a suggestion and Scawen is or course free to make the change now or sometime in the future when IPv6 support is actually implemented into the core code.
The only real benefit of making the change now would be one less thing to break InSim applications/libraries in future (when they may not be so regularly maintained).

Quote from cargame.nl :

Nah, seriously.. Full IPv6 readyness will imply another incompatible patch anyway when the world is changing to that format, lets change it when it's actually needed.

But an incompatible patch doesn't necessarily imply an incompatible InSim update.
As NCI is the only thing that would need changing, we may as well get it over with now so future InSim apps should Just Work™ when the time comes.

For the record, the only things that aren't ready for IPv6 yet are consumer ISPs, short sighted/moneygrabbing router manufacturers and some software. All supported operating systems have had it working and enabled by default for years.

Quote from PeterN :

IS_NCI: unsigned IPAddress;

IPv6 isn't exactly new. Even if the game doesn't support it yet, this packet could at least be forward thinking so this bit of the protocol doesn't need changing in future. A 40 character string is enough for IPv4 and IPv6.

I knew someone would beat me to it

BTW, IPv6 is only 128 bits (4x unsigned, same as 16 chars). There's no need to mess around with strings until you need to display to a human.

The shadows on concrete mostly works, but there's now some Z-fighting on intersecting concrete while a shadow is being cast (couldn't see any on Shift+U mode with no car)

nacim does know what you mean and is correct.

The reason that LFS goes into windowed mode is so you can see any popups from the firewall asking whether to allow LFS access to the network or not.

A common problem with games is that these firewall popups are rendered *behind* the game window, preventing you from ever seeing them. Most firewalls will ask again every time the binary changes (ie after a new patch).
This is a common source of confusion, so LFS automatically switches modes after a patch, to ensure you see the popup. Otherwise, most firewalls will just block LFS by default, until you tell it otherwise.

After driving around a bit, the shadows (where they're in the right place) are pretty nice and there's definitely a significant improvement in framerate.

Quote from Scawen :

Misc :

Collision detection improved near the ends of long objects

Just been testing the collision detection.



This happens for any car if driven slowly into the end of an armco or long barrier centred on the front of the car:

The front suspension is totally destroyed, but there's no damage to the car model.
Driving in at different angles tends to cause a LOT of damage to both suspension and model at all speeds.
At high speeds it's back to the old "to the moon" physics (if not worse) from a few years back.

Quote from pipa :

Does the IS_SCH packet also receive key presses?

No, it's a one-way instruction to LFS.

AFAIK, the only thing that tells you if a key is being pressed is OutGauge and that only tells you about Shift & Ctrl

Quote from gibasa :

Do I really need to add ^B or is it regarding the bug you think you've fixed earlier?

You almost certainly do need ^B on both parts - LFS probably treats it as two separate strings (that happen to be encoded in the same char array), so the encoding would need to be set on both.

Quote from Bladerunner :

Come on guys...READ the previous threads...the "paths" have absolutely NOTHING to do with the AI cars or WR's or anything other than GRAPHICS!!

We can read.

We were discussing/asking how they might be implemented and made, not what they're going to do, or how they might be used.

Oh, and by the way, there's a very good chance they could be used for other things that Scawen hasn't mentioned as well, depending on how they're implemented and what data we (as programmers) get access to.

A good example is the current/old paths (rendered on Flame's post).
They are used for graphics as well (for the same reason as the new paths), but also for timing, the racing line, to render the track map, and contain data about the track area and drivable area.
They are generated by (presumably Scawen) actually driving around each track config (hence the WR reference), but that method wouldn't necessarily be so practical with the new paths due to the potentially huge number of possible routes.

Quote from Dygear :

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 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.

IMO, it's unlikely that any paths will be based on WRs, or even regularly updated for that matter - the current ones certainly aren't.

Since the new paths look to be dealing more with open (or custom) configs with multiple potential routes, there's a good chance they may not be based on driving an actual driven lap at all, but rather multiple linked sections of road similar to digital mapping/navigation systems.

Do you have ISF_LOCAL set when connecting? With it set, it will only permit buttons to be sent locally (UCID=0).

Quote from MadCatX :

Also, comparing string contents with "==" operator doesn't do what you want in C#.

Yes it does. String is a special case where == is overloaded to compare value instead of reference. (MSDN)


A couple of issues with the code:


1.
All cases of
within the while loop should be
If you use
it will exit the function at the first sniff of a line that doesn't contain an IP - if you're scanning a log file, that means it'll quit on line 1. Continue will instead move on to the next line, which is probably what you want.



2.

and

will return 1 instead of the expected -1 if the string is not found. You need to check the result of .IndexOf() before adding anything to FromIdx:

3.
If anyone types ": blub (Somebody'sUsername)" into chat, it won't return what you're looking for.



P.S.
You're probably better off doing this kind of thing using Regex. It'll be more reliable, probably faster and can be done in something like 10 or so lines of code.

P.P.S
Also, I just realised that code will still only find the first IP for that user, not the latest.
You'll need to define IPStr at the start of the function, keep running the while loop until you hit EOF, then return the latest version of IPStr.

Last edited by Degats, Sat 22 Nov 2014, 12:01.

FWIW, I've (accidentally) had LFS running at console-beating framerates (35+fps @1920x1080) with my CPU locked at 800MHz. Took me 20mins to notice that it was more choppy than usual, even on a full server, open layout with lots of objects.

That would be pretty terrible on a rift though, so yeah at least 2GHz is probably a more sensible minimum - preferably dual core, as background processes are good at stealing frames.

I've never had any problems running LFS in Win7,8/8.1. I can't remember installing the DX9 runtime, but I guess I must have done (or likely another game installer did it for me).

I tried LFS in a Win10 VM a few weeks ago: had to manually install the graphics drivers and followed the link on the LFS error message to install DX9. No problems whatsoever, didn't even have to use compatibility mode.
I haven't tried it on real hardware yet (no room for more HDDs) but I doubt there'd be any problems.

(all 64bit)

Quote from Jesse Kyytinen :

This is very annoying to me, as my Logitech Driving Force pedals don't support to keep both pedals down at the same time in LFS.

Is there not an option in the profiler to turn off combined pedals? I know the DFGT does.