Hi programmers.

I decided to try and get this new button interface done in a day, sooner rather than later as patch X will be out in less than two weeks (planned for 1st of June) so you need enough time to test this out. I still have a few things to fix generally - I want to be basically finished by this weekend, apart from important fixes in that patch X final testing week.

So this morning I've designed this button interface. I'll try and implement it this afternoon, and release it to you maybe today or tomorrow. I've tried to keep the interface as simple and small as possible while giving enough flexibility to you. Please check out this specifiacation and let me know if you spot any issues, and if you'll be able to do what you want to do with the button interface.

EDIT - removed the interface specification - a new one can be found here :
http://www.lfsforum.net/showthread.php?p=430874#post430874

So I understand if ISB_CLICKABLE is not set, button would be just text with no background at all?

Can text on button use colour codes? Also, how about text align on button? (left, center, possibly right).

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

Few more thoughts... maybe slightly better would be to define button with top left coordinates X, Y and size X, Y. Also way to delete all buttons at once could be useful, perhaps with MaxType = 0; ClickID = 255.

And how would you define "coordinates" on a auto scaling interface? Remember, this must work for all different resolutions LFS offers, so using absolute pixel coordinates isn't advisable.

I didn't mention any pixels...

AndroidXP is right wich sense then would make a x,y coordinate?

@nikka
yes, but you shouldn´t need it if you play singleplayer, only in lan it could cause problems.

Quote from hackerx :

I didn't mention any pixels...

Then what unit would the coordinates be? And what would be the difference to using Left (X), Top (Y), Right (X+length), Bottom (Y+height)? I mean, adding the button dimension can't be a serious problem, no?

Quote from hackerx :

Few more thoughts... maybe slightly better would be to define button with top left coordinates X, Y and size X, Y. Also way to delete all buttons at once could be useful, perhaps with MaxType = 0; ClickID = 255.

I'll consider the width and height request. Would that make it easier to create buttons?

There is already a way to clear all buttons - an IS_BTN with no buttons is a special case meaning delete all.

Quote from AndroidXP :

And how would you define "coordinates" on a auto scaling interface? Remember, this must work for all different resolutions LFS offers, so using absolute pixel coordinates isn't advisable.

0 is the left, 100 is the middle, 200 is the right.

A box which is 100 x 100 is not square, it is the same aspect ratio as your screen.

While you're at it, how about a text field with variable text length? It would allow me to display a MOTD, detailed information about the server [and so on and so forth] without having to align a large number of buttons.

Quote from Scawen :

I'll consider the width and height request. Would that make it easier to create buttons?

Just I thought that this way it would be little bit more elegant. Not important really.

Quote from Scawen :

There is already a way to clear all buttons - an IS_BTN with no buttons is a special case meaning delete all.

Oops, somehow I missed that, sry.

Quote from felplacerad :

While you're at it, how about a text field with variable text length? It would allow me to display a MOTD, detailed information about the server [and so on and so forth] without having to align a large number of buttons.

int TextLen[1] // number of characters
char Text[TextLen] // text

Well... to keep it all simple, clean and safe, every button just has a fixed size text field stored in it. It gets more complicated if I start to have to allocate special text arrays for long text buttons - it's not just a case of adding a packet. And I don't just want to have a massive text field for all buttons, I'm trying to keep down the memory usage of the system, so if long text buttons were available they'd have to be programmed as a special case - one that I was hoping we could avoid...

So... do you really need long text buttons? I sort of thought that for most buttons, 31 characters would be enough. I suppose you are thinking you'd just like to write one long sentence - but I'm not sure it's worth the extra trouble of programming, if possible I'd like to keep it quite small and clean. Is there something you just can't do with limited size text buttons?

Quote from Scawen :

I suppose you are thinking you'd just like to write one long sentence [...]

Since I'm interested in printing, for example a full Message of the Day (one or two paragraphs of text) I'd currently need to align a large amount of buttons into a table-structure. A text container with x, y, width, height, length, text would be nice.

I guess it would be useful if InSim programs could create screen with multi-line text field, like one that pops up when hires skins are enabled in Options/misc. Also with OK/(optional?)cancel buttons. Could display there for example help text for InSim program.

Only problem I can think of is if you have limit on packet size, then text could be split to multiple packets.

Edit: doh, of course there's packet size limit, as byte is used for it.

ok my camera-change-per-buttons app is waiting for the patch ;D

Whats with a lifetime from LFS or/and from a InSim program and how can a player stop a button and all button?

Quote from CLRS530 :

...and how can a player stop a button and all button?

That's a good question. I hope nobody has the idea to fill the whole screen wih buttons if someone crashs to "force him to shift+s"...

Quote from GeForz :

That's a good question. I hope nobody has the idea to fill the whole screen wih buttons if someone crashs to "force him to shift+s"...

It is already possible to /spec, /kick & /ban with InSim so I don't see problem here. If function is powerful enough to be useful it can also be abused. If somebody decides to spam buttons, then just leave that server...

And few more ideas:

How about possibility to position button also relative to existing HUD elements? For example, so that Y position is given with normal 0-200 coordinate, but in X direction button is placed as much right or left as possible, without covering HUD (X = some magic number > 200). In this case also makes sense to have button size defined as I proposed above (coordinate + size instead of pair of coordinates), as one coordinate is not known to InSim program.

Another idea is adding button to Escape menu, for easy access to InSim program without cluttering the screen. Could be enabled with IBtn.ClickID = some number > 159 in IS_BTN.

Also I don't see way to show same button on all connections? Maybe a flag in IBtn.BStyle to make button show on all connections, including those made after defining a button. So to say, a persistent button.

OK that's all I can think of right now, hope that some of my ideas are helpful.

Quote from felplacerad :

Since I'm interested in printing, for example a full Message of the Day (one or two paragraphs of text) I'd currently need to align a large amount of buttons into a table-structure. A text container with x, y, width, height, length, text would be nice.

After some thought, I have decided to do variable length text - 32 chars per text box just won't be enough so I'll allow fully variable text strings, up to 240 chars or so (whatever will fit in to a 252 byte packet with a button header).

Quote from hackerx :

I guess it would be useful if InSim programs could create screen with multi-line text field, like one that pops up when hires skins are enabled in Options/misc. Also with OK/(optional?)cancel buttons. Could display there for example help text for InSim program.

I'm not sure yet if I'll support multi line text buttons but I've noted it for consideration - of course it's possible now that long text will be supported. I'll consider the OK and cancel buttons - though I think that is just a text colour thing, you can make your own ok and cancel buttons.

Quote from CLRS530 :

Whats with a lifetime from LFS or/and from a InSim program and how can a player stop a button and all button?

I'm not sure what you mean about the lifetime from LFS bit. But my current intention is to have a key probably SHIFT+I that can do two things - (1) if there are no buttons on screen - send a simple message to the hosts's InSim meaning "I want some info" and (2) if you already have InSim buttons on screen, it would clear them all. So it would work like a toggle.

Quote from hackerx :

How about possibility to position button also relative to existing HUD elements? For example, so that Y position is given with normal 0-200 coordinate, but in X direction button is placed as much right or left as possible, without covering HUD (X = some magic number > 200). In this case also makes sense to have button size defined as I proposed above (coordinate + size instead of pair of coordinates), as one coordinate is not known to InSim program.

Another idea is adding button to Escape menu, for easy access to InSim program without cluttering the screen. Could be enabled with IBtn.ClickID = some number > 159 in IS_BTN.

I think I'll just keep it simple - the programmer should be careful not to overwrite LFS 2d display - see the attachment for the left middle part of the screen which is free both in game and in the game setup screen. In the game setup screen, connection and players list is not shown if there are any InSim buttons up. You can also see the left and right alignment options in operation and two different button colours. Also "clickable" is now separate from the option to have a button background. The plan is that when a programmer sends no clickable buttons, the mouse button doesn't need to appear.

Quote from Scawen :

Quote from CLRS530 :

Whats with a lifetime from LFS or/and from a InSim program and how can a player stop a button and all button?

I'm not sure what you mean about the lifetime from LFS bit. But my current intention is to have a key probably SHIFT+I that can do two things - (1) if there are no buttons on screen - send a simple message to the hosts's InSim meaning "I want some info" and (2) if you already have InSim buttons on screen, it would clear them all. So it would work like a toggle.

Hmm, could it be that you mostly don´t understand what I mean :/ We are definitely not on one writing-level

With lifetime I mean how long the buttons stay until they dissapear (automatic SHIFT + I). If you plan to have such a lifetime.
The other question was if it would be good to let us decide how long the buttons should appear.
It´s only an idea, I don´t use this interface (in the near future)

Quote from MoHaX :

you could clear any button by it's id, also you could clear all butons at once, isn't it enough?

He probably wants to create some "info buttons" which only display info. And it would be much easyer if you could create a button which is only displayed for 60 seconds instead of tracking the button and connection id's in your program and send a "remove buttons" packet after 60 seconds.

Quote from MoHaX :

2Scawen:
I can't figre out from your description and screenshot: how to make big (as on top of your screenshot) and small (as buttom one) buttons? And it seems that buttons are 2 size only - big and small. Is it possible to make it's size variable (width only, not font size)?

The size of a button is defined by the positions of the top, left, right and bottom borders in the IBtn struct

OK, I think I've covered most of the requests and a some more things I thought of. It now supports local AND remote buttons, so you can have a local InSim program running with its buttons, independent of the host buttons.

Please have a look at this new specification and see if it makes sense, any mistakes or anything I've left out.

I hope to release this to you this evening so you can have a go. Time is running out now for patch X...

Just 2 Questions:

// Local InSim programmers should try to avoid overlapping host buttons.
How does the programmer know where the "host buttons" are? Or do you mean an overlapping in the ID'? How does the programmer know that there is no other (local) insim program setting up a button with the same id? And are Button clicks sent to "all" connected insim Applications or is this seperated?

// highest bit (128) can be set to initialise dialog with the button's text
Does that mean if the first bit is set and the user clicks on the button the text will stay in the button and the user can change the text? And when the first bit is not set the text displayed in the button disappeares as soon as the user starts to enter his own text?

Quote from GeForz :

// Local InSim programmers should try to avoid overlapping host buttons.
How does the programmer know where the "host buttons" are? Or do you mean an overlapping in the ID'? How does the programmer know that there is no other (local) insim program setting up a button with the same id? And are Button clicks sent to "all" connected insim Applications or is this seperated?

I meant they should try to avoid overlapping on screen. A local InSim program can't use the same button ID as a host InSim because the local button ID's run from 160 to 239, whereas host buttons runs from 0 to 159.

It is impossible to know where other buttons are, but I think programmers of "local" InSim programs (with not too many buttons on screen at once) may wish to provide a cfg option for the button positioning and the button ID range, so that a user can have more than one "local" InSim program running, and also the user could choose positioning that avoids the menu or info display of their favourite hosts - if that InSim program may be running while the user is online.

There is no protection against one local InSim program overwriting the button of another one.

Quote from GeForz :

// highest bit (128) can be set to initialise dialog with the button's text
Does that mean if the first bit is set and the user clicks on the button the text will stay in the button and the user can change the text? And when the first bit is not set the text displayed in the button disappeares as soon as the user starts to enter his own text?

Yes, actually the user doesn't type in the text box, but in a LFS style dialog (though I may improve that in future). But yes, with highest bit set, the dialog box is initialised with the text from the button.

OK, thanks for your help.

I've started a new thread for the new system which is ready for testing.

http://www.lfsforum.net/showthread.php?t=24783