OK.. I guess I'll give an update to my progress, if you want to call it that. Lately I've lost intrest in LFS for multiple reasons but now that things have calmed down a bit with me and with the new LFS progress, I think I will get back into this more.

I'm still poking away at the new version of LYTe/my hobby 3D engine I mentioned waay back in 2007. I've made a lot of progress on it since then of course.. but not near as much as I would have liked. Its turned more into a general game engine than anything LYTe specific really. It all still applies in a way.. My plan is to still create LYTe of course but I'm not so sure anymore. Other people have been making a lot of progress on things (especially some sweet stuff for autox) and with my absence, its only a matter of time before someone works on something better.

That time is now here I guess so I might as well come clean, show what I've got and see what others are planning to do so we can collaborate on some more sweet stuff! Stay tuned for a new post soonish with what I've got so far and we can go from there..

Cheers too!

Yeah, += is good in C++. No problems there.. But I do see a problem with the method of distance calculation. In the MCI packet, speed is meters per second.. Well, in order to get the distance you have to know how much time has passed. Which is what that 2 is I guess, 1 packet every 500ms? On top of that, the speed is variable between the 2 packets. Right? (I didn't work anything out, just theory )

For the 0, you have make sure its not integer division, which I think that is as speed is a word and the rest of it is whole numbers. I would copy speed into a float then do the math.. Also, check out C++ casts instead of plain C ones..

Instead of speed, another distance solution might be to use the X,Y,Z point and calculate the distance between the current and the last packet using something like:

However this will also be an approximation as it will be a straight line between the points and not a curve like the driver may have taken. On a hairpin for example. In either case, the more points the better.

One final thing that might work is messing with the NLP packets. I'm not sure how the nodes work but if you know where they are and which node the driver is currently at, then you could get the distance between the nodes.

Hope this helps!

I'm interested! I've been messing around with C++ and OpenGL for a couple years and been thinking of making some type of game. It started out as an upgrade to LYTe but I haven't made any real progress. And with the fade in community around here (I can't complain really, I'm no help), and my lack of a good racing setup, no motivation either.

The hardest thing for me would be physics but there are engines for that. Kart racing would be sweet and fun as would rally racing. Ooh, how about rally kart racing? Quad racing?

Yeah, TORCS is out of date but VDrift seems pretty nice. Haven't played either one though.. What about a realism update for Super TuxKart? :P

Oh the possibilities are endless when its DIY. Trade off is it takes forever to get there.. Hmm

WOULDBLOCK just means the connection is busy at the moment and is saying if I were to wait for it, it would block/freeze your application to do so. So it sends that message and the proper response is to stop sending/receiving and wait for another send/recv event from winsock to notify you to continue..

This shouldn't cause a timeout or a disconnection as its not a connection problem but one of bandwidth. But since this one is implemented as an "error" most people treat it like that and close the connection entirely.

When you send/recv a packet, just put the whole thing into a buffer and track the position, number of bytes. The send/recv functions tell you how much was transferred so just handle that in a temporary place and resume when the next event fires.

You should be able to mix C and C++ with no problems. I'm still new at everything but a lot of the examples I see do it all the time. For example, strcpy, strlen, printf, etc are all C functions yet they're in a C++ app with OOP and templates.. Hmm

One valuable thing I've done recently is start using the Boost libraries for a lot of common things. They even have one for serial port communications that may work for ya. Found that by searching Stack Overflow.

If you want VB6, then heres my example.. Dunno about VB.NET though

Hola Napalm! I'll post here to keep things where everyone can see them. To go along with the rest of this post, I updated my OutGauge example that now works, I think.. Updates include functions that convert from the byte arrays in the packet to usable data and a function to check if a bit is set.

All the OG_* (now mostly DL_*) are just saying which bits they are. They are used like booleans in that 0 = false and 1 = true, just in the simplest format possible to save space. The trick is checking which bits are 0 or 1 and that is done with bitwise operations. Read up on that and it will become clear. If not, let me know..

Hope it helps..

Hello!? Bumping this old thread to post an updated OutGauge VB6 example for some. It's just like the one in my first post except for patch Z+, I think, or whenever it was updated.. works in Z28 anyway.

I have the HTC (T-Mobile) G1/Dream too. Got it October 2008 and its been great so far, although a little slow. I hacked it with CyanogenMod and that helps a ton, esp the Apps2SD and having roooot.

Been thinking about the unlocked Nexus One but its kinda spendy for what I have now. Hmm.. Once I can drop the voice and text msg plans I will switch ASAP. I FRAKKING HATE the txt msg markup crap.

Quote from yankman :

In general you should stick to stl c++ container classes they have bullet proof memory management integrated.

Just started reading this nice thread and that right there is the best statement I've heard yet. Allocating static character arrays, printf stuff, malloc, etc are all very low level and mostly C and not the newer, safer, dynamic STL classes that are in C++. printf is nice and "simple" but you might regret it later. Memory leaks anyone?

http://www.parashift.com/c++-f ... nput-output.html#faq-15.1
http://stackoverflow.com/quest ... -printf-for-faster-output

Quote from blackbird04217 :

That said I need to make the AI 'see' the DriveTo points through the visual sensor. As of now I hacked it to grab the DriveTo points through the world directly. Then I will need to look ahead and choose which point to drive towards. Currently it goes from cone to cone, as you can see it turns hard as it gets near the cone then continues on. I have a small radius around the cone. The car needs to be within 2.5 meters of the target, this will need to expand.

The primary test here was to see if the LFS layout format kept track of the object order. Meaning the first cone placed is the first DriveTo point, and so on. Currently if I was to go click in the middle to try adding another DriveTo point it would corrupt the 'ai' file and that wouldn't be good. So the tip here would be to add more DriveTo points than needed, and move them around as necessary, ALWAYS maintaining proper order and only deleting from the back if absolutely needed. But the test succeeded, and that is one less thing to worry about with the LFS to AIRS interface.

What about using route checkers for this? They have a diameter (2-30m) and an index that defines an order (0-255 I think). On top of that they'll work for real people too!

Last edited by Stuff, Wed, 3 Feb 2010 01:05. Reason : diameter, not radius..

Quote from Flame CZE :

It returns me the same...

SELECT U.username, COUNT(L.user_id) AS number_of_layouts
FROM users U
LEFT JOIN layouts L ON U.id = L.user_id
WHERE U.id = L.user_id
GROUP BY U.id

To me this looks close but I think you need the keyword OUTER when doing the join. ie LEFT OUTER JOIN layouts L ON U.id = L.user_id. I'm pretty sure the default join type is inner, which will throw away all rows that don't match whereas outer won't. Also take out the WHERE clause as thats exactly what the join replaces

Yeah, pretty sure structs have to be a static size. Which means in InSim for the buttons you'd have to define TEXT_SIZE yourself between 0-240 depending on what your program does. Smaller the better of course.. Once defined, the struct works as usual. No problems I can see.

But for a variable length struct? Well, that's an array or in C++ a std::vector or a special class (something that returns an array or vector that's the packet) would be better. Just get your text length, fill in the data and ship it Seems like it would work..

Quote from Flame CZE :

So, here are all the current object IDs: http://www.flame.hj.cx/lyt/

Sweeet! Thanks..

For undo about the only thing I could think of was to store a reverse/undo command in a stack of some sort. Not sure how to do state tracking.. sounds like a lot of memory and maybe less flexibility?

Kyoto tyres?

About the only thing that might work is OutSim. If you can detect a vibration that a rumblestrip or something would give, would that work somehow? Combine that with some type of skid detection from OutGauge (direction vs angle_velocity right?) and thats a start to testing some kind of limit.. Other than that, I dunno

Ahh OK.. I assumed those errors were displayed in the error log of lfs_external and not in LFS itself. If the error messages are in LFS itself then I think this one is another bug to fix as like I (and the winsock FAQ) said, its a case of defensive programming and/or a choice of buffer sizes.. If it truly is a simple wouldblock message then it needs to be fixed. Otherwise LFS handled all the wouldblock messages it could, filled its maximum buffer, threw the wouldblock message (misleading in this case) and finally empties the buffer/store. Either way the wouldblock message needs to go away.

A technical explanation from Scawen would definitely help to clear some things up though. Until then, not much more we can do..

Yep, that's about the way I figured out the IDs. Place them on a layout and read it in. Except I guessed they would be added to the file sequentially, so that sped things up a lot. Not too much pain regardless.. I too will need all of them anyway as the new LYTe will support all tracks and objects.. including undo!

Also, if you guys (not just anyone) want the source code to LYTe, let me know as it's pretty much retired as is. And I will definitely make a new thread for the new version once ready..

Here is the list LYTe uses.. I would update the wiki/manual myself but there are a few differences that should be tested first..

OK, I did some poking around last night and solved a couple bugs. The major one is the header error and the fix was removing that check. The latest BL3 layouts seem to place the objects correctly but I have not tested it completely. The other one I fixed was the latest bug yaeger reported (thanks). It was a basic, uninitialized object. Doh!

Anyway, I uploaded the exe for version 0.5.0.7 to the first post. Just close LYTe, overwrite the exe from 0.5.0.6 and that's all..

Lemme know how it goes. Thanks!

Hrm.. about the only reason it complains about a header error is because of the versions. They are kinda sneaky. I thought I put in a robust enough check to get them all but I guess not. I will poke at it tonight to see what the differences are and get it to work..

Sorry about the lack of development for this version but don't worry, I'm developing a whole new editor instead. No ETA for that yet but will share if anyone is working on something similar.

And yep, my old lfsnal.org site is definitely out of date. Best place is here.. for now. Meh, another item on my to-do list.

I dunno the format of any GPS stuff but if you can plot it on a x,y coordinate thing then you could create a grid on top of the AU1.png in LYTe and map your stuff to a layout of some sort. The accuracy is decent but not perfect, but better than no grid and measuring maybe.

Still working on a 100% accurate version but not too much on that since it will be a while

Hrm.. sending less information is not the correct way to handle that error. It works for now, but it's a slower solution than need be. A TCP wouldblock message means the socket is busy send/receiving/waiting and it would have to block (or freeze) your thread in order to do so. The appropriate response to that "error" is to wait for another successful message from the socket layer and resume where it left off. See this for a little more info: Winsock Programmer's FAQ. And a search for the C/C++ error constant WSAEWOULDBLOCK reveals tons of info. Also, here's a .NET 1.1 MS article on it.

Really, the programmer of the InSim library you're using should make this transparent and handle that error as needed. I do that in my old VB6 okSocket thats used in CSR and maybe Virtual LFS Dashboard. I can post some psuedo code later if interested.

Hope it helps!

Quote from Napalm Candy :

If Logitech G25 would run on OS X, I would use OS X. But I'm using Win7

Quote from dawesdust_12 :

G25 does work in OSX, and then you can make it better with some tool that will enable clutch support and 900 degree rotation by sending the special packet that the G25 requires.

Same reason as Napalm Candy except Ubuntu 9.10 and WinXP. In my limited testing with the G25 and wine I couldn't get it to work all the way. So if you guys have any info about magical tools and packets for OSX/Linux, please share

Happy to report that it mostly works in Ubuntu 9.10 with Wine 1.1.33

I chose all default options. It put it into "C:\Games\Live for Speed", really /home/rayok/.wine/drive_c/Games/Live for Speed and that works fine.

It created 2 shortcuts on the desktop. A windows .lnk that doesn't work and a .desktop one that does, neither of which have the icon set correctly. Looking at the .desktop contents, it refers to the correct icon file, it just doesn't display correctly probably because of naming. The shortcuts it created in the menu are fine however so if you just copy those to the desktop/panel you'll be ok. I guess some of the shortcut problems are due to Wine creating the .desktop from the .lnk.

The file associations almost worked too. The icons display correctly in nautilus except when executed a windows dialog just says "File not found" and exits. I think this is also due to Wine too because the registry entry is correct "C:\Games\Live for Speed\LFS.exe "%1"" and wine should map C:\ to /home/rayok/.wine/drive_c but does not. I haven't tried to fix this one..

Before when creating a shortcut to LFS.exe I would always have to make sure the relative "working directory" is correctly set before launching otherwise nothing is found. A small cd command in a .sh file was all it took to fix that however. Overall, nice installer! Just a few problems due to Wine I think but nothing you can do about those.

Sorry I haven't replied in a while. I've been busy with other things and don't get much time anymore to program or even race. For the time I do have, I'm using it to create a new version of LYTe in C++ using OpenGL. I have the basics done but its still going to be a while..

Quote from Tomasevich :

Overflow in frmLayout.LayoutSave

Oops for that. Hopefully you didn't lose too much time. I don't think the latest version will fix it though. I'm not sure how that one happened.

Quote from Flame CZE :

How come I can't open some layouts and the others work fine? It shows me a "header error".

I'm not sure about that one. It should open up all AU layouts now.

Quote from SF-Turdtron :

im having a little problem with it......i made a pic to show it, basically, when i make a layout in AU4, it doesnt work, i save it into the layour folder, load up lfs, click the layout i want to use, start race, and i get nothing....so i go into autox editor, adn according to that, the layout is fully loaded....so i took this picture for you to look at.

By the way, im using 0.5Z , if that makes a difference

I was slightly afraid of that. I think it has to do with the Z position of objects. I set them all to 0 and LFS should place them on the ground but maybe not.. Not sure how to fix that one easily.

Quote from sinanju :

Any way that layout tracks can be turned, so instead of something like AU1 being almost vertical, it can be turned horizontal?

Any way some sort of grid could be overlaid as a visual aid on the layout tracks, so for us people who draw layouts on paper can more easily transfer to track in correct scale?

I was thinking about turning the tracks but never got around to it. You can do the grid thing though by editing the background .png and adding a grid. Then change the background using the dropdown