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.
If it needs to be a string, it may as well have its own (optional) packet.
That would mean it maintains compatibility (no need to change the size of NCN); be sent on demand if requested by the InSim; and sent whenever an existing connection changes language.
Alternatively if it were to be a byte incorporated in NCN, PFL has two spare bytes one of which could be used when the language is changed.
Either way, IMO it would be better to have its own packet (or a SMALL) anyway and leave the spare byte in NCN for something more likely to be used - I'd be surprised if many InSim apps would make use of language info.
That would mean it maintains compatibility (no need to change the size of NCN); be sent on demand if requested by the InSim; and sent whenever an existing connection changes language.
Alternatively if it were to be a byte incorporated in NCN, PFL has two spare bytes one of which could be used when the language is changed.
Either way, IMO it would be better to have its own packet (or a SMALL) anyway and leave the spare byte in NCN for something more likely to be used - I'd be surprised if many InSim apps would make use of language info.
Set your LFS and G27 rotation to be the same (minimum 720 degrees*), and in LFS set wheel turn compensation to 1.0.
If you've done it right, your G27 will match every car in LFS 1:1. The only downside is that you'll loose the FFB soft stops in several cars, so beyond full lock your wheel will keep turning and FFB will be a bit weird.
*Side note for people from the future: VWS is 900 degrees, so you'll need 900 instead of 720
If you've done it right, your G27 will match every car in LFS 1:1. The only downside is that you'll loose the FFB soft stops in several cars, so beyond full lock your wheel will keep turning and FFB will be a bit weird.
*Side note for people from the future: VWS is 900 degrees, so you'll need 900 instead of 720
Is that through wine or natively? CS:GO is native on Linux & Mac, using OpenGL instead of DirectX - it will run slightly better than on Windows in some hardware/driver configurations, whereas DirectX via wine will in theory always be slower to some extent. Again, how much slower depends on the game/wine version/hw/drivers.
The node values in InSim would probably be pretty good for lap percentage actually. IIRC they were generated by driving the track and logging position every 0.2s. They can be a bit out in places due to cars' different acceleration/braking performance though.
In LFS, the outer physics loop (currently) runs at 100Hz. There is (again, currently) no interpolation between physics updates. Therefore no position updates of the cars/view/whatever will happen more often than 100Hz, so if you render faster than 100fps you will get duplicate frames.
Go watch a replay at 0.125 speed and the effect will be obvious.
Ah, I remember seeing that now. Forgot about it then noticed it while doing some skin stuff the other week.
Mind like a sieve and all that...
No AF on car skins
Speaking of AF, I noticed something weird with skin rendering since 6F3.
The top image is from 6F (6F2 is the same) and the bottom one is from 6F6 (6F3 and above are the same).
In this particular case, the vertical lines are blurred, but it affects any detailed skin when viewed from a shallow angle.
All graphics settings are the same, only difference is the exe. AA & AF are at maximum.
If I turn off AF on 6F, it looks the same as 6F3+, so I assume AF isn't being applied to car skins for some reason.
The top image is from 6F (6F2 is the same) and the bottom one is from 6F6 (6F3 and above are the same).
In this particular case, the vertical lines are blurred, but it affects any detailed skin when viewed from a shallow angle.
All graphics settings are the same, only difference is the exe. AA & AF are at maximum.
If I turn off AF on 6F, it looks the same as 6F3+, so I assume AF isn't being applied to car skins for some reason.
Last edited by Degats, .
I made an imagemagick script for that; feed it a 2048 png and it'll spit out a high quality 2048 jpg for LFS and the best quality 1024 jpg that'll fit in 400kb for LFSW.
It'd be nice if I could upload 512 ones as well, because I'm sure I could generate something with better quality than the smudge that LFSW comes out with - I have the CPU cycles to burn to do that, not something I'd expect LFSW to spend the time doing.
Product means content level, ie Demo/S1/S2, that's pretty much what I meant by content.
If I understand correctly, the server mode restricts the specific content that can be loaded on that server. As it's fairly common for InSim to be setting things like cars & track (yes, even client side InSim if it's a helper program for admins) it would be important for an InSim app with that functionality to be aware of what can and can't be loaded.
I guess it could be useful to have an additional field to report the licence level of a client, but the two would certainly mean different things.
(Either way, we're getting rather off-topic here
)I assume it reports the level of content that is available at that time. If you're connected to a demo server, there's no point in the InSim trying to do something with S1/S2 content that it has no access to.
Knowing the /mode setting of the server could be useful to automatically reduce functionality of the InSim app to what is actually usable.
There is no vibration as such on the G27, or LFS for that matter; it's all FFB.
And no, it's not possible to disable some sources of FFB in LFS, because it's all simulated based on forces in the steering rack.
The best way to stop what you describe is to not hit anything
And no, it's not possible to disable some sources of FFB in LFS, because it's all simulated based on forces in the steering rack.
The best way to stop what you describe is to not hit anything
The absence of recovery trucks for endurance racing would be a prime example I think - wait a couple of laps and spawn a stranded car back in the pitlane somewhere for them to do whatever repairs they want/need. Yes, the pitlane command kinda does that already, but that fixes damage as well which isn't always a good thing, especially as things like engine damage can't be repaired in a pitstop.
Another use might be some of the stunt based layouts where it's easy to get stuck somewhere where the normal reset doesn't help at all. A few safe places for the InSim to reset the car to, especially keeping damage, would be pretty good for that.
IMO it would be a bad idea to be able to spawn a player who isn't already on track somewhere, as there's a good chance they won't be ready for it - the act of joining the track would be a clear indication that the player is ready to drive and can then be used to trigger an InSim app to move the car.
There's also the complication that the player/car isn't in a known good state until they're actually on track. You have no idea what car/setup/skin etc they have.
16bit programs won't run under 64bit windows, even XP/2003 http://support.microsoft.com/kb/896458
This used to be a fairly common problem, where the software itself was 32bit, but had an old, 16bit installer. The software itself would run fine, you just couldn't install it.
---
One potentially relevant thing I noticed while researching SM2 v SM3, is that it was rare for SM2 cards to have more than 256MB RAM, and often only 128MB. This probably isn't much of a problem currently, but if the new Westhill is using more/higher res textures then it might become an issue. I don't know the specific numbers of cards still in use, but based on what was available >256MB didn't really become common until SM3.
Also to echo someone else here - provided you have a PCIe capable motherboard (again, circa 2004; seems to have been a big shift in all types of hardware around then) you can pick up a new 1GB GPU for £20 that'll monster any DX9c era card (it'll even run Crysis at medium-high).
---
Regarding the shader issue in Linux, I had already installed D3DX9_43 (d3dcompiler_43.dll, d3dx9_43.dll) using winetricks, as someone had suggested in the 0.6F threads.
However, there is an option for: "directx9 - MS DirectX 9 (Usually overkill. Try d3dx9_36 first)". I haven't tried installing the full DirectX9 yet or a newer Wine version - I'll try to test over the weekend if I get chance.
It uses the positioning of a couple of potentiometers to emulate button presses, yes (although I can't remember how it distinguishes between 6th and R).
The problems are generally caused by:
1. worn/dirty POTs producing noisy/wrong values (more obvious in the spiky pedal issue).
2. a small, soft-ish metal part scraping along a much larger, harder metal part every shift into, or out of, gears 1/2 or 5/6/R. Said soft metal part is vital for the alignment and eventually gets sanded down after a fair amount of use, causing it to lose alignment and randomly jump out of gear.
In some earlier G25s, some people had wires break because they were too short, but I haven't heard of that problem for a long time, so they probably fixed that one at least.
It might have helped if he'd mentioned auto gearbox and described how to reproduce it then
"going from 5th or other to reverse by itself" sounds just like a *very* common hardware issue, and nothing like the actual problem.
AFAIK, shifting 4->5 isn't really possible currently, because it's operating the same manual gearbox simulation, which *must* go into N to actually change gear.
Ignoring the user's shift requests while it's in the process of operating the gearbox (I think that was your other suggestion) may well be the best way to deal with it. Alternatively, in the case where the autobox was shifting one way and the user requested a shift the other; abort the current shift operation and shift in the direction the user requested (eg auto tries to shift 3->2 and the user requested an upshift it should shift 3->4 instead). This may be more intuitive rather than just ignoring the input regardless.
Last edited by Degats, .
Sounds like the infamous "Crap Logitech Hardware Bug" that's been causing problems with G25s and G27s for years now.
In all seriousness, what you describe sounds exactly like the problems the G25/G27 shifter has, caused by worn and/or dirty components (some parts are very poorly designed).
I personally have never heard of any shifting issues unique to LFS.
I seem to have the same shader issue in Linux. Mine throws an error message though, which might help (see attached).
OS: 3.13.0-32-generic, Xubuntu 14.04 x64
Wine: 1.6.2
GPU: Kaveri (APU) R7 200 Series, fglrx (proprietary driver)
I've yet to try the open source driver.
OS: 3.13.0-32-generic, Xubuntu 14.04 x64
Wine: 1.6.2
GPU: Kaveri (APU) R7 200 Series, fglrx (proprietary driver)
I've yet to try the open source driver.
The vast majority of LCD monitors are still only 60-75Hz max. 120Hz CRTs used to be fairly common (at lower resolutions at least), but mainstream LCDs still haven't caught up.
The main reason for the 100Hz limit is because that's what the outer physics loop runs at. There's generally no point, other than for sync reasons, to run any faster than that as things will only change on screen at max 100Hz.
Sure, you can brag you're running at 300FPS, but only 1 in 3 frames will actually be different, so all you're doing is stressing your GPU and wasting power.
FGED GREDG RDFGDR GSFDG