A UI modding adventure
Moderators: Moderators for English X Forum, Scripting / Modding Moderators
- TheRealBix
- Posts: 400
- Joined: Thu, 2. Jul 09, 14:34
- YorrickVander
- Posts: 2702
- Joined: Tue, 29. Oct 13, 21:59
Understood mate, I've even made a couple of simple mods myself (Shady Slater, Copilot Convo etc) due to some of the more glaring and irritating design failures. My point here is simply that scripting a solution for friendly fire isn't really feasible without the actual collision physics allowing for fleet members not being hitTheRealBix wrote:So yes, if Egosoft don't do it, someone have to do it for them.
X Rebirth - A Sirius Cybernetics Corporation Product
Split irritate visiting pilot with strange vocal patterns.
Split irritate visiting pilot with strange vocal patterns.
How is that a sane option?YorrickVander wrote:I'm gonna go out on a limb and suggest this friendly fire is something ES needs to address in the exe - the normal game cheat of 'fire through' friendlies at the base code level would be the sane option.
I might come over a bit idealistic here but if you ask me it'd be quite immersion breaking to watch an epic space battle between fleets take place and friendlies just shooting straight through each other.
How about spatial tactics? positioning? flak defensive lines (that your own fighters/drones better stay far clear of if they don't wish to be torn to bits)?
@Mad_Joker, regarding the 'station fleet' thing, I believe it'd be cleaner to group those into a 'fleet'(?) called STATIONS, under which the -actual- station fleets are located.. this way if you have, say, 20+ stations, the first 20 entries in your fleet management window isn't taken up by all those stations that may or may not have ships/fleets assigned to them.
Grouping them all together in one big 'STATION' parent entry means you can either expand that to look at your station fleets or ignore this one single fleet entry and work on all of your ship fleets.
That's just how I imagine it'd be best to go about keeping the fleet window uncluttered, I just mention it to make you aware of the fact that it could get messy real quick if one has many stations/fleets.
- YorrickVander
- Posts: 2702
- Joined: Tue, 29. Oct 13, 21:59
Maybe i phrased that badly Replace 'sane' then with 'likely to happen in a reasonable timeframe' perhaps? Telling your fighters to stay out of the capitals firing solution (BSG springs to mind) would be great but I imagine there would be a lot of fiddly code and probably inherent lag for in-zone fights with the extra overhead.
X Rebirth - A Sirius Cybernetics Corporation Product
Split irritate visiting pilot with strange vocal patterns.
Split irritate visiting pilot with strange vocal patterns.
Alright, here then a screenshot of the final version of the fleet management screen for now. Tomorrow is a holiday where I live, so I hope I will be able to release UFO tomorrow.
http://static-2.nexusmods.com/15/mods/1 ... 884615.png
{Images posted directly to the forums should not be greater than 640x480 or 100kb, oversize image now linked - Terre}
http://static-2.nexusmods.com/15/mods/1 ... 884615.png
{Images posted directly to the forums should not be greater than 640x480 or 100kb, oversize image now linked - Terre}
- TheRealBix
- Posts: 400
- Joined: Thu, 2. Jul 09, 14:34
Oh well played with the tree-like display !
On the other side, there will not be a lot of space for characters.. I think for other languages like French, but even for english, in the right side dor exemple (location).
Maybe you could shorten some words like "Shields" and "Hull", or remove "Location" (it seems obvious this is the location).
Bref, you should try to gain some space and I don't see anything more to say at the moment.
Great job anyway !
On the other side, there will not be a lot of space for characters.. I think for other languages like French, but even for english, in the right side dor exemple (location).
Maybe you could shorten some words like "Shields" and "Hull", or remove "Location" (it seems obvious this is the location).
Bref, you should try to gain some space and I don't see anything more to say at the moment.
Great job anyway !
-
- Posts: 1002
- Joined: Fri, 13. Jan 12, 19:09
Hey, at least someone have put the decompiler into good work, great! =)
BTW, about the column vs. point issue - it should be fixed in the latest version. The decompiler tries to guess obj.func(obj, foo, blah) calls being obj:func(foo, blah) calls instead, but sometimes it may still fail miserably due to considering two "objs" being different.
UI framework is pretty much crappy, that's true, but that's a legacy of being a little bit too universal - EgoSoft clearly planed UI to be somewhat moddable. At least eventmonitor/main monitor handlers have a distinctive plugin system in place. But other then that everything else just looks a bit too rushed (just as a whole game, that is).
Bad news are that visuals are still out-of-reach. We can't create new controls or change their appearance - damn binary Anark files. I've found a place in code which reads then and a way to disassemble/debug it - it should be fairly possible to create a decent structure of the format, but that's a tedious process and I just don't have so much time. If anyone interested I may send instructions and information I dug up so far (via PM, obviously. I doubt EgoSoft will be happy with decompilation instructions just lying around the forum).
But I see that another problem - Inability to change a game state via UI is somehow fixed, isn't it? Because a few versions earlier it was clearly impossible to affect any arbitrary game object state (other than a very small set of explicitly exported narrow functions) or issue a MD command. Even such a simple thing as ship renaming wasn't possible until EgoSoft did it exporting a corresponding function along the way.
Anyway, if you'll encounter any problems with the decompiler - just create an issue on github and I'll do my best and try to fix it asap. Well, unless that's a while loop with complex subexpressions - that will take a while to fix.
BTW, about the column vs. point issue - it should be fixed in the latest version. The decompiler tries to guess obj.func(obj, foo, blah) calls being obj:func(foo, blah) calls instead, but sometimes it may still fail miserably due to considering two "objs" being different.
UI framework is pretty much crappy, that's true, but that's a legacy of being a little bit too universal - EgoSoft clearly planed UI to be somewhat moddable. At least eventmonitor/main monitor handlers have a distinctive plugin system in place. But other then that everything else just looks a bit too rushed (just as a whole game, that is).
Bad news are that visuals are still out-of-reach. We can't create new controls or change their appearance - damn binary Anark files. I've found a place in code which reads then and a way to disassemble/debug it - it should be fairly possible to create a decent structure of the format, but that's a tedious process and I just don't have so much time. If anyone interested I may send instructions and information I dug up so far (via PM, obviously. I doubt EgoSoft will be happy with decompilation instructions just lying around the forum).
But I see that another problem - Inability to change a game state via UI is somehow fixed, isn't it? Because a few versions earlier it was clearly impossible to affect any arbitrary game object state (other than a very small set of explicitly exported narrow functions) or issue a MD command. Even such a simple thing as ship renaming wasn't possible until EgoSoft did it exporting a corresponding function along the way.
Anyway, if you'll encounter any problems with the decompiler - just create an issue on github and I'll do my best and try to fix it asap. Well, unless that's a while loop with complex subexpressions - that will take a while to fix.
It's funny you mentioned BSG because that's -exactly- what I was thinking of.YorrickVander wrote:Maybe i phrased that badly Replace 'sane' then with 'likely to happen in a reasonable timeframe' perhaps? Telling your fighters to stay out of the capitals firing solution (BSG springs to mind) would be great but I imagine there would be a lot of fiddly code and probably inherent lag for in-zone fights with the extra overhead.
So, I have finally release the new UFO version. The mod download only contains the compiled UI files, but you can find the sources on my GitHub repository.
Thank you very much!Mad_Joker wrote:So, I have finally release the new UFO version. The mod download only contains the compiled UI files, but you can find the sources on my GitHub repository.
- TheRealBix
- Posts: 400
- Joined: Thu, 2. Jul 09, 14:34
-
- Posts: 711
- Joined: Tue, 20. Jun 06, 02:29
-
- Posts: 1002
- Joined: Fri, 13. Jan 12, 19:09
So... there are magic functions
and corresponding helper functions in the Helper script. That's a lot. Guess I should've paid more attention on some basic handlers.
Too bad it works only for conversations - it's impossible to implement everything in Lua, you still have to prepare arguments and apply returns using the horrific XML language. But that's a big help anyway.
Just a short run-through on how it (Lua<->MD ex) works:
You register your lua scripts into
. That will load them into the game (There are more addon categories than detailmonitor - eventmonitor or gameoptions, for instance)
Then you may call
where "YourMenuName" is a lua-script base name which establish a particular set of callback functions to be a valid menu. And params could be just anything valid for XML - it will be translated into lua transparently, AFAIR.
When your menu (which could be written with or without EgoSoft's helper) opens you may read arguments passed into using function stated above, or just let the Helper to supply them to you (as it will call your callback when it's already loaded into given parameters). And when you are done, you may set return args with the function above or use convenient Helper functions to close-and-return.
You may establish a cue waiting for the return by waiting for gMainUniverse_main "section" to become active and probably some other flag (which you set before the call and unset after receiving the return) to detect if that's yours menu closed, not just any.
All the credit for that revelation goes to MJ.
Code: Select all
arg1, arg2 = GetMenuParameters()
ReturnFromMenu(array)
Too bad it works only for conversations - it's impossible to implement everything in Lua, you still have to prepare arguments and apply returns using the horrific XML language. But that's a big help anyway.
Just a short run-through on how it (Lua<->MD ex) works:
You register your lua scripts into
Code: Select all
ui/addons/detailmonitor/detailmonitor.xml
Then you may call
Code: Select all
<open_conversation_menu menu="YourMenuName" params='valid_xml_expression_which_could_be_an_array' />
When your menu (which could be written with or without EgoSoft's helper) opens you may read arguments passed into using function stated above, or just let the Helper to supply them to you (as it will call your callback when it's already loaded into given parameters). And when you are done, you may set return args with the function above or use convenient Helper functions to close-and-return.
You may establish a cue waiting for the return by waiting for gMainUniverse_main "section" to become active and probably some other flag (which you set before the call and unset after receiving the return) to detect if that's yours menu closed, not just any.
All the credit for that revelation goes to MJ.
- YorrickVander
- Posts: 2702
- Joined: Tue, 29. Oct 13, 21:59
I think the only way to be free of xml would be to replace the debug log/input keypress lua files, but I'm not sure what functionality could be added without connecting to mission director scripts.
X Rebirth - A Sirius Cybernetics Corporation Product
Split irritate visiting pilot with strange vocal patterns.
Split irritate visiting pilot with strange vocal patterns.
-
- Posts: 1002
- Joined: Fri, 13. Jan 12, 19:09
Nah. You may process keys, you may do virtually everything within lua, but you can't change an arbitrary game state property in lua (which kinda makes sense for an UI framework). MD may change almost anything. Original implementation of command interface MadJoker was referring too as being "a weird mix or MD and lua code" was trying to split UI (made in Lua) and logic parts (various sanity checks made in MD), which probably is not so great idea (while split is a good idea, implementing different parts in different languages is definitely a bad one).
Result of moving both UI and logic into Lua while using MD only for applying Lua-calculated params into the game state is that MadJoker's implementation is not only more functional, but also shorter and cleaner, which means more readable and understandable.
IMO EgoSoft should think about implementing MD<->Lua bindings - that will help a lot. Probably changing an UI framework will be a good idea too =) Anark is... weird one.
Result of moving both UI and logic into Lua while using MD only for applying Lua-calculated params into the game state is that MadJoker's implementation is not only more functional, but also shorter and cleaner, which means more readable and understandable.
IMO EgoSoft should think about implementing MD<->Lua bindings - that will help a lot. Probably changing an UI framework will be a good idea too =) Anark is... weird one.
I did some analysis on the Anark file formats (.bgp, .bgf and .bsg) and got them figured out pretty much completely. Here's the documentation.
As a summary, these are the formats involved:
As a summary, these are the formats involved:
- .bgp: Binary Game Plan, defines the different states that the game can be in and the UI files that need to be loaded in each state. There's only one file of this type (ui/core/default.bgp). Its source (default.xgp, an XML file) is in the same folder.
- .dae: Collada scene file containing the model for a specific GUI component. The game uses this file for scene hierarchy information, but the actual mesh information is retrieved from .xmf files.
- .bgf: Binary GameFace?, defines presentation slides and animations on top of the scene nodes in the .dae.
- .bsg: Binary Scene Graph, just a binary file containing a subset of the information in the .dae. Not sure what the point of this format is, it doesn't seem to have any added value.
- .amw: Anark project file. Unused by the game.
- YorrickVander
- Posts: 2702
- Joined: Tue, 29. Oct 13, 21:59
Re: A UI modding adventure
Hello!
People, did anyone have information about the .bgf format? User arc_ has found documentation, but links are no longer available.
Help what you can.
thank
People, did anyone have information about the .bgf format? User arc_ has found documentation, but links are no longer available.
Help what you can.
thank