Topic: Content and looks of the new "cheap in-game help"

SirVer wrote: Hi,

Now for the content: I looked through the empire toolsmithy and the coalmine. I generally feel that the at-a-glance and detailed separation works well for me

I hoped it would. ;) And I hope it does work for others, too. I am still not sure about where exactly the "at a glance" and the "detailed" should be called from, and whether they should be available from one spot (house window?) or better separated and two spots (short from house window, detailed from "?" menu). But that can be found and discussed later, if now we have no time left.

• I also love the shot you made at the lore; I think they are excellent examples of what I had in mind.

Hmm... I still think, we should try to find some native English speaker for that job, but as long as we don't have one, I'll carry on with it. If we ever find one, my texts can always be refined.

In the at-a-glance section I would not list properties that are of no interest (namely conquer area, enhanced from).

Are you sure they are "not of interest"? I could imagine they sometimes may be. Not sure though.... easy enough to skip when doing the final layout. If you don't mind, I'd like to keep them for the time being for the sake of completeness.

About the layout: I assume the blue triangles are a kind of "link" to the description of the item in the help. That is unfortunately not supported, some of the other Layout is also not supported, e.g. tables.

No, the triangles are bracketing "variables" (in my wordprocessor). I used them (though they don't make much sense for my writing atm.) to indicate, that this is an information (or a string) that can be found elsewhere in the game, be it in the conf files or some other (i.e. /Widelands/global/militarysites) files. This should indicate, that such parts can be referenced maybe and so should be less troublesome when keeping the help files up to date. As for the rest.... the layout is not at all a suggestion for the final one. Just something to make the current version more "readable".

About the empire toolsmith: I also like what I see there; The lore fits my understanding of the empire and is nice in tone and quality. I am not missing any information and I can't think of any more to include atm.

Well, glad you like it , Hope I can keep up some decent speculations on what you want the tribes to be.....

As mentioned I feel it is important trying to get a prototype help into the game. It will show quickly where more work is needed layout and controlling wise.

I expect that will take some time still. But if anybody can come up with some sort of template for me to fill, I'll try to work with it. Otherwise I'll just go on collecting and sorting the information for each house and write some more of the pdfs. I don't mind the extra work of possibly cutting and pasting it into a final from later.

Regards and a happy season to everyone!

Same to you, SirVer, whereever you spend your December

Being no programmer, I apologize for all my suggestions that imply undue workload and for other misjudgements due to lack of expertise or relevant skills.
I am on Win32, have no means to compile, and rely on prefabricated distributions (Thanks to Tino).

Top

Quote

Hi Venatrix!
First and foremost my apologies for taking so long to react.
I am really sorry, but always shortly before Christmas, things tend to become a bit crazy.
I think, we will be making something out of this and I'll look into your source.lua files to see if I can
understand part of it.
For the moment, I'll comment only on what I can see.
It seems a pdf montage might server best for that purpose.

Here it is.

Being no programmer, I apologize for all my suggestions that imply undue workload and for other misjudgements due to lack of expertise or relevant skills.
I am on Win32, have no means to compile, and rely on prefabricated distributions (Thanks to Tino).

Top

Quote

I'm at it - but will need more time again to reply to the pdf - sorry again.

Too bad Siver is currently not available.
I am really starting to wonder, if we're not trying to re-invent the wheel with this. As everybody should know by now, I am pretty naive as far as programming goes, but I am really asking myself, if we truly have to struggle with the formatting of rich text boxes! It's like coding a little word-processor of your own, just for having a help system.
I mean ... this is something that each and every game, and most programs need. An in-game help, decently formated, using text and graphics. Can it really be that there are no pre-existing solutions for this in the public domain? Okay, localization to many languages and easy maintainance are harsh requirement on top of it, I could image. Or is more like a challenge that you all feel willing to pick up?

Syntax for a masked link is: [text to display](URL to link to)

Being no programmer, I apologize for all my suggestions that imply undue workload and for other misjudgements due to lack of expertise or relevant skills.
I am on Win32, have no means to compile, and rely on prefabricated distributions (Thanks to Tino).

Top

Quote

Well...

Actually I am not that deep into the graphics rendering code, however I'll try to explain the situation and hope that at least most of it is correct ;).

Basically both of you are right - there are quite a lot tool-kits and librarys one could possibly use, so the question is, why don't we use one of those. I think there are several reasons for this:

• When the richtext renderer was initially introduced (btw. mostly a copy of the one of Battle for Wesnoth) there was no need for very complex structures like "dynamic tables" or "floating images" - the renderer was fine as it is.
• The renderer was based upon SDL libraries and thus was easily integrated into Widelands, which used SDL as render engine - in the mean time the rendering was ported to OpenGL as well.
• Using another common tool kit would cost (of course depending on which tool kit we would choose) a lot of time to work with our SDL + OpenGL backend - just as example: the QT richtext boxes or html boxes look very nice in QT applications, but they are almost incompatible to our code, as we use our own SDL/OpenGL based tool kit (again the question why using our own tool kit? Well the decission was made about 10 years ago - QT was no alternative for game programming back in these days (and it still really isn't)) So integrating these text boxes would basically mean, that we have to rewrite the whole graphical rendering of widgets and most likely not just the text boxes, but from all widgets - basically a move to the QT widget set - might improve the game, but it is likely a lot less work to improve our own tool kit to fit our likings, than converting all UI code to use QT widgets and make the code QT rendering (actually I am not quite sure if using QT rendered boxes inside a SDL window would work at all - so perhaps even the map rendering and all this stuff would have to be rewritten with QT code to have a complete QT version of Widelands).
• Using another uncommon tool kit compatible/almost compatible to our SDL rendering (a quick internet search lead me to SDL_rtf, but I did not find any screenshots of rendered text. Another library was SDL-widgets, but I am not sure how good their text renderer works, neither if all their code is already working with OpenGL or how easy it is portable - and even if, this would cost a lot of time as well -> like with the QT example): This might work and might even be less work in taking care about the code in future, once the move is done - but only if the library/tool kit stays under development and bugs are fixed quite fast -> a good example how this can end is our metaserver / internet code - we use the ggz libraries, which are quite far developed, however at some places they do not offer everything we need and unfortunally the development rests since quite a while... now after all work we put into the ggz code it is hard to decide to ripp it out again to write our own code, but a decission on this is still pending, as no more maintained libraries are at least a security problem...

Well I think I have written quite a lot ... I could write even more, but basically the point is: From our current point - with all the code we have written and improved - the best way to go seems to be to improve our on richtext renderer instead of using another one.

Top

Quote

(getting offtopic - sorry for that - but I would like to comment on the "dropping SDL" ;))

The "dropping of SDL" that is discussed lately only applies to the graphical backend. It does not mean, that we would remove all SDL dependencies... unfortunally this would take quite a lot more work. Just keep in mind, that we use a lot of libraries, which themselves need SDL, like SDL_mixer for music and sound playback, SDL_net for network functions, SDL_png (okay that one would not be needed once we switch to OpenGL ), etc. - and there are more non graphical SDL calls in our code (at least i implemented one for the max frames per second feature and I am quite sure there are even more)...

So... things are quite more complex (or should I say complicated ) than they seem

Top

Quote