[Nuke]

oh goodie so it will be scriptable from the ground up.

[Valathil]

its more like i give you every feature in the scripting api that you have in C (except adding something to the ui code yourself of course) the ui itself is coded in C and i just expose an API to you in lua that you can use to register elements how you want them and when something happens i call you script back and say hey button id 12 was just mouseovered or clicked or whatever and you have to handle the event.

[Nuke]

sounds good. thats pretty much how my lua based system would have worked.

[z64555]

Thumbs up guys, I'll definitely will be watching this topic. 

Maybe use something like http://berkelium.org,
it would make it possible to create the ui in javascript and html.

I think they are the most future proof way to build ui's today.

Novalogic's DF:BHD through DF:X2 has used an XML based ui for its pre-game menus and some of its in-game menu's too.

I've also heard that several of the new fps games use sometime similar... but I don't know if XML support is worth discussing here.

[Valathil]

im not a fan of the "me too"  xml approach. xml is a great way do dynamically define datasets but not really good to enable dynamic responses i a ui. sure you could define the layout of the ui with xml and script the rest but why dont we just define the layout in the script as well and skip the "me too" part

[Valathil]

I got the first script hooks for presentation working. Here is the graphics options menu i posted earlier reinplemented in script with the script in question so you can get a feeling for the syntax. Lot of numbers, most of them are the colors for the borders and windows. Im thinking of writing a wrapper in lua so you can use tables to predefine colors. Thing is you have to include this bit of code yourself so i am open for any suggestions that could simplify passing colors to the functions.

[attachment deleted by a basterd]

[Nuke]

cant wait till it hits trunk, can use it to configure script related things. how will events be handled?

as for the wrapper theres my lua-based table parser which is quite functional right now. though there is still much room for improvement. especially needs better documentation. i intent to have a qualification system in place that enforces certain values and ranges of values of a specific type and generates proper error messages for modders. as usual my svn should have the latest version of the script under script include. i posted it somewhere on the scripting forum but its probably an old version. as of right now i dont know if anyone is using it. id love some feedback and bug reports from other scripters to help improve it.

http://nukedspace.fsmods.net/svn/trunk/script_include/data/scripts/parser.lua

[Nuke]

i kinda just had an idea about how to better handle apperance of scripted elements. what if we have table based style sheets that define the default and alternate styles (including color data and bitmaps) for the various interface elements, so that scripting can just needs to concern itself with things like form layout and and event handling. this way a mod can define the interface style and if that mod uses any scripted forms then they would also use the same style in order to keep the interface elements somewhat uniform. have an interface style object to use as an argument to the button registering function, you could load any style defined in the table. you could probably also have ui functions to create styles from scratch in the code. this would eliminate a lot of redundant data in the script and make the ui scripts a little bit easier to read.

[Valathil]

good idea i thought about that myself but was too lazy to implement it till is saw the numbers mess that i created.