Quote from Hollywood :

Because I don't want the script running while they are in the pits/garage menu... simple enough.

The NPL does not get fired until they leave the garage so that does not do any good as far as stopping scripts. Its the event that is used to start the scripts up.

OK. I don't know excactly what your script does or how it works so I really cant say how to solve it... but I'm pretty sure it could be solved without a "lobby screen" PLP packet.

Quote from Hollywood :

So that you know when someone goes into the garage!

As an example, I have scripts that whenever you join, i.e. when the IS_NPL is sent, that check to see if you are in the right car and have the right handicaps. Those scripts are to stop if you a) spectate which you can tell when a IS_PLL packet and b) if you go to the garage/pits

Uhm, why don't you just check the NPL packet, and then stop the script?

Quote from Crazy Harry :

Nothing looks more stupid then someone driving in a UF1 with a helmet.

Not as stupid as people waking up dead threads for no apparent reason.

Quote from icyocean :

i loop through the compcar[] in a set of MCIs, and when the last compcar is met (info: 128) i fire a custom event to signal a complete new set of MCIs has arrived and the UI can reload the buttons etc.

Just in case you didn't know, there is a bug in the compcar struct when a player is in pit, so you shouldnt rely on the compcar.Info alone..
http://www.lfsforum.net/showthread.php?t=28061

The only way is to use pubstat i think..
http://www.lfsforum.net/showthread.php?t=14480

Quote from Veiti :

Hi mates,

I was just playing around with insim and was hoping to activate my flasher by sending an insim pack. In LFS options I bound '8' to the flasher and sent a package to LFS. Unfortunately the flasher did not flash. But if I open the chat window, the '8' appears.

Hey all, old thread, but I got the excact same problem..

If I send SCH 'h' to LFS, it turns on my right indicator.. but when I press 'h' in LFS, the history list is enabled/disabled, just as it's supposed to do. To turn on the right indicator, I have to press '8'... (and yes, I know the SCH 'h' is recieved as a 'h' in LFS, cause if I open the chat window before I send it I can see a 'h' being written)

The same for all other keys I try to send... they are recieved correctly in LFS, but are interpreted totally wrong. Is it just me, or is something very wrong?

Thanks!

Quote from Krammeh :

Is there any tool, where I can see what the XY co-ordinates are, that surround the pits/garages?

You need a tool so you can watch your coordinates as you drive? In that case, here's something I made in a hurry to trace MCI packet info..

Insim port is hard coded to 29992. Just start the app, type /insim 29992 in lfs, and your x and y coordinates will be displayed as you drive.

http://www.0815-software.com/xy.zip

Quote from DieKolkrabe :

Agreed, I wasn't meaning that it'd be automated

Well, if it is supposed to be controlled by an admin (or two..), then why just don't use the /p_?? command to give a penalty, or /spectate to spectate him? Or ban or kick him as speedway said.

Quote from Hollywood :

Voluntary mass and intake restriction handicaps appear not to be reported by InSim. The H_Mass and H_TRes only seem to report the server set handicaps, unless I missed something.

H_Mass is voluntary mass added. Dunno bout H_TRes, but I'm pretty sure thats the same.

Quote from A.Fedorov :

if point(xa,ya) in square area then true or else false


function vectors(x1,y1,x2,y2,x3,y3,x4,y4, xa,ya)

local s = math.abs(1/2*((x1-x3)*(y2-y3)-(x2-x3)*(y1-y3))) + math.abs(1/2*((x3-x1)*(y4-y1)-(x4-x1)*(y3-y1)))

local sa = math.abs(1/2*((x1-xa)*(y2-ya)-(x2-xa)*(y1-ya))) + math.abs(1/2*((x2-xa)*(y3-ya)-(x3-xa)*(y2-ya))) + math.abs(1/2*((x3-xa)*(y4-ya)-(x4-xa)*(y3-ya))) + math.abs(1/2*((x4-xa)*(y1-ya)-(x1-xa)*(y4-ya)))

if (s ~= sa) then
return false
elseif (s == sa) then
return true
end
end


Just FYI: This algorithm didn't work for me at all, dunno why.
But I searched the net and found this algorithm.. (look at "Code Sample"). The "polygon" in my case is simply a rectangle (the car).

This seems to be spot on... tested with the UF1, and it's close to 90% perfect, the reason why it's not 100% is because it's hard to find the excact length and width of the car, and where the "centre" x,y of the car (reported by mci) is. I assumed it was in the middle of the car, but not sure if that's right

Anyways, for my app this is good enough. I was looking for a way to detect contact between UF1 at relative slow speeds, and that's what I got. So I'm happy.. for now

But does anyone know the excact length and width of all or some cars? And where the centre point of the cars are located? I've only figured out the UF1, and the length seems to be 2,84 meters and width 1,47 meters, but I doubt these are the excact figures.

Thanks A.Fedorov, that was very helpfull indeed!

But there is one big problems with using the "rectangle-overlap-detection" method only, and that is the rate of the MCI packets. With shortest delay (50 ms) and 32 cars on track (4 packets between each cars MCI), you get a 200 ms interval between one cars MCI... so when cars are moving fast, a lot of things can happen in 200 ms that this method wont detect.

Also there could in theory be up to 100 ms between two close cars' MCI packets, so even though you detect overlapping rectangles, it doesn'h have to mean contact, it's just one car chasing another at high speed.

(and, but not that important, car sizes are not constant, a crashed car for example could be shorter than a repaired one)

So in addition to this method I guess I have to look at change in velocity and direction (as sdether mentioned), and maybe use that when cars are moving fast, and rectangle-overlapping for slow moving cars?

But thanks for pointing me in the right direction, more ideas and thoughts are more than welcome

Last edited by nikka, Thu 19 Jul 2007, 12:42.

Heya all!

I'm working on an insim app where I have to find a way to detect a collision or contact between cars. I assume this can be done by looking at mci packets and calculating distance between cars (using X and Y), but that will (for several reasons) never be 100% accurate (or at least thats what I think...).

I hate to re-invent the wheel, so have any of you done something like this already, and would like to share this with me?

Or would anyone of you like to help me out with this? Any ideas are more than welcome.

Or maybe even Scawen would be so nice to add a insim packet that notifies you when there is contact between two cars?

Many thanks,
nikka.

When a player is in pit (PLP), his MCI CompCar struct is set to 0, including Info byte.
So, if his CompCar is CCI_FIRST or CCI_LAST, this info is missing.

(yes, this one caused some brain twisting... )

Edit: Not entire struct is set to 0, PLID is still intact.

Last edited by nikka, Wed 18 Jul 2007, 17:36.

Yes it's a bug, already reported and confirmed by Scawen.

http://www.lfsforum.net/showthread.php?p=370568#post370568

Quote from DieKolkrabe :

Why not just set the server to practice mode? :S

I'm really glad you took time to read, and understand, my post before replying...

Quote from DieKolkrabe :

I'm against this. Usually qualifying only lasts an hour.

So just because it's a feature YOU don't need, you're against it? It wouldn't hurt, would it?

Edit: WOOOW! a bit of pre-weekend-grumpyness there, Nikka? Go home, have a beer and relax in the sun!
(but i wont edit my reply cause I still think your post was rather stupid)

Last edited by nikka, Fri 6 Jul 2007, 14:09.

Hei hopp!

Usualy when my team is practicing for some event, we like to do it in qual-mode, cause then it's easier to keep track of each others best lap.
BUT. Maximum qual time is 60 minutes, and that is sometimes not enough. So my wish would be to either:

• show the best lap time of each driver when in practice mode (just like in qual)

or:

• have "unlimited" (or at least much longer than an hour) qualification length.

The former makes most sense, the latter is easier for Mr. Roberts to implement i guess. But either work.

Thanks!

Today (May 31st) it's 2 years since some morons raced in S1 demo, and thought it might be fun to put the tag "[noobs]" in front of their names. Since then more morons have come and gone, but the hard core of true noobs still remains.. (and the rest is history, yada yada yada)

Sooo, big party tonight! Bring your car, a sixpack of (non-alcoholic) beer, and obviously a NICE birthday present.

Starting in the "[noobs] jump!"-server at 20:00 CEST / 18:00UTC, and you'll never know where it goes from there. But expect some banger racing, ai challenge, some semi-serious racing at the classic [noobs]-combos, and more.

Oh well, hope to see you!

Quote from Scawen :

- Can show up to 240 local and 240 host buttons
- Added an ISF_ flag to specify local or host program (replaces ClickID ranges)

Excelent, but you might consider removing this comment to prevent confusion:

Quote :

// ClickID byte : buttons from the host and local buttons are kept separate.
// If you are writing a host program to show buttons on host or guests. use
// the range 0 to 159. If you are writing a strictly local InSim program you
// must use the values 160 to 239 so that your program can be used online.
// This allows local InSim buttons at the same time as host buttons.
// Local InSim programmers should try to avoid overlapping host buttons.

Anyways, I really admire your pace... thanks!

Quote from Scawen :

No. But there is a reason to send buttons even if they can't be seen. Because they will be seen as soon as they leave the options screen or whatever screen they are in. Now that it's visible in game, the game setup screen and the front end screen, that means they should usually be visible. Why would someone "hang around" in one of the other screens? I'm just trying to understand if we really do need some kind of "buttons are visible" notification, as the idea is that shouldn't be needed.

Well, I told you about my app. I just need an alternative way of handling stuff when a user is in a screen where buttons are invisible, so I need to know when the user is in such a screen.
And no, I don't expect people to "hang around" in these screens, I just want to cover every possible situation.

BTW, a typo in insim.txt (W28):

Quote :

byte ReqI; // non-zero (returned in IS_BCL and IS_BTT packets)

Should be "IS_BTC and IS_BTT" i guess.

Speaking of, I don't quite see the point with ReqI in button packets. ClickID is the identifier you should keep track of anyways, or am I missing something?

I need some way of knowing whether I'm in a screen where I can draw buttons or not (no use of drawing buttons if they're not visible).
Is this possible using excisting insim functionality?

Quote from Scawen :

If you can describe to me a reason why you need it on some other screen then I can consider it.

Well, what i'm working on right now is an insim messenger client (will maybe make it a jabber client later if i'll ever bother).

I was planning to use the buttons to display people who are online (in messenger), so you can click the button to say something to someone, and also use buttons as a list of active conversations to make it easier to handle multiple ongoing conversations.

Obviously, it would be nice if you could chat with people when not connected (or in single player)... if someone say something to you when you're in the list-of-games-screen, it would not be very user friendly if you'll have to hurry up and join a host so you can reply...

But if it's just me, please don't hold back X for this.. I know you have alot of (more) important things to do. But anyways, thats why I need it
Before I knew the buttons were comming I was looking for a decent and non-messy way of solving this (handling multiple conversations and initiating conversations), and the buttons was a gift from above for my app.

Thanks, just what the doctor ordered!

But in my local computer-app (IS_BTN UCID=0), buttons are only visible when connected to a server, not in main menu, connection list screen and so on.. hopefully it's not intended to be this way since IS_MSL's for example are visible everywhere.

Edit: and uhm, shouldn't the buttons disappear when you close your insim app?

Edit again: omg, the thing with clicking the button to open a text input box... it's just awsome! Just what my app needed!

Edit III: would it be possible to add a "char TextCaption[20]" or something to IS_BTN to change the caption in the input box from "Edit" to something else?

Last edited by nikka, Wed 23 May 2007, 20:32.

Again, using UCID is not very local-computer-app-friendly.

On the bottom of the forum front page:

Live for Speed Statistics:
Threads: 22,435, Posts: 415,406, Members: 0

Quote from Scawen :

OK - in my version the MSL (MSg Local) is done, allowing up to 127 chars and a sound effect if you want.

Woho!

MST ignore the '\n'-character, will MSL do the same? (will save some bandwith when you want to print many short lines if you can just send one MSL with \n in it)

And uhm, not sure if you have confirmed this (yes I did search), but will the programmable buttons be in X already?

And uhm (crap, stop the uhm'ing and behave like a grownup nikka!), I had a crazy idea.. how bout making separate text input boxes for /i and /o messages, you know, simular to the 't' input box? For example, you press.. uhm (doh!) 'i', a text input box appears, and the message you enter is sent to insim as a III.. and same for MSO_O ('o' or something) (maybe these text input boxes should be default disabled and have to be enabled via insim to stop confusing people if they hit the wrong key when they wanna type a message and writes it in the wrong text box).
Maybe this will just cause a lot of confusion. I dunno. Just a thought.

And speaking of IS_III, W24's insim.txt have a typo... I guess IS_III's Type should be ISP_III, not ISP_MSO (the comment).