This is a snail of a thread, pretty much 1 post every ~4 months or more.
Anyways MaKaKaZo, why don't you use the flag provided by InSim to check whether the interface is shown or not. I recently read about it in InSim.txt while I was searching for a solid way to detect certain things.
Anyways MaKaKaZo, why don't you use the flag provided by InSim to check whether the interface is shown or not. I recently read about it in InSim.txt while I was searching for a solid way to detect certain things.
I've usually used dynamic arrays, or vectors (std::vector in C++) for tracking my UCIDs and PLIDs. This is an array that grows and shrinks as more/less players/connections come to the server. Though really it is a little more complicated because my 'DriverManagementSystem' which handles new connections, renaming, joining/spectating etc does all this behind the scenes for me and it's been forever since I touched that code (2yrs I think?). But I remember doing something where the PLID and UCID knew about eachother and I think I actually had a list of PLIDs for each connection since there can be multiple.
This way it only takes the memory needed. You might be right with the UCID thing, but if by chance LFS moved the limit to 64 in race and more for spectating what would happen to your code? It'd break, and InSim likely wouldn't need to be updated for that switch to happen. Hope this helps with array stuff, I don't know about dynamically sizing arrays in php because I don't know php : / but I know all about it in C/C++!
This way it only takes the memory needed. You might be right with the UCID thing, but if by chance LFS moved the limit to 64 in race and more for spectating what would happen to your code? It'd break, and InSim likely wouldn't need to be updated for that switch to happen. Hope this helps with array stuff, I don't know about dynamically sizing arrays in php because I don't know php : / but I know all about it in C/C++!
I wasn't saying they didn't have relays or indicators. Just stating I am not sure the GTR class should since it is a purpose built race car, not a daily driver/track car combo. That said I understand the relay (which is required for the indicator) is what makes the sound we are all familiar with. But I just stated that with the GTR class it is a toss up whether they should even have indicators (lights included) in the first place. It is kinda like the single seaters don't have headlights or indicators - because they are purpose built race cars.
I've always assumed they could get to 255. I guess it depends how fast people are joining/spectating or connecting/disconnecting. I wouldn't go assuming those values though, since the type is a byte the value can range between 0 and 255 even if in practice you rarely see anything larger than what you say. (Unless you have significantly trustworthy documentation, although I still don't know why you'd put in the assumption since it is a byte still... My thoughts / opinions.
How is your C++ practice going?
How is your C++ practice going?
Umm, we needed to know?
I mean, really that should be your first 'tweet' I believe it is called...
(This is all being said sarcastically not angrily! So please take it as the funny that it is not.)
I mean, really that should be your first 'tweet' I believe it is called...
(This is all being said sarcastically not angrily! So please take it as the funny that it is not.)
There was a discussion about this earlier. A few things I remember about it was;
Some people saying race cars remove the sound ticker.
Others saying the sound ticker would exists since it is the mechanism that changes from light on to light off state as some form of mechanical reason.
Some people agreed with the idea,
others did not.
Some people said the improvement is too small, and then the response -> why say no to small improvements.
I am probably forgetting things since I had only briefly read that thread. Not meaning any harm from saying the above, not even saying I agreed with or that there is truth in the statements just saying what I remember.
That said, I think it is an interesting improvement for the road cars. Cars that are daily drivers that are track ready as well. STD, TBO LRF etc. GTR I remain skeptical about since it is a purpose built race car, designed for the track. While some track policies may allow/require indicators, I am pretty sure there are lots that don't/disallow. So my opinion here is 50/50 for the GTR classes.
Some people saying race cars remove the sound ticker.
Others saying the sound ticker would exists since it is the mechanism that changes from light on to light off state as some form of mechanical reason.
Some people agreed with the idea,
others did not.
Some people said the improvement is too small, and then the response -> why say no to small improvements.
I am probably forgetting things since I had only briefly read that thread. Not meaning any harm from saying the above, not even saying I agreed with or that there is truth in the statements just saying what I remember.
That said, I think it is an interesting improvement for the road cars. Cars that are daily drivers that are track ready as well. STD, TBO LRF etc. GTR I remain skeptical about since it is a purpose built race car, designed for the track. While some track policies may allow/require indicators, I am pretty sure there are lots that don't/disallow. So my opinion here is 50/50 for the GTR classes.
Does the OP know that you can be driving along the line and all of a sudden be pulled off exactly how he is talking. It is still the drivers fault for not changing the tire sooner, for locking up the brakes often or cutting a tire during a turn. The tires in LFS do pop, for reasons of the drivers fault. And when it pops it can be quite unexpected, go race some longer stints.
S3 isn't finished so you can't download without the 'hassle' of waiting.
If you mean pay for S3 without the promise, guarantee or anything that S3 will or will not ever be yours, you can add money to your LFS account, which would be used for S3 when it is finalized. Since there is no release dates, or things truly set in stone, I would recommend just waiting and paying when it comes.
If you mean pay for S3 without the promise, guarantee or anything that S3 will or will not ever be yours, you can add money to your LFS account, which would be used for S3 when it is finalized. Since there is no release dates, or things truly set in stone, I would recommend just waiting and paying when it comes.
Are you talking about building to 'exact' specifications?
I stated I'd like to build an LX4/LX6. In real life these cars are comparable to Lotus 7's, Caterham's etc. Or the popular choice for builders; a 'locost'. This doesn't violate copyrights, yet I would still consider when I do end up building mine that it will be like an LX4/LX6 depending on how I do the build.
Eitherway, it wouldn't violate any copyrights or laws to build something to the specifications of a RAC, MRT, BF1 etc - it would only do so if you tried commercially selling it to race teams or the public for that matter. For personal use there isn't anything anyone can do with you buying all the parts and following a pattern/specification etc... It only fails legally when trying to sell the product or trying to patent the idea as your own.
I stated I'd like to build an LX4/LX6. In real life these cars are comparable to Lotus 7's, Caterham's etc. Or the popular choice for builders; a 'locost'. This doesn't violate copyrights, yet I would still consider when I do end up building mine that it will be like an LX4/LX6 depending on how I do the build.
Eitherway, it wouldn't violate any copyrights or laws to build something to the specifications of a RAC, MRT, BF1 etc - it would only do so if you tried commercially selling it to race teams or the public for that matter. For personal use there isn't anything anyone can do with you buying all the parts and following a pattern/specification etc... It only fails legally when trying to sell the product or trying to patent the idea as your own.
I agree UCID is a faster comparison, as I mentioned above that was the downer for doing it my way, but when your checking events; Grid Reorder, Race Finish, Joining/Spectating then the time wasted in string compare is a fine sacrifice. I consider a 'session' the amount of time my application is running, not the amount of time that a client is connected to the server. Therefor the UCID changes during a session, in my eyes. And whereas I have a solution, by creating a third id unique to my program for each client - I haven't seen the need - though I see the need to if using that for a real-time update (MCI etc... or just running a real-time application instead of event based that runs at 15fps at most).
CPR.PType ?? What is this, I don't have any documentation on it.
CPR.PType ?? What is this, I don't have any documentation on it.
LFS does have Single Player mode and Tutorials that get unlocked online to get S1 or S2 licenses. If you get a new LFS patch you need to re-unlock your license, again online.
Yes you can play the demo; a few cars with a track! And even a few tutorials all without an internet connection - assuming you had access to LFS in the first place.
Yes you can play the demo; a few cars with a track! And even a few tutorials all without an internet connection - assuming you had access to LFS in the first place.
That would be why I use the username, it is the one constant, that is always different for each user. I would not recommend keeping your own unique ID for 100 days per client... Instead, after 10 to 15 minutes of the client being, and staying disconnected from the server (perhaps longer if desired) be sure to remove the information - saving what is necessary (not the ID directly, although you can do that to if you make a unique id per username, although I prefer to keep the username the unique constant. (Did that make sense?).
The reason is simple, say you have your application on a public server that has been running for 100days, (over three months). Think of the number of different users that have connected and disconnected. Now for giggles, take that number an multiply by the amount of information you keep for each client; timeLastOnline, numLapsDriven, playerName, etc etc... It will be a lot of memory, and a lot that could be safely saved and stored until the next time that user jumps online, even if it is 20 minutes later.
But my first post describes the way I've used it, I would like to see other thoughts/takes on it. Though, my LFS to AIRS project uses it in slightly different way.
Connecting only to local copy, no servers. Making sure that only 1 connection exists (UCID = 0) and a few other things. Then I need to find the player's carm as that is the car my AI Controller can control and I need to save / update the PLID whenever it changes. Then I use MCI and OutGauge packets to update the AI by converting that information to a way that AIRS excepts and sending it to the AIRS project. Though, this is likely so far different than a server system, or even any other single player application that it doesn't exactly apply.
The reason is simple, say you have your application on a public server that has been running for 100days, (over three months). Think of the number of different users that have connected and disconnected. Now for giggles, take that number an multiply by the amount of information you keep for each client; timeLastOnline, numLapsDriven, playerName, etc etc... It will be a lot of memory, and a lot that could be safely saved and stored until the next time that user jumps online, even if it is 20 minutes later.
But my first post describes the way I've used it, I would like to see other thoughts/takes on it. Though, my LFS to AIRS project uses it in slightly different way.
Connecting only to local copy, no servers. Making sure that only 1 connection exists (UCID = 0) and a few other things. Then I need to find the player's carm as that is the car my AI Controller can control and I need to save / update the PLID whenever it changes. Then I use MCI and OutGauge packets to update the AI by converting that information to a way that AIRS excepts and sending it to the AIRS project. Though, this is likely so far different than a server system, or even any other single player application that it doesn't exactly apply.
Dygear, did you look at the post date? 3 1/2 year bump!
/sarcasm
/sarcasm
In my InSim applications I have a Connection/Driver manager. It allows only one -PLAYER- per connection. (With the exception of my AI project which is different altogether). I always use the UCID whereever possible, however more importantly almost all my lookups are done via username, which will get me the correct UCID or PLID (even if disconnect/reconnect, pit/spec/join had occurred). I use the username because it is unique _always_ for each individual racer, and it does not change for that racer. If a username is not connected for 10 minutes (on my casual systems that I've made) I throw the information about the user out of memory, saving what is needed to file/disk etc...
This was the easiest, most flexible way I found of doing this for Dash For Cash, and Head-to-Head. Both of which needed to keep information about a driver in the event of a disconnect/reconnect. By using the username I can get all information about the player; their current state, Playing, Spectating. Their Player Name (used for all LFS Displays), their UCID and PLID. Sure the downfall is a string comparison instead of a byte == byte comparison but for the flexibility, ease of use and everything this is well worth it - IMO. It would always be possible to make a new ID for my application to remove the need of string comparisons, but that has always been overkill IMO for something that runs with event-based structure. (I don't collect NLP / MCI messages during these applications, and if I was to start I would likely do my above example and create my own ID that stays the same for each racer.
I think that is what you were asking... It is how I work the system anyway during my casual and league systems.
This was the easiest, most flexible way I found of doing this for Dash For Cash, and Head-to-Head. Both of which needed to keep information about a driver in the event of a disconnect/reconnect. By using the username I can get all information about the player; their current state, Playing, Spectating. Their Player Name (used for all LFS Displays), their UCID and PLID. Sure the downfall is a string comparison instead of a byte == byte comparison but for the flexibility, ease of use and everything this is well worth it - IMO. It would always be possible to make a new ID for my application to remove the need of string comparisons, but that has always been overkill IMO for something that runs with event-based structure. (I don't collect NLP / MCI messages during these applications, and if I was to start I would likely do my above example and create my own ID that stays the same for each racer.
I think that is what you were asking... It is how I work the system anyway during my casual and league systems.
LX4 / LX6 - Considering this is a life goal of mine I am sure I will do it, in about 10 more years. (Not built to LFS Specifications though.)
Nowhere in there does it say you bought it from a store. You could have bought it online. Next time read your own damn post before accusing me, what was with the attitude?
Last edited by blackbird04217, .
Reason : Added Emphasis
You're complaining about downloading a game and not being able to activate/play it until it is released? That is idk, on the high end of idiocy...
Come on now, if the game is released for Feb th, 2010 you would need to expect that you can download, pre-order or 'get' your copy without being able to play it until it is officially released. Kinda like watching a band in concert, you don't complain when you get there 3hrs early to watch an empty stage... It is expected the band will come on at the time they said they would . . .
Wow.
Come on now, if the game is released for Feb th, 2010 you would need to expect that you can download, pre-order or 'get' your copy without being able to play it until it is officially released. Kinda like watching a band in concert, you don't complain when you get there 3hrs early to watch an empty stage... It is expected the band will come on at the time they said they would . . .
Wow.
It really depends on the bank and other things. General policy here is the money will be transferred withing the 'business hours' of the 'business day'. So if it was place 8pm today it would be transferred tomorrow at 9am. (Business hours are typically 9am to 5pm). But if it was on 8pm Saturday, it would have taken until 9am this morning...
Also a catch a lot of banks have, that I've noticed, is they will hold the money until the check clears. Meaning, they give you the first $100 of the check, but the remainder will be held for two days, three days sometimes a full week before it 'clears'. Like I said though - this depends greatly on the bank policy. I've seen that transferring stuff online from my savings account to checkings account happens within the business hours, but I can initiate the transfer anytime. Since both accounts are with the same bank I do not need to wait for things to 'clear;.
I don't know the general rules of thumb over on that side of the puddle though.
Also a catch a lot of banks have, that I've noticed, is they will hold the money until the check clears. Meaning, they give you the first $100 of the check, but the remainder will be held for two days, three days sometimes a full week before it 'clears'. Like I said though - this depends greatly on the bank policy. I've seen that transferring stuff online from my savings account to checkings account happens within the business hours, but I can initiate the transfer anytime. Since both accounts are with the same bank I do not need to wait for things to 'clear;.
I don't know the general rules of thumb over on that side of the puddle though.
That works great! Thanks Morpha, by the way I had to re-update my InSim.txt apparently ... I probably would have noticed that, but I didn't have RIP packets... Or Screenshot stuff... Hmm. Well, now I wonder if there is a way to detect Hotlap mode. Or at the very least to tell LFS to invalidate a hotlap. Not that I think my AI will compete with WRs but I don't want someone using it for any sort of malicious activity. Although I really don't know if I will share in the first place, but better to be safe all around than not.
Quick bragging note; my AI beat the LFS (pro) AI on the dragstip with LX6 (0.80) and FZR (0.24)... :P
Quick bragging note; my AI beat the LFS (pro) AI on the dragstip with LX6 (0.80) and FZR (0.24)... :P
InSim Checking for Single Player
Okay, so for my Artificial Intelligence in Racing Simulators project using Live For Speed, I really want to limit this to Single Player only, even better if I could limit to "Single Player" _ONLY_ meaning; no Multiplayer, no Hot lapping or Training.
Inside the IS_STA packet I can detect if the player is playing by checking to see if ISS_GAME is turned on _AND_ ISS_MULTI is turned off. However, using InSimSniffer, with many different situations I've found that even while watching a multiplayer replay ISS_GAME is turned on AND ISS_MULTI is turned off. Which would allow the LFS -> AIRS interface to believe it can successfully work, when it can not.
I can so far detect when the player is watching a SPR, connected to a server - including their own or multiplayer in general (which is a good elimination as that prevents people from abusing this to gain miles in LFS or compete with the AIRS).
But I still need to detect hotlapping and MPR correctly, any thoughts ideas or things I've overlooked?
EDIT: Ahaa. I can now detect the MPR correctly, actually I was already detecting it correctly. My detection works like this so far, still need to detect Hot Lap mode...
"OnConnect" -> Request IS_STA from LFS using the TINY...
When STA is received, set "IsSafeToUseAIRS = false".
Only set "IsSafeToUseAIRS = true" IF the ISS_MULTI is off and ISS_GAME is on.
If IsSafeToUseAIRS then request IS_NCN from LFS.
When NCN is sent, make sure there is only 1 Total connection, and that the UCID is 0, 'host'. Which will eliminate MPR, at least those where the player was not alone on the host. . . Hmmm.
Still would like a way to detect hotlapping, and perhaps a better way to detect MPR.
Inside the IS_STA packet I can detect if the player is playing by checking to see if ISS_GAME is turned on _AND_ ISS_MULTI is turned off. However, using InSimSniffer, with many different situations I've found that even while watching a multiplayer replay ISS_GAME is turned on AND ISS_MULTI is turned off. Which would allow the LFS -> AIRS interface to believe it can successfully work, when it can not.
I can so far detect when the player is watching a SPR, connected to a server - including their own or multiplayer in general (which is a good elimination as that prevents people from abusing this to gain miles in LFS or compete with the AIRS).
But I still need to detect hotlapping and MPR correctly, any thoughts ideas or things I've overlooked?
EDIT: Ahaa. I can now detect the MPR correctly, actually I was already detecting it correctly. My detection works like this so far, still need to detect Hot Lap mode...
"OnConnect" -> Request IS_STA from LFS using the TINY...
When STA is received, set "IsSafeToUseAIRS = false".
Only set "IsSafeToUseAIRS = true" IF the ISS_MULTI is off and ISS_GAME is on.
If IsSafeToUseAIRS then request IS_NCN from LFS.
When NCN is sent, make sure there is only 1 Total connection, and that the UCID is 0, 'host'. Which will eliminate MPR, at least those where the player was not alone on the host. . . Hmmm.
Still would like a way to detect hotlapping, and perhaps a better way to detect MPR.
Last edited by blackbird04217, .
That would be because iSize is not a constant, so the size of the array is unknown - todo that you would need dynamic memory, which for your current situation I advise to stick with 1024, or 2048 if needed... At least for now.
I''m not too familiar with open source licenses, though recently I've been trying to use open source projects to get better at analyzing code. Something one of the companies I applied to mentioned I should practice by looking at open source projects. Problem is I haven't got a single one to build properly, they all have dependencies and strange stuff out of the gate... Why can't you just get a project and go? -sorry for the rant. I was going to ask if anyone knew of a small resource that described in laymen terms the advantages/disadvantages/purposes of each license as 'general overlook' versus getting nitty and gritty. Not exactly C++ related but it was brought up in the thread.
Side note, where cout has type checking, I find printf much more readable and at times easier to use. I'm not saying you can't make mistakes though;
So where as you do have to be more careful there is nothing wrong with it. In my opinion if you are coding you need to be careful so this helps stay on your toes.
Side note, where cout has type checking, I find printf much more readable and at times easier to use. I'm not saying you can't make mistakes though;
std::string strHello = "Hello";
char szHello[] = "Hello";
printf("char * = %s\n", szHello);
printf("string = %s\n", strHello); //BAD CODE
printf("string = %s\n", strHello.c_str()); //Good.
//OR the equivalent
cout << "char * = " << szHello << '\n';
cout << "string = " << strHello << '\n'; //works fine because string overloaded the << with iostream.
cout << "string = " << strHello.c_str() << '\n'; //also works
So where as you do have to be more careful there is nothing wrong with it. In my opinion if you are coding you need to be careful so this helps stay on your toes.
Well, no - but yes all at the same time. The AI still has very limited knowledge / intelligence at this point. Here is a list of goals the AI does once it gets the 'green light'
Find Next DriveTo Target. If Target is to left, turn steering left, it Target is to the right, turn steering to the right. That as simple as that gets, but it does not look passed the next cone. Meaning, it always gets to cone A before going to cone B. Hence the subtle zig-zag you see.
(I say subtle because if you look at the very first replay posted you will see funny stuff)
Now that the AI knows where it is going it tries to maintain a speed of 80mph. Way too fast for turning, but the primary goal was to make sure the AI shifted during this test, which it did successfully. Basically if speed is < 70mph hit full throttle. If 70 < speed < 80 it will fade off the throttle and aim for ~80mph.
Now that the AI can turn, and keep a desired speed it starts checking the driving functions. Should I be shifting up? (RPM too high) Should it be shifting down? (RPM too low). While shifting it presses clutch, releases throttle and performs the shifting. (Currently sequential although I have a feeling H-Shifter would be far easier to implement. Gear = X and be done... But sequential is finally working.
The last thing the AI does is checks for the RPM dipping too low, indicating a point of stalling at which point it hits the clutch.
That is all the intelligence so far, so there isn't much - in fact, the AI can not start the car if it stalls, can not shift into reverse, can not even hit the brakes as demonstrated by that beautiful replay! All it can do is turn from cone to cone, maintain speed and shift up/down depending on the GaugeSensor.
I think my next step is to take this to the drag strip, and try racing against the LFS AI with my own. . . Hmmm. Going to edit an AI layout for the dragstrip, consisting of 1 cone to DriveTo and then it's all about the shifting... Oughta be interesting! Will likely edit in ~5 minutes with a replay here. So do check.
EDIT: Can't race against the AI because of my LFS to AIRS interface needs some work. InSim needs to know which car is which, and handle it properly... Also, my AI does outstandingly bad at driving in a straight line at high speed... Especially in my 'drag set'
Find Next DriveTo Target. If Target is to left, turn steering left, it Target is to the right, turn steering to the right. That as simple as that gets, but it does not look passed the next cone. Meaning, it always gets to cone A before going to cone B. Hence the subtle zig-zag you see.
(I say subtle because if you look at the very first replay posted you will see funny stuff)
Now that the AI knows where it is going it tries to maintain a speed of 80mph. Way too fast for turning, but the primary goal was to make sure the AI shifted during this test, which it did successfully. Basically if speed is < 70mph hit full throttle. If 70 < speed < 80 it will fade off the throttle and aim for ~80mph.
Now that the AI can turn, and keep a desired speed it starts checking the driving functions. Should I be shifting up? (RPM too high) Should it be shifting down? (RPM too low). While shifting it presses clutch, releases throttle and performs the shifting. (Currently sequential although I have a feeling H-Shifter would be far easier to implement. Gear = X and be done... But sequential is finally working.
The last thing the AI does is checks for the RPM dipping too low, indicating a point of stalling at which point it hits the clutch.
That is all the intelligence so far, so there isn't much - in fact, the AI can not start the car if it stalls, can not shift into reverse, can not even hit the brakes as demonstrated by that beautiful replay! All it can do is turn from cone to cone, maintain speed and shift up/down depending on the GaugeSensor.
I think my next step is to take this to the drag strip, and try racing against the LFS AI with my own. . . Hmmm. Going to edit an AI layout for the dragstrip, consisting of 1 cone to DriveTo and then it's all about the shifting... Oughta be interesting! Will likely edit in ~5 minutes with a replay here. So do check.
EDIT: Can't race against the AI because of my LFS to AIRS interface needs some work. InSim needs to know which car is which, and handle it properly... Also, my AI does outstandingly bad at driving in a straight line at high speed... Especially in my 'drag set'
Last edited by blackbird04217, .
If you want direct contact with me, for throwing questions at or whatever, PM me and I'll give you my Instant Messenger info.
My example was a little over the top, really you would need to call the 'big' function anytime you go over 1kb, though like I said, in common practice I've never hit that limit in years of coding like that - then again, it is also ony used in debug builds for me- getting completely removed in Release builds.
My example was a little over the top, really you would need to call the 'big' function anytime you go over 1kb, though like I said, in common practice I've never hit that limit in years of coding like that - then again, it is also ony used in debug builds for me- getting completely removed in Release builds.
FGED GREDG RDFGDR GSFDG