Hi,

Does anyone know a way to slow down the button sending from PRISM to LFS?

I currently have maybe 40 buttons sent in a row and some people with weaker internet connection lose connection.

I thought of adding a 30ms pause in between each button send, but it doesn't really seem possible since it isn't multi-threaded.

I changed the speed of the main loop in PRISM, but that just causes it to use 50% CPU performing the stream_select() much more.

Ugh, PHP.

If I recall correctly PRISM has a timer capabilities - is that not suitable?

Quote from the_angry_angel :

If I recall correctly PRISM has a timer capabilities - is that not suitable?

The timer system runs from the main loop which collects the packets from the LFS servers.

If I create a timer of 0.03 seconds, I have to all change the default sleep value for the packet collection from 1 second to 0.03 seconds which in turn causes 50% CPU usage.

Add the second server and it will be 100% without counting the actual 2 LFS servers

Well that's crap =( I've had a brief look at PRISM's main loop and I'm not seeing an obvious patch - I'd have to fire up xdebug which I can't do right now.

I suppose an inline call to usleep in your button sending function is a possibility, the issue with that being obvious (backing up the main loop - although if you're not using positioning packets that may not even be an issue). Without re-architecting PRISM I can't see an immediate workaround if a low stream_select timeout is causing you issues, sadly

Quote from the_angry_angel :

Well that's crap =(

I suppose an inline call to usleep in your button sending function is a possibility, the issue with that being obvious (backing up the main loop). Without re-architecting PRISM I can't see an immediate workaround if a low stream_select timeout is causing you issues, sadly

I did implement a usleep(), but when PRISM is restarted with a full server, PRISM begins disconnecting from the LFS servers due to all the sleeps

A very easy solution is to modify your buttons based GUI to send fewer buttons. Not perfect, but it's definitely an option....

Quote from the_angry_angel :

A very easy solution is to modify your buttons based GUI to send fewer buttons. Not perfect, but it's definitely an option....

Which I don't really wanna do to be honest

Feel so upset that I've actually used PHP since it has no multithreading

why not do what i did and learn how to make a streamer? just a suggestion.

Quote from Beaver08 :

why not do what i did and learn how to make a streamer? just a suggestion.

Read above.

not using inbuilt functions actually create a button streamer..

not using sleep or anything like that.. just have it show a few then check they are loaded then show more

Quote from Beaver08 :

not using inbuilt functions actually create a button streamer..

There's no multithreading so I can't use 2 threads to run the main thread at the same speed as usual.

i have atleast 48 buttons showing on my screen at once and i have no problems.. plus i dont use multithreading either

Quote from Beaver08 :

i have atleast 48 buttons showing on my screen at once and i have no problems.. plus i dont use multithreading either

Then you use timers (which are multithreaded) or sleeps (which doesn't work in my case).

no timers as i explained i created a streamer that shows a few buttons checks that they have loaded if so then show some more it's all called under a function as it's used so no timer is needed

Quote from Beaver08 :

no timers as i explained i created a streamer that shows a few buttons checks that they have loaded if so then show some more it's all called under a function as it's used so no timer is needed

But that's not even what I'm trying to do

Yeah I use usleep but that indeed is not very cool because it pauses the whole script and if you want to send different buttons to different connections then you basically are f* ...

Quote from cargame.nl :

Yeah I use usleep but that indeed is not very cool because it pauses the whole script and if you want to send different buttons to different connections then you basically are f* ...

That's what I tried. The worst thing is if there's 47 connections, you start the insim up, and all the pauses cause PRISM to close connection since there's about 7 buttons sent to everyone in the IS_NCN event.

Quote from PoVo :

I currently have maybe 40 buttons sent in a row and some people with weaker internet connection lose connection.

you need to stream them to sort this problem i give up trying to tell you. :slap:

Quote from Beaver08 :

you need to stream them to sort this problem i give up trying to tell you. :slap:

You don't say I've mentioned that in the first post.

Are you sending a different set buttons to every connection, or all the same info to all connections?

Quote from cargame.nl :

Are you sending a different set buttons to every connection, or all the same info to all connections?

Different to all at different times.

Ah.. Yeah well.. That is nasty.

Would like to know a solution to. Didn't try streaming though (yet).

Put the buttons into an array "to be sent".

Then every PRISM tick send half a dozen from that button array to its connection.

The build of the initial interface may be slow but other than that it should be pretty speedy.

Also ensure that you're not sending buttons that are not already identical to what is already on the screen of the client.

hope this helps!