Ok, I promised Dygear to continue working on this, so this thread should be the central discussion topic for the ButtonManager/Button classes.

Let's start by specifying


The user (i.e. plugin writer) should be able to create new buttons with callbacks like in any other insim application. As prism is a multiuser/plugin system the user does not know which ClickIDs and areas of the screen are not already occupied by other plugins.
-> The main task of the Button system is to coordinate the assignment of ClickIDs to used buttons, so that no two plugins use the same ClickIDs.

Planned/partially implemented features:

1. Assignment of unique ClickIDs to buttons on a user/host basis
   
2. Restricting the ClickIDs in the hosts configuration
   
3. Named buttons. e.g. Deleting buttons by key
   
4. Grouping of buttons. e.g. Defining 5 buttons with the same group key and deleting them all with a single line of code
   
5. Callback functions to buttons for clicks and text input
   

Proposed features:

1. Reservation of an area on the screen to place buttons
   
2. Automatic update of an button on "Content" change
   
3. Throttling mechanism like Krammeh's for the above feature
   
4. TTL - automatic deletion after x seconds
   
5. Automatic deletion of buttons on certain events like race restarts
   

The assignment of the ClickIDs is the most important point which has to respect certain criterias:
- Upon sending a button has to have an unique ClickID
- After deletion the ClickID may be reassigned to another button
- Sending a button to all users should find a single ClickID which is not used for all users or one button for each user must be sent with user specific ClickIDs
-> The ClickIDs have to be on a host/user basis.


--

The current git version in the official repository is not ready to use. i.e. will probably crash after adding 240 buttons etc.

Please provide feedback on the proposed feature list and perhaps you even have more features to propose.

We should really have a paging mechanism, where buttions that go past the 240 are displayed once a the require number of ClickIDs are available for that element. This becomes important when the client is given a interface where multiple elements are presented to them in a single context. These single context relationships will have to be known to PRISM so that it may intelligently display these buttions to the client when the ClickIDs do become available to it. But it has a caveat, where even tho the elements are within the same context, it might not be assigned sequential ClickID's as the ClickID's could open at random.

I went a slightly different way than ClickID+1 - as I find it important that you can pre-define a ClickID for each button - especially if a user has more than one insim app running on the same server/client. They end up overriding each other.

I simply have an array for of button IDs linked to friendly names $this->button['ui1_back']; for example is ID: 6. I can then always use ui1_back as its ID, rather than having to remember it is 6.

Within menus there is (100 I think) menu_1, menu_2. which I use dynamically while building each menu.

I should really clean the code and make that public

But multiple insim connections don't share buttons/clickids?
At least that's what I found out by starting prism twice and clicking a button; only one instance got the BTC packet.

--

The way my implementation works is, that you a) can define keys for buttons and b) you can define callback-functions, thus you never need to compare clickIDs.
see https://github.com/GeForz/PRIS ... 1/plugins/buttonTests.php

start PRISM with your app using button ids (1-10 for instance), then start LFS Mail (if still compatable) which also uses those same buttons.

Should not make a difference, unless there is a bug within LFS.

Each InSim app gets its own click IDs. It would be insane if all InSim apps had to share them.

never used to. as I couldn't run LFSMail and the LTC app at the same time - it would remove parts of the LTC interface on screen when it showed the LFSMails interface. There is a thread somewhere where I was asking for customIDs for the LFSMail app, so I could write the IDs around LTCs IDs

Yeah, OK, I totally take that back, they do share click IDs. My bad, sorry.


The second button overwrites the first one.

I think I also wrote a thread asking for them to be given their own button space, but it got rejected saying use ya own IDs.

Which is why I then requested lfsMail to have a config file. also got rejected.

Oh okay you are right, my bad :/

That means the buttonmanager has to be configured with a button id restriction in the hosts.ini file for each host...

Yea, buttons id's are one for all 8 InSim connected to LFS Server. You can display only 255 buttons on user's screen. Not 8*255=2040

Well, how to hell are we meant to know if a another InSim Client is using that ClickID? This is a terrible idea and a massive oversight!

There are a few things that we can do, but none of them are great.

• We could like GeForz said, limit the ClickID number available to the client by a configuration file option.
  
• Ask Scawen to give us a packet once a InSim Instance uses a ClickID, and allow us to reserve a set of ClickIDs when we want to present a interface object to the client.
  
• We could ask the Scawen fix this, so that each InSim client get's in own button space.
  
  
• We ourselves make a Meta InSim client, that acts as an intermediary to the other InSim instances. So "MetaSim" will connect to LFS's InSim. From there, all of the conventional InSim client's connect to MetaSim, and it acts as a pass-trough. But we ourselfs add some packets to the InSim interface so we know when another InSim instance uses a ClickID as the information will be reported back to each InSim Instance that is connected to MetaSim. Basically, it's MetaMod for LFS.