As far as the racing, that was great. But the video was rather boring; the default camera shots - and not only just the default camera shots but the same ones over two laps. (Until the very end where you did add another perspective). I know you were likely not aiming to make a quality video; but (and without meaning to sound as harsh as it does) I think this would have been best written in a story vs shown like this.
Add different points of view and play with the cameras for a little bit of time, it will give a lot better result; possibly liven it up with some form of music. Not saying remove the ingame sounds, but some background music would be a nice touch. Like I said, the racing was nice.
Add different points of view and play with the cameras for a little bit of time, it will give a lot better result; possibly liven it up with some form of music. Not saying remove the ingame sounds, but some background music would be a nice touch. Like I said, the racing was nice.
NIce nice, are you making some form of driving game, sim perhaps or is this purely for graphical purposes?
Looks nice, though I don't know the details behind ray-tracing it does seem like AA needs to be turned on, or something needs to smooth the image; the rims look odd. +1 for the effort!
Looks nice, though I don't know the details behind ray-tracing it does seem like AA needs to be turned on, or something needs to smooth the image; the rims look odd. +1 for the effort!
Now you know that PIT is unacceptable behavior! :chair:
You've been hardly playing a month and already complaining about the need of more content? I've played for well over two years and still haven't got bored with it. Here's a good question how many other games actually release more developments _without_ being subscription based? VERY FEW. So just sit back, race in a UF1, or XRG or BF1 or something that works for you and wait.
Edit: SilverArrows beat me to my point.
Edit: SilverArrows beat me to my point.
I have minimal MySQL experience but I believe it would be;
"SELECT number_of_layouts FROM _layout_table_here_ WHERE username = 'Flame'";
EDIT: I don't think this is what you were asking for anymore. But I believe that would give you the number of layouts for a particular user.
"SELECT number_of_layouts FROM _layout_table_here_ WHERE username = 'Flame'";
EDIT: I don't think this is what you were asking for anymore. But I believe that would give you the number of layouts for a particular user.
As far as the loadkb / savekb it does not work with wheels / controllers. I've tried because of the recent AI with LFS project. Currently my copy of LFS is unplayable, and it is so hard to setup the virtual controller that I haven't tried going back to my wheel. I've had the the thoughts of scripts and already use the scripts for other things so I know setting up two controller configurations would not take more than an hour.
I understand spending most of the day doing X then coming home you'd like to do Y instead of continuing to do X. But with coding skills already it would take you less than 30 minutes, on one occasion and save you the headache for the remaining lifetime of LFS. I've played LFS for a very long time, the one product these days that was so worth my money that I have actually given more from buying things like high quality skins; I am no graphics enthusiast, but I've logged countless hours of enjoyment. I would recommend taking 30 minutes of your time; could do it during the weekend when it would be kinda relaxing anyways - all the info you need is available in the Command.txt, right near the bottom. I am actually going to now go make a script to setup the virtual controller - though, a virtual controller I may have to go in and add manual keyboard input to the AI project so that I can see what button id it would be with the virtual controller; also I've noticed LFS (or my G25 perhaps) changes its button IDs when another controller is also plugged in, including the virtual one.
EDIT: Here are two scripts that contain almost everything I need. You gave me the inspiration to make the Player and AI script so I could still play LFS, however for me there is still a transmission selection issue since I have it so the car selects the transmission type depending on the car. And since the AI needs sequential (as of now) I needed to disable that - anyways, since you don't use scripts for that sort of thing it should take no more time than rebinding your keys and inputting the proper values. Good luck.
NOTE: I couldn't find a way to unbind keys. I found a way to unbind axes and buttons but not keys. Shouldn't be too important.
NOTE2: Had to rename .lfs.txt so the forum would upload it. Apparently .lfs is not allowed.
Last edited by blackbird04217, .
Android that is pretty much what I mean, I guess in a sense the world doesn't have Forward/Right etc - but it certainly has Up, and in the industry it is common to call them right/forward and whatnot; the more important thing is knowing whether you are talking about world/local space - or as you put it; track/car space.
Anyways, here is a quick update of the finished progress of tonight. I do have the car working as I said in the post above. I added a multiplier so that even when 'close to the right direction' the car will still turn a little bit to have better overall accuracy. The car hits the cone, and continues circling the location where the cone was because that is what it knows how to do.
My next step is to make it follow a track. I will edit a small track in the layout, and do the appropriate changes in code; though I am looking for a volunteer that; can listen well to instructions, and has about 2hrs give or take, to make a layout around an actual track. After that I will need to figure something out to get the car speed higher than 10mph! PM me if interested in making a layout, first person whom I feel comfortable giving the task will get it and the instructions of how; I don't want more than 1 person doing it since that is unneeded work, however when I get the proof of concept done I may tell others how to make more layouts!
EDIT: Added a quick clip of me adding more speed to the AI - goes 40mph instead of 10, still hits the mark - does a little understeering to oversteering and remarkably hits the mark again!
Anyways, here is a quick update of the finished progress of tonight. I do have the car working as I said in the post above. I added a multiplier so that even when 'close to the right direction' the car will still turn a little bit to have better overall accuracy. The car hits the cone, and continues circling the location where the cone was because that is what it knows how to do.
My next step is to make it follow a track. I will edit a small track in the layout, and do the appropriate changes in code; though I am looking for a volunteer that; can listen well to instructions, and has about 2hrs give or take, to make a layout around an actual track. After that I will need to figure something out to get the car speed higher than 10mph! PM me if interested in making a layout, first person whom I feel comfortable giving the task will get it and the instructions of how; I don't want more than 1 person doing it since that is unneeded work, however when I get the proof of concept done I may tell others how to make more layouts!
EDIT: Added a quick clip of me adding more speed to the AI - goes 40mph instead of 10, still hits the mark - does a little understeering to oversteering and remarkably hits the mark again!
Last edited by blackbird04217, .
World space definitely has a right, up and forward axis; And in my world space it is as described above;
Right 1,0,0
Up 0,1,0
Forward 0,0,1
When you put a car in the world initially it starts with that same orientation, meaning the cars right is the same as the worlds right and so on. When you rotate the car 90 degrees clockwise, then the cars forward (still (0,0,1) in relation to Local Space) is now (1,0,0) in relation to World Space). Which is where things can be different from World to Local space, but each still have Right, Up and Forward vectors.
I still have yet to wrap my head around all of this stuff sometimes, though once I get setup I am good to go from there. I do think something is a bit off though, as first of all the AI should have been trying to turn after it passed the cone; so I am confused why it went straight after reaching the destination when the only thing the car can do is head towards that point in space and continue driving 10mph.
I am quite tired, so there are probably a few things wrong and likely I am not making sense somewhere down the line.
EDIT: Ok, after some extensive testing when I finally got the idea to use the 'S' key to place starting points at different angles and make sure my debug display matches I finally have the correct orientation from the MCI packets. It seems X = -sin() and Z = -cos(). It also seemed that another mistake was leading me to believe the prior way was correct, as I used wrong values from testing other situations and never changed it back. I am 90% sure now that it is corrected; and the car drives a LOT more smoothly to that cone which is what my algorithim should have been doing. Actually it now shows that it drives "too smoothly" and misses the cone, only to turn sharper later. So as expected the AI continues to chase the cone forever, and circling it at 10mph. This was the expected results. Thank-you AndroidXP for pointing out you thought it was a fluke; if you still think its a fluke let me know and I will continue investigating, although I am quite sure that it is corrected now since I started the car in several different orientations to be sure the forward pointed in the right direction in comparison to my cones.
Right 1,0,0
Up 0,1,0
Forward 0,0,1
When you put a car in the world initially it starts with that same orientation, meaning the cars right is the same as the worlds right and so on. When you rotate the car 90 degrees clockwise, then the cars forward (still (0,0,1) in relation to Local Space) is now (1,0,0) in relation to World Space). Which is where things can be different from World to Local space, but each still have Right, Up and Forward vectors.
I still have yet to wrap my head around all of this stuff sometimes, though once I get setup I am good to go from there. I do think something is a bit off though, as first of all the AI should have been trying to turn after it passed the cone; so I am confused why it went straight after reaching the destination when the only thing the car can do is head towards that point in space and continue driving 10mph.
I am quite tired, so there are probably a few things wrong and likely I am not making sense somewhere down the line.
EDIT: Ok, after some extensive testing when I finally got the idea to use the 'S' key to place starting points at different angles and make sure my debug display matches I finally have the correct orientation from the MCI packets. It seems X = -sin() and Z = -cos(). It also seemed that another mistake was leading me to believe the prior way was correct, as I used wrong values from testing other situations and never changed it back. I am 90% sure now that it is corrected; and the car drives a LOT more smoothly to that cone which is what my algorithim should have been doing. Actually it now shows that it drives "too smoothly" and misses the cone, only to turn sharper later. So as expected the AI continues to chase the cone forever, and circling it at 10mph. This was the expected results. Thank-you AndroidXP for pointing out you thought it was a fluke; if you still think its a fluke let me know and I will continue investigating, although I am quite sure that it is corrected now since I started the car in several different orientations to be sure the forward pointed in the right direction in comparison to my cones.
Last edited by blackbird04217, .
There is a difference between Local and World space yes; but in World space +Z (in my system) is still forward, and local to the car +Z is forward. It is important to know which system your coordinates are in, but should be possible to change from one to another; I haven't had to do that as of yet though.
About the "North" comment this is not really a good way of thinking about it, at least for me. Because it can change; at least I believe so- depending on how it is set out. I still have some things to work out - obviously, and who knows maybe you are right and something is still wrong and it works by a fluke.
About the "North" comment this is not really a good way of thinking about it, at least for me. Because it can change; at least I believe so- depending on how it is set out. I still have some things to work out - obviously, and who knows maybe you are right and something is still wrong and it works by a fluke.
See, you can't just imagine the LFS Y = my Z. In reality it is LFS Y = my -Z, remember my +Z points forward, and LFS +Y points backward; which is, I believe, what is causing the phenomenon where it is corrected. However, I will be testing more; my AI display showed everything exactly as I expected, I will take a screenshot of it shortly and post. EDIT- posted
As stated before I won't be doing any image processing. The pixel location would be different for different tracks, resolutions, window positions etc... Thus I won't be handling that sort of thing; the button press is the best way to detect it for now.
Last edited by blackbird04217, .
Because I am paranoid. :P
And actually;
vDir->m_fX = sin(val);
vDir->m_fY = 0.0f;
vDir->m_fZ = cos(val);
Is the code that works; likely it could be that the LFS Forward to Backward and my Backward to Forward axis's switch this around, though I whatever is happening I know that things are working from my debug display. I am still a bit excited; such a small thing yet, really such a big step.
And actually;
vDir->m_fX = sin(val);
vDir->m_fY = 0.0f;
vDir->m_fZ = cos(val);
Is the code that works; likely it could be that the LFS Forward to Backward and my Backward to Forward axis's switch this around, though I whatever is happening I know that things are working from my debug display. I am still a bit excited; such a small thing yet, really such a big step.
Woooh!! Whooo! (Yes, I am every bit excited!) AMAZING!! Whoo!
Proof attached to this post!
I have successfully driven my AI to a target! Okay, when you watch the replay you will likely die of laughter, as I came close to on the first time I saw the behavior the other day... However - the AI driver successfully hits the blue cone; which is where I set him to go! Now, to fix some behavioral issues! ENJOY!
EDIT: Ignore the 30sec penalty. That is _my_ fault as the AI is dependent on me to tell it when the lights turn green. LFS has no accurate way to detect the light change so I substituted an input key for the time.
Proof attached to this post!
I have successfully driven my AI to a target! Okay, when you watch the replay you will likely die of laughter, as I came close to on the first time I saw the behavior the other day... However - the AI driver successfully hits the blue cone; which is where I set him to go! Now, to fix some behavioral issues! ENJOY!
EDIT: Ignore the 30sec penalty. That is _my_ fault as the AI is dependent on me to tell it when the lights turn green. LFS has no accurate way to detect the light change so I substituted an input key for the time.
Last edited by blackbird04217, .
You don't need to allocate any memory to pull this off. Simply have it defined as text[240] inside the Insim packet; however when sending it get the size of your string and pad it until it is 4 bytes. The struct IS FIXED size, but what you SEND to LFS is variable sized; the reason for this is likely to save on bandwidth because a lot of InSim applications have lots of buttons going back and forth.
In this current example I am using the MCI pack, which would be the CarComp. This is a way that will get me the data available on all the cars, and not just the one being driven; of course the OutSim packet has other information that may be usable for the _actual_ driver. But at this time I am using the MCI pack; so yes I am sure that I am getting this value as an unsigned short as described from InSim quote above.
As far as my world coordinates I am fully used to it that way, doing it this way allows me to change from 2D to 3D without changing the coordinates. In my 3D worlds Z is always forward, X to the right and Y up and down; hence why I used the convention here. Since the AI project will have life outside of LFS I have used my convention. It seems I may have some issues in my conversion from LFS -> AI World interface that I have.
If not stated already I have named the project; Artificial Intelligence for Racing Simulators. Or A.I.R.S. for short. I will need to look further into things for the rotational thing. For some reason when I was reading the InSim document I understood it as Y was back to forward; maybe this explains some of my issues. I will get back to this when I figure out the problem - though I am still willing to accept help if my math above is converting something in the wrong way...
As far as my world coordinates I am fully used to it that way, doing it this way allows me to change from 2D to 3D without changing the coordinates. In my 3D worlds Z is always forward, X to the right and Y up and down; hence why I used the convention here. Since the AI project will have life outside of LFS I have used my convention. It seems I may have some issues in my conversion from LFS -> AI World interface that I have.
If not stated already I have named the project; Artificial Intelligence for Racing Simulators. Or A.I.R.S. for short. I will need to look further into things for the rotational thing. For some reason when I was reading the InSim document I understood it as Y was back to forward; maybe this explains some of my issues. I will get back to this when I figure out the problem - though I am still willing to accept help if my math above is converting something in the wrong way...
I don't know, I would likely be aiming more towards 'real drivers' since I have hopes that eventually sim-racing will get closer to that. Motion simulators do exist, it will only take time before a small enough version is built for the home. And you don't need to feel full forces, even just partial forces would give you that level of feedback needed; of course it will never be quite the same...
Anyways, I came back as I am having some issues with my world coordinates now. One of the things that I could foresee, although this should be something that can be overcome with a little effort; so I ask for some help before I beat my head against the keyboard;
In my world the following apply;
X-Axis: 1, 0, 0 (RIGHT)
Y-Axis: 0, 1, 0 (UP)
Z-Axis: 0, 0, 1 (FORWARD)
The "ConvertOrientation" function should takes in the orientation values from the MCI packet, so 32768 = 180 degrees. All my Math:: stuff has been proven to work on several projects so I already know that code is not suspect; though I am trying to make sure this is working. (The car is not going where I thought it would be and the rudimentary display I made wasn't quite what I expected. Leading me to believe this is the problem; however I am still checking my display code to make sure the units are setup correctly there as that is new code as well.) I am hoping someone could check that code out.
I would want;
X = 0, Y= 0, Z = 1 when the car is oriented with the world Z (0,0,1) Which should be an orientation of 0 I assume; it's not listed but other rotational values in InSim.txt say it rotates anticlockwise. Of course; in LFS Z is the upaxis and Y is the forward, though this should be converting that just fine. Help?
EDIT: It is listed, and not an assumption, I just never read the 'notes' before apparently! Either way it still isn't quite working for me at this time. Though I will keep checking to see if there is something wrong with my world coordinates in the AI Project.
Anyways, I came back as I am having some issues with my world coordinates now. One of the things that I could foresee, although this should be something that can be overcome with a little effort; so I ask for some help before I beat my head against the keyboard;
In my world the following apply;
X-Axis: 1, 0, 0 (RIGHT)
Y-Axis: 0, 1, 0 (UP)
Z-Axis: 0, 0, 1 (FORWARD)
namespace LFS_to_AIRS
{
void ConvertToOrientation(ice::iceVector3 *vDir, const unsigned short usAngle)
{
float val = ice::MathConverters::DegreesToRadians((usAngle / 32768.0f) * 180.0f);
vDir->m_fX = sin(val);
vDir->m_fY = 0.0f;
vDir->m_fZ = cos(val);
ice::Math::Vector3Normalize(vDir, vDir);
}
}
The "ConvertOrientation" function should takes in the orientation values from the MCI packet, so 32768 = 180 degrees. All my Math:: stuff has been proven to work on several projects so I already know that code is not suspect; though I am trying to make sure this is working. (The car is not going where I thought it would be and the rudimentary display I made wasn't quite what I expected. Leading me to believe this is the problem; however I am still checking my display code to make sure the units are setup correctly there as that is new code as well.) I am hoping someone could check that code out.
I would want;
X = 0, Y= 0, Z = 1 when the car is oriented with the world Z (0,0,1) Which should be an orientation of 0 I assume; it's not listed but other rotational values in InSim.txt say it rotates anticlockwise. Of course; in LFS Z is the upaxis and Y is the forward, though this should be converting that just fine. Help?
EDIT: It is listed, and not an assumption, I just never read the 'notes' before apparently! Either way it still isn't quite working for me at this time. Though I will keep checking to see if there is something wrong with my world coordinates in the AI Project.
Last edited by blackbird04217, .
Sure I don't know Java syntax directly but I think I would be able to pickup the ideas. I finished reading the NN chapter in that book; all except the source code implementation. I like some of the ideas, but would certainly need to test the idea of this outside of realms of the racing simulation; on something very simple and then one step further than simple without over complicating things. I now see that the implementation of NN is considered the easy part of the process, and that the hard part, time consuming part and challenging part is to get the required results.
I do understand that X,Y,Z inputs are patterns which if you answer with A will always lead to B; but when it comes to handling traffic, and other things I think this will lead to less than desired results. In other words, I can't think of any way to accomplish training the NN; which is the hard part of NN's!
I do understand that X,Y,Z inputs are patterns which if you answer with A will always lead to B; but when it comes to handling traffic, and other things I think this will lead to less than desired results. In other words, I can't think of any way to accomplish training the NN; which is the hard part of NN's!
Like I mentioned you would allow everyone to finish their race; which the timer keeps going and a special InSim based application could be used to retrieve the time that each person finished the distance. So even if LFS thinks you are done racing you still need to do the additional 2 laps that you were lapped by.
Ok, well from my 5 minutes spend reading in, not my college book but another AI book I bought, I have learned quite a bit about my own brain... Some of which as you said was astonishing and I looked at the individual letters on the page for a moment and was like; damn - this reading thing is perfect for NNs due to the patterns that are presented.
However, although I am kinda excited about continuing this read I a currently starting to feel more negative about NN's in the AI here. I am not so sure that a racing simulation has patterns in the way NN's deal with them. That said I do need to keep reading and yes racing has a pattern; go around the track. But from a moment to moment pattern, I am less sure about. I got to get deeper into how it would be implemented before I can really decide whether it is useful or not.
However, although I am kinda excited about continuing this read I a currently starting to feel more negative about NN's in the AI here. I am not so sure that a racing simulation has patterns in the way NN's deal with them. That said I do need to keep reading and yes racing has a pattern; go around the track. But from a moment to moment pattern, I am less sure about. I got to get deeper into how it would be implemented before I can really decide whether it is useful or not.
Not that I want to waste your time, especially where i have not yet gone into reading it myself; which is something I promise I will do at somepoint, likely today if I can find the time; which considering my current state I should be able to do, as I am currently keeping track of the AI thread, and working on the AI project itself. Attempting to get the car to drive towards a point. Interestingly enough, it starts to; and then goes the opposite direction.
Sorry, I got side-tracked while trying to form a question. I get the input/output idea. But I don't understand very well what happens on the hidden layer. Obviously this is likely where the meat is. At least, I am thinking so... I am trying to think of an easier example than driving for you to use to explain that layer; and again, don't bother if it is something that I really will need to read on to understand in the first place. I can likely follow any other simple example you have even if it doesn't involve four tires a couple pedals and a steering wheel!
I am quite lost at fitting this into the project; though that is understandable since I need some reading on. The breif mentioning on this topic in college, (including the article I read and wrote about), has long escaped my memory... Going to dig out the books now.
Sorry, I got side-tracked while trying to form a question. I get the input/output idea. But I don't understand very well what happens on the hidden layer. Obviously this is likely where the meat is. At least, I am thinking so... I am trying to think of an easier example than driving for you to use to explain that layer; and again, don't bother if it is something that I really will need to read on to understand in the first place. I can likely follow any other simple example you have even if it doesn't involve four tires a couple pedals and a steering wheel!
I am quite lost at fitting this into the project; though that is understandable since I need some reading on. The breif mentioning on this topic in college, (including the article I read and wrote about), has long escaped my memory... Going to dig out the books now.
This is actually a simple one to explain, it has to do with the landing of the angle. The planned jump took a lot of things into account; this is very evident while watching the angles clip above. You can see that he had reached speed, and feathered it to maintain that speed while launching. The hard part about the jump, as stated in my previous posts, was the making sure X speed was achieved and maintained for launch; after that it was down to gravity (which doesn't magically pull harder now and again). Of course, wind plays another role; and tends to cancel things of this nature.
That said, the Escort video showed them slamming down onto flat ground, the worst possible landing situation; which is why in extreme sports you find people not able to ride/skate/continue away from a landing when it is not on a ramp (after a big jump) because of the force from the impact; when landing on a slope it gets absorbed a lot easier than a flat. Hence, less damage.
Unfortunately at this time it is not possibly to detect if a wheel is locked or spinning rapidly via Insim/OutSim or OutGauge. I know this because I have been looking for a way to do this for my AI project.
That said I really like the idea. I've been hoping for FFB pedals for quite some time. Though the brake is really the one that could use FFB; especially with brake-fade and the pedal just drops to the floor! That would make even a simulation experience scary!
That said I really like the idea. I've been hoping for FFB pedals for quite some time. Though the brake is really the one that could use FFB; especially with brake-fade and the pedal just drops to the floor! That would make even a simulation experience scary!
Ahhh yes, that makes sense now. Basically everyone does 100laps (or some high number) at event 1. Then on event 2 everyone does another amount of laps at another combo. They continue driving after the race has finished until each driver has 100 laps. Take the times and add them up; The winner should be somewhere close to 168hrs. It is a distance race more than a time race, though the distance given is something that would take roughly 168hrs to complete.
I am certainly hopeful that it becomes 'human-like'. I assume that the reason a lot of people have trouble understanding my intentions is likely because; they may have changed (though I am not sure they did), and there are probably several layers of intentions that fight at eachother / conflict. I am guessing here as it seems that no one seems to understand what my intention is. (This includes the possibility that perhaps I don't understand my intentions well enough to explain them).
That said, I do know my intention is to remove some things that racing AI have done for years; in my mind cheating. This is acceptable for games, but not for simulations. If I could make the AI behave believably like a person within the constraints I set out for myself than that would be amazing, I would call the 'competitiveness' a sub-goal though, especially when it comes time for the car to judge traffic and handling scenario's that a human can just change input and everything is okay; there are too many special cases.
That said; I am trying to get the Ai to work within human constraints. We don't have super fast reaction skills, while most AI algorithms (including that of LFS) do. We can't spin the steering wheel from 90* to 180* in 0.0001 seconds; whereas some AI algorithms can, ad do. Things like this will come from an interface the AI needs to deal with to input the controls;
Here is something like what my idea is...
Simulation -> Reference Points & Information -> AIWorld -> AI Sensors -> AIDriver -> Decision Layers -> Desired Control Output -> Reaction Time Checker -> Real Control Output -> Simulation -> loop
The decision layer and reaction time checker are the only things left untouched at this moment. Everything else has a structure within my simulation, even if it is not fully linked up to LFS or other things yet. The reaction sensor thing will behave a bit like this (in case you missed that post somewhere here).
Scenario A: RPM: 4500 Driver wants to Shift Up .25 seconds later driver shifts up. (Simulating H-shifter where driver takes hand from steering wheel to shifter. Actual time would need to be tested to human limits) In this case the shift actually happened around ~4800 depending on acceleration.
Scenario B: RPM 3900, Driver prepares to shift. (signals that the arm is moving toward the shifter which takes .25 seconds to complete the action). RPM hits 4500 driver shifts which takes about .05 to take place since the hand is on the shifter already. (Again times need to be worked out.)
This scenario is for h-shifters, cars with paddles obviously don't need the hand to move but I wanted to point out the level of detail I want to put into this layer of the AI control/reaction time thing. Some sort of "Prepare for Twitch Steering" could take place as well, since when the AI knows they are on the verge of the limits they could use that to successfully catch it. This comes with experience on a human, knowing that the car may be upset during a particular corner and preparing for it. However it takes concentration to do this, and I do want to have the AI have some form of emotion gauge to wear them down after time or something. This is also the area where Ai difficulty could be changed; more or less ability to concentrate / judge distances... Like I said, still need to work on the gameplan here.
That said, I do know my intention is to remove some things that racing AI have done for years; in my mind cheating. This is acceptable for games, but not for simulations. If I could make the AI behave believably like a person within the constraints I set out for myself than that would be amazing, I would call the 'competitiveness' a sub-goal though, especially when it comes time for the car to judge traffic and handling scenario's that a human can just change input and everything is okay; there are too many special cases.
That said; I am trying to get the Ai to work within human constraints. We don't have super fast reaction skills, while most AI algorithms (including that of LFS) do. We can't spin the steering wheel from 90* to 180* in 0.0001 seconds; whereas some AI algorithms can, ad do. Things like this will come from an interface the AI needs to deal with to input the controls;
Here is something like what my idea is...
Simulation -> Reference Points & Information -> AIWorld -> AI Sensors -> AIDriver -> Decision Layers -> Desired Control Output -> Reaction Time Checker -> Real Control Output -> Simulation -> loop
The decision layer and reaction time checker are the only things left untouched at this moment. Everything else has a structure within my simulation, even if it is not fully linked up to LFS or other things yet. The reaction sensor thing will behave a bit like this (in case you missed that post somewhere here).
Scenario A: RPM: 4500 Driver wants to Shift Up .25 seconds later driver shifts up. (Simulating H-shifter where driver takes hand from steering wheel to shifter. Actual time would need to be tested to human limits) In this case the shift actually happened around ~4800 depending on acceleration.
Scenario B: RPM 3900, Driver prepares to shift. (signals that the arm is moving toward the shifter which takes .25 seconds to complete the action). RPM hits 4500 driver shifts which takes about .05 to take place since the hand is on the shifter already. (Again times need to be worked out.)
This scenario is for h-shifters, cars with paddles obviously don't need the hand to move but I wanted to point out the level of detail I want to put into this layer of the AI control/reaction time thing. Some sort of "Prepare for Twitch Steering" could take place as well, since when the AI knows they are on the verge of the limits they could use that to successfully catch it. This comes with experience on a human, knowing that the car may be upset during a particular corner and preparing for it. However it takes concentration to do this, and I do want to have the AI have some form of emotion gauge to wear them down after time or something. This is also the area where Ai difficulty could be changed; more or less ability to concentrate / judge distances... Like I said, still need to work on the gameplan here.
I'm going to say that the title is very misleading.
From this statement I gather that he wants a championship; decided by points, or some other form; possibly even where gaps are kept from race to race... But his idea is (from my understanding) to do an endurance race that lasts 1 week in virtual time, and each race/event adds to that virtual timer. It isn't a week straight.
14 races * 12 = 7 * 24. These 14 races could be spread out over the entire year yet his idea of a "1 week race" could be happening. I don't know, maybe I am misunderstanding it. The idea seems fine in concept though I don't know if it really differs from DoP or MoE except for the fact that he states that there isn't multiple car classes; though a possibility of the car changing?? I like the car changing from event to event if that is what is meant by the statement.
From this statement I gather that he wants a championship; decided by points, or some other form; possibly even where gaps are kept from race to race... But his idea is (from my understanding) to do an endurance race that lasts 1 week in virtual time, and each race/event adds to that virtual timer. It isn't a week straight.
14 races * 12 = 7 * 24. These 14 races could be spread out over the entire year yet his idea of a "1 week race" could be happening. I don't know, maybe I am misunderstanding it. The idea seems fine in concept though I don't know if it really differs from DoP or MoE except for the fact that he states that there isn't multiple car classes; though a possibility of the car changing?? I like the car changing from event to event if that is what is meant by the statement.
FGED GREDG RDFGDR GSFDG