Orxonox

btw. I just looked at the few examples, Starlance has a quite large cockpit, so does Aquanox.

A large cockpit yes, but does it contain any information? no, it does not - it is purely for the feeling.

I think the criticism of the first HUD should be more specific, guys. Not good is way not good enough constructive criticism. Also be more specific what each example does right, and what could be better in each example.

True... I try to be a bit more specific.

In general, most HUD in games are symmetric. I'll elaborate for Freelancer.
In the lower corners, there are 2 lists; the left one is for all objects in the area (or at the players choice, only important ones, waypoints, loot, or just fighters or (dockable) stations.) the right one is for the players ship, it displays loaded and activated weapons, amount of shield batteries and repairbots. The energy system is rather simple, and displayed in the 3 bars at the lower edge are for shields, armor and afterburner. The upper center bar describes normal actions: free flight, auto pilot, docking maneouvre and formation flight. Top right corner is the games menu.

About the steering itself: it was optimised for mouse use, thus you were able to click on any menuitem/list if you wanted, but I always used the keyboard which is was much faster.

The more i think about it, the more I see the need to do a meeting and discuss what we want in the game. otherwise it is rather difficult to design a HUD which only displays what we need, and not to many irrelevant information.

cheers
nico

Okay, thanks for all of your answers

Last semester, I just wanted the HUD to work, but didnt care whether the HUD looks smart. (Something that doesnt work is useless, it doesnt matter how cute it looks) Actually, in the last version, all attributes (like position, color) of every single element were variable. And few elements were put into a container, which was variable as well.
In the C files, I wrote several functions for variation.

Well, now I want TWO things.:

1. try to vary the attributes while the game is running
2. a new HUD design, which is cute enough for all

For further programming and designing I have to know which attributes actually have a value (like energy value, or shild value) so I can start with these ones.

A large cockpit yes, but does it contain any information? no, it does not - it is purely for the feeling.

my cockpit was also just for the feeling and I prefer thing that doesnt look symmetric

Anyway, I think making it semitransparent is a good idea. I am going to paint modules semitransparent, sofar you tell me which ones are necessary at the moment. How we put them together, we can discuss when I have them finished.

For further programming and designing I have to know which attributes actually have a value (like energy value, or shild value) so I can start with these ones.

sure... {could somebody correct me if I write BS}

And keep in mind, that most "values" are should be represented in an abstract way - think bars.

• Weapons energy (one or more is not fix yet.)
• shields - I'd like to have multiple shield sections later on - but we'll start probably with 1 value.
• armor
• electronics - like armor, but for your systems
• missiles - think highly limited big ouch weapon

What IS important is, what patrick wrote earlier:
The HUD should be modular so changes can be applied a lot easier. For instance: Don't create a health bar, a energy bar, a shield bar etc. but one single bar, which can be used at different positions, for many values and behaves like we like to.
This is of course only a example. Modularity has to be driven farther than just that. Think what parts of the HUD are similar and can be grouped.

You mean I should write a class for, for example, "bar", which contains things like length, width, color and functions like show(), setFOO(args)?

It's a nice idea. I can do it, but since orxonox doesn't run on my computer, I cannot debug my code. Anyway, I will write a construct at first.

Exactly. Of course you should keep in mind, where it DOES make sense and when not. The bar for instance can be used for several things. Also think about vertical and horizontal bars and ask you the question if the bar should be rectangular or dashed or rounded or curved or whatever and if the style of the bar can be set as well.

I just found out that it will not be possible to write a class such as Class Bar, because no constructor can be made. Bar's "motherclass" Ogre::OverlayElement does not have a constructor as well, it is created by a factory named Ogre::OverlayManager.

Anyway, I dont see any possibility to create a Bar unless I can write an inheritance class from Ogre::OverlayManager, which seems to be quite complicated.

Hope has not gone yet, there is another way to create modules. Namely, templates can be written in the script. Lets see, what I can find out about this way.

Good thing you found that out. In this case you will have to do more programming on those scripts. Just try to keep it as modular as possible.

Or you make a class that creates a bar with the OverlayManager and that has functions (setSize, setPosition or something like that) to access it.

Now I just tried another possibility: I put this overlayElement as a public variable of the Bar class, so that it can be used by "Bar b->element".

Anyway, I still got this error message "Undefined Reference to <any function of Bar>". This error message comes out, after codes have been compiled and are waiting for being linked to each other.

Why can I declare an object of that class, but cannot use its functions?

Maybe you've forgotten to write Bar:: before the functionname in the .cc file?

No it's not the problem. This will cause an error while the program is being compiled, but the compilation ran very well. The error just occured by linking codes to each other.

Well, the problem is surely LINKING.

In the last version of orxonox, the class HUD worked. So I copied this class to a class named HUD2 and also changed several things in orxonox.cc . Anyway, HUD2 doesn't work anymore, although it exactly has the same code as the original one.

Do I have to change anything in any file when I add a new file to project? What is "svn add" and does it have an influence on this problem?

Anyway, HUD2 doesnt work anymore, although it exactly has the same code as the original one.

I really doubt that it has. Different class name means different implementations, so the code cannot be exactly the same - though I start splitting hairs here.

have I to change anything in any file when I add a new file to project? what is actually about "svn add", does it have an influence to this problem?

svn add has, as the name implies, only to do with svn. it add the file to the repo, which means it is under version control fro now on.

short answer yes, long answer, it depends on what file it is... I assume you are talking about a source file, then yes you have to add it to an appropriate CMakeLists.txt, that way the source gets built, and it can be linked at link time...

I hope this answers your question.

cheers
nico

fabian told me on irc that I have to add the file name to CMakeList.txt or something like this. And now it works