Quote from T3charmy :

Alright, I'm working on one more feature to push up from my personal codebase without breaking existing functionality of it. Almost done, just doing code cleanup, then will push to my server to do testing, then to my repo for a pull request.

Ok, once I get the pull request I should be ready to test it. In the next 24 hours right?

I'm going to give it 24 hours, then T3, if you'd like can you please setup for a PRISM 0.4.5 release. There are a number of enhancements that should be released to everyone.

Quote from Ped7g :

I do believe that is not possible (violation of DX9 license). Haven't seen DirectX for some years, but back then they provided "DX distributable" installers which you could bundle to your SW. Anyway, I think it should suffice if LFS will check if DX9 is installed and tell user to go ... update himself.

Agreed!

Also the DLL does not just work by it's self, I'm pretty sure, you need the framework around it.

Does that mean that you're teaching it your driving style? What would happen if you put it on with the WR Replay?

Take out everything you don't want and make a plugin for LFSLapper / PRISM, etc..

Quote from blackbird04217 :

Youtube: Path Prediction in Action

Is the AI driver driving or is it just predicting where the car should go. As far as path's go, would it not make sense to include a cone of uncertainty. The cone of uncertainty being the same visual representation that is used for hurricane paths.

Quote from DaY_WaLkeR_TR :

I need a InSim written from bottom.

I have no idea what you mean by that.

Epic fail on my part.

Quote from Bose321 :

Would be nice to have actual mirrors as well where you can see your car and can adjust them. The current ones are just a view from the back, slightly moved. Or are they even the same? I thought I saw a post about that a long while ago.

Ya know, I don't think anyone else does that ... and come to think of it, it's not really needed because in theory we are all the same height in game because we all use the same model. Might become an issue when the occulus starts to know where you are in the Z axis in a 3D space, as the next version supports that, so it might be cool to add that now.

OutSim Packets are always local to the car, as it's meant for motion rig setups.

If someone makes an asm InSim application, I'll give them a billion geek points.

From my understanding, the idea of this project is to make a Driving AI that is agnostic to a single game. That's why there is a visual sensor, so he could then take the project and load up iRacing and it should just work because it can "See" the track the same way we do.

Quote from Degats :

AFAIK, the auto gearbox mode uses the optimum shift points, that might be easier to use for measuring than AI drivers.

I guess you'd have to use the up-shift values to work out at what points a kick-down is needed, as the auto box's downshifts while decelerating are pretty shocking for actual racing (mostly because there is no one optimum down-shift point when braking - it can vary massively based on engine braking, limits of traction etc)

To reduce the advantage of knowing the optimal shift points, you could add a bit of randomness to it.

Fair point, about just using the auto gearbox mode. But it would depend also on the gear ratios ... I guess you could fuzz this information. Set 20 different values evenly spaced apart in 20 different setups then have the AI do a hot lap and find out where it shifts up and down. From there you'd only have to read the setup file and tween between the numbers if they are not on a value already set. That should get you 90% of the way there. When it comes to engine breaking and everything else, you'd also have to take in weight of the car, if it's on an incline or decline while breaking when you should be shifting ect.

You should be able to get the optimum shift time by RPM by looking at the RPM when the AI shifts into the next gear. I don't know for sure, but I think the AI (written by Scawen) knows the best time to shift.

Quote from Scawen :

P.S. I noticed the frame limitation in a window as well, seems limited to desktop frame rate. When I used a debug version with a lot of AI cars, it was limited to 30 instead. So somehow it does work like vertical sync, and it's not related to Aero because my computer is XP.

If I remember correctly, that's because once you no longer are running the application in full screen mode, the driver will force V-Sync to save power. So when your just sitting at desktop, not doing anything, it's not rendering at 10,000 FPS, using needless power. I asked John Carmack on twitter, because I don't know the twitter handles of nVidia or AMD GPU reps, so I'm hoping for a reply to confirm.

[EDIT] Wow, Carmack is quick this was his reply:

Quote from @ID_AA_Carmack :

@Dygear @scawen1 if you have a desktop composting mode active, the driver often can't override the sync behavior in a window.

So the answer is, it depends.

Quote from Bigbob1993 :

Yes please! This could be made as an option in menu. I would give up my 2XAA to have this and still run the game smoothly on my PC
However, it is up to you, what will you spend your time on... this is just my little wish

That would be pretty awesome. Having the setting "Tire Smoke Behind Fence (Costly)" [Yes / No] Would be a nice touch, let us decide if we want it, or you can just force it as everyone is getting free FPS from the DX9 patch anyway, so we might as well get some visual fixes to offset it anyway. I think we can burn a 15.98% FPS improvement to fix a visual bug.

0.6E (DX8)

0.6E13 (DX9)

Quote from cargame.nl :

If that tyre psychics saga is not going to be completed / shutdown / put behind then there is no LFS future to begin with. How many times I now have heard the last years; "after the tyre psychics have been updated", it's becoming uncountable.

I don't really care about the tire psychics update, progress in any form is good. If we can move forward in any way, that's a good thing. If nothing else, I'm quite happy with Scawen working on other things while we all wait for the new tire model.

Anyone know if Valve open sourced that wrapper?

Porting Source to Linux - Valve's Lessons Learned
Slides (PDF)
Video (YouTube)
Video (GDC Vault) - Much Better Audio

It's not a bad idea for the future of LFS to switch to OpenGL.

Last edited by Dygear, Mon, 20 Jan 2014 12:44.

I was thinking about Endianness using + and - before the datatype. If you had no symbol it would use the native system endianness. I've also slightly expanded it scope.


Endianness
(No Symbol) - System Native
+ - Big Endianness
- - Little Endianness

I want to make this into the SplStruct class.

Last edited by Dygear, Sun, 19 Jan 2014 08:51.

That means Victor is behind it then? I doubt Scawen tweets.

Quote from Scawen :

Hi, the DX9 version seems good but there are a couple of minor things to fix (easy) and also I should have a look at my list of things to do. There isn't really anything else new in this version so it's not a very exciting test patch so far! But do let me know if it is important to release the DX9 test more quickly.

I'd like to see it, if for no other reason then "progress". At this point, DX9 is better supported the DX8 as vendors begin to deprecate DX8.

Last edited by Dygear, Sat, 18 Jan 2014 14:04.

I got it, and I'll merge it soon into the main branch. Thanks for the fix!

Ideally you:

1. Fork the project
   
2. Make one or more well commented and clean commits to the repository. You can make a new branch here if you are modifying more than one part or feature.
   
3. Perform a pull request in github's web interface.

Some projects won't use the pull request system. Check with the author or mailing list on the best way to get your code back into the project.

Yes, but it would not be accurate, and therefor pointless.

If you want to submit the patch to github, I'll galdy merge it so you get credit in the history. Looks like we are squashing quite a few bugs, so I think a 0.4.5 would be a good idea to release soon.

I should probably submit that pat h to the master.