Interesting subject. :-) I was doing the same what you did and was able to do some laps. But indeed there seems to be some problem updating the UDP packets. So resulting in not up to date X,Y info and then missing a corner ... But to be honest still like to get it working one day. :-)
Btw I used PPJoy to do the steering and my X,Y was every 1 meter I guess.
I haven't had any problems with the packets being out of date. Well, I suppose my drive is only going 50mph, or only straight on the drag strip. Keeping it at 50mph allows me to make the assumption that the car will not slide or lose grip.
My problem is detecting the feel of the car accurately. Also the development environment has been annoying to work with, I don't want to restart LFS each time I want to run a test, but I don't want to leave LFS open while programming, as it hogs my CPU. I tried making it so LFS ran on another computer and my AI driver ran on primary, but for some reason the UDP connection I made for that kept failing - using the same code I've used for years... It was mind boggling and I decided to work on other things for now/
I like staying on track, which takes ~50% of my CPU. If I was to send a /end command (which is possible) I would then need to enter the track each time. Then I would be forced to - wait for lights each time I am doing a test, or to make it so the AI driver comes from pitlane...
I suppose the alternative could be a specially designed AutoX layout.
Also you maybe can lower the graphics? I personaly don't have any problem with CPU. I have my C program running and LFS on the same pc and I don't see any problem due to CPU.
The feel of the car is only possible with calculation. But to do that you need all the data of the car.
- The grip of the tires.
- The weight of the car.
- The z value.
- The speed.
- The direction of the car.
- The direction of the force of the car (not always equal at the previous).
- The brake force.
- The brake balance.
- .... probably a lot more :-)
To I think it is possible, but I am to lazy (or don't have the brains) to figure this out. :-)
What I do is draw a line the car must follow. Then calculate the distance to that line and try to drive to that line again. In a corner I also lower the speed dependent of the distance to that line.
I have a file with data - X,Y, speed - and the car try to execute this data. When all is ok I can make several rounds. :-)
I think a lot is possible only by calculation, but I am not a physicist, so I now use a combination of calculation and try and error. :-)
Doesn't your development environment have a standalone compiler? In that case you can use only a text editor and that command line compiler.That is how I do it. Just MinGW gcc and the file commander (fcw).
I prefer using the development environment, since it is essentially a text editor with a few additional things to be helpful. It uses minimal CPU, but can be a pain when LFS is running - as I said earlier. I use a computer for my convenience, so I typically have a lot of stuff going, and it does well at keeping up until LFS uses 50% of my cpu.
This is a CPU problem, I can't imagine graphics are causing much at all. I suppose refreshing the screen each frame, even in windowed mode, would take a slice of time, but I can't think it would be that much. Worse case scenario a mem copy of 1680x1050x3.
This seems to be spot on, still annoying that I have to minimize / maximize for subtle changes. I don't have problems with this when making major code changes - but during testing and just trying random things out this is a pain.
However I think I have a good solution which will take me the rest of the night / morning to code but I will basically make an "LFSController" that will run next to LFS on the "test machine" while I run AIRS on my dev machine. A simple connection between those two apps, and the data can be passed around with no cpu hogging ever happening on the dev machine.
---------------------------------------
On new thoughts, instead of detecting the state of each tire, like I have been on about for ages - I think I will give a try at detecting under/over steer based on g-forces and the visual perception of motion. I -think- this will be an accurate way to detect it, but unfortunately I am not sure yet if that will be good enough to use.
Possible issues are;
- Small collisions with walls/cars/objects.
- Unable to know 'where' the limit actually is as slip angle will be perceived as "sliding" even though the tires are still within limits.
I have started working on this project again until further notice.
So I have been trying to do some tests involving humans trying to race with only cones where the reference points would be. The idea is to make LFS completely black except for cones and cars. And to have people race under those conditions, however the following screenshot is the best I have come up with.
I have edited all .dds, .jpg and .raw files within data/dds and data/pic to be black. Still need something else.
I see the 'easier' way is proving quite difficult.
I know I've said this before but maybe it's the time to start considering creating your own environment? Even a very basic one, with some basic physics?
de Souza - Yea I think that may be the direction to take, even if it means I have to figure out some more complicated physics to do this test, it may be the best solution overall. I am thinking a completely flat track environment, with cones at the edges and an extremely simple physical environment to simulate (hopefully); understeer, oversteer and some sort of slip ratio for the tires. Other collisions are not needed so that makes some things easier.
mstram - You probably need to configure LFS to see your virtual controller as by default it is likely using your existing wheel/controller. I had to write a "configure" app using the ppjoy to make my virtual gamepad so that I could press a specific letter on the keyboard to get the output I expected; then configure LFS using that.
Other than by just using the options / controls / axis ?
As I wrote, it *does* work with the ppjoyMouse.exe, connecting to the virtual joystick.
You keep feeding me "general", vague quasi-solutions / tips, I don't know why you're so reluctant to share some basic "driver level" code, that has nothing to do with your application code
I'm not trying to compete with your product, or even create anything commercial in the forseeable future.
There was nothing special I did besides sit and calibrate something that took ages to get correct, and I don't think it is correct. (My virtual steering wheel would not travel in a straight line at '0' so I had to play with the 'centerOffset' until I got something that works "good enough" for the time being.
I don't get the mean attitude, I was trying to be helpful?
I know parts of this are mimicing my own code, although I also know parts came from that resource above - which is working, it seems I messed the link up at first... Anyways I used only that page as a reference, but hopefully the following is enough to get you going - because I can't remember doing anything different.
//From ppjoy "http://ppjoy.bossstation.dnsalias.org/Docs/Diagrams/Virtual/IOCTL.htm" #pragma pack(push,1) /* All fields in structure must be byte aligned. */ struct VirtualControllerState { unsigned long Signature; /* Signature to identify packet to PPJoy IOCTL */ char NumAnalog; /* Num of analog values we pass */ long Analog[VIRTCTRL_NUM_ANALOG]; /* Analog values */ char NumDigital; /* Num of digital values we pass */ char Digital[VIRTCTRL_NUM_DIGITAL]; /* Digital values */ }; #pragma pack(pop)
Well, I did make my code run interactively, but that has nothing to do with the sample or using ppjoy - that is all how you setup your application to work, which I would never have guessed. Secondly, my application runs in the background at approximately 60fps since I call Sleep(16) each "frame". It sends the control changes via the code above. This allows LFS to run in the foreground as you know it needs to in order to collect/capture/use the input.
If you are stuck on "general programing" tips I can still help, but try specifying the problem a little better; I thought you had issues with ppjoy/virtual controller - not the 'real-time / interactive' environment running behind LFS.
Start with something like this:
main { //Initialize Here
while (!quitCondition) { //Update the status of your virtual controller. Sleep(16); //Don't waste _all_ cpu cycles. (unless desired?) }
I am about to put some more effort into the A.I.R.S. project using LFS for a few days. I don't expect to make leaps of progress, actually I am planning on rewriting a lot of the networking, and making an official protocol for the A.I.R.S. project so that at a later date it will/should be compatible with more than just LFS.
At this time I still don't want to release this publicly, due to the setup of the PPJoy virtual controller being less unfriendly than I would like. I will be sure to share replays of my programmed driver as it makes progress as I already did above.
I plan on making an LFS communication program that takes all Insim, Outsim and Outgauge packets, and converts them into packets that AIRS will use. The communication program will also receive control packets from AIRS which it will use to play LFS via the Virtual Controller. None of this is news to those who followed along, really all I am doing is separating communication portion of the project into a separate Communicator.exe.
Once this step is done, I should be able to run the Communicator.exe and LFS.exe on my laptop, while programming/running AIRS on my desktop. Finally.
Unfortunately I don't see much going on beyond that at this time. I've been swamped with my Indie Project, making code samples and doing programming tests. Trying to find a job, which I may have finally done. Helping and visiting family... But, with this puzzle piece out of the way, I should be able to start the more interesting pieces since I have been offered a little bit of help.
Thanks for the interest, and hopefully I will work on this project more in the year to come.
I know that it is possible to artificially control an LFS car. If you look up in the thread I displayed a few replays where I had the "AI" driving from point to point, but that isn't all I wanted done with from this project that seems to be not exactly alive... I wish I had the time to work on it.
