Orbiter Shipyard Project: Gathering ideas

[Dig Gil]

4. Universal Cockpit? with a one-for-all Flight Computer?

Wow, like Marty McFly said: "That's heavy...". I say: possible without extending the releasing date to more than 6 months?:hmm:

 

[Eccentrus]

well, I'm currently re-learning C++ because I wanted to do that, I'm learning the very basic first though, trying to implement a custom 2D panel for the tin cans and then see if I can implement it to other vessels, it might be a completely different project, but after the launch, like in the next version we can implement it, how bout that dig?

 

[Dig Gil]

You are asking to work with me? (I think I misunderstood)

 

[Eccentrus]

not yet, until I figured out how to make one though, but I think it will be nice if every add-on could have a nice flight computer therefore, when I'm done with it, I will make it portable so that Artlav can implement it in this program, it's still in the hatching moment, but who knows what it might bring to this community... But then again even without flight computers, the initial release of this shipyard will be Uber Awesome, it can just be implemented on a later date.

EDITed after a mishap :embarrassed:

 

[Talon1]

Well, it's been about 3-4 months so, Artlav, any new updates?

 

[tl8]

What do you think?

 

[Dig Gil]

Well, it's been about 3-4 months so, Artlav, any new updates?

There's the Station Shipyard to try out (I think you already knew that )

 

[Talon1]

There's the Station Shipyard to try out (I think you already knew that )

Uhh... No, I haven't even been on for 5 or so months.
Also, now it looks like OSH isn't comming out till Christmas 2009. Until then, I won't be playing Orbiter cause there isn't much to do. On top of that, I 've got a new found interest in computers (which include re-building dead computers) and now I'll be busier than ever.
Any way, my point is that I'm waiting until OSH comes out before I start playing orbiter again because right now obiter is kinda boring at the moment simply because there's nothing for me to do.

EDIT: Also, now it looks like OSH isn't comming out till Christmas 2009. Until then, I won't be making add-ons for orbiter cause there isn't much to do and I'm still a bit of an amateur with making add-ons. On top of that, I 've got a new found interest in computers (which include re-building dead computers) and now I'll be busier than ever.
Any way, my point is that I'm waiting until OSH comes out before I start making add-ons for orbiter again because right now It's kinda hard and boring for me at the moment simply because there's nothing for me to do and because I'm still a bit novice at this.

 

[Artlav]

Orbiter Shipyard is still alive, and the development is slowly thawing as the weather gets colder.

So, some status updates.

I've been cleaning out and simplifying the thing lately.
Also, the common way of manipulating objects are lined out.

For every object, a beacon for example, there are 2 ways to position it - by moving it with axes, and by typing in it's position:

For the engines, animations, etc the base and the direction are 2 separate objects. You can point the engine by moving the direction object, or typing in it's position/direction vector.

For simplicity, there are also utility options - "snap the direction to axes" for preventing tiny mouse movement skill requirements, "align RCS thrusters on opposing sides of action", "add default engine sets" to save time on manually plotting a dozen RCS's, etc.

The interface is somewhat cleaned up.
Besides the custom file select dialogs there will be default ones. Instead of variable-change-sliders there will be input boxes, etc.
Also, a lot of internal changes, but no one cares about that.

So, what about object positioning?
I can't think about any other common ways for it, besides axes and direct type-in.
Any requests?

 

[Zop]

Nice to see it its still being developed :speakcool:

What about a damage model? (overheating,breaking up?)
Adding reentry effects?

 

[Dambuster]

The RCS function looks very nice!

I'm currently trying to avoid getting round to sticking RCS's on my first spaceship

EDIT: Also, perhaps you could have a way to export the coordinates of things like beacons and your RCS thrusters into a .txt file, so that it would easy to copy & paste in locations for the 3D models of such objects, rather than having to copy such coordinates down by hand.

 

[Artlav]

Some more progress:
-Panning along the vessel for easy viewing (like in station shipyard)
-Reconstructed general parameters menu
-Semi-transparent mesh when editing nodes like engines
-Several new nice functions
-Heavy work on making it useful and usable

a way to export the coordinates of things like beacons and your RCS thrusters into a .txt file, so that it would easy to copy & paste in locations for the 3D models of such objects, rather than having to copy such coordinates down by hand.

Certainly to be added.

What about a damage model? (overheating,breaking up?)
Adding reentry effects?

Damage - unlikely.
Reentry effects - quite likely.

 

[Dig Gil]

I'm like that pictures. I think it would be better to understand what's being made if those spheres 'n' cubes that locate and handle the thrusters, beacons, etc. had different shapes and/or colour to identify each other from what they are for (ex.: light green handles for RCS thrusters, dark green handles to main thrusters and blue handles for beacons). Also, to add a more visual aspect to the Shipyard, those handles for what uses direction vectors should be conical or have arrows so to point the direction.

 

[Artlav]

Development is picking up pace.
-Airfoils and control surfaces implemented
-The SpaceCraft3.dll vessels converter is nearly complete

For the last one, you can have an example.
Below is Greg Burch's [ame="http://www.orbithangar.com/searchid.php?ID=2877"]Swift1[/ame] craft, a beautiful bird, now in a Orbiter Shipyard generated DLL form:
http://orbides.1gb.ru/orbf/swift1_osh_090926.zip (978 kb, self-generated package including all dependencies of the original add-on).
It should behave just like the original, sans SC3 limitations and attachment points. (if not, bug reports are welcome).

I'm like that pictures. I think it would be better to understand what's being made if those spheres 'n' cubes that locate and handle the thrusters, beacons, etc. had different shapes and/or colour to identify each other from what they are for (ex.: light green handles for RCS thrusters, dark green handles to main thrusters and blue handles for beacons).

Currently, the colors define different elements of the same class in the view, and shapes define elements of different views.

For example:
-a sphere with a cube (to be cone, i hope) is an engine
-red sphere with a cube is a main engine
-green sphere with a cube is a hover engine
-a cross is a beacon, with it's own light color.
-A smaller isolated sphere is an airfoil force point,
--orange ones are ailerons
--blue - elevators
-etc

There should be no more that one or two views active at once (no one will enforce the limit though), so it should suffice, no?

Also, to add a more visual aspect to the Shipyard, those handles for what uses direction vectors should be conical or have arrows so to point the direction.

Yes, they should. And they will.

 

[Dig Gil]

Is the readme.txt automatically generated? It made me LOL.
It's great the file/folder simplification the Shipyard does when converting a vessel.

Results of First try (in Orbiter installation with Vinka's DLLs yet): CTD

Orbiter.log analysis result:

>>> ERROR: Missing texture: HUDTEX.dds
>>> [C:\Source\Orbiter\Texture.cpp / 781]

I've renamed a copy of a randomly chosen texture of burchismo's folder to "HUDTEX" and still the same problem and log file.

 

[n72.75]

Does this project allow dynamic touchdown points, because swift doesn't have them. or do you plan to add that feature?

 

[Artlav]

Is the readme.txt automatically generated?

Yes, it's automatically generated. That's the whole point, no?

Results of First try (in Orbiter installation with Vinka's DLLs yet): CTD

Orbiter.log analysis result:

>>> ERROR: Missing texture: HUDTEX.dds
>>> [C:\Source\Orbiter\Texture.cpp / 781]

I've renamed a copy of a randomly chosen texture of burchismo's folder to "HUDTEX" and still the same problem and log file.

Something else is wrong - the textures are pulled out by the mesh files, if it's not in the zip, it was not there in the first place. I get the same error in the log, yet it all works.

Try to run it on a clean install?
Do you use Vista/Win7?

Does this project allow dynamic touchdown points, because swift doesn't have them. or do you plan to add that feature?

They are not to be found in SC3 vessels (as good as i know).
But yes, they are supported - you can define several sets of touchdown points and set an animation to trigger touchdown points switch.

---------- Post added at 03:25 PM ---------- Previous post was at 03:23 PM ----------

A question into the void:
I wonder, if i release a public alpha/beta (this evening), will there be any meaningful feedback?
Or, is it better to have a closed beta testing on a project of this scale?

 

[n72.75]

A question into the void:
I wonder, if i release a public alpha/beta (this evening), will there be any meaningful feedback?
Or, is it better to have a closed beta testing on a project of this scale?

Closed beta is always better, that way you filter out the lazy ones.

 

[Dig Gil]

I'm pleased to support: give log files, give information (unless it seems abusive to me ), try both on messy and clean installs, try with different compatibility modes or Windows versions, organize and detail info and I have a joystick :hotcool:. *siffle* Then Tex puts me a Beta Tester gray bar.

 

[Dambuster]

If you want testers, I'll gladly be one!