IMO, that's up to the admin/programmer to choose whether they want people to spawn on the start grid before a race or not if there's a chance they're not ready. It's not something that'll happen by accident if the server admins don't want it to.
The only problem I see is if /join is called while someone is actively editing/naming/renaming a setup or colours. In those situations it would be unwise to disturb the player IMO. I haven't thought of any other situations that could cause problems.
In Firefox and Chrome, F11 goes into full-screen borderless window mode on the current monitor (not the one with the most pixels - I've never seen that behaviour; maybe a coincidence because the monitor with the most pixels is usually chosen by the user to be the 'main' monitor?).
IMO, it would make sense for Shift+F11 to mimic that behaviour (full-screen borderless window on the current monitor), Shift+F12 for full-screen borderless window across all monitors, and keep Shift+F4 for exclusive full-screen toggle on the main monitor.
FWIW, full-screen toggles are very inconsistent across windows applications - common ones are F10/F11 (and combinations with modifiers), Alt+Enter, <modifier>+Space and I'm pretty sure I've seen something other than LFS use something and F4 as well.
As an aside, I currently have a two monitor setup, but with different sizes/resolutions. I wonder what the "all monitors" mode would do on this kind of config.
IMO, it would make sense for Shift+F11 to mimic that behaviour (full-screen borderless window on the current monitor), Shift+F12 for full-screen borderless window across all monitors, and keep Shift+F4 for exclusive full-screen toggle on the main monitor.
FWIW, full-screen toggles are very inconsistent across windows applications - common ones are F10/F11 (and combinations with modifiers), Alt+Enter, <modifier>+Space and I'm pretty sure I've seen something other than LFS use something and F4 as well.
As an aside, I currently have a two monitor setup, but with different sizes/resolutions. I wonder what the "all monitors" mode would do on this kind of config.
It's already been updated 2 or 3 times - no significant changes to routes (except a completely different pitlane), just more routes and more polish. I'd be surprised if the next update isn't more of the same.
Ah, yes that's what did it.
It's interesting (and a little counter-intuitive) that the AA setting ingame is removed when post-process is on, but it's functionality is still there and adjustable in the config file.
This isn't strictly speaking test patch related, but since 0.6K (or maybe even before), I haven't been able to see the Anti-aliasing option in graphics settings. The option for mirror AA is there, but not the global one.
Modifying the value in cfg.txt appears to change the AA level, but the option doesn't seem to appear in game anymore.
Has anyone else noticed this?
http://i.imgur.com/pgr0lyq.png
I'll add my vote to that request
Modifying the value in cfg.txt appears to change the AA level, but the option doesn't seem to appear in game anymore.
Has anyone else noticed this?
http://i.imgur.com/pgr0lyq.png
I'll add my vote to that request
Which graphics card exactly? There's a good chance that's struggling as well.
As someone else already said, you *will* need to run with low res textures with only 256MB.
To overclock a P4, you'd probably have to do it in the BIOS (likely by increasing the multiplier if it'll let you). Be careful though, you can easily fry it if you take it too far - small increments and do a stress test every time, keeping an eye on temps.
If you want to play it (slightly) safer and ebay, there were some 3.0GHz P4s @200MHz FSB. Check compatibility first though.
Oh, and you really don't need an i3 and dedicated graphics to run LFS - I've had a £70 AMD APU (CPU with integrated graphics) running the new Westhill at well over 100FPS on a 1440x900 screen. You'd probably even get away with the £50 one for 60+FPS at that kind of resolution.
You've also got to bear in mind that torque curves *will* be different for the real cars vs the LFS approximations which will effect acceleration, so a Formula BMW is probably the only thing we'll be able to decently compare. I assume Scawen got a decent amount of data from the real car.
Tyre tread/compounds can make a significant difference in lap times as well, and who knows how they compare.
Still, it's mighty close in that video, despite the gearing being way off
It was actually the fact that the ESC in the Scirocco made the handling worse instead of better that tipped him off. The VWS had been delayed several months already before we even heard about Rockingham.
Tyre tread/compounds can make a significant difference in lap times as well, and who knows how they compare.
Still, it's mighty close in that video, despite the gearing being way off
It was actually the fact that the ESC in the Scirocco made the handling worse instead of better that tipped him off. The VWS had been delayed several months already before we even heard about Rockingham.
The kerbs have been updated to match the new sausage kerbs in the real track that were changed a couple of years after the laser scan (you can compare the original/new screenshots)
As Dave said, some of the textures seem to have been improved as well, though I haven't actually done any side-by-side comparisons.
----
I have found a small InSim bug - IS_VER.Product returns S2 instead of S3, even when Rockingham was loaded from the config file.
That isn't valid C++, which is why it's complaining.
Pos is of type Vec - don't get confused by std::vector, which is a variable length array-like container.
Vec (along with Vector) is already defined at the top of cinsim.h.
If you want to grab the whole of Pos to store/use somewhere else, you should be able to do:
Vec Pos;
Pos = pack_cpp->Pos; // Assumes pack_cpp is a pointer to a struct. If it's an actual struct object use pack_cpp.Pos
You can then access the values using Pos.x etc
Alternatively, you can just access the values directly:
float X = pack_cpp->Pos.x; // again, access members using . instead of -> if it's an object instead of a pointer
float Y = pack_cpp->Pos.y;
float Z = pack_cpp->Pos.z;
Disclaimer: the above *should* work, but I haven't tested it against CInsim as I stopped using it a while ago.
As a side note, make sure you're using a C++11/C++14 compliant compiler - it'll make your life much easier. Modern C++ is waay nicer to use than the old styles.
Would this work? (A guess based on what the php pack() funcion does)
edit: nm, it probably doesn't. I'll try to take a proper look into it later
<?php
IS_CPP()->Pos(pack("l3",-39175822,11394484,1037662))->H(65117)->P(757)->R(0)->ViewPLID(0)->InGameCam(0)->FOV(24.60000038147)->Time(0)->Flags(0)->Send();
?>
Last edited by Degats, .
You might have to live with replacing Pos with 3 ints then, unless someone can give you some better insight - I know basically nothing about the way PHP handles this kind of stuff.
As far as the packet/data that LFS gets is concerned, 3 ints is equivalent to a C struct containing 3 ints.
As far as the packet/data that LFS gets is concerned, 3 ints is equivalent to a C struct containing 3 ints.
In LFS/C(++), Vec is just another struct containing 3 ints.
I don't know how you'd translate that to PHP, but a hacky way would be to just replace the Pos with 3 ints
edit: It probably wants to be its own class in PHP with the relevant pack/unpack functions, but that's just a guess
I don't know how you'd translate that to PHP, but a hacky way would be to just replace the Pos with 3 ints
edit: It probably wants to be its own class in PHP with the relevant pack/unpack functions, but that's just a guess
Last edited by Degats, .
#52 [TC] Racing
(updated with correct positioning)
(updated with correct positioning)
Last edited by Degats, .
BTW, it only contains the PNGs, there's no .psd
Last edited by Degats, .
In the case of Hyper-V, it's not in the startup list, or services; it's effectively a driver.
You have to use the bcdedit command to disable it - I only knew it was even running because VMWare refused to start.
You have to use the bcdedit command to disable it - I only knew it was even running because VMWare refused to start.
It's not quite as simple as that: https://www.youtube.com/watch?v=wnS50lJicXc
tl;dr a single thread that's using your CPU efficiently *can* use up to 1/4 of your CPU, even though windows says 1/8th. 1 hyperthread is not equivalent to 1 core.
~~~~~~~~
The following *may* be useful for a small number of people with performance problems, but I really don't know how widespread it is. It might only affect CPUs similar to mine (Phenom II X4 955) or it could be more common.
During the test patch phase, I noticed some weird performance issues on my PC:
In 0.6H, I was getting between ~35 and ~95 FPS in Westhill, depending on where I was looking and whether or not my car was between paths. I was pretty much CPU limited and saw no improvement when I upgraded GPUs (4890 -> R9 285).
A few test patches in and my framerate had dropped to 25~45, at a time when most other people had a ~50% increase. It was bad on other tracks as well (max 80 on an empty Kyoto).
I tried older test patches and 0.6H, but I still had worse framerates than before, so I knew it was something weird with my system and not test patch related (which is why I didn't report it).
Long story short, turns out Visual Studio 2015 installed some Hyper-V stuff that was wrecking LFS performance. I disabled the Hyper-V hypervisor (rebooted) and now I get 100~200fps on Westhill open config with 40 players, 200~300 on a Kyoto race with a handful of players.
The shift+p lag happened in Win 8.1 as well, but it seems to be fixed in H6
However, I have noticed similar lag (for a shorter time maybe?) happening when exiting replays and when the multiplayer server list finishes loading.
This happens in H5 & H6, but not in H4.
When exiting a replay, it happens only when the frame limiter is on, the server list doesn't seem to matter if a frame limit is on or not.
It seems odd to me that it would happen in the server list, but it does seem to be a genuine hang (rather than waiting for a host to respond) because it never pauses in H4, but in H5/6 windows again briefly detects that LFS is not responding sometimes.
dxdiag on my old W10 laptop says DX9Ex.
I'll let you know what deb.log says on there in an hour once it's booted up...
I'm still on Win8.1 64bit - I haven't got W10 on here yet.
I *might* be able to test with W10 on my old laptop, but the GPU probably hasn't got enough grunt to exceed the frame limiter.
deb.log says timer resolution is 1ms.
A couple of quick tests (all in windowed mode for now):
I get the freeze whether frame limit is set or not. (Very rare if no limit. I can't actually reproduce it anymore with no limit, so I may have messed up a setting). Doesn't seem to happen if I set a 200fps limit (getting ~170fps).
While the freeze is occurring, CPU usage is zero.
The freeze length seems to be quite variable - anywhere from unnoticeable, to long enough for windows to think LFS has stopped responding briefly.
TBH, the biggest problem with the 512 skins is the horrible jpeg compression, which is more noticeable at a lower resolution.
The 512 skins either need a higher base jpeg quality or (the better option IMO) store them on LFSW and download as a gzip'd dds.
I concur that 2048 seems to be the most suitable.
I've noticed one bug - previously uploaded VWS skins are showing in the XFG list.
I've noticed one bug - previously uploaded VWS skins are showing in the XFG list.
FGED GREDG RDFGDR GSFDG