Base definition files

[chuck_starchaser]

Would it be too much to ask for a "base definition file" feature?
Perhaps this problem has already been resolved, and I'm not aware of it... I'm writing on the basis of a bug report with Privateer: Parallel Universe, which, as of this writing is still a mod of PR1.2; so, using a VERY old version of the VS engine. But just in case, here it goes:

The problem:

When ships are landed at a base (at least in PU) they seem to "remember" the lighting conditions in space, which are often quite different from the lighting conditions at a base (or the lighting conditions of the 3D mental model that the 2D base representation suggests).

Another manifestation of this "ship memory" bug, is that if one lands on a planet while on side-view, or external view, one can end up with the ship hanging up-side-down from the ceiling like a bat.

The proposed solution:

A file, or an entry in some existing file, that allows to define:

• Screen coordinates of where the center of the ship should be. Preferably, the center of the base of the ship, so that bigger or smaller ships don't seem to appear parked off-center on the landing pad.
• 3D rotation of the ship
• 3D position of light source(s).
• Name of texture for custom environment map.
• EXTRA: Optionally, a rate of rotation; for possibly having a rotating platform, for like show-rooms...

If the file is not provided, then the engine could revert to the old behavior, for backward compatibility.

If the proposal is deemed relevant but not urgent enough, any info on where in the source code one could try and look to make it happen, would be much appreciated.

Thanks; and Happy New Year!

PS:
If I may add, this feature would be good for ALL VS mods, methinks.

[ace123]

The Base interface and UI is terrible as it is, however it can't hurt to just add another function.

An extra file just for this is way too complicated and also adds another series of complications with directory paths,

I'm thinking something like "Base.Light(x,y,z,i,j,k)" where you specify the coordinates of the light and the direction it faces. If you don't call that function it will use the old behavior.

If you look in base_interface.cpp you can see where it draws the ship... I think it's a function called DrawNow that was kind of hacked up in the last minute.

As for center coordinates, it shouldn't be hard to get the center coordinates by scaling it by the Z value. The rotation I think you just specify the forward and top vectors, and you should be able figure it out, with the right hand rule. I don't see how an extra parameter would make this part any simpler.

However, allowing for dynamic rotation and so on is asking for way too much. Feel free to do this if you want... however I would like to see a nice new base system designed first, with a possibility for 3d bases as so many people have asked for.

And an environment map... that'd best wait until we have a nice OGRE-based engine.

[chuck_starchaser]

Alright!; thanks Ace! That's good enough... almost; just one more param: The ambient light. I'm thinking, for instance, in the repairs shop, in Privateer, there's a lot of lights in the ceiling. Once could approximate that pretty well with about half the light coming from one white light above, and the other half from white ambient light.

If you look in base_interface.cpp you can see where it draws the ship... I think it's a function called DrawNow that was kind of hacked up in the last minute.

I'll have a look. I'm curious why is it that if one lands while on external view (specially if one has rotated the view around) the ship appears stuck on a wall, after landing at the base. Even after leaving the base, the external view is remembered. Maybe resetting the view to standard cockpit view at the moment of landing might fix the bug.

[chuck_starchaser]

Another thing that would be good is being able to put in formula-based
numbers, rather than fixed numbers. Take, for instance, the upgrades room:



Small ships could be centered over the shadow; but if the player owns some huge ship, like a Drayman or a Paradigm,
perhaps all we should see above the shadow is just the tip of the ship's nose.
To do that, one could shift the center of the ship to the right as a function of the ship's length.
The height of the ship's center could similarly come from its vertical dimension.
Unless the code could help do these calculations; though, in that case, we'd have to have an extra parameter, for
what to use as the reference... Landing pads would use the center of the base of a ship; the upgrades room would use
the point at which the ship's nose projects onto the plane of the base, and so on...
On the other hand, size differences in ships can be so huge, that perhaps one might want to
scale larger ships down by like the square root of their actual sizes...
Maybe the best solution would be to have per-ship parameters that affect how they are scaled
and oriented and shifted in the various rooms...
Nah; that's a cross multiplication of cases; better to use formulas; but I don't know where that's done,
or could be done.
Come to think of it, the larger ships would not fit in some of the landing pads or rooms, and
perhaps should not land, at all, but rather dock with stations. This could be the best solution; but then
we'd need a boolean in units.csv to tell whether a ship should land or dock...

[chuck_starchaser]

Update: After Hellcat's help in migrating to the latest vs engine, we did these
different computer backgrounds and they work great. Thanks!

I was just coming to BUMP this thread in regards to the subject of the first
post. Ships look ridiculous sometimes, like when the light comes from below
them before landing on a planet, and they keep illuminated from below even
though the lights in the room or landing pad come from above. Even if, to
simplify things, the light were fixed as coming from above the ship, it would
be orders of magnitude better than what we got right now.

[chuck_starchaser]

I have a simpler idea, in lieu for a better fix to this lighting problem:

The lighting on the ship only gets messed up when you land on a planet after flying with the sun on your belly.

When you load a game, however, and you see your ship landed, the lighting looks right... --probably because
the engine assumes a default light position above the ship.

If the code could be changed so that the engine *always* assumes that default light position, rather than
"remember" the lighting conditions in space, when you land, it would be much better.

[ace123]

now if only I could figure out where that initial value comes from... I suspect something in the Camera constructor.

Is that true for all planets, or is it just a coincidence with the starting system? Doesn't it depend on which sun is in that system?

[chuck_starchaser]

LOL
I just went to check to make sure, went through all my save files, about 25 of them, and...
The light is always from above, EXCEPT at mining bases. At mining bases it seems to be random.

[chuck_starchaser]

Would this be easier if we provide separate models (bfxm's) for ships when seen at bases?
Because, I'll tell you what: When ships are landed, you're supposed to see their landing gear; so we'll have to have separate meshes, anyways.
If so, how'd we go about specifying specific meshes for the landings and/or the upgrades room?

[Dilloh]

The initial values might be sent from the NO_ROOM_ERROR-"script", if there is one - at least there seems to be one for the case if no base script is specified.

[klauss]

Re: base definition file

It so happens that when GUI.py was created (for GUI elements like buttons and such), also XGUI.py was created in a similar commit. The purpose of XGUI.py is... gues...

To wrap GUI.py calls into an XML base definition file

Problem is, that XML has to have behavior descriptors, and the specification alone of how such a behavior would work is quite some work. The idea I had is to add "pythonscript" support (elements like buttons could have embedded python scripts that get called when something happens, like html's javascript).

My knowledge of python was, at the time, too nimble to flesh that out properly, and so I didn't (not even improperly). I just knew it was possible, and since the feature wasn't required ASAP I left it there.

Now I know a lot more python. I might be able to do it without that much effort, but I'm stretched already. In any case, better control over how 3D objects (and not only your ship) appear in bases was always planned for that GUI/XGUI duetto.

[chuck_starchaser]

How long would it take?
(Texture Packing Version and Tangents *MUST* come first, though.)

Any way we could hack this into existence? Never mind whole base definition files... Just of getting an alternative mesh displayed when you land?
I could give this mesh pre-baked lighting, too. I'd like to, in fact.

[klauss]

The idea is to have mini-scenes. You'd specify object positions, light positions, even environment textures.

I believe the API support for that could be done without much trouble - perhaps customizing environment textures is the hardest. But positioning stuff is probably rather easy.

But, as you said, tangents and techniques come first (BTW: techniques is half-way there).

[chuck_starchaser]

The idea is to have mini-scenes. You'd specify object positions, light positions, even environment textures.

I believe the API support for that could be done without much trouble - perhaps customizing environment textures is the hardest. But positioning stuff is probably rather easy.

Why not go all the way and have whole 3D scenes?
I don't think it would take me half as long to model a base as it takes to figure out how to place 3D objects
onto 2D backgrounds. I mean, defining the positions of ships on the landing pads was horrendously painstaking
work and they still aren't right. If you gave me half a chance to put a 3D environment there, I'd drop those
2D background graphics like a hot potato.

But, as you said, tangents and techniques come first (BTW: techniques is half-way there).

YEY!

[ace123]

We really need an overhaul of the whole base system (I'm talking the C++ side more than Python).

As to switching to XML, I take it that you don't mean the old format we initially tried:
http://vegastrike.svn.sourceforge.net/v ... threv=4225

I would like a 3d system as long as it includes 2D support (for UI, etc.)

The system should allow for scripting, and as I saw with what GUI.py made possible (the base system was modeled off that XML format), the more scripting, the merrier.
It would be cool if you could script animations in a mesh (door opening, etc.)

Also, it must allow for UI... and as sad as it seems it might be worthwhile keeping support for existing python code, and sticking all of the sprites in front of the 3D layer--then you can change existing base by removing the textures and adding a model.

I don't know if we want actual person models but it would be nice to build in support for having models fly/drive/walk through the bases... I'm thinking like the cars you see in Privateer bases, or ships (they can use the actual ship models) near a landing pad.

So a lot of things to consider... I'm scared about moving everything to XML since that limits flexibility, and it would be cool to have a system designed right from the ground up rather than in a quirky way.

[klauss]

It won't limit flexibility. The pythonscript will be able to do whatever we do now in bare python, it will only wrap it all up so that you don't have to write code for common tasks.

Think:

Code: Select all

...
   <script>
        import whatevermodule
        do whatever XML doesn't let you
        define whatever function you like

        class LaunchButton(GUIButton):
             def onClick(self):
                  # launch
   </script>

   <button style="menuitem" id="save" onClick="setRoom(rooms.save)" />
   <button style="menuitem" id="load" onClick="setRoom(rooms.load)" />
   <button style="invisible" id="launch" class="LaunchButton" />
...

Exactly what "style" means I was specifying when I stopped working on it. Basically, the idea is to separate behavior from style as much as possible (like stylesheets).

As you see... you can always script by hand if required. Item placement is purposedly separated from everything else (through stylesheets) too, so editors can play around with item placement without messing with behavior and viceversa.

[chuck_starchaser]

WOW! Sounds wonderful.

[safemode]

is all this just to amp up the eye candy of bases or are we going to attemp to bring bases into the realm of actual gameplay?

Right now, your enter a base and it's like you've been plucked from the universe. what happens out there means nothing to you and vice versa. Time pretty much has no meaning on a base.

It'd be cool if that wasn't the case. Bases could be just as dangerous as flying outside, and what happens outside could effect the base as you're in it. The game could pretend in many cases and create actions, like bases on a planet can't currently be acted upon from the outside, so the game would have to make things up for those bases, but for space bases, if your base is under attack, when you land, it should act like it's under attack. And you could die in the base.

What's needed for that type of effect isn't a walking interactive environment, just the scripting mentioned in the xml definition of the base. Have certain rooms on a space base lose compression when damaged, if you happen to be in there, poof you're dead. Have ships crash land in the dock sometimes and cause havok. have crazy claxons giving out warnings. Etc etc. that type of effect should be possible if we're able to bring meshes and sprites onto a base and move it around with scripting. Could even make it possible to loot a base that's about to be destroyed. Dangerous and profitable.

Now that would be cool. Down with the safe havens.


Edit. Just had a funny idea. You're nearing the end of the "as-yet-unwritten-campaign" and you outrun a fleat of enemy ships to restock at a base. They're close behind, you have mere seconds. You rush to the repair area and begin making repairs, you watch the progress bar (new thing that takes into account how much work needs to be done and it takes varying time to do it). Suddenly the base starts to shake and red claxons go off. the sprites in the repair shop show steam and gas busting loose from a wall. The repair completes, you rush to the computer to save, hoping that you can make the escape at least after N tries if you dont make it the first. You get to the computer room just in time to see it burst in a shower of sparks. No way to save. You click on the hanger, it's now or never. The docking bay is a mess but your ship is still intact. You launch your ship and you make it out of the docking bay as it rumbles around you. You hit the afterburner while still in the tube and pray. The laser fire explodes around you as the base attempts to defend against the fleat. You're hit a couple times but you make it out of the fray, the base keeping the fleat busy for the moment. You get far enough away to spec to a safer base, a planet. Behind you, you see a flash that brightens the view for a moment as the base is destroyed, taking a few of the dumber ships from the fleat with it, leaving them dazed for now. that was close.

cmon, you cant deny that would be cool.

[chuck_starchaser]

This needs to be mod-configurable. One of the features of Privateer I really liked, versus many other games of the time, was precisely that landing at a base was a relaxing chance to catch your breath, and like a different kind of game altogether: From FPS action, to turn-based stragegy, sort of. And I would very much like to preserve this dicotomy in PU. Having time pass, and dangers lurk, while at a base, would kind of "ruin the game", --for me, at least (I don't like to be rushed 100% of the time while playing a game, though obviously you do); and it would positively be un-canonical.

[safemode]

well, yea, moddable definitely. It would definitely be good to get vanilla vegastrike further away from the various games it's been based on though. kind of put it in it's own and not just be some recreation that it's not supposed to be.

[ace123]

Actually this base scripting system could be pretty nice.

It would be awesome IMO if we could take full advantage of XML, like allowing for XInclude:
http://www.w3.org/TR/xinclude/
(The !DOCTYPE and !ENTITY systems might have similar features if we can't use XInclude)

Here's an example of the type of language I was thinking about:

Code: Select all

<?xml version="1.0"?>
<base title="Agricultural" xmlns:xi="http://www.w3.org/2001/XInclude">
	<script type="text/python">
import VS
from base_animation import moveTo
	</script>
	<room title="Landing Pad" id="landing_pad" onLoad="VS.playList('agricultural.m3u')">
		<camera i="0.5" j="0.87" k="0" />
		<script>
Base.Mesh('landing_pad', 'ship', VS.getPlayer().getFilename()), (0, 25, 0), (0.71, 0, 0.71))
		</script>
		<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>

It looks pretty messy but also could be cool if designed correctly...
Klauss, how would you envision doing a whole base in XML.

[klauss]

I already have provisions for inclusion, but in the form of processing instructions:

Code: Select all

<?include file.xml?>

It's not implemented but rather easy to.
I think the problem with XInclude is that expat doesn't handle namespaces, or something like that. But maybe we can fake it. I dunno. I'll have to try - if it pans out, I guess I could replace the PI with XInclude.

A full base would be a single XML, but with inclusion it could be divided both into rooms (one XML per room), or even standard components (ie: common rooms have their behavior scripted in common XMLs, with each base specifying a different stylesheet).

It's all playing with includes. The system will simply see a big XML with all the info.

[chuck_starchaser]

Be sure to make it user-friendly; I'm getting a headache already...

[klauss]

Well, the idea is to have editors for that kind of stuff.
We can't avoid some level of complexity when dealing with complex behaviors. At the very least, the separation between behavior and styles would allow anyone to easily play with item placement and appearance without messing around with scripts.

[chuck_starchaser]

I'm all for that; I was talking about the syntax and stuff. Personally, I absolutely HATE xml, to be honest. But I guess I'm in a minority here. Python has at least one thing gloriously right: Using indentations. With xml, just trying to figure what starts where, not to speak of where it ends, is a headache and a half. Lack of indentations means that one just has to not only figure out structure but to remember it also. I was trying to figure .system files once, and after an hour I was exhausted. Stars that contain lights, lights that appear outside of stars, asteroid field entries that seem to be repeated, things inside of things inside of things... It's just impossible to work with...