Base definition files

For collaboration on developing the mod capabilities of VS; request new features, report bugs, or suggest improvements

Moderator: Mod Contributor

chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Very true, but don't forget that vegastrike the engine shouldn't necessarily be able to serve only the needs of vegastrike-like games. One of these days you might get a bunch of people wanting to use the engine for a Homeworld Remake, and they'd need a dumb meteorite approaching, which cannot be persuaded to veer off course, but has to be destroyed.
Planetary orbits and ship AI's are fine, but these are high level constructs; and completeness calls for the availability of low level constructs as well. If people misuse them and end up in a bad state, it's their problem; but low level handles on things should exist.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Post by safemode »

indeed
Ed Sweetman endorses this message.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Post by klauss »

Ehm... Actually I was thinking scene manager stuff (animations) for the discussed 3D base interface - ie: interiors, where AIs take little part.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

What I was suggesting is that perhaps there's no reason for the engine to even differentiate between bases, space, animations, etceteras. Rather than write interfaces for all these game states; I think it would be much easier to write one scene manager that manages everything 3D, 2D or any D's. Right now there are 4 hard-coded game states in the engine: Booting, @aBase, Animation and Space. Video is kind of a fifth. And there seems to be a common theme running of features from one state needed in another:
  • Will need all kinds of animations at 3D bases: characters, doors, elevators, including character AI driving the characters, and dumb, repetitive motions, like a radar dish or light turning back and forth in an arc.
  • Ships could use animations for opening blast doors for escorts to land and stuff.
  • Need to write take off and landing animations for PU, but we don't know how; there's no official interface.
  • Will need keyframe animations inside cockpits, to talk to the pilot of a ship while sitting next to him (future project)
  • Will need to put video onto 3D quads, for comms in 3D cockpits; as well as change 2D textures on 3D computer screens at bases
  • PLUS, 3D positional sound is applicable in just about any state. For instance, if tomorrow a bunch of people decide to use vegastrike for a Starcraft remake, they will need positional sound in spite of being essentially in a 2D interface all the time.
So, it just occured to me to wonder, why hard-code all these states? That's like 5x the work of just coming up with one generic scene manager and leaving game states to the data side. Game state should be a python thing, seems to me.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Post by klauss »

Hardcoding states streamlines the code associated to any state. But I wouldn't stick to those states anyway. I'd revise the list first. For instace, I'd make "base interface" (and cockpit) a layer, rather than a state. (simultaneously running)
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Layers... Yeah, that sounds righter. Z-buffer layers, eh? I guess it also offers the possibility of each layer having its own coordinate system. Maybe tarzan's planetary LOD thing could occupy a layer between those two.
TBeholder
Elite Venturer
Elite Venturer
Posts: 753
Joined: Sat Apr 15, 2006 2:40 am
Location: chthonic safety

Post by TBeholder »

chuck_starchaser wrote: When you consider the problem of animations at bases, and combine it with the problem of producing animations in space, the two come together. There's no point in trying to resolve them separately. [...] Then *ONE* scene manager will be able to produce normal space action, scripted animations of ships landing or taking off, ships or bases with moving parts, base interiors with people walking around, etceteras.
I just would like to point out that this side of issue cannot be emphasized enough.
IMO most important here is not possibility to see docker bots crawling around PC's ship (or even tractor-beam crane replacing turret in real time), but possibility to see NPC ship's landing/takeoff at next berth while PC ship is docked. That is, “life continues, even if you're at portâ€
"Two Eyes Good, Eleven Eyes Better." -Michele Carter
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Base definition files

Post by chuck_starchaser »

BUMP!

Something needs to be done about this. Ships look AWFUL at their pads.

Image

Maybe just forget about 3D bases and animations; just a means to control the lighting would be awsome.
legine
Bounty Hunter
Bounty Hunter
Posts: 139
Joined: Mon Sep 27, 2004 8:40 am
Location: Germany
Contact:

Re: Base definition files

Post by legine »

I not feeling like wanting to say much. I just didn't supply anything jet except a lot of Ideas...

Wouldn't it be more wise to generate out of an XML File an Object that is available within python?

I mean maybe doing something like:

Code: Select all

    <?xml version="1.0"?>
    <base title="Agricultural" xmlns:xi="http://www.w3.org/2001/XInclude">
       <room title="Landing Pad" id="landing_pad" onLoad="VS.playList('agricultural.m3u')">
          <camera i="0.5" j="0.87" k="0" />
          <mesh file="landing_pad.bfxm" x="0" y="0" z="0" scale="150" />
          <mesh file="generic_door.bfxm" id="concourse_door" x="0" y="0" z="100" />
          <button style="invisible" onClick="moveTo('concourse_door',(0,5,100), 2.0, lambda: goToRoom('concourse'))" />
       </room>
       <room title="Main Concourse" id="concourse">
          <camera i="1" j="0" k="0" />
          <mesh file="agri_concourse.bfxm" x="0" y="-5" z="0" scale="2" />
       </room>
       <xi:include href="weapons-room.xml" />
    </base>
And then call it from an python script:

Code: Select all

import VS
import guitng
    
readbase("XMLfile.XML")
agricultural.addmesh('landing_pad', 'ship', VS.getPlayer().getFilename()), (0, 25, 0), (0.71, 0, 0.71))
agricultural.show
I think that is a better approach to use XML stuff. I am aware that this is different then you guys used it before, but I think it is easier to handle in general. What do you think? Hope I am not stressing you guys to much :)
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: Base definition files

Post by chuck_starchaser »

Yeah; something like that should suffice, with the addition for a light position.
In fact, there's already the means to specify camera and ship positions via the
python file; so it's a matter of adding one more entry for a room mesh... --AND
the light(s)... The biggest problem right now being that lighting for the ship on
the pad is not computed, but rather "remembered" from the last lighting
condition in space. If the starlight is coming from below you at the moment
you dock, your ship on the pad looks like it's lit from below.
Another thing that's necessary; almost forgot, is a per-room environment map.
This is even more important than lights, as the lighting could be standardized
for all bases as semi-diffuse (meaning semi-ambient) and coming from above;
but nothing would provide as much "presence" as specular reflections that
agree with the environment we see.
Phlogios
Confed Special Operative
Confed Special Operative
Posts: 298
Joined: Sun Jul 30, 2006 1:38 pm
Location: Sweden
Contact:

Re: Base definition files

Post by Phlogios »

chuck_starchaser wrote: This is even more important than lights, as the lighting could be standardized
for all bases as semi-diffuse (meaning semi-ambient) and coming from above;
but nothing would provide as much "presence" as specular reflections that
agree with the environment we see.
Aye
"Enjoy the Choice" - A very wise man from Ottawa.
Post Reply