Looking ahead

[Kaks]

...bad... software patents...

Meh, just as bad as H264, if slightly better in places!
And isn't Theora FOSS & supported in all linux distros because of that?
I don't quite know the support status of WebM, but I suppose that's the only other alternative...

Fruity Oaty Bar

Wait, did Whedon release it with a FOSS compatible licence?

[JensAyton]

Fruity Oaty Bar

Wait, did Whedon release it with a FOSS compatible licence?

Nah, but I can put it on billboards for my own personal use. Not legal in the UK, though.

[Zireael]

Moderator: the stricken section was cross-posted from here. Please do not post the same comment in multiple threads; post links instead.

Back to the topic of player ship lasers, I think the solution for the future could be: max 2 lasers to each given view, and they'd cross in the crosshairs.

And set them so you can fire them continuously for, let's say, 5 seconds and no more, thus eliminating the hard-to-explain overheating in space. Well, if we have non-Newtonian physics, why have this overheating...? Let's say it's the way the lasers are built in Ooniverse that they can't fire longer.

-----------------------
And on the other hand, I've had another idea. Shield strength displayed either as units (say, 200/256) or as a percentage (say, 70%) in addition to the display we all know and love.

[DaddyHoggy]

If possible in a future version of Oolite I'd like more control of the exhaust plumes during game time: width/height/length (the option to keep it relative to speed or to control it by script) and colour as well as have position controllable via scripting during the game too (but really, I still only want transparent textures...)

[Killer Wolf]

i asked for that and got no comment back. it seems stupid to have a variable in a game that is part of an attribute definition that then isn't used. either the code should go in or the attribute should come out. different length exhausts would be good for a large ship i had planned, i wanted big thrusters at the back and smaller manouevering engines - if they all have the same length exhaust though, it'll look stupid and impact on the design of the ship.

[zsozso]

A couple of small additions I'd suggest that would suport OXP/Z's:

* expose information (e.g. via callback) about currently selected missile/pylon -- which one is active, what type it is, is it armed?
* allow javascript to alter parts of the HUD on the fly, e.g. display status info of some OXP equipment, this may require a hook in the
HUD plist to define the location and/or shape of the part to be updated, then a javascript function call could alter the content or color

[Lone_Wolf]

Are there plans to incorporate functionality now offered by 'ambiance' oxps in Oolite 2.0 ?

some of the oxps that seem suitable :
BGS, Famous Planets, Lave, Snoopers , Tionisla Orbital Graveyard ?

[Simon B]

Woot.

Lessee - I read through all these posts and took notes. Now it's my turn...

1. Multiple Lasers for player ships - I've been exploring this but keep getting distracted
2. Player POV rotates according to the ship axis of rotation ... at the mo the view rotates centered on the screen.
3. Position the crosshairs to where the laser ends up. I can kinda manage this in a hud at the mo.

4. Witchdrive
... a max limit should exist - the fuel pod and others mitigate this nicely where longer range is needed.
... I think that some ships should have a shorter range
... I think some drive should be "faster" meaning reduced elapsed time for the jump (or slower)
... witchdrive should be an equipment item.
... when a target ship prepares to jump out - message shows: "target spinning up witchdrive"

5. Jump Drive
... this was originally a time-saving thing in Elite but the smooth fast-forward effect is cooler - how about just using it as a fast-forward... the whole game speeds up, including the clock. No need for condition detection.

6. Galactic Jump
... not sure - I have played with the idea of making galactic jumps depending on jump gates instead of happening anywhere. Also allows some gates to go galaxies other than the normal next in sequence. At least as an oxz possibility. The gates go to a specific system in the target galaxy.

... notice how a galactic jump from anywhere always places you at a particular system in the target? This should have an economic impact on that system. One of the prototypes I have is a galactic hub station for those galactic receiving stations.

7. Huds
Customizable message location in huds
Ability to place an inset showing target ship close up ... perhaps as wireframe either rotating as the shipyard display or as oriented to the player ship.

8. Systems
Political situation affects prices - eg if there is a
response to close approaches (local enforcement ships rise up to meet or something)

9. Cargo
differentiating "medical supplies" from narcotics.
a special cargo for special missions ... named by oxz.

The way the cargos are handles could be more elegant ... eg the name of the cargo need only be a label, with the commodity price determined by what type of cargo that item is.... "leexi wines" on the manifest are "wines" internally, the cargo screen lists the hold stock and prices offered, and the available cargos with prices asked... and maybe a few out-of-stock but they are wanted so an offer is made.

10. Personal:
Self-shadows ... this may be bad for some of the complex ships though. (I could fudge this in an illumination map by painting deep holes dark etc.)
Transparancy ... even if it is just a "material = transparent;" sort of thing with a fixed amount of transparency.

I'll rate self-shadows above transparency.


I suspect a feature will be more likely to make it into 2.0 if code is submitted.
I suspect there would be a "traditionalShips.oxz" for purists.

Aside: perhaps colling stuff is why there is a drive plume at 0 acceleration?
... cooling is a big deal in space, here's the cliff-notes version:
http://quest.nasa.gov/space/teachers/su ... 3keep.html
presumably the ooniverse has improved methods.

[JensAyton]

Self-shadows ... this may be bad for some of the complex ships though. (I could fudge this in an illumination map by painting deep holes dark etc.)

The image-based lighting model I’m aiming for is basically incompatible with self-shadowing, or hard shadows from other objects. It might be possible to fudge it in custom shaders using horizon maps.

Given that we’re predominantly looking at mostly-convex objects sitting in isolation, I think supporting arbitrary amounts of secondary lighting – reflected from planets, other ships, weapon effects etc. – is a better goal than shadows. (Soft shadowing from planets and stations will be emergent.)

[Commander McLane]

... notice how a galactic jump from anywhere always places you at a particular system in the target?

No, it doesn't, at least not usually. Where you end up in a new galaxy, depends entirely on galacticHyperspaceBehaviour. Its default is BEHAVIOUR_STANDARD, which puts you in the connected system that is closest to your origin system in the previous galaxy.

There are two alternatives: BEHAVIOUR_ALL_SYSTEMS_REACHABLE puts you in the closest system to your origin system, even if it is disconnected from the rest of the galaxy. BEHAVIOUR_FIXED_COORDINATES does what you describe, putting you always in the same system. Which system that is, can be chosen with galacticHyperspaceFixedCoords.

Maybe you have an OXP installed which has changed the default behaviour to BEHAVIOUR_FIXED_COORDINATES? This could have been done in a script, or in planetinfo.plist, where the analogous commands exist.

[Switeck]

8. Systems
Political situation affects prices - eg if there is a
response to close approaches (local enforcement ships rise up to meet or something)

Going further, a TL15 Rich Industrial Corporate State system should have different prices than a TL9 Rich Industrial Multigovernment system. TL shouldn't have a large effect on prices...but have at least a little if the TL differs by more than 1-4 points.

[Simon B]

Could we at least trial a shift to Objective-C++ instead of plain Objective-C (i.e., try building with the C++-enabled version of the ObjC toolchain, probably with gcc 4.6 now it's out). This would be positive, because then it would be clearer to everyone what the process would be to at least accept C++ code contributions and additional libraries.

Reason I'm suggesting this is that there are lots of good libs - like for physics engines - but they are written for C++. There are a lot of C++ programmers too ... the biggest impediment for me doing any coding is having to learn Objective C. I've also been pointing programmers i know at this and it's the main comment that is coming through.

[Simon B]

While I'm thinking about the coding side...

Is the Newton lib being considered?

The big thing with Newton is that it's hugely capable in collisions, and you don't have to go to full Newtonian physics for gameplay. Again, a typical point of connection between the graphics and physics subsystems is that you apply LOD levels to the model geometry right? All the classic models in Elite had convex hulls of necessity and for most engines a low-LOD model typically supplies that, so need the pipeline for bringing models in to involve generating the low-LOD versions which you can use both for distance render and for collision (although for low ship counts the full-LOD models would be fine, it matters when you have what the Freespace 2 folks call "Battle of Endor" missions as their game tends to and oolite2 will presumably still be keeping things relatively lo-fi in that respect). Y'know, oxzs notwithstanding.

Any others in consideration?

[another_commander]

Could we at least trial a shift to Objective-C++ instead of plain Objective-C (i.e., try building with the C++-enabled version of the ObjC toolchain, probably with gcc 4.6 now it's out). This would be positive, because then it would be clearer to everyone what the process would be to at least accept C++ code contributions and additional libraries.

Reason I'm suggesting this is that there are lots of good libs - like for physics engines - but they are written for C++. There are a lot of C++ programmers too ... the biggest impediment for me doing any coding is having to learn Objective C. I've also been pointing programmers i know at this and it's the main comment that is coming through.

Simon, you can tell the programmers you know that if they can program in C/C++, learning the basics of Objective-C is a matter of three to four days. In very few weeks' time they will be fully capable of generating at minimum sufficiently good quality code. Tell them that this comes from someone who is not a programmer by profession and has only had his first encounter with Objective-C when he found Oolite - up to that point I did not even know that a programming language with that name existed.

Additionally, writing C++ code and linking it with Oolite is already possible. The Spidermonkey JS engine we use is full C++ and some time ago, dajt was making alternative texture planets using libnoise, which is also written in C++. It was doable back then and is doable now. But changing the language in which the Oolite core is written, when the established codebase exceeds half a million lines of code, now that would prbably not be very well received by the team. The shift to gcc 4.6 at some point in the future could be a possibility, though. But that is just my opinion, others may have somewhat different points of view.

[JensAyton]

I haven’t got to the point of evaluating physics libraries. There will probably be support for low-LOD models and/or separate collision meshes.

I’d like to be able to switch to gcc 4.6 (or clang) for improved Objective-C features, and Objective-C++ would be a nice bonus feature, but that has to be weighed against the burden of installing extra tools.

Even if we adopted Objective-C++, the game would still predominantly be using ObjC classes, so you’d still need to learn the language. Also, Objective-C++ takes several times longer to compile. The most practical way to use it is generally to write only those classes that interface with C++ libraries in ObjC++.