UI modding - support thread

[stefanEgo]

3.50 Beta 2 was just released and should fix the problem with distributing mods in the catalog files as well as several incompatibilities between FFI-IDs and LuaIDs.

Here's the list of UI modding issues fixed in 3.50 Beta 2: http://www.egosoft.com:8282/jira/issues ... ity%20DESC

Breaking changes in 3.50 Beta 2 - see http://forum.egosoft.com/viewtopic.php? ... 23#4498023

• IsComponentValid() renamed to IsValidComponent()

[blackmilan]

Hi Stefan, thanks for bringing us 3.5 beta 2. As promised before I tried a few things and I have to say I am quite happy with the new possibilites. Adding and removing objects from the menu is working out fine and having all the little helper functions which have been local before available makes things much more accessible compared to beta 1.

There is one improvement which I like to mention at the moment. It is not really a feature request but rather a suggestion for a general improvement of the code and I am aware that it is not that easy to change without putting in some effort.

At the moment there are some functions with a lot of code lines (e.g. menu_trading_offers -> menu.displayMenu() has roughly 300 lines). If you want change something right in the middle of such a function this can get quite challenging because one has to handle all the things which depend on the changed part.

For example I am working on adding an additional filter to the trade menu that automatically filters the list based on the cargo type of the selected ship (see http://forum.egosoft.com/viewtopic.php?t=373397 for the old version compatible to 2.51). If the code to filter and sort the trades would be separate functions instead of being part of menu.displayMenu() it could be changed without touching the rest of the menu structure. Right now I am trying to take the final trade menu as returned by menu.displayMenu() and remove those lines which are not applicable to my ship. But it would be much easier if the filter could be changed before the wares are added to the menu.

Have a nice weekend and I am looking forward to your feedback.

Edit: I have added a feature request in JIRA http://www.egosoft.com:8282/jira/browse/XRUIMOD-16

[stefanEgo]

@blackmilan: We'll consider simplifying adjusting the filter logic in the tradeoffer menu by modders. Unfortunately we can't afford the resources to go through all the Lua scripts and simplify whatever feels worth the effort to us.
It would take quite a while to go through everything and then we end up with only a handful of things we overhauled actually being used by modders in the end. This would be quite some waste of time which would have better been invested in other work, in our opinion.

I hope you understand this. I suggest that you simply create a JIRA issue, if you run into a case where you feel it could be simplified (also a list of cases which you want to use is fine with us - but these should be concrete examples). We will then consider doing that at some point.

For future script changes we will obviously also better keep an eye on splitting functionality in certain functions for the purpose of simplifying the modders work, but be aware that we can't give a guarantee here.

So the best way would be to report limitations to us while you run into them. That way we won't invest time in things which nobody needs and can rather concentrate on stuff which is not only potentially useful to everybody, but actually really used in the end.

I've updated ur JIRA issue and limited the scope to the trading offers menu filtering logic. Feel free to create subsequent JIRA issues for other cases, if you think there are more which would help you.

[stefanEgo]

I'm glad to be able to reveal another surprise as part of the upcoming 3.50 release to you: We now opened-up our Wiki-system. All UI modding documentation is now accessible directly from our internal wiki system: https://www.egosoft.com:8444/confluence ... dding+Home

We hope that this more direct distribution of modding documentation benefits you in that you get updated documentations faster (since we no longer need to port them to the Forum) as well as improve the readability of the documentation, since the Wiki system allows for better formatting than what is possible here in the Forum.

The documentation thread will still be kept in this Forum with the main purpose of other modders being able to add their own documentation there.

[YorrickVander]

Loving the new modding wiki Stefan - do you folks have any plans to allow the use of lua as a function, or as a mod 'script' in it's own right outside the use of menus? What I have in mind is the way C code can be integrated into python.

EDIT : I'm aware we can directly call lua via debug command line but that's not very user friendly for a released mod.

[blackmilan]

Another surprise? I have to say Christmas for modders is really early this year The Wiki looks great!

I am totally fine with your approach. Thanks for updating my JIRA ticket and considering an update of the filter functionalityin the trade menu. This is the only concrete case I have right now and I agree you should not waste time on code which is not used in mods.

[stefanEgo]

@blackmilan: XRUIMOD-16 should be fixed in the next version
@YorrickVander: What exactly do you mean by "Lua as a function or as a mod 'script'"? Are you suggesting a facility which allows you to copy/paste Lua code into the game directly and have it executed? If so, then this should in principle be achievable by writing your own mod. The only thing which might be missing would be a function to paste the text into the game (atm only copying to the clipboard is possible). Is that what you have in mind?

[stefanEgo]

We've also just added a page which shows the changelog of UI modding changes as a shortcut to get a quick overview of what's going on atm as well as what was done in older versions: https://www.egosoft.com:8444/confluence ... /Changelog

[stefanEgo]

@wysiwyg: in the next build we added support for single addons to run in multiple environments and also specify dependencies based on the environment. That should restore (and actually even extend) the same functionality which was possible in 3.20.

Please note that this will impose a breaking change of existing addons unfortunately, since we changed the ui.xml format slightly. The change is recorded here: https://www.egosoft.com:8444/confluence ... .50+Beta+2

[stefanEgo]

@Phipsz/wysiwyg: The described workaround (adding a subdirectory called ui/addons/ego_xxx/ui.xml) doesn't seem to work here. Can you provide test-files which work for you?

[YorrickVander]

@stefan - no mate, as I said, in a similar way to which compiled c can be used from python scripts. To elaborate - say there's a function/mod i want to write that is best achieved in lua, but i currently cannot do that unless i am running that lua code as part of a detail monitor menu. Are there any plans to make this possible?

[Phipsz]

@stefan: simply adding a folder didn't work for me either, but adding a ui/addons/ego_* folder with ui.xml etc in a subst_01.cat worked for me. Don't know if it still works, as I ported my mods already to the official structure. If there should still be need of an example I can see if I can upload a previous version of any of my mods tomorrow.

@yorrick: you could create a fake menu that you call from md. this fake menu would need to have Helper.closeMenuAndCancel as last action of menu.onShowMenu (don't know if these are completely correct, have no examples on current pc) that way you could include lua into md while that menu closes itself

[stefanEgo]

@Phipsz: I'c. using the substitution facility for this was the missing link. Thanks for clarifying.

@YorrickVander: Pardon me, but still having difficulties fully getting what you mean here... By adding a Lua file to any addon, all the code which is inside the Lua file is executed on load (which normally is at the time the game starts). So if you write the following code:

Code: Select all

function foo()
-- do whatever you wanna do here
end

foo()

your function foo will be executed on load directly.
If you want to execute that upon some other trigger, you have different possibilities to do so. One example was given by Phipsz. Another example is to execute the function/code on a timely manner or upon certain gamestates, in which case you have the onUpdate()-function you could use. The onUpdate() function is executed every frame, so you could implement the trigger condition like:

Code: Select all

function onUpdate()
-- if I'm in a ship and being attacked by drones then
foo()

-- or alternatively to call ur function every 200 frames
int count = 0
function onUpdate()
  if count == 200
    foo()
    count = 0
  else
    count = count + 1
  end
end

function init()
-- create your frame
SetScript(myFrame, "onUpdate", onUpdate)

Do u mean that atm you lack the possibilitiy to execute scripts upon keypresses directly? Aka you would like to execute your function foo() when you press "k" for instance?

[YorrickVander]

I had meant as a function call from xml, but the onupdate method might well be a viable workaround, i hadn't considered it before.

[stefanEgo]

@YorrickVander: Thanks for clarifying what you mean. Now I got it. We are considering improving the interfacing between the UI and MD at some point. I've created a JIRA issue for that feature request: https://www.egosoft.com:8443/jira/browse/XRUIMOD-19

@all: We've also updated Lua/FFI function overview in Confluence. It should be easier to get an overview of the available functions now. See https://www.egosoft.com:8444/confluence ... n+overview and https://www.egosoft.com:8444/confluence ... n+overview

[wysiwyg]

@wysiwyg: in the next build we added support for single addons to run in multiple environments and also specify dependencies based on the environment. That should restore (and actually even extend) the same functionality which was possible in 3.20.

Please note that this will impose a breaking change of existing addons unfortunately, since we changed the ui.xml format slightly. The change is recorded here: http://www.egosoft.com:8292/confluence/ ... .50+Beta+2

Seems to be working fine - Many thanks for the continued updates.

[Vim Razz]

I'm still digesting all of this -- the new amount of information you guys are making available is amazing.

Is there any chance we might get a few more input options for menu button hotkeys in the future? I've got a few in mind that I'd really love to see:

INPUT_STATE_DETAILMONITOR_PGUP
INPUT_STATE_DETAILMONITOR_PGDN
INPUT_STATE_DETAILMONITOR_HOME
INPUT_STATE_DETAILMONITOR_END

[stefanEgo]

@wysiwyg: thanks for the update
@Vim Razz: input handling is really a bit limited atm, unfortunately - I've added a feature request to the bugtracker for you ( http://www.egosoft.com:8282/jira/browse/XRUIMOD-20 ), but can't give an ETA

[stefanEgo]

@Phipsz: FYI in the next 3.50 build, the "workaround" you suggested will no longer work, since all the cases for which you previously had to use the subst-catalog-files should now be properly supported by the engine (see: https://www.egosoft.com:8444/confluence ... .50+Beta+3)
Please let us know if you still run into a case which seems to not be possible without the subst-catalog-files, so we can resolve that in time for 3.50.
@YorrickVander: In the next build we added a new MD action called "raise_lua_event". That should allow you to send data from MD to Lua scripts as well as being used as a trigger for any kind of functionality. Please let us know if that does not solve the case for you.

[YorrickVander]

Sounds great Stefan, thanks