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?
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, .
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.
You'll probably just have to split the messages across multiple lines.
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
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)
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).
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.
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.
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.
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.
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
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.
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.
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).
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
return "";within the while loop should be
continue;If you use
return "";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.
FromIdx = Line.IndexOf(" (") + " (".Length;and
FromIdx = Line.IndexOf(": ") + ": ".Length;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:
FromIdx = Line.IndexOf(" (");
if (FromIdx < 0)
{
continue;
}
FromIdx += " (".Length;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, .
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.
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)
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)
Is there not an option in the profiler to turn off combined pedals? I know the DFGT does.
That should work, however you don't need the /msg:
I can't really help you more than that, as I've never used LFSExternal - it's possible that LFSExternal is being "helpful" by treating the UCID 255 as invalid (which it normally would be) and rejecting the command instead of sending it anyway. This is quite likely, as I believe LFSExternal is older than the "send to all" feature that introduced the 255 special case.
You may just have to be inefficient and write a loop to send the message to each player, one by one.
InSim.Send_MTC_MessageToConnection("Some Long Text", 255, 0);I can't really help you more than that, as I've never used LFSExternal - it's possible that LFSExternal is being "helpful" by treating the UCID 255 as invalid (which it normally would be) and rejecting the command instead of sending it anyway. This is quite likely, as I believe LFSExternal is older than the "send to all" feature that introduced the 255 special case.
You may just have to be inefficient and write a loop to send the message to each player, one by one.
If all you want to do is display a message, use MTC (Message To Connection) which gives you 128 characters to play with IIRC.
If it's a client-side InSim, set the UCID to 0.
If it's a client-side InSim, set the UCID to 0.
Yes, I understood you about the GT2 thing, which is why I didn't mention it again and suggested other, more reasonable uses for a per-player version 
Preventing cars joining the track with the wrong restrictions (by spectating the player) has been possible for a long time. The way I see it, the HCP packet was intended to make everyone's life easier, especially the player; it doesn't really add anything that couldn't be done before, it's just considerably less painful to do now.
I forgot about success ballast when writing my previous post, and I'm sure there are other cases where it could come in handy (maybe alternative penalties to drive-through, as the handicaps can be changed live).
The obvious uses are rarely the only uses...
Last edited by Degats, .
OutGauge does indeed show pedal inputs and sending keys is fairly simple with Windows APIs.
LFS' more accurate gearbox simulation may create some odd edge cases that may result in some odd shifts though.
LFS' more accurate gearbox simulation may create some odd edge cases that may result in some odd shifts though.
I'd just like to add my +1 to this.
It would make true multi-class racing (ie GT1+GT2) much easier, amongst other things.
I appreciate this isn't a short term thing, I'm just getting it on the radar for future.
Not sure if I should make an RFC for this in addition to this thread - if anyone thinks I should, please let me know.
FGED GREDG RDFGDR GSFDG