Project Aquarius B1 + A-II launch vehicles (5m+ diameter rocket thread)

[Urwumpe]

I don't know what you mean by normalizing the vectors.

Normalizing a vector is simply scaling the vector so, that it has length 1. You do this by dividing every component of the vector (x, y, z) with the magnitude or length of the vector ([math]\sqrt{x^2 + y^2 + z^2}[/math])

Normalizing a vector makes a lot of math a lot easier, since you can then use it as direction vector for many purposes.

For example, if you want to know how much of your velocity is in direction of an engine inlet, you just do a scalar product of the air velocity vector with the engine inlet direction vector. Also, if you have two such vectors, which are perpendicular, you can use them for defining a projection matrix - orbiter does that with the docking ports for example.

 

[ISProgram]

Verseau-M rocket

Okay, Verseau doesn't work as advertised. Silverbird says it can get about 9256 kg to LEO, Orbiter says about 8300 kg to orbit. That's (more or less) within the ~10% discrepancy between Orbiter and Silverbird, so while I'm disappointed, I"m satisfied.

The Verseau is basically a smaller relative of the Aquarius. The Verseau's second stage uses a single engine of the same type as the Aquarius', and the first stage is powered by a single-chamber variant of the four-chambered staged combustion engine the Aquarius employs.

These pictures don't speak true for the rocket's payload capacity. It only just got into orbit with 113.6 kg of fuel left in it. But now that the Verseau is going to end up in this addon, it gives me a lot more room to play around with potential configurations.

(outdated picture, Verseau is the dark grey rocket w/ the black interstage)

---------- Post added at 09:50 AM ---------- Previous post was at 08:08 AM ----------

Anyone know how to make a good rocket texture?
Like this, for example:

---------- Post added at 04:58 PM ---------- Previous post was at 09:50 AM ----------

Decided that while test meshes did the job good enough, the "actual" mesh would be better. So now I'm working on all that detail.

Anyone have any input as to what my texture resolution should be. OrbiterConfig says 200-something pixels, but that's seems to be kind of small...

 

[PhantomCruiser]

should be at least 512 x 512. Any smaller and detail can run together.

 

[Pipcard]

I recommend at least 1024 x 1024 if you're going to add decals.

 

[ISProgram]

So 512 x 512 is the minimum size? Then why does OrbiterConfig says otherwise...? Oh. For maximum compatibility, I'm guessing.

For maximum compatibility, avoid textures larger than 256x256 pixels, because
of limitations of some older graphics cards.

Probably not coincidentally, that is half the the size which you mentioned (really a quarter by surface measure). So another question is what the largest resolution for texture should be. I should have mentioned that I was looking for a range...

 

[Urwumpe]

So 512 x 512 is the minimum size? Then why does OrbiterConfig says otherwise...? Oh. For maximum compatibility, I'm guessing.



Probably not coincidentally, that is half the the size which you mentioned (really a quarter by surface measure). So another question is what the largest resolution for texture should be. I should have mentioned that I was looking for a range...

You should decide, what you can texture with a single texture well and what you can better do in different textures or with finer faces. Meshing is more an art than a craft.

 

[ISProgram]

Okay, the Aquarius 227 (the third to last rocket in the previous graphic) is capable of at least 120 mT to LEO, compared to 108 mT for Aquarius 124.

There's still a autopilot issue, it still oscillates, so I'm beginning to suspect that it may be an issue of actual thruster placement as opposed to being a autopilot issue.

 

[Pipcard]

If you mean the thruster exhaust placement, Velcro Rockets doesn't actually simulate the physics of that. It's all visual.

 

[ISProgram]

If you mean the thruster exhaust placement, Velcro Rockets doesn't actually simulate the physics of that. It's all visual.

No, I didn't mean the thruster exhaust. I meant logistically. It seems like the autopilot is fighting itself. Maybe it's because the actual LRBs aren't in the exact position they should be in, but this shouldn't be a problem since they're aligned with respect to their thrust direction.

Also, I've decided on all the rockets which will be in the addon. There will 9 total configurations of the Aquarius + Verseau, which feature interchangeable components (economy of scales, yay).

This thread title is no a little more inaccurate since the Aquarius B2 in it now, but oh well.

Now, what would constitute a good addon to you guys? It would be easy to just include the rockets, but I feel there should be more functionality to this one.

 

[kerlix]

Once you get everything working properly and smoothly (AP/etc.), I would say payload customization. People are going to want to throw anything they can find/make onto the top of these.

EDIT: Also, would it be possible to customize the AP? Customize the PeA, ApA, inclination? I know there's a Delta addon that does this, but I'm not sure if you're able to implement these things.


Being able to easily specify things like that would be awesome. Either through easily changeable scenario files or "in-sim" inputs would be amazing.

 

[ISProgram]

Okay, so the rocket's aft is buried into the ground. I tried editing the PADBIAS parameter, but to no avail. Any suggestions?

 

[IronRain]

Okay, so the rocket's aft is buried into the ground. I tried editing the PADBIAS parameter, but to no avail. Any suggestions?

Try a negative PADBIAS. So if you want it 2 meters higher, set it to -2.

 

[ISProgram]

Tried it, but saw no discernible difference, if I set it 22.0000(!), the stage doesn't move(!). The current PADBIAS is 1.0000...

Also, when rendering the LRBs for the first time in their final positions, I get both of them on just one side of the rocket, in the exact same position, to the point where they hide within one another (so it looks like there is just one).

This is not the case, since I can see the vessel names, so what parameter should I change, and how, in order to get 1 of the LRBs to flip to the other side? Both LRBs use the same .cfg file, but different .msh...

---------- Post added at 11:59 PM ---------- Previous post was at 07:54 AM ----------

Okay, what's the SIZE parameter for the .cfg files for, and how do I get it? I HAVE read the OrbiterConfig document, BTW.

 

[ISProgram]

Finally got the Aquarius 2257 to fly. Contrary to what the image may say, the second stage needs 7 engines to get to orbit with 120mT of payload, though there is plenty of margin left.

Considering a beta release to gain feedback, since this is going to be my first add-on. Up to your guys though.

 

[ISProgram]

Okay, working on some issues, not going to talk about them at the moment.

Something that interested me was in the Centaur G/G thread, namely how it is intended to allow for a custom PAF to be affixed to the Centaur US.

I mentioned WAYBACK that I wanted Aquarius to have the option for custom payload adapters, which in principal should be easy to implement, but in practice wasn't very easy.

The main issue stems from the fact that Orbiter treats the COG of the individual stages as the point of the .msh's origin, as intended. This means that the attachment plane for such a adapter must be treated as the positioning of a payload, which in turn, means editing the files directly.

The Centaur G/G goes over this by making the origin the attachment plane, so all you have to do is model your adapter's attachment plane to the origin, and they would automatically stick together when rendered in a simulation. The offset of the adapter's attachment plane (or a payload) would then only have to equal the adapter's own height, and the payload would attach to this.

However, if I were to do this, the stage would still rotate over the now extremely-forward origin, so it becomes rather inaccurate and strange looking. So my question is:

Is there a way to set a point for COG, and if so, how? This would override the origin point as the defaulted COG, so it could be used for the aforementioned payload attach fittings.

Also, There was a lot of work done on Aquarius' technical feasibility before starting on this addon, but one thing I never managed to determine a concrete launchpad design/layout, so I'm not sure what it's going to be like at the moment. I'm wondering if Velcro can integrate animations, so that umbilical drawback and the like can be simulated...

 

[decpau]

Dan, email response sent to your email this morning. On these issues:

Develop your PAF meshes and build them as payloads. You can define the mass as "zero" to solve your COG concerns and adjust the main booster config with increased mass to compensate. Then it becomes only a matter of stacking their load script in the .scn so they remain with the booster stage upon jettison of the actual payload they support. This also gives you the option of multiple PAFs for your launch system as defined in the .scn

As for your Launchpad I use a modified LC-34 for many of my launches. It is a separate vessel within my .scn files that has gantry movement prior to launch. You could do the same with umbilical retrieval or anything you want to model in your sim.

decpau

 

[ISProgram]

I'll check it out, but I've been sick for a few days, so it might take a little longer for a proper response. Sorry if this becomes inconvenient.

---------- Post added 01-25-15 at 01:49 AM ---------- Previous post was 01-24-15 at 07:17 PM ----------

Setting the PAF as a payload came to mind too, but I decided to do some testing, because one potential issue I don't want to happen is have someone press J twice and jettison the payload, and the PAF, in the same orbit.

'cause that makes space debris.

However, the parameter I have turned to - NO_JETT - is not working as I feel it should. It's supposed to keep a payload from jettison under any circumstance.

So I place this parameter in the .cfg of the simulated PAF, so that it will never jettison, but when it comes time to jettison the payload, I can jettison the PAF too. So I have no idea what I'm doing wrong.

Any feedback?

 

[ISProgram]

Here's an early test of texturing.

Still not too much 'cause I'm still away from the computer, and still kinda sick. Texturing is certainly not one of my strengths, no idea where I'm gonna source some of the detail for the rest of the rocket.

I would also strongly prefer to leave the rocket as as simple cylinder basis, but I want detail, so...slightly different widths for the intertank and skirt assemblies. That might be a bit noticeable here.

---------- Post added at 09:10 AM ---------- Previous post was at 09:08 AM ----------

Oh great. I forgot the interstage and aft skirt assemblies are supposed to be WHITE. Early renders of the rocket had them black, still kind of like them that way. But white is more realistic.

 

[Urwumpe]

Considering a beta release to gain feedback, since this is going to be my first add-on. Up to your guys though.

Make no public beta release, if you don't want to risk trolling, especially as beginner. Select a few people whose judgement you trust and give them your test releases always together with some precise test goals, like a small one page questionnaire : "Did this function work?", "How much DV have you have left after reaching orbit", etc.

For launch vehicles, I especially recommend you to prepare a small standard Excel spreadsheet, where the tester should gather test flight data, so you can look yourself for optimizations and compare... every tester has a different matter of taste and different styles of piloting.

Before you release to the public, always ask yourself the question: "Would I like this, if somebody else made the add-on?"

 

[PhantomCruiser]

I'd be willing to give it a go, but am covered up with domestic tasking at the moment. I've got some furniture to finish building beforwe I can dedicate any time (hours and hours) to Orbiter like I want.

I'd still take it for a spin around the block and give some feedback, but I won't be able to "test it until it's broke" kind of testing.