Support for xData file format for readme files

[datiswous]

Currently readme's are txt files, but when they're longer, they can't be displayed correctly in the Notes section of a mission listing. If they would be xData files, scroll-buttons can be added so that the whole file can be properly read.

This is under the asumption that it cannot be done with unformatted txt files. My idea (if possible) is to support both formats, so readme's of current missions still work correctly. Otherwise I don't see it happening soon, because all the txt based readme's have to be converted, so a program has to be written to do that job in a non-painful way.

I orinally posted this idea here:

 

Edited April 20 by datiswous

[OrbWeaver]

I'm not really up to speed on exactly what goes into an xData file, but do you mean that each readme would include its own copy of the scroll buttons and their required functionality? Because that's definitely the wrong solution to this particular problem from an engineering perspective.

If a readme is only intended to include text, then that's all that should appear in the file, not text plus a load of GUI boilerplate which will be identical in every readme and will probably just have to be copy-pasted from somewhere else. It should be up to the game engine to display the text in an appropriate way, including adding a scroll mechanism if it is needed.

[datiswous]

Xdata has a formatting for page 1, page 2, etc. (at least in briefings) So if you support it, mission authors can use the format to put the readme in multiple pages, which can be viewed in the main menu via the Notes button, the up and down buttons work the same as in a text only briefing.

The scroll button functionality whould go inside the gui file that is used to display the readme file in TDM Notes.

If possible it would only show the navigation buttons if a "page2_body" (or something) is present.

 

[OrbWeaver]

Oh I see, that's fine then (at least with regards to my concern about GUI duplication — I have no idea if the switch from text to xData would cause any other problems).

[datiswous]

Well, the idea is, that first is checked what type of readme is loaded, xdata, or just text. If only text, then current view is used, if xdata readme file, the gui has different rules.

Seeing how it works inside briefing gui's I assumed xdata is the easiest way to implement proper viewing of large readme's inside Notes gui.

Off course this is all under the assumption that it is possible to implement and if developers are interested in implementing it..

[datiswous]

On 4/21/2023 at 5:20 PM, datiswous said:

and if developers are interested in implementing it..

I guess not. If I ever get the knowledge to program tdm patches, I might give this a try. Currently readme file display is essentially broken if more than a certain amount of text is used.

[nbohr1more]

1 hour ago, datiswous said:

I guess not. If I ever get the knowledge to program tdm patches, I might give this a try. Currently readme file display is essentially broken if more than a certain amount of text is used.

I wouldn't necessarily say there is a lack of interest, rather this is lower on the priorities list than other things.

I agree that we should consider xdata  support though. Especially since it would be easier to hook existing translation code into.

( Though there is also a line of thought that we should completely revamp our translation mechanism and expanding the existing mechanism will make that even harder. )

 

There's no hard and fast rule but I would say the priorities go something like:

1) Crashes or breakage that needs to be fixed ASAP

2) Community code contributions

3) Community asset contributions

4) Things that are "interesting" or "fun" to implement

5) Things that are "easy" to implement

6) Things that the developers feel would really improve the project game-play

7) Code cleanup and structural fixes

8  ) Performance improvements and optimization

9) Accessibility improvements ( subtitles, translation, etc)

10) Bugfixes for existing assets

11) Enhancements to existing assets

12) New graphics features

Given that we are a volunteer project, the priority list is always gonna be a mixture of "proper priorities" and things that are easy, interesting, or fun to implement.

Grayman's approach was to survey the bug tracker for trends that revolve around a somewhat narrow topic and then compare that to community comments about the topic and develop a new design that covers all contingencies related to the topic. This would fix a large number of bug reports at once since it would either make them obsolete by removing the wonky parts of the prior design or make the design better match how players interfaced with the issue. The only downside to that approach was that covering "all contingencies" sometimes meant a very large conditional tree and that would span a huge swath of the project code ( thus risking lots of unforeseen bugs ).

[datiswous]

Thanks for giving detailed insight.

22 hours ago, nbohr1more said:

Especially since it would be easier to hook existing translation code into.

I don't understand what the navigation of readme files has to do with translation. Or can readme files also be translated? I didn't look much into translation, because of the complexity and I personally don't have a need for it for my language.