post release: What to do about nebulas

Talk among developers, and propose and discuss general development planning/tackling/etc... feature in this forum.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: post release: What to do about nebulas

Post by chuck_starchaser »

klauss wrote:
safemode wrote:ps. moving to a new physics subsystem that can handle nifty effects like explosions and such isn't a bad idea, but not one that would happen soon. Replacing the collider with bullet or the like though, is a waste of time at the moment. The only thing that would require it would be needing to deal with colliding with dynamic meshes (meshes that bend and warp)...which we dont have and wont have anytime soon.
I agree. In fact it was my point when I wrote that it wasn't a trivial matter.

But it's not only to handle nifty effects... it's also to offload development. Which is good when we're short on time and/or developers.

In that sense, maybe ODE's development is a little slow... bullet seems more actively developed. But if you've found compatibility issues...

I know ODE works well in all our supported platforms. And it integrates well with opcode, BTW. In fact there's an example of how to use opcode as collision library with ODE as dynamics solver.
Sounds good to me; or if people prefer, I could write a new physics; --been itching to do so since I found that link I posted in regards to RK4.
Or I could work on improving ODE. I found no references to RK4, but I'd be surprised if it doesn't use it. However, I also found no references to SIMD or SSE, and if it doesn't use SSE I'd be happy to work on that.
Opcode could use some refactoring, for sure; --ugly code--; and speeding up the critical routines with SSE would be an opportunity to refactor it as a side-line.
log0 wrote:2. Collisions
You don't need to use a spring-mass model.

The most simple model is an elastic collision of two point masses m0, m1 imho.
(ui, vi velocities along collision normal)
v0 = (u0 * (m0 - m1) + 2 * m1 * u1) / (m0 + m1)
v1 = (u1 * (m1 - m0) + 2 * m0 * u0) / (m0 + m1)

Then you may want to add some plasticity(coefficient of restitution cr).
v0 = (u0 * (m0 - cr * m1) + (cr + 1) * m1 * u1) / (m0 + m1)
v1 = (u1 * (m1 - cr * m0) + (cr + 1) * m0 * u0) / (m0 + m1)
The cool thing here is that you could use the loss of kinetic energy to describe the amount of damage.
This way it would automatically depend on the masses, velocities, restitutions of the colliding objects.
Good points all, and this in particular. Even friction at the point of contact could be hacked at the global object level by modulating torque force; so there's no need to "spawn" springs or the like.
Still, from a design decisions point of view I would include springs as declarations of classes and functions, for the sake of completeness and scalability, even if they are left unimplemented.

Regarding point 4, what klauss means is that the code is already in place to use thrusters in all 6 directions; but the ship models don't show the thrusters (even though they have been a requirement repeated ad nauseum for the past 5 years or so)... ((If you think programmers are unmanageable, try artists...))

EDIT:
One thing that needs to change about ANY physics library we may decide upon is using doubles for the distance accumulators.
I'm not sure if we'd need doubles for speed.
At first thought, I'd say no.
On second thought, yes.
This second thought is that if a station is orbiting a planet, and its speed is, say, 30 kilometers per second, and you have a battle raging around the station, all speed precisions will suffer from the high "absolute speed" (oxymoron notwithstanding) of the station's surrounding space, as a whole.
So, unless we bite the bullet and decide to implement moving frames of reference, we're prbably better off keeping velocity vectors in double precision.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: post release: What to do about nebulas

Post by klauss »

chuck_starchaser wrote:I'm not sure if we'd need doubles for speed.
At first thought, I'd say no.
On second thought, yes.
This second thought is that if a station is orbiting a planet, and its speed is, say, 30 kilometers per second, and you have a battle raging around the station, all speed precisions will suffer from the high "absolute speed" (oxymoron notwithstanding) of the station's surrounding space, as a whole.
So, unless we bite the bullet and decide to implement moving frames of reference, we're prbably better off keeping velocity vectors in double precision.
Good point, that's something I overlooked every time.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
log0

Re: post release: What to do about nebulas

Post by log0 »

but the ship models don't show the thrusters
I think there is no need to modify the meshes/textures(although it would be great).
You could simply place particle emitters at thruster positions.
All the artists would have to do is to provide thruster positions on the ship hull.

If you look into current/future spacecraft propulsion. The way to go are electric thrusters.
And this thingies are tiny. A magnetoplasmadynamic thruster is capable to deliver up to 10^5 N/m^2.
Meaning to accelerate a heavy 10^4kg space ship with 1g you would need a 1m^2 MPDT.
And 10m/s^2 is a ridiculous acceleration for a space craft imho.
Already existing 100KW Lorenz-force accelerators deliver 12.5N with an anode outer diameter of 15cm.
http://alfven.princeton.edu/papers/Encyclopedia.pdf
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: post release: What to do about nebulas

Post by safemode »

do people not think we already do full blown rigid body simulation? because we do. ODE != a collider. like bullet. or opcode. ODE would replace what we currently have as our physics subsystem, which takes information from the collider (bullet,opcode,gimpact) and modifies the vector of the units involved in the collision as well as notify the units damage functions if necessary etc etc. We use opcode, it's no less of a collider than any others, what we do with it may be different than ode but ODE is a fully generic collision system, ours is not. Ours may very well be very inefficient in some areas, but seriously, it's not even close to the bottleneck that puts performance down in the single digits (on my lowly 6600 with only 256MB texture mem and 2Ghz cpu) when we have 10,000 units in a single system all attacking eachother. Which i've recently done in the total_war mission. Our LOD system is fairly good when it comes to simulation, if i'm far away from the majority of the 10,000 ships, my framerate is 120fps and it's like nothing is going on...but the more i view the majority of the battle the worse it gets. I'm fairly sure we dont cull graphics at a short enough distance for things reduced down to 1 or two pixels (we should).

10,000 ships, each with Ai, each firing and getting hit and exploding and communicating and doing what they do in a single system is a good amount load.


If you want to focus on performance in the game, look into how we appropriate damage (esp via recharge shields), look into prefetching data for new ship creation and insertion into the game to reduce stutters, look into loading a new system so that the transition in a jump is smooth and transparent to the player. These are changes that would have noticeable effect to gameplay.


ps. I added -Bsymbolic to a local build of vs and it didn't mis-compile so i'm going to add it to cmake and automake 's linker. It is supposed to reduce overhead to function calls within the libraries we link to.
I also want to add a cmake option that prompts the user to choose their cpu arch, and then provide a series of optimal compiler arguments for each available cpu. These are options that usually aren't on by default and aren't turned on by the normal -O2,-O3 options. things like -mtune, the simd options, -mfpmath. etc.
Ed Sweetman endorses this message.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: post release: What to do about nebulas

Post by safemode »

as for any further optimizations, delving into the builtin features of gcc vectorized output (sse,mmx,3dnow etc), i dont think would be appropriate unless we've optimized the current major bottlenecks first.


I'm still interested in discussing the topic though. What is the general consensus on making nebulas a system wide attribute rather than a unit. This attribute would be something that every ship / turret, has to take into consideration when dealing with radar and damage and maybe even things like jumping and spec.

Visual representation changes (if any) can be done independently of this change.

edit: by builtin features, i'm talking about possibly modifying our transforms to use this: http://gcc.gnu.org/onlinedocs/gcc-4.4.3 ... sions.html , which with the proper compiler flags that i talked about previously, will generate optimized vector code. I would consider this a micro-optimization though, only to be considered until after much more visually noticeable ones have been squashed.
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

Re: post release: What to do about nebulas

Post by klauss »

@safemode: I really really believe it's easier to design a galactic-scale scenery (now in the real sense, only meshes placed at certain places facing in a certain direction).

Systems already have a location in the galactic map, all we have to do is place the nebulas in those areas, design shaders and techniques to properly render them, and add that as background rendering instead of the cube, and that's it. Sooo easy.

While we work on the artsy part (modelling the nebulas and coming up with shaders), we can still use the cubemaps.

I'm thinking we'll need dynamic cubemaps when that's done though... to render the nebulas into environment cubemaps... hm...

If you want foggy systems we'll still need the attributes. Feel free to add them to universe.xml - should be rather simple. Or add a ticket in trac, and lets wait and see who grabs it first ;)
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
log0

Re: post release: What to do about nebulas

Post by log0 »

do people not think we already do full blown rigid body simulation? because we do
I had no idea. My first impression(download, install, flight around for about 15-20 minutes) was there is none.
This might be due to low mass, high thrust(manual says 10-20g) and low maneuvering speed of the default vessel?
But I also have to admit that it should be rather difficult to determine the flight speed/direction in empty space. :)

PS: And yes, I didn't read the manual before playing vegastrike.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: post release: What to do about nebulas

Post by chuck_starchaser »

Agreed. I'm interested in physics for the sake of features; not because the current physics is slow or anything.
Then, the conversation went to possible third party physics, and in that context I was saying I'd work on them
first for the sake of compatibility (use of doubles for positions and velocities), and to improve their speed, if
needed, using inline assembly with SSE. Part of the reason is personal: I once developed a vector and matrix
library using the old AMD 3DNow! SIMD extension to MMX, and I enjoyed that work a lot. (The header files
were very C++-ish, using templates and all; plus units were appropriately modeled, like multiplying meters by
meters returned meters-squared and so on (no run-time overhead); but if you'd look at the .cpp files, every
function would immediately begin with asm_ { and plunge right into 3DNow! assembly.) A collision library
could benefit immensely from hand-coded inline assembly, and processing several primitives simultaneously.
The engine in general could benefit immensely from prefetching memory into cache during iterations, BTW,
which prefetch instructions have existed since the days of MMX.

But disk-prefetching (ships, systems) would be great, too.

This thread has been all over the place: We went from nebulas to effectors to unit organization to physics to
collisions, and now back to nebulas.

The first question is not whether they should be system-wide. The first question is how we define "nebula".
Real nebulas probably would have NO effects, and modeling the galaxy in 3D and generating backgrounds
from that model would be fantastic. Other than that, the term "nebula" no longer applies, IMO.
I think we were on a good course in the early posts: Perhaps we need to think of what we want to simulate
in the game in terms of real universe things (pulsars?, super-flares?, ((neutron stars?, mini-black holes?, ...))),
and once we decide what we want, we could name them appropriately and discuss implementations. Because,
again, using the term "nebula" for some effect that has nothing to do with them would be misleading, and
would add to an already heavy load of misleading terms in the sources (halo, fog, fawg, ...).

And just to derail this thread again before it has a chance to get back on topic... :)
There are hardware functions in gpu's called "fog" that presently are not being used, and I think we should.
Asteroid fields, planetary rings, the surrounding space of mining stations and maybe space factories, as well
as, if we decide to implement them, protoplanetary disks for young stars, all could be modeled using mesh
and transparency from the distance, but lerp that to hardware fog as you approach and enter the thing.
Same thing for clouds, if we ever implement atmospheric flight.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: post release: What to do about nebulas

Post by klauss »

The best term, if implemented the way I mentioned, would be "galactic scene"

(or "galactic scenery" when referring to the individual components and not the whole scene).

Right now, I'll have to think carefully the part where we'll need dynamic cubemaps. That's a tough one. We could overlook it, and just use precomputed cubemaps for the environment, but that would mean rendering them in an offline tool (say blender) carefully matched against the game's rendering.

The jury is still out on that one. In the meanwhile, I adhere to safemode's idea of adding system-wide fog and whatnot. It's easy, very very easy to do, and would add some artistic value to the game. So a ticket for that would be in order, noted for the proper milestone (ie: after the release).

I just want to bring attention to one important matter: systemwide damage may be a gameplay killer, if the player has no safe hiding place from the effects of the nebula nor a quick escape route. Either the damage is "systems" damage (ie: radar/sensor interference), or very subtle and slow so as not to hurt gameplay.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: post release: What to do about nebulas

Post by safemode »

galactic scenery is a neat idea. But, user-side generation of dds files may be problematic, as i'm not sure if we can distribute our dds compressor ourselves. Though, we could have some generator that feeds the user's opengl non-dds graphics, and ask it to compress it and then feed that back to our cubemap generator. So we have a script that creates background cubemaps, send it to opengl on the end-user's box, compress to dds, feed faces back to cubemap gen so it can create a seamless dds cubemap file. It can do this 1 time when first run or if a new campaign is requested (and you request new galaxy, which would have to be a new option as this is likely to be time consuming).

But we have to think about this, that's likely to be many times more cubemaps than we currently support in such a setup. Disk space on the end user's machine may become an issue. Though, much less of an issue than we currently have with distribution....and we can ditch all currently pre-packaged cubemaps.


Back to nebulas though, I'm trying to go the path of least resistance here because the alternative requires the above functionality and all kinds of rewrites to deal with it. And instead of damage, we can just do what nebulas currently do. Staticfy your instruments, limit radar functionality, screw with things like spec or speed or whatever else we want. it doesn't have to inflict real damage though, since that might be a game-ender for too many people. Though, we could disable shields within a nebula system. That might be interesting.
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

Re: post release: What to do about nebulas

Post by klauss »

Dynamic cubemaps have existed since a long time ago. They're usually not compressed, only lower resolution.

A 512x512 cubemap is enough for environment effects, and it only takes up 512x512x6x4 = 6MB. You only need one... so we're cool.

It can be rendered in parallel in the GPU, mostly in SLI configurations, so it's a no brainer. The problem is implementing FBOs, and that's basically what made me swear I would rather port the graphics engine to Ogre than trying to implement dynamic cubemaps in VS engine.

If galactic scenery needs dynamic cubemaps... well... I'm in trouble ;)

Besides I have to find a way to implement cubemapgen's angular filter entirely in the GPU, otherwise I'd have to download the cube into system memory for CPU processing and that's... not nice.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: post release: What to do about nebulas

Post by safemode »

You know what would be infinitely more useful to the player than any of this is a better nav map computer. The whole galactic persistance idea got me remembering just how god aweful our current nav computer setup is and how many users always say it's totally F'ing unuseable.

Is it possible to portray a 3d galaxy in the space of a monitor screen and make it functional for a user to create a flight path?

Then lets bring it to the system level, What's the purpose of this map view at all? Does it allow us to do anything or know anything we dont know from just flicking through significant units or targets in the ship's regular view? Can we give it a purpose ?

I would think that would be far more valuable than getting involved with galactic scenery, since it's a great deal of work for relatively little as far as the user's concerned. Persistence of backgrounds are nice, but subtle and in the end, eye candy. We should demote eye candy to do after the game is fun again.
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

Re: post release: What to do about nebulas

Post by klauss »

Actually, it's not just eye candy. It gives the galaxy unity, you can then see (in the nav map, say) a map of the galaxy with landmarks (spacemarks?) and everything.

Suddenly everything makes more sense.

You can see the center of the galaxy, you can see globular clusters, etc, etc...

It's true, it's less important, but it's also easier to implement - ignoring cubemap stuff of coruse. We can always render them offline for environment effects. It's a chore, but it's certainly doable.

About the nav map - amen. I've been toying with the idea of coding a navmap as an in-ship "base interface". Ie: activate the base interface at mid flight, using a hot key, and have a python script create all the necessary interface for a nav map.

The benefit over a C++ solution is maintainability. I know you all are C++ coders and frown at python, but python is by far faster for this kind of development, and since drawing is done by the C++ engine, it's in no way performance critical.

Besides, coding such a complex interface on top of the base interface framework will be sure to push the base interface framework further, making it richer, and eventually resulting in better in-base experiences.

Another option was python-scriptable cockpit interfaces - so the same thing, only without leaving the cockpit interface.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
charlieg
Elite Mercenary
Elite Mercenary
Posts: 1329
Joined: Thu Mar 27, 2003 11:51 pm
Location: Manchester, UK
Contact:

Re: post release: What to do about nebulas

Post by charlieg »

I don't recall Privateer having nebulas and consistent galactic scenery.

What it did have was a decent navigation UI.

I think you guys might be suffering a little from being developer drunk. You see what is cool for you, as developers, but not what makes a big difference to Joe the player.
Free Gamer - free software games compendium and commentary!
FreeGameDev forum - open source game development community
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: post release: What to do about nebulas

Post by safemode »

Well, we already leave the cockpit interface for the current nav comp. It completely replaces the everything with this translucent menu system.

I'd really be happy with a scaled setup. Lower class vessels or those that are basically 1 seaters, can use a text based setup that is in-cockpit and looks like it is. You scroll a list of systems that are organized in distance order from your current location. Once you select a system, you select a destination inside that system (sig units only) Once you select this the nav computer "works" and computes a flight plan, this is shown to you as a textual list of jump points, this list is calculated on shortest number of jumps. You can then "detour" a jump point to avoid a system and it will compute a workaround that uses the shortest number of jumps and avoids that system if possible. This can be done a number of times until you are satisfied and save it.

Of course you're doing this all while not getting shot at, hopefully.

Your upper echelon can have a graphical point and click method using a setup similar to what you described using the base computer.


I thought the cockpit interface was python driven... The current navcomp may not be, but the current nav comp is broken. For regular ships, i'm thinking something more akin to another radar like interface on your console that you punch in your settings with a limited keypad.....ala BSG, only without needing all the numbers for coordinates .
Ed Sweetman endorses this message.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: post release: What to do about nebulas

Post by safemode »

Why can't we do nav comp like we do communications. Have it thrown up where the coms list is usually at when we select it and use the numpad for traversing and selecting things in it. Then you dont have to take your eyes off what's going on in space. The main issue here is making the overlay scroll when we want to, as there is going to be a long lists that we dont want to display in their entirety.
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

Re: post release: What to do about nebulas

Post by klauss »

charlieg wrote:I don't recall Privateer having nebulas and consistent galactic scenery.

What it did have was a decent navigation UI.

I think you guys might be suffering a little from being developer drunk. You see what is cool for you, as developers, but not what makes a big difference to Joe the player.
That's why tickets help ;)
You throw all your idea into trac, in ticket form, and let someone a bit more... gameplay aware... assign priorities and milestones.

Then you follow that lead.

So, I'm for a new nav map, entirely coded in python. Remember the load/save game and main menu have been coded in python already, so it's neither revolutionary nor hackish... high-level scripting of user-level interface has been happening in games for a long time. The only really new thing is being able to invoke the base interface mid-flight.

The benefit I'm saying it will entail is that this new nav map will be both a lot more flexible, a lot more moddable, not require rebuilding the engine for that moddability (which windows guys, and in general non-engine-devs will greatly appreciate), and it will push support for better, richer interfaces at bases. And perhaps ships. And even cockpits.

What should the nav map be able to do and how?
  • Should it represent the 3D layout of systems in 3D, or limit itself to 2D projections?
  • Should it support any advanced search/routing? (python is soooo cool and efficient for this kind of stuff)
  • How should it represent system maps? An iconified version of radar readouts + landmarks and significants? What's its use as insystem map?
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: post release: What to do about nebulas

Post by safemode »

with navigation over a large dataset, i think less is more. I'm leaning toward the suggestion i made just prior, and forgo all graphical representation for all except the most expensive ships. i think it's much less important to know physical where something is in relation to something else than to just know how many jumps something is and so how long roughly one path is compared to another. People can digest a text list in order of distance and the rest that i suggested i think faster than they can view a graphical map and select things.

Plus, what i suggested can be done while still flying. just like communications can be. Not ditching gameplay to deal with your nav comp is very significant.


ps. we will definitely be using the python frontend to the basecomp to code up a joystick configuration menu and keylayout configuration menu ala the "select game command, then do something". I really wish we had this now, but it may be too complicated to get right quickly, so it can wait.


edit: The thing that i keep considering is that normal captains of a spaceship would have to be fairly intelligent navigators. They would be able to look at a 3d map and see it for what it is. A player is not a space ship captain. They're going to get confused looking at all the points on the map. Plus, when are they supposed to do this? it's going to take a lot of time to create a route and they've gotta avoid enemies. Nav computing has to be rapid, and it has to be done without taking your eyes off the road - so to speak. While it will look great being able to select your destination and see it displayed through a 3d representation of the galaxy, it's too inefficient and complex for a player.
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

Re: post release: What to do about nebulas

Post by klauss »

I like the differentiation of navigational equipment sophistication.

It serves the dual purpose of incremental improvements on the engine AND gameplay enhancement.

How would you envision such an interface?

I'm thinking:
  • <hotkey for nav computer>
  • Menu appears: 1. Plot course, 2. Find location. 3. System information, 4. Current plot. 5. <some optional feature>
  • Select: 2
  • Menu appears: 1. Planet, 2. Station
  • Select: 2
  • Text appears: Type station name:
  • Type: Serenity
  • Menu appears: 1. Crucible > Cephid 17 > Serenity (mining station) 2. Some other match perhaps?
  • Select: 1
  • Menu appears: 1. Plot course 2. Show info
  • Select: 1
  • Text appears: 1. Jump to Cephid 17 2. Approach Serenity (mining station)
  • Select: 1 (selects the jump point to Cephid 17)
  • Or select: 2 (bad sound, shows "Destination off-system" briefly)
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: post release: What to do about nebulas

Post by safemode »

yea all that all shown where the comms is normally, or perhaps in the spot that shows us selected weapons and the like.

In your major ships, you'd likely have to go out of cockpit, but that's normal for users of ships that have turrets and such. In those ships, you can have your full on 3d representation and what not.


We can even make "detours" an incremental upgrade to the nav computer, so can auto-course-correction if we jump out of the system through the wrong jump point. As well as information regarding the systems. (maybe this is how maps can play a role finally in the game). Buying up to date information about systems at various bases can give you data in your nav comp about threats in certain systems given your current faction or friend/foe status with the factions.

All this then basically creates an ad-hoc type of mission (or uses the same mechanism that missions do) for displaying your series of destinations. We then have two choices, we can make it auto-target the correct targets once it jumps into a system or do what missions do and make you do that, as well as decide if we want to make autopilot auto engage and if we want to auto-jump. Basically, do we want a true auto-pilot fully functional or do we want the user to have to initiate everything and only provide them a heads up of where to go....leaving the how up to them.
Ed Sweetman endorses this message.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: post release: What to do about nebulas

Post by chuck_starchaser »

I remember a few years ago this subject was discussed, and a very good idea came up; but it would require 3D cockpits.
The idea was to have screens to the left and right (and a bit down, so you can still see out of the side windows):
One screen for navigation; the other for remote trading while flying.
So, you just turn your head and use the screen.
Advantage is, this would only require one hot key for UseItem, or simply a hotkey that changes the mouse cursor from a navigational pointer to a Use cursor.
Deus Siddis
Elite
Elite
Posts: 1363
Joined: Sat Aug 04, 2007 3:42 pm

Re: post release: What to do about nebulas

Post by Deus Siddis »

For the players' sakes I would recommend sticking with one navigation interface in the game at one time. Improve it and evolve it in later versions of VS, but don't have more than one interface for the same task that the player has to deal with. For the sake of realism this is the way to go too- in 1000 years it is hard to imagine computers not being a mature and dirt cheap technology already. Every ship would come equipped with the latest and greatest in this one area, IMO.

Going back to the original topic, can't sound waves travel through nebula as they can through atmosphere? At least in the denser nebulae or in regions of space where the nebular particles are being pulled together by a large nearby gravity source.

It would be interesting if you could hear things in nebula and atmosphere, both from the environment directly (like a rushing or buffeting wind kind of sound of traveling though the stuff) and from nearby engines and weapons fire and explosions from other ships. Something to contrast with the nearly dead silence of the open vacuum environments. Asteroid fields, planetary rings and chuck's vision of debris clouds around stations could offer a similar effect.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: post release: What to do about nebulas

Post by safemode »

certain interfaces would be streamlined for efficiency and less upkeep. It's really very hard to imagine what stuff like that would look like in a thousand years.

On one hand, you can imagine what a fighter jet might evolve to.. . but you also have to consider what a fighter jet would evolve to if you had tons of factories putting them out scattered across a galaxy, no one in direct control. access to common components would be crucial and that would likely mean less than top end stuff. Combine that with needing spare parts as your stuff breaks down even out in the boonies and you have the recipe for ships made with relatively low tech for the time (outside of military vessels) but are highly redundent and dependable and serviceable anywhere.
Ed Sweetman endorses this message.
Neskiairti
Confed Special Operative
Confed Special Operative
Posts: 334
Joined: Thu Jan 11, 2007 4:10 am

Re: post release: What to do about nebulas

Post by Neskiairti »

Deus Siddis wrote: Going back to the original topic, can't sound waves travel through nebula as they can through atmosphere? At least in the denser nebulae or in regions of space where the nebular particles are being pulled together by a large nearby gravity source.

It would be interesting if you could hear things in nebula and atmosphere, both from the environment directly (like a rushing or buffeting wind kind of sound of traveling though the stuff) and from nearby engines and weapons fire and explosions from other ships. Something to contrast with the nearly dead silence of the open vacuum environments. Asteroid fields, planetary rings and chuck's vision of debris clouds around stations could offer a similar effect.
nebulas, though they look like nice little clouds in space... you could fly a ship between the individual atoms :p
for sound to pass through a medium, it needs to be close enough to carry a coherent wave and structured not to lose the sound.
space is very empty, if you bump a few atoms you will be lucky if even a tiny fraction of those atoms strike another atom on their way through the star system.
even in a dense nebula you wouldn't be able to produce much of a wave.
Post Reply