So there's a gap between game ouput rules and requested input rules. Using shared memory plugin this process is not synchronous: game sends rules in a function call, plugin picks up rules update from the input buffer in a separate function call, and will apply update next time game calls rule update function. The reason for that is that when done inside of a plugin, rules are applied synchronously: game sends rules input, and allows updating that input in the same callback, meaning synchronously. However, this is experimental, because I am not positive this approach is going to "fly"/is reliable. The idea was that it might make developing custom rules plugin easier, by being able to change logic in an external app/script without rebuilding plugin/restarting rF2. It allows sending Rules input to the game. RFactor 2 API has some limitations/bugs, and plugin tries to deal with that by deriving some information: basic accumulated damage info, tracking session transitions and optionally reading game memory directly. A lot of work was done to ensure it is as efficient and reliable as possible. For read operations, it can handle any number of clients without slowing down rF2 plugin thread. This plugin is carefully implemented with an intent of becoming a shared component for reading rF2 internals. It also allows keeping CPU time impact in rFactor 2 plugin threads to the minimum. Reading and writing shared memory allows creating external tools running outside of rFactor 2 and written in languages other than C++ (C# sample is included). Plugin also allows some level of input back into the rFactor 2 API. Essentially, this is direct memcpy of rFactor 2 internals (except for extended stuff implemented to workaround API limitations/bugs). It could do with more options but what we have right now does the job, obscures vision about as much as you'd want, and runs fast enough for it ok to be forced and stop people 'cheating' by turning it off.This plugin mirrors exposed rFactor 2 internal state into shared memory buffers. Peterchen: it looks fine from behind, sure it doesn't look great from side on but any better looking solutions will probably be more demanding. But because of some aspects of the implementation and the discovery of the super grippy wet tyres bug we've shelved it. I wrote a program for our league use that randomised weather within set parameters. And because of the speedy transitions the inters are a waste of time anyway. With no aquaplaning intermediates and wets are faked because there's no clearance of water to worry about. Unfortunately recently, and possibly still, the transition is broken and wet tyres can get super grippy on a damp track. Because the blocks moving around and overheating isn't modeled, as far as I know, so this gives you wets that work in the wet while being too slippery in the dry. To get some sort of balance between slicks and wets across dry and wet conditions, wet tyres usually gain grip when the track is wet. Missing WetGrooveEffects, as mentioned above, so there's no reason to drive a wet line. Don't believe wet tarmac offers any tyre cooling. Wet tarmac, like grass, offers less grip but still heats and tears your tyres up. If it stops raining, 2 laps later you need slicks. Track gets wet too quickly with light rain (supposed to be 3 levels of intensity, but almost always you'll see 1), 2 normal laps after rain starts you need wets. Click to expand.Depends on the mod of course.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |