You don't need the Profiler to be running, but the Logitech drivers have to be installed for the FFB to work. Make sure you have the latest drivers and that the wheel's external power supply is plugged it. As was pointed out above, trying a different USB port is also a good idea.
It depends on what you consider a drift and I can see that it would take a bit of work to get it right, but a very simple algorithm could work like this
This would of course require quite high sample rate to get any useful data.
if (car.Speed > MIN_SPEED) {
unsigned short driftAngle = abs(car.Direction - car.Heading);
if (driftAngle > MIN_DANGLE && driftAngle < MAX_DANGLE)
driftPoints[PLID] += COEFF * car.Speed * driftAngle;
}
This would of course require quite high sample rate to get any useful data.
It depends on the level of accuracy. Giving a button a fixed position in 3D space and determining if and where it should be displayed involves some vector algebra and trigonometry. I don't know what calculations exactly you'd have to do off the top of my head, but I reckon it could be reasonably easy.
@sarxes: At this point it would be interesting if you could try another InSim app you've never used before to see if it would too have trouble connecting to LFS. I'd consider reporting a bug in Qt or something if the problem was specific to WinAmper. It would also be helpful if you could do the testing on a clean install of LFS with no admin password set, because so far I found nothing that could be wrong...
"Everything" is a rather vague description, if you got past the "Connection refused", have you tried it with a blank admin password? It'd be interesting to know how does this work for other people.
Last edited by MadCatX, .
Reason : odd typo
After that I was laughing just like the guys in the room. If it's done like Sci-Fi comedy, it might not be bad, but I still think the idea of moon-dwelling nazis attacking the Earth is just... dumb.
Check the chat log in LFS, LFS doesn't send IS_VER if a connecting InSim app supplies wrong password. Because LFS isn't Unicode aware, your password could be a problem if it contains some non-English characters.
Winamp version wouldn't have any effect on this...
Winamp version wouldn't have any effect on this...
If there's an error during connecting, the application displays error returned by QTcpSocket::errorString(). You can see how the connection is created in InSimComm::initialize(), the application creates a socket, tries to connect and blocks for 5 seconds. If a connection is not established by that time or an error is reported, an error string is returned. There's nothing more to log.
This method works fine on two Windows and one Linux box, so unless there's some obscure bug in Qt, I don't see where it could trip.
This method works fine on two Windows and one Linux box, so unless there's some obscure bug in Qt, I don't see where it could trip.
I'm not sure it would work like that because LFS would most likely intercept the Winamp shortcut (unless Winamp sets its shortcuts as global which I doubt). You'd also have to do that every time you play a new song, the whole point of this tiny app is to spam the LFS chat with "I'm currently listening to" kind of messages.
The app worked on another W7 machine, so there's got to be something specific about your machine. "Connection refused" usually means that an application is trying to connect to a non-existent address or port, which doesn't appear to be the case here.
The only way I can reproduce this issue is by not enabling InSim in LFS. If you're sure you have InSim enabled and it's working with other applications, then I have really no idea what would cause such a problem expect for the statically linked exe being somehow magicowierdly broken...
I might have gone blind but from the screenshot it looks like LFS is not running on your machine so the app has nothing to connect to. You have to start LFS and init InSim first.
It worked for me, it might your firewall blocking it or for some reason the app cannot connect to LFS through "127.0.0.1". I can't think of anything else ATM.
Since I discovered a rather stupid bug in the app, I eventually decided to reupload it, this time with the option to enter admin password.
http://dl.dropbox.com/u/37342755/WinAmper2.7z
http://dl.dropbox.com/u/37342755/WinAmper2.7z
I know, I just didn't expect anyone to have the admin password set as that's something you'd probably want to use only if you run a private server. I put very little effort into this hack so it always assumes that the password is blank
Well, you can't. I really didn't expect someone to use this on a host...
It will probably not handle songs with wrong or non-English characters well, but I really can't be bothered to fix nuances like that. I hate the way it's written, but under the ugly Winamp stuff is something that looks pretty neat so far and I might turn it into high-level C++/Qt based InSim library one day
(The executable is huge because it has half of Qt compiled in statically)
-- LINK REMOVED --
(The executable is huge because it has half of Qt compiled in statically)
-- LINK REMOVED --
Last edited by MadCatX, .
Do you use any InSim library? What language do you use? Can you show us the code where you're sending the MTC packet?
I think this means that you're trying to send an empty message
My guess is that you're trying to send a message to non-existent UCID or PLID.
It's a long shot, but does LFS register in the audio mixer? Launch LFS in a window and start a race, then click on the speaker icon in the systray and click "Mixer". You'll see a window with a "Device" slider in the left section and a list of applications that are currently using the selected device. You can adjust the sound level for each application, so make sure LFS isn't muted for some reason. If LFS is not listed, try selecting a different device.
I gave it a shot and it seems to be working, if there's no way Winamp can change this I might as well release it after I clean the source up a "bit".
Just a sidenote, mutual distances of 32 cars would need 496 calculations (because when you know A->B you also now B->A) which is rather bad, but perhaps not as bad to justify the usage of a K-D tree plus it will give you the most accurate information about closure speeds and distances...
I admit I can't really imagine what sort of logic are you planning to use to check if "there is something going on", but wouldn't you need a rather dense tree to get any useful data?
EDIT:
I didn't really think this through, but perhaps an algorithm working solely with distances could be optimized even further. Imagine a following situation:
There are 6 cars on the track (A - F) and we want to know of some of them are close enough to be considered fighting for position. A fully unoptimized junk needs 30 calculations to get all the distances, assumption A->B == B->A gets it down to 15. This is OK for 6 cars, but still too much for 32. A following idea crossed my mind.
1) Calculate distances from A->B to A->F
2) If (abs((A->N - A->(N+1)) < threshold)), add cars N and N+1 to a "preliminary" group
3) Check if car A could belong to some group
4) Run distance checks for all preliminary groups and remove too distant cars.
Checking the distance AND the direction to increase the accuracy of "preliminary" groups sounds like too much of an overhead to me because of the floating point maths that's involved (this algorithm could work only with ints). I'm really sorry I don't have time to try to implement such an algorithm, but I reckon it could be reasonably efficient with larger grids (or I missed something stupid and you're trying hard not to chuckle right now).
I admit I can't really imagine what sort of logic are you planning to use to check if "there is something going on", but wouldn't you need a rather dense tree to get any useful data?
EDIT:
I didn't really think this through, but perhaps an algorithm working solely with distances could be optimized even further. Imagine a following situation:
There are 6 cars on the track (A - F) and we want to know of some of them are close enough to be considered fighting for position. A fully unoptimized junk needs 30 calculations to get all the distances, assumption A->B == B->A gets it down to 15. This is OK for 6 cars, but still too much for 32. A following idea crossed my mind.
1) Calculate distances from A->B to A->F
2) If (abs((A->N - A->(N+1)) < threshold)), add cars N and N+1 to a "preliminary" group
3) Check if car A could belong to some group
4) Run distance checks for all preliminary groups and remove too distant cars.
Checking the distance AND the direction to increase the accuracy of "preliminary" groups sounds like too much of an overhead to me because of the floating point maths that's involved (this algorithm could work only with ints). I'm really sorry I don't have time to try to implement such an algorithm, but I reckon it could be reasonably efficient with larger grids (or I missed something stupid and you're trying hard not to chuckle right now).
Last edited by MadCatX, .
Is the window title way guaranteed to work? It's been a while since I moved away from Winamp, but as I recall it it was quite moddable. As long as Winamp always sets its window title like this, it would probably be a viable solution.
A quick google tells that it should be possible to do like this in C++/CInSim
Where is_songMessage is an IS_MSO struct.
Because the SendMessage call returns a pointer to the string with the song's title, one would have to write this as a WinAmp plugin or use WinAmpMiniMagic (the sample code for that almost made my lunch go back on the plate though).
EDIT: BTW I just noticed the method chaining style in PRISM, pretty neat gotta say
// Get current position in the playlist
int curPos = SendMessage(hWinAmp, WM_WA_IPC, 0, IPC_GETLISTPOS);
// Read the file title
char* title = SendMessage(hWinAmp, WM_WA_IPC, curPos, IPC_GETPLAYLISTTITLE);
strcpy(is_songMessage.Text, title);
insim.send_packet(&is_songMessage);
Where is_songMessage is an IS_MSO struct.
Because the SendMessage call returns a pointer to the string with the song's title, one would have to write this as a WinAmp plugin or use WinAmpMiniMagic (the sample code for that almost made my lunch go back on the plate though).
EDIT: BTW I just noticed the method chaining style in PRISM, pretty neat gotta say
Last edited by MadCatX, .
To be absolutely sure everything works it's best to ask someone else to connect to your server.
What cargame is trying to say is that when you're connecting to your dedicated server from the machine it's running on, you should connect to it using either your PC's internal IP or localhost IP (127.0.0.1).
You can do that in LFS by picking Join specific server option in Multiplayer menu.
You can do that in LFS by picking Join specific server option in Multiplayer menu.
FGED GREDG RDFGDR GSFDG