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..
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.
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
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..
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.
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?
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..
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..
//cones 29, 22, cone red 34, 23, cone red2 30, 24, cone red3 33, 33, cone red pointer //AU = cone pointer 31, 25, cone blue 61, 30, cone blue2 64, 35, cone blue pointer 32, 27, cone yellow 62, 32, cone yellow2 63, 34, cone yellow pointer 39, 26, cone green 60, 31, cone green2 65, 36, cone green pointer 40, 28, cone orange 41, 29, cone white NA, 0, cone1 //BL only NA, 1, cone2 //BL only
//tyres 0, 12, tyres white //BL = tyre white new1 3, 17, tyres2 white //BL = tyre white new2 1, NA, tyres red //AU only 4, NA, tyres2 red //AU only NA, 13, tyres blue //BL only NA, 18, tyres2 blue //BL only 19, NA, tyres small //AU only
//objects NA, 19, banner rsc //BL only NA, 20, banner cromo //BL only 24, NA, banner ad1 //AU only 25, NA, banner ad2 //AU only 27, NA, banner ad3 //AU only 23, NA, bale //AU only 2, NA, post //AU only 42, 42, post green 43, 43, post red 44, 44, post white 45, NA, post orange //AU only 46, 41, barrier white 47, 40, barrier red 48, 39, barrier long 49, 38, keep left 58, 37, keep right NA, 82, ramp //BL only[/SIZE]
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..
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.
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..
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.
I'm not sure about that one. It should open up all AU layouts now.
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.
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