Im testing only online (40 connections ).. But I still don't see them... Also not with that zip.

I'm confused now. If it's me doing something wrong or if it really is not working.

hmm, first of all, be careful running this on a public host with people on them, because the LVS plugin will currently spam every racer on the track whether he's on or off the track, a few times every second. I guess dygear put that in for testing purposes, which i found handy as well. But it's no good for production use.

Second .. uhm, I've no idea why it doesn't work for you. Any chance you'd allow me to have a look-see? Could probably narrow down the problem fairly quickly if i could see it running.

I think this has something to do with it;
if (!$this->pth) { return PLUGIN_CONTINUE; }

(LVS.php)

But.. See it... Yeah.. Hmm.. Patience

Quote from Victor :

will currently spam every racer on the track whether he's on or off the track, a few times every second.

Already made that error.. It isnt in the newest version...

But...

They should be able to handle such things anyway..

when you start prism, do you see a message in your console stating something like "Loaded AS1.pth" ?

Also, since we were on the topic of 32bit vs 64bit before, I noticed that in the path detection algorythm, intermediate values were beyond 32bit. So I've now pushed an update that fixes this, using smaller numbers.

Quote from cargame.nl :

Already made that error.. It isnt in the newest version...

hmm, it was in mine. So are you sure you tried the right version?
I know it can be a bit confusing having different (development) versions
Best use different folders too for these test versions, if you haven't already.

Quote from Victor :

Best use different folders too for these test versions, if you haven't already.

I have.. But that many that I forget to keep track of config files.

LVS wasn't in plugins.ini in the newest situation. Sigh

Quote from Victor :

As for the coordinates in insim packets, they should be signed (jebus, i wrote unsigned first). So that 0,0,0 lies at the center of the world and coordinateds go smoothly from positive to negative.

I'll finger the commit in my branch and revert the changes.

Quote from Victor :

You can skip the top and bottom sides because we already know the point is in between them; we already have the node ID.

That's awesome, never really thought about that.

Quote from Victor :

One other thing, about prism in general. When I tested this path stuff on a local, single player instance, I noticed the MTC packets telling me I'm on or off the road do not work (of course).

Do you take this into account in other places where info is sent to the racer directly through MTC packets? Because they won't work when prism is connected to a offline, single player LFS client.

Or should prism not be used in single player mode?

No, that's just because I tested in a local server on my client, I do not normally test for single player type accounts. But yes, PRISM should support all modes that LFS supports. It was just me in the programming of that LVS plugin using the MTC packets that made it not work as well as it should off.

Quote from Victor :

I guess dygear put that in for testing purposes, which i found handy as well. But it's no good for production use.

Yeah, that's why I did it. I also don't have the chance to test PRISM on an active host because I don't have a server to test on. Just the servers that I make for myself with my LFS client. The only clients I have on besides my self is the AI that I put on the track.

A good nights sleep and now i've got that optimised path poly creation method. No need for sines, cosines, tangents and such.
This is prolly my final update of the day. There are some additional optimisations that can be done, but they don't really matter that much. So this should be fine for now as far as I'm concerned.
Pushed to vic_pth branch as usual.

edit - ok pushed two more fixes and cleanups

btw, there is an incorrectness in KY2.pth. I've asked Scawen about this before, but as it didn't present any actual problems he didn't update it so far. I guess he will in the future though.
See attached file :

Quote from Victor :

So this should be fine for now as far as I'm concerned.

edit - ok pushed two more fixes and cleanups

That edit made me giggle.

Quote from Victor :

[T]here is an [flaw] in KY2.pth.

So I guess we could fix that ... The SMX file should have the correct track markings, we could use that and convert it over to the PTH.

Quote from Victor :

btw, there is an incorrectness in KY2.pth

Hmmm...

Sometimes I have a sick memory but;
http://www.lfsforum.net/showthread.php?p=1390609#post1390609

You are mentioned there too

He 'licensed' it to Victor, I don't want to take someone else's work without permission.

Yeah, thats no problem.

Quote from cargame.nl :

Hmmm...

Sometimes I have a sick memory but;
http://www.lfsforum.net/showthread.php?p=1390609#post1390609

You are mentioned there too

yeah. Not sure why i never thought of doing that in the first place. Anyway, I asked him if it's ok for prism to include it. We'll know soon.

From my understanding he has been MIA for about 2 months now, but it's not every day that you get a message from a dev so ... who knows!

I merged Victors changes and Dygears changes together but still... If I adjust LVS.php, LVS is only working for one racer.

Problem must be inside function onCarInfo(IS_MCI $MCI) because thats the only difference.

I want to get rid of that message spamming all the time. On/off track should only be reported when the change happens.

And another thing. I noticed that every time someone joins the track or spectates (STA)... The pth file gets reloaded again. This is not very good for performance.

It should happen on race restart (RST) and on first prism init (only moment to trigger on STA).

But I'm quite happy with the progress. It's a big step forward for racing servers

Quote from cargame.nl :

I merged Victors changes and Dygears changes together but still... If I adjust LVS.php, LVS is only working for one racer.

Problem must be inside function onCarInfo(IS_MCI $MCI) because thats the only difference.

Yeah, I'll fix that.

Quote from cargame.nl :

I want to get rid of that message spamming all the time. On/off track should only be reported when the change happens.

Yeah, that was my intention.

Quote from cargame.nl :

And another thing. I noticed that every time someone joins the track or spectates (STA)... The pth file gets reloaded again. This is not very good for performance.

It should happen on race restart (RST) and on first prism init (only moment to trigger on STA).

I was under the impression that STA packets are only sent when the track is loaded, I did not know it happens when some one leaves and joins too ... So I'll have to change that to something else. Actually, it should not reparse the file if the track is the same.

Quote from cargame.nl :

But I'm quite happy with the progress. It's a big step forward for racing servers

Glad to hear that! I feel the same way.

Quote from Dygear :

Actually, it should not reparse the file if the track is the same.

Yes.

Complicated with the fact that a layout change also implies a track change nowadays.

Quote from cargame.nl :

Complicated with the fact that a layout change also implies a track change nowadays.

Had not really considered that.

(BTW, my girlfriend is here, so I can't even program because she wakes up when ever I type.) <- Slowest typed sentence of my life.

Hahaha.. Some recognition here.

It's OK. Looking at the layout filename when an AXI packet is there should be fine.

After this pth loading and spamming is working 100% it's possible to store timings and do some stuff with safety which really would be great (can do that on my own I think, but I'm slow).

No hurry though, relax.

Quote from cargame.nl :

Hahaha.. Some recognition here.

It's OK. Looking at the layout filename when an AXI packet is there should be fine.

After this pth loading and spamming is working 100% it's possible to store timings and do some stuff with safety which really would be great (can do that on my own I think, but I'm slow).

No hurry though, relax.

Yeah, I'm gonna make an API so that programmers can do that, using this plugin as a template.

I merged vic's pth branch. I think I did it in a dirty way so it might not look like that in the tree. But that's besides the point. Cargame, if you can try that out, let me know what's working and what's not on a populated server.

Are these lines to stay in LVS.php?

It's just that you already have found the result of isOnRoad() a couple lines earlier, and stored it in $isRoad. So you wouldn't have to do the detection again.

Quote from Victor :

Are these lines to stay in LVS.php?


<?php 
if ($this->pth->isOnRoad($CompCar->X, $CompCar->Y, $CompCar->Node) === FALSE)
    IS_MTC()->PLID($CompCar->PLID)->Text('You are ^1off^9 the track!')->Send();
else
    IS_MTC()->PLID($CompCar->PLID)->Text('You are ^2on^9 the track!')->Send();
?>



It's just that you already have found the result of isOnRoad() a couple lines earlier, and stored it in $isRoad. So you wouldn't have to do the detection again.

No, it's just for debugging, I'll remove them on release.

Alrighty.

Another question : Do you keep track of a host's state / race status / who is on a host / any information about a host, which can be instantly queried by other parts of prism?

EDIT - Is that the StateHandler? Does every host have a StateHandler?

For example, I wanted to look into making a generic msgToLfs class that would figure out whether to use MTC or MSL depending on an LFS host being a real multiplayer host or a single player instance. But for that the class will have to check at least to see what type of LFS instance we're talking to. To figure that out we'd need information from IS_STA's ISS state flags for example. Is that IS_STA information stored somewhere and made available to any function that needs to instantly check that value?

Quote from Victor :

Is that the StateHandler? Does every host have a StateHandler?

For example, I wanted to look into making a generic msgToLfs class that would figure out whether to use MTC or MSL depending on an LFS host being a real multiplayer host or a single player instance. But for that the class will have to check at least to see what type of LFS instance we're talking to.

Yes, everyone has access to that, it's exposed by the command get(Client/Player)By(UCID/PLID/UName/PName), and it returns a reference to that class. Every host has it's own instance of statehandler, and every packet that updates information by the State Handler is handled and recorded by this class. It allows for information to always be available for the plugin classes, but it can be used by other modules as well.

Quote from Victor :

To figure that out we'd need information from IS_STA's ISS state flags for example. Is that IS_STA information stored somewhere and made available to any function that needs to instantly check that value?

Using $PRISM->hosts->getHostById($HostID)->State, will get you the ISS state flags for that host.