# ProjectGenericVessel 140205, the SC3 open-source replacement

#### Piper

Tutorial Publisher
Donator
A little request if I could make one; Right now with SC3 a jettisonable payload is always generated and launched in the same direction, only the velocity is adjustable. Could you be able to define the orientation of the payload spacecraft is generated in and a seperate orientation for how it is launched? Kinda like how attachments are already done?

#### Donamy

Donator
Beta Tester
Right now with SC3 a jettisonable payload is always generated and launched in the same direction, only the velocity is adjustable. Could you be able to define the orientation of the payload spacecraft is generated in and a seperate orientation for how it is launched? Kinda like how attachments are already done?

This is not correct. You define the position of the payload in the OFF=x,y,z option and the direction in the speed=x,y,z option.

Code:
[PAYLOAD_0]
MESHNAME=dragonnosecone
NAME=dragonnosecone
OFF=(0.0,0,2.8)
MASS=2
MODULE=Spacecraft\Spacecraft3
SPEED=(0,3,3)
ROT_SPEED=(3,0,0)
MESHNAME=dragonfairing1
NAME=dragonfairing1
OFF=(0,0,0)
MASS=2
MODULE=Spacecraft\Spacecraft3
SPEED=(2.5,0,0)
ROT_SPEED=(0,0,0)
MESHNAME=dragonfairing2
NAME=dragonfairing2
OFF=(0,0,0)
MASS=2
MODULE=Spacecraft\Spacecraft3
SPEED=(-2.5,0,0)
ROT_SPEED=(0,0,0)

#### Piper

Tutorial Publisher
Donator
This is not correct. You define the position of the payload in the OFF=x,y,z option and the direction in the speed=x,y,z option.

Code:
[PAYLOAD_0]
MESHNAME=dragonnosecone
NAME=dragonnosecone
OFF=(0.0,0,2.8)
MASS=2
MODULE=Spacecraft\Spacecraft3
SPEED=(0,3,3)
ROT_SPEED=(3,0,0)
MESHNAME=dragonfairing1
NAME=dragonfairing1
OFF=(0,0,0)
MASS=2
MODULE=Spacecraft\Spacecraft3
SPEED=(2.5,0,0)
ROT_SPEED=(0,0,0)
MESHNAME=dragonfairing2
NAME=dragonfairing2
OFF=(0,0,0)
MASS=2
MODULE=Spacecraft\Spacecraft3
SPEED=(-2.5,0,0)
ROT_SPEED=(0,0,0)

You're right, I forgot you could do that. But being able to change the orientation as launch as well would be nice.

#### Donamy

Donator
Beta Tester
How do you mean ?

#### 4throck

##### Enthusiast !
You can play with the displayed payload mesh before jetisson (MESHNAME=dragonfairing2), that is different from the actual model mesh only visible after jetission.
Those two are separate.

SC3 is more powerful than most people realise, and really well thought. That's why it hasn't been replaced in a satisfactory way yet.

#### perseus

Now, I Even Spacecraft3 prefer to GenericVessel but when this mature, he will make all necessary

With intenciónde improve, the current version, and give thanks for this initiative,

Not much worry about versions and desarros. The user's smart to find the version of genericvessel need, if there are different versions, and to taste the colors.

Propose suggestions.

-even the view virtual copick is different when genericvessel and Spacecraft3 and used,

-Also in-line mode the RCS exaut malfunctioned. Iexaut RCS

-I hope soon to be incorporated, Ummu and UCGO.

- Set HOVER in any user-defined axis,

#### Gendo

##### New member
Yes, if it's possible to add it in, I would also like to be able to define the hover thrust direction. Set it up so that if the direction is not specifically defined in the ini, then it goes with the default.

#### Lisias

##### Space Traveller Wanna-be
I never heard of anyone sticking to that rule... :shifty:

Well, now you heard of two!

I had *TERRIBLE* experiences on trying to reimplement "undocumented features" on a new codebase, it commonly leads to a new codebase being worst to maintain than the old.

(and I'm talking both professionally and hobbystically)

So, my initial approach is to stick with the documented features and evaluating the need for retro-bug-compatibility in a per case basis.

Bug exploiting is and will be always be a headache for the people that will maintain the thing. If you see a programmer exploiting bugs in his code, be advised that the codebase will die with the environment it uses to run.

---------- Post added at 06:43 PM ---------- Previous post was at 06:34 PM ----------

Since my code is quite likely different from SC3, i can't just make the same error and get the same bug behaviour pattern, so i had to code it directly, as a feature.

Which is a large set of tiny, undocumented micro-features.
So, the problems appear to never quite end, even though i keep fixing them.
That's the sort of thing that happen when you try to turn a bug into a feature.

If it's still time to give an opinion, I would just stop all movements before saving, and so everything would be stopped at reloading.

It's how vessel's attitude are saved anyway - after reloading, the control surfaces obeys the current Sidestick settings (as thrust), not the one at the time of the saving.

And since the code will be open sourced, nothing stops someone to fork the main codetree into one that implements the specific bug that a vessel needs - what appears to me a saner way to deal with the problem instead of replicating every "undocumented feature" in the new codetree while trying hard (and commonly failing) to avoid creating new ones.

#### Face

Beta Tester
And since the code will be open sourced, nothing stops someone to fork the main codetree into one that implements the specific bug that a vessel needs - what appears to me a saner way to deal with the problem instead of replicating every "undocumented feature" in the new codetree while trying hard (and commonly failing) to avoid creating new ones.

Or the origin project simply implemented that, anyway... This here is already a fork. Check the dates, this discussion is over a year old.

#### Lisias

##### Space Traveller Wanna-be
Or the origin project simply implemented that, anyway... This here is already a fork. Check the dates, this discussion is over a year old.

Whoops...

#### Michael_Chr

##### New member
GV animation issue

Hi Face and Artlav.
Have come across a strange behavior in both your GV implementations (have tested both -and they exhibit same behavior in this context). I'm working on a lauch tower with a number of animations.
It seems as if GV is not able to do animations of a mesh group if the group is above a certain group number.
I have reimplented the old SC3 module just to verify if i had made a mistake in my coding of the ini file. I could get the animations to work as expected when using Vinkas SC3.
Now...In order for you to verify this I need to send you the mesh - textures and ini files along with a proper explanation.

If possible could you PM me a way to send you the files in question? its about 20-25 Mbytes

The GV versions I have used are:
Artlav: ver 140205

Best regards

Michael

#### Face

Beta Tester
If possible could you PM me a way to send you the files in question? its about 20-25 Mbytes

I can't speak for Artlav, of course, but my mailbox should allow receiving that attachment size.

However, please be aware that I stopped development temporary due to this.

---------- Post added at 14:51 ---------- Previous post was at 14:40 ----------

Also, the last version I have released was in March, not February: http://www.orbiter-forum.com/showthread.php?p=498755&postcount=147 (link there is not working ATM, mind you).

#### Michael_Chr

##### New member
Copy all...
So I guess GV is "on hold" at the moment.
So...for the moment I will have to revert to SC3 for the development of the ini.file.
Maybe GV will come back online later.

#### Face

Beta Tester
Copy all...
So I guess GV is "on hold" at the moment.
So...for the moment I will have to revert to SC3 for the development of the ini.file.
Maybe GV will come back online later.

Yep, on hold. The password restriction is because I closed the repos. In the event of having to change the license, I don't want to have more confusion than there already is with multiple archives flying around. I also have to review under which terms I can keep on distributing it myself.

If everything goes down the drain, I can still send out PMs with links to temporary downloads, but I doubt that it will be that serious.

#### Artlav

##### Aperiodic traveller
Beta Tester
Meanwhile, i can look at the problem while waiting for someone to give me a TL;DR on the license thread.

I'm theartlav at gmail, if you want to e-mail the mesh and ini files along with an explanation of the problem (how to reproduce, what is expected, what you see happening).

#### Michael_Chr

##### New member
...the mesh and ini files along with an explanation of the problem (how to reproduce, what is expected, what you see happening).

Will do that. Thx. Artlav

Mail sent to email adress as listed above

Last edited:

#### Artlav

##### Aperiodic traveller
Beta Tester
Mail sent to email adress as listed above
Got it.
Unfortunately, with genericvessel-140205 (this thread one) i can't reproduce the problem.
Have you tried it on a clean Orbiter install?

Also, the e-mail appears truncated - P.S. ends mid-word.

#### Michael_Chr

##### New member
Got it.
Unfortunately, with genericvessel-140205 (this thread one) i can't reproduce the problem.
Have you tried it on a clean Orbiter install?

Also, the e-mail appears truncated - P.S. ends mid-word.

Understood unsuccesfull replication of the problem. I havnt done the test on a clean install which is a mistake on my part. I will offcourse go about and set this up, test it and report back.

I'm sorry for the truncation in the email - that is another mistake on my part. What I meant to say after the truncation was that I also with this vessel (the Launch tower) and associated mesh observed a difference in how the touch down is interpreted between SC3 and GV. But lets put that one aside for a while. As GV works right now works the latter issue is not a problem. I will describe it in details later in a mail to you (on a clean instal :lol:.

---------- Post added at 09:36 PM ---------- Previous post was at 07:12 PM ----------

Artlav...
Starting with a clean environment is always a good advice which I''m glad I followed because all of a sudden I couldn't reproduce the "anomaly" either.
The telltale sign (embarrassingly enough) was that overwriting the original ini file I was working with with the one I sent to you changed everything.
The obvious conclusion is that there was an error in the original ini file which I removed by clearing that file of several lines of what was thought to be remmed out statements prior to sending it to you. So the mistake rests solely with the individual operating the keyboard writing these lines.:facepalm:

I will investigate into it tomorrow to see where I goofed up... But for now I will retire to the couch with a Mojito and watch a movie - hopefully licking my wounds in that process... :leaving:

Thanx for coop
Michael