General Question Spacecraft3.dll in Orbiter 2010

[Arthur Dent]

So, anyone of the SC3 fans up to writing a specification for a replacement framework? And no, "the same as SC3" doesn't cut it, because that would mean all the bugs, all the short-comings... and all the incompatibility, too.

Now that is a great idea. With all the new features available in orbiter maybe it's time for a new take on SC3. Maybe SC2013 should be in the planning?

That would be great. I'm all up and psyched for this. That is exactly what we need. Anybody who is developing a framework after "SC3-fans" specification will be, like Vinka, forever remembered as a hero to the community.

 

[Face]

So if there is enough interest in it, let's kick it off. I can create a project on Bitbucket with an open Wiki for people to put in ideas/specification bits and an empty add-on structure. If nobody has a better idea, that is.

 

[Arthur Dent]

Go ahead then - I'm eager to help with writing specifications and of with course testing.

Although I'm out of country until next Sunday and won't be using the internet, I'm more than willing to help you with this in the following weeks/months.

 

[Izack]

I think that's a fine idea, Face.

 

[orb]

Well, if you didn't know, it's been already there for 29 minutes : https://bitbucket.org/face/genericvessel/

 

[Arthur Dent]

Great!

I'm already writing a lot of specifications in a text file. When Face is ready with setting up the project, I will publish them

 

[Izack]

Well, if you didn't know, it's been already there for 29 minutes : https://bitbucket.org/face/genericvessel/

Well, I still think it's a fine idea.

So, to get it straight, the goal is to provide an alternative ground-up interpreter for SC3 initialisation files, which correctly parses files in the existing structure, while fixing bugs/limitations of SC3 and providing additional functionality, or to provide a new, but similar environment for non-programmer developers to create spacecraft?

In other words, is this a spiritual Spacecraft 4 or an entirely new system with a similar purpose?

 

[orb]

When Face is ready with setting up the project, I will publish them

I think you can edit the wiki on the linked in my earlier post project already (at least the "Edit" and "Create" buttons on main wiki page work for me). You only need a Bitbucket account.

 

[Arthur Dent]

I guess it has to be a new system with similar purpose (but it can have a similar syntax). It needs elements of the multistage.dll and of course, UMMU support.

I wouldn't even mind if it was basically a compiler/converter that compiles the script files into dlls not unlike Artlav's SC3 to dll converter.

---------- Post added at 15:22 ---------- Previous post was at 15:13 ----------

Thanks for the information. I've never used bitbucket before.

I've put the list of specifications in there, but maybe we should discuss them in the forum.

 

[Face]

Well, if you didn't know, it's been already there for 29 minutes : https://bitbucket.org/face/genericvessel/

Yikes! I have a stalker! :lol:

I'm already writing a lot of specifications in a text file. When Face is ready with setting up the project, I will publish them

The Wiki is up and running. Go ahead and add pages with your specifications as you see fit. You need a user account there, but it is free, anyway.
If you don't want to do that, I guess a posting here is sufficient also.

So, to get it straight, the goal is to provide an alternative ground-up interpreter for SC3 initialisation files, which correctly parses files in the existing structure, while fixing bugs/limitations of SC3 and providing additional functionality, or to provide a new, but similar environment for non-programmer developers to create spacecraft?

In other words, is this a spiritual Spacecraft 4 or an entirely new system with a similar purpose?

I think it should be both. A standard SC3 INI set should work without changes IMHO. And of course nothing stops it from adding more features or even different description formats.

---------- Post added at 15:53 ---------- Previous post was at 15:22 ----------

I've made a few commits to the project's repository with vinka's packages extracted to a standard Orbiter directory (without the Orbiter files, of course). I think it is safe to upload them to the public repository, as he explicitly states in SC3 documentation:

All add-ons based on spacecraft3.dll may be distributed freely with this base package include.

For developers
The source code can be obtained upon request.

Such a setup will make it much easier for folks to test their work against various versions of the generic frameworks (SC1,2,3 and whatever the new is called then).

Of course I've taken care to keep the credits where they are due in the commits, so it is clear where the files are coming from in the history, even if we use them later on in the project as e.g. test scenarios.

If there are no objections, I'm going to push them to the repository and link the documentation PDFs for reference.

 

[orb]

A standard SC3 INI set should work without changes IMHO. And of course nothing stops it from adding more features or even different description formats.

If you ask me, I like how it's done in the ScriptPB vessel, i.e. the class configuration file could point to itself to read the vessel description.

New GenericVessel vessels could use their class configuration files for the vessel definition, or point to an external file (I'd prefer those vessels use separate vessel classes but using the same Module, which IMO is better than one class for different kinds of vessels).

Of course for backwards compatibility and for people still using legacy method of creating Spacecraft/Multistage vessels, e.g. the new Spacecraft3.cfg should be pointing to something like "Spacecraft/${VesselName}.ini" or "Spacecraft/%VesselName%.ini", etc. for "VesselDesciptionFile" parameter (or something like that), and similarly for the new Multistage2.cfg.

 

[Face]

If you ask me, I like how it's done in the ScriptPB vessel, i.e. the class configuration file could point to itself to read the vessel description.

New GenericVessel vessels could use their class configuration files for the vessel definition, or point to an external file (I'd prefer those vessels use separate vessel classes but using the same Module, which IMO is better than one class for different kinds of vessels).

The ScriptPB solution is indeed elegant. I also agree on the reference-per-class vs. reference-per-name approach, as the later - used by SC3 - is making scenarios with multiple instances of the same class cumbersome.

Of course for backwards compatibility and for people still using legacy method of creating Spacecraft/Multistage vessels, e.g. the new Spacecraft3.cfg should be pointing to something like "Spacecraft/${VesselName}.ini" or "Spacecraft/%VesselName%.ini", etc. for "VesselDesciptionFile" parameter (or something like that), and similarly for the new Multistage2.cfg.

Hm. Why such a parameter at all? In the legacy cases it would be the class "Spacecraft3" that triggers the old INI file path, in the new cases it uses its own configuration file like with the ScriptPB approach. Does it make sense to have different class names for the same description?

That said, maybe a simple include mechanism in the config file makes sense, so you can build a new class from shared definition blocks.

 

[PhantomCruiser]

Is there a way to implement a basic, generic VC? Something, that if not otherwise defined would have a bare-bones cockpit (say one maybe two MFDs, hud, switches for gear, rcs/translation, hatch open/close, etc).

 

[Face]

Is there a way to implement a basic, generic VC? Something, that if not otherwise defined would have a bare-bones cockpit (say one maybe two MFDs, hud, switches for gear, rcs/translation, hatch open/close, etc).

Certainly. But what should it look like? A cube-like box with window holes and spherically arranged elements? Scaled by the vessels size? By the mesh size? No box at all, just transparent with the elements in the air?

 

[Izack]

Is there a way to implement a basic, generic VC? Something, that if not otherwise defined would have a bare-bones cockpit (say one maybe two MFDs, hud, switches for gear, rcs/translation, hatch open/close, etc).

Hey, there's an idea. IIRC Moach had been working on something like this some time ago - it may be possible to consult him on it.

On the topic of thrusters, the ability to define additional or nonstandard thrusters would be a great step forward, I think.

 

[Ripley]

I think this thread is a real milestone!!
Thanks all!!

 

[PhantomCruiser]

I'll try to spend some time tonight with paint.net (or something) to see if I can come up with something that might be suitable for a generic cockpit panel. If I can please, say 75% of the crowd, I'll put together a mesh or something that will match.

Then again, we may have a conflict of person X wanting a two seater and person Y wanting to fly solo. But then, this would endeavour to be a generic layout.

Maybe it could be configurable?

 

[Face]

I'll try to spend some time tonight with paint.net (or something) to see if I can come up with something that might be suitable for a generic cockpit panel. If I can please, say 75% of the crowd, I'll put together a mesh or something that will match.

Then again, we may have a conflict of person X wanting a two seater and person Y wanting to fly solo. But then, this would endeavour to be a generic layout.

Maybe it could be configurable?

Wait a minute... do you mean a generic 2D panel, or a 3D virtual cockpit?

 

[Donamy]

I'll donate my Jason Project to be the test vehicle if no one objects. It has quite a few animations, including robotics. It also has a VC with 2 mfd's and HUD.

 

[PhantomCruiser]

Wait a minute... do you mean a generic 2D panel, or a 3D virtual cockpit?

Both maybe?