ogre branch ? new attempt from scratch

[ghoulsblade2]

ugh, messy. ingame i see the weapon slots, but not sure about the restrictions of the rest.
I'll assume every ship has exactly one slot of these (correct me if wrong) :
armor, capacitor, reactor, spec, jump, sensors, shields, overdrive....
But how about ecm, cargo expansion, cloaking etc,
any "med-power" or "1 per category" slot system i'm missing or just limited by upgrade-space ?

in units.csv i also only found the weapon slots, so i'll assume something like 1 per category (2 reactors ? yummy)

[klauss]

Now that you mention it, I have no idea.

You may be right (one per category). I'm not sure. Perhaps the master_part_list.xml (or something name like that) holds some clues.

[ghoulsblade2]

dragdrop working, also added scrollpane and a grid widget for the inventory on the left to allow icons to be dragged back as well.
also figured out how to make the git repos public readable, and it's now available under :
git clone git://zwischenwelt.org/vegaogre.git
(not much sense yet, since i'm still playing around with the api and there's no gameplay yet. also the win exe is outdated, but we should get a new one early next week)

[ghoulsblade2]

uploaded a small vid of what we have so far, no real gameplay yet :
http://www.youtube.com/watch?v=nKH-Y6-xLSs
also not in the vid yet : first experimental target markers in hud.

[klauss]

Watch out for distances and numerical precision issues.

VS aims at realistic distances, and that means really huge numbers.

[ghoulsblade2]

yep, already on it. the new ogre v1.7 has some improvements there afaik

[klauss]

Check the Ogre branch for inspiration if you wish, but in order to render such huge distances correcly, VS has to render things in 4 layers.

Farthest from all is the skybox: We had planned 3D skyboxes (nebula and other major galactic features would be dynamically rendered there - it would provide really wonderful intersystem warp for vegatrek and other mods).

Next comes the far layer: planets and distant stations need to be rendered with specific z-buffer settings, since the distances are so great. We tried rendering without z-buffering, but planetary rings would not render correctly, and bases would also look funny since we had to render a mesh at a time, so painter sort only handled things up to a point. The final solution here was setting an infinit z-far projection matrix with a rather large z-near value and render all far objects there.

Next comes the near layer: nearby ships and near stations get rendered after a z-buffer clear after the far layer. Ie: render background, zclear, render far layer, zclear, render near layer. z-buffer settings are the usual.

Finally comes the cockpit: vs supports 3D cockpits. They're not used very much because we don't have many modelled, and because we don't have a way to properly overlay HUD elements on them as we discussed earlier. But, again, cockpits handle distances way too small for the other layers, so to properly display complex cockpits, z-buffering must be tuned to the cockpit's mesh. VS computes z-far and z-near from the cockpit's mesh, and renders it on its own layer.

All that can be done with Ogre, but it requires setting up a lot of weird stuff in-between rendering sequences using a RenderQueueListener.

[ghoulsblade2]

far/near render-layers : yep, sounds like a good idea, especially the nebula effects sound interesting.
I also think ogre1.7 handles large distances from the coordinate origin better than 1.6
as long as the relative coordinates (to the scenenode to which an object is attached) are small,
so a good scene-node-hierarchy with re-attaching the ship-scenenode to the nearest "location" might help a lot.
I'll soon find out, that what i'm gonna play with next =)

Skybox and stars should probably be rendered with both depth-check and z-write disabled.

Layers : Ogre render-groups didn't work for it ?
haven't done anything with them yet,
but what you refer to as "layer" sounds like what a ogre-"rendergroup" does.
(possibly a z-clear-rendergroup in between).


btw, any feedback on the dragdrop slot system gui so far ?
is it the way you imagined or did you expect something totally different ?
the window/gui theme is programmer-art/placeholder and could probably be improved,
not sure how you like the style i picked,
we could also make it transparent green-grid like cyberspace stuff,
or something entirely different if you have suggestions =)

how would you like something circular around the ship like in eve-online :
http://junglebiscuit.com/images/evescreenshots2.jpg
http://axyd.us/blog/media/1/thorax_fitting%201.png

realistic distances and planet sizes :
Do you happen to know what sizes of planets and distances from the sun would be appropriate ?
I didn't find planets in the units.csv and distances wouldn't be there anyway.

[klauss]

Layers : Ogre render-groups didn't work for it ?
haven't done anything with them yet,
but what you refer to as "layer" sounds like what a ogre-"rendergroup" does.
(possibly a z-clear-rendergroup in between).

Yep, only 1, people tend to not realize there's a problem with z-buffering until it's too late (so I thought I'd give you a heads-up), and 2, they probably added the z-clear-rendergroup you mention after I commented about what I was doing on the forums . I had to do it with RenderQueueListeners.

[klauss]

btw, any feedback on the dragdrop slot system gui so far ?
is it the way you imagined or did you expect something totally different ?
the window/gui theme is programmer-art/placeholder and could probably be improved,
not sure how you like the style i picked,
we could also make it transparent green-grid like cyberspace stuff,
or something entirely different if you have suggestions =)

Only I was thinking something more visual.
Your mockup seems too similar to the current interface, only with icons in place of text, and atm no place for detailled stats (which a lot of peopl are fond of).
Being a wip, I wasn't going to say much until I saw more of its progress, but since you asked

Perhaps if you had the slots overlaid on ship schematics or something like that...

realistic distances and planet sizes :
Do you happen to know what sizes of planets and distances from the sun would be appropriate ?
I didn't find planets in the units.csv and distances wouldn't be there anyway.

I know earth is 8 light-hours from the sun. In VS, it's not so, I think the scale is 1:10, so it's be 48 light-minutes = 864.000.000.000 meters.

[ghoulsblade2]

thanks =)

more visual than icons: i don't quite understand, do you mean 3d dragdrop to the actual weaponslots on the shipmodel or something else ?

description text : of course i'll add that, those are neccessary infos if you're not buying blind.
and a big tooltip with image and name and some important values as well.

[klauss]

more visual than icons: i don't quite understand, do you mean 3d dragdrop to the actual weaponslots on the shipmodel or something else ?

3d dragdrop would be great, next to that, a dragdrop into slots placed over a 2d ship schematic would also work. So that you know what slot is for what.

(perhaps color coding and a legend would also help there)

[ghoulsblade2]

how about the placement of stations ?
random inside a system sounds bad,
how about placing them at some distance near planets and asteroid fields or so.
how far away from a planet (surface) would a station roughly be ?
(how about moons ?)

[klauss]

All (stations and moons) orbit around planets.

Ships too btw.

[Neskiairti]

what GUI lib are you using for ogre? CEGUI, MyGUI?

[ghoulsblade2]

gui lib : selfmade : lugre framework : lua+ogre bindings and utilities a few friends and me developed across multiple projects using ogre.

how far away from a planet (surface) would a station roughly be ?

[klauss]

In sectors/Sol/Sol.system line 29 you have earth, the moon, and its stations.

There, the ri/rj/rk + si/sj/sk attributes specify an orbital plane and orbit radius (the two directions specify a plane, the magnitude its radius). In a particular case, |r|=|s|=0.28e5, that's roughly 28km.

[ghoulsblade2]

ah cool, thanks =D

[ghoulsblade2]

asteroid belts : any render tech for that yet ? is there player-mining in vegastrike ? would it be thinkable gameplay and canon-wise ?

[klauss]

For asteroids, I had planned to implement prefabbed imposter clouds (ie - not dynamic, runtime-rendered imposters, only statically baked imposter clouds used as LODs).

Nothing too fancy, yet efficient.

I never got to it, so right now VS only renders them as usual. Hence the less-than-desirable performance.

Re. asteroid mining, yep, there is something like that. Not sure it's that valuable gameplay-wise, but it's there. (I believe you just blow the asteroids and tractor in the "minable leftovers").

[-REBEL3-]

For asteroids, I had planned to implement prefabbed imposter clouds (ie - not dynamic, runtime-rendered imposters, only statically baked imposter clouds used as LODs).

Nothing too fancy, yet efficient.

I never got to it, so right now VS only renders them as usual. Hence the less-than-desirable performance.

Re. asteroid mining, yep, there is something like that. Not sure it's that valuable gameplay-wise, but it's there. (I believe you just blow the asteroids and tractor in the "minable leftovers").

Re. asteroid mining-I took a look @ the code-roids are treated as ships with no engines/shields. They have AI. Have cargo in the hold-when killed, drop cargo. Make roids a special class, not ships-they don't work well-they drop regular cargo boxes.

Got to run.

[ghoulsblade2]

how about a weapon : "mining laser" that spawns ore/rock in cargohold when fired at an asteroid ?
A brutal combat weapon wouldn't be the best mining tool after all.

[TBeholder]

how about a weapon : "mining laser" that spawns ore/rock in cargohold when fired at an asteroid ?
A brutal combat weapon wouldn't be the best mining tool after all.

As i understand it, in-'verse it would be a special short-range stone-grinder "weapon" (laser may or may not be not the best) + tractor beam.
Of course, we still can just break it and tractor big fragments in (deal with stones instead of gravel).
It's just that right now weapons work in a rather primitive way that doesn't allow simple things like event handlers, so no "asteroid's hitpoints to my cargo". Even tractors and EMPs are hardcoded.

[ghoulsblade2]

weaponscripts hardcoded and hard to extend : oh damn, that sounds bad =(

such a mining grinder/laser/tool could use sensors to tractor in the valuable ore and leave the worthless stone. if you just shoot the asteroid without thinking and pick up all lumps that fit in the cargohold, you should end up with mostly worthless stone.

[klauss]

You say games don't usually have damage models hardcoded?

Scriptable damage models?

It's a neat idea but I hadn't seen it implemented previously in any game.