OHM Negi-1 satellite launch vehicle v0.1

OrbitHangar

Addon Comments
Joined
Apr 9, 2008
Messages
3,832
Reaction score
18
Points
0

Author: pipcard

The Negi-1 (ネギ-1) was a rocket developed by the Hatsunia AeroSpace Development
Agency. Named after the vegetable also known as the “green onion” or “welsh onion”,
among other names, the launch vehicle consisted of four stages with solid propellant.
On August 31, 1967, it launched from the Negishima Space Center* in southern
Hatsunia to put the first Hatsunese satellite into Low Earth Orbit.
(*since Negishima doesn’t exist yet, the included launch scenario takes place in Cape Canaveral instead)

HATSUNE (High Altitude Test Satellite Using Numerous Experiments) (はつね) was an
experimental technology demonstration satellite. Meaning “first sound” (初音), the
satellite weighed 42.0 kg and was 1,580 mm long. It consisted of the fourth stage of the
Negi-1 and various scientific instruments.
 
Installation:
· Make sure you have installed Vinka’s Multistage2 and Spacecraft3, from to your
Orbiter directory. These plug-ins are available at http://users.swing.be/vinka/, and
are required for the add-on to function properly.
· Then install Vinka’s Spacecraft3.dll and Stage.dll patches (place those patches in
the “modules” folder of your Orbiter directory).
· Unzip this .zip file to your Orbiter directory.
· Two scenarios (HATSUNE in orbit and Negi-1 launch) are included in
HASDA/Negi-1.

Disclaimer:
Hatsunia is my fictional federal republic based on Japan and the synthesizer
software/fictional singer, Hatsune Miku. The Hatsunese space program is inspired by
Japanese space agencies. The Negi-1 is based off the Lambda-4S rocket, and the design
of the HATSUNE is based off the Ōsumi, Sputnik, and Explorer-1 satellites.

Thanks to Martin Schweiger, for creating Orbiter,
and Vinka, for creating Spacecraft3 and Multistage2

If you came here to complain about how this wasn't .dll-based, then feel free to make a .dll version. Not everyone has programming skills, and your help would be greatly appreciated.







DOWNLOAD
 
If you rated this 1 or 2 DGs, please give a reason.

I didnt rate, but thank you for finally giving something of an explanation as to what Hatsune is. I think a lot of people were just confused by not knowing what the heck it is in your previous stuff.
 
I didnt rate, but thank you for finally giving something of an explanation as to what Hatsune is. I think a lot of people were just confused by not knowing what the heck it is in your previous stuff.
My "target audience" for my "previous stuff" was any Vocaloid fans that happened to be on the forum. Sorry for not explaining it before.
 
It's about Miku!!
but get 3 Deltagliders for your excellent work!
 
I haven't downloaded it yet, the pics look good.

N.
 
I didn't rated it but :

for creating Spacecraft3 and Multistage2

Please, try other options... :hail:

Have you tried Artlav's SC3->DLL converter, to begin with ? :hmm:

Then I suggest the use of normal maps. :2cents:

I like the idea of a "test rocket", there are not a lot of light launchers over there. :thumbup:
 
Last edited:
I didn't rated it but :



Please, try other options... :hail:

Have you tried Artlav's SC3->DLL converter, to begin with ? :hmm:
Spacecraft3, Multistage2, and Velcro are my only options. I do not know how to code a .dll launcher.

The SC3 -> DLL converter is only needed if HATSUNE wasn't a one-off satellite. And I heard some bad things about the converter a year ago. About how it makes "messed-up code", or something like that.
 
I do not know how to code a .dll launcher.

Such a "simple" launcher is one of the best opportunities to learn. IMHO. :2cents:
 
Such a "simple" launcher is one of the best opportunities to learn. IMHO. :2cents:
I think you're underestimating the complexity of a .dll launcher.

Then I suggest the use of normal maps.
I tried normal maps before. They didn't work for me. (The lighting was all weird)
Besides, this rocket and spacecraft don't need normal maps.
 
Last edited:
I mean, basically we have :

- 1 core stage
- 2 boosters
- 1 upper stage
- 1 payload

IMHO, the best way to go is to define to define those elements as separate vessels (5 vessels then). Each vessel has it's one code. That code will be 90% common to the 5, so copy-paste will make the most of it. That being said :

1) We define the characteristics of the different "vessels" : mass, thrust, isp, etc... That's only numbers to input.

2) We define attach points. Docking ports will probably be more convenient in the Orbiter next release, that will allow ground-docking.

- Stage 1 : 3 points : booster1_toCHILDREN (+x,y,z), booster2_toCHILDREN (-x,y,z), stage2_toCHILDREN (xyz) ; it means that stage 1 is the "Parent" (active), and the other will follow (passive).

- Boosters : 1 point : stage1_toPARENT (x,y,z) ; of course 1 of the 2 boosters is "mirrored".

- Stage 2 : 2 points : stage1_toPARENT (x,y,z), payload_toCHILDREN (x,y,z).

- Payload : 1 point : stage2_toCHILDREN (x,y,z)

3) We ask the code to attach everything before the scenario starts.

4) We add "sensors" that check the state of things like (Stage1 code : "How much propellant in stage 1 ?" : "IF no more propellant in stage 1, THEN detach stage 2 !" "Oh, AND fire retrorockets for clean separation !)

5) The key is to build the sequence using "condition checks" like (Stage2 code : "IF I am detached, THEN let's fire the main engine !". "IF I have no more propellant, THEN lets detach the payload AND add a small force to him to simulate a spring or pyro device".

6) Autopilots work the same way, though there are different approaches, here one of the simplest ones, "time vs. pitch" : (Stage 1 code : "IF 30 seconds elapsed, THEN fire the "pitchdown" RCS thrusters but ONLY IF the current pitch is greater than 75°. ELSE, fire the "pitchup" thrusters for correction. etc...

All the "sentences" or "questions" above are declared or asked at each frame per second. So sometimes, it is useful to add "IF question 45 has already been asked, THEN q45_done = true" ; and question 45 will begin like "IF q45_done = false (ask the question) ELSE disregard it." And of course at the all beginning of the code (in a part that isn't read each frame), we set "q45_done=false". And in another part that executes only when Orbiter closes, we ask the code to note if q45_done is "true" or "false" in the scenario file, so Orbiter will be able to remind its status when we reload the scenario. Also somethimes you just don't want to have two instructions with opposite effect run at the same time.

Well you see the idea, that's not complex, but you have to assemble all the "bricks" in the right order :blahblah:
 
Last edited:
I'm not ready for that. People should stop assuming that everyone knows the arcane language of C++. I don't even know where/how to start.

You make it sound so simple, it's actually condescending.
 
Last edited:
I'm not ready for that. People should stop assuming that everyone knows the arcane language of C++.

You make it sound so simple, it's actually condescending.

They don't assume that everyone knows it (you assume that), they encourage to learn C++ since it has far better functionality then SC3/Multistage.

I don't even know where/how to start.

That's not really hard http://bit.ly/A39ybu
 
Last edited:
I'm not ready for that. People should stop assuming that everyone knows the arcane language of C++. I don't even know where/how to start.

You make it sound so simple, it's actually condescending.

It's not an arcane at all. It's just a tool. Like a calculator, a hammer, or a table knife.

And of course I know a minority of users knows it. There's no will from myself to be condescending, I can assure. I don't pretend to be anything else than a messy amateur. I learned because I wanted to have access to the incredible possibilities of Orbiter's API. What I suggest you is that writing .dll modules opens you a lot of doors, allowing you to make your launcher less "generic", by adding all sort of custom effects and features you can only dream of now. ;)

By the way you have to know where to start. It's calling setting up the compiler, and it is explained step by step here :


An excellent video :thumbup:
 
Last edited:
New here, and a rookie, so I know next to nothing about Orbiter.

Attempting to run the HASDA scenario on Orbiter (for me) fails.

I get this in my Orbiter log... (NOTE: this is the entire Orbiter log, sorry about that)

**** Orbiter.log
Build Aug 30 2010 [v.100830]
Timer precision: 6.98183e-007 sec
Found 0 joystick(s)
Devices enumerated: 6
Devices accepted: 5
==> RGB Emulation
==> Direct3D HAL
==> Direct3D T&L HAL
==> Direct3D HAL (Intel(R) HD Graphics)
==> Direct3D T&L HAL (Intel(R) HD Graphics)
Module AtlantisConfig.dll .... [Build 100830, API 100830]
Module AtmConfig.dll ......... [Build 100830, API 100830]
Module DGConfigurator.dll .... [Build 100830, API 100830]

**** Creating simulation session
DirectDraw interface OK
Direct3D interface OK
Graphics: Viewport: Window 1360 x 733 x 32
Graphics: Hardware T&L capability: Yes
Graphics: Z-buffer depth: 32 bit
Graphics: Active lights supported: 8
Loading 15382 records from star database
Module Sun.dll ............... [Build 100830, API 100830]
VSOP87(E) Sun: Precision 1e-006, Terms 554/6634
Module Mercury.dll ........... [Build 100830, API 100830]
VSOP87(B) Mercury: Precision 1e-005, Terms 167/7123
Module Venus.dll ............. [Build 100830, API 100830]
Module VenusAtm2006.dll ...... [Build 100830, API 100830]
VSOP87(B) Venus: Precision 1e-005, Terms 79/1710
Module Earth.dll ............. [Build 100830, API 100830]
Module EarthAtmJ71G.dll ...... [Build 100830, API 100830]
VSOP87(B) Earth: Precision 1e-008, Terms 2564/2564
Module Moon.dll .............. [Build 100830, API 100830]
ELP82: Precision 1e-005, Terms 116/829
Module Mars.dll .............. [Build 100830, API 100830]
Module MarsAtm2006.dll ....... [Build 100830, API 100830]
VSOP87(B) Mars: Precision 1e-005, Terms 405/6400
Module Phobos.dll ............ [Build ******, API 060425]
Module Deimos.dll ............ [Build ******, API 060425]
Module Galsat.dll ............ [Build 100217, API 100215]
Module Jupiter.dll ........... [Build 100830, API 100830]
VSOP87(B) Jupiter: Precision 1e-006, Terms 1624/3625
Module Io.dll ................ [Build 100217, API 100215]
Module Europa.dll ............ [Build 100217, API 100215]
Module Ganymede.dll .......... [Build 100217, API 100215]
Module Callisto.dll .......... [Build 100217, API 100215]
Module Satsat.dll ............ [Build 100215, API 100212]
Module Saturn.dll ............ [Build 100830, API 100830]
VSOP87(B) Saturn: Precision 1e-006, Terms 2904/6365
Module Mimas.dll ............. [Build 100215, API 100212]
SATSAT Mimas: Terms 113
Module Enceladus.dll ......... [Build 100215, API 100212]
SATSAT Enceladus: Terms 33
Module Tethys.dll ............ [Build 100215, API 100212]
SATSAT Tethys: Terms 101
Module Dione.dll ............. [Build 100215, API 100212]
SATSAT Dione: Terms 59
Module Rhea.dll .............. [Build 100215, API 100212]
SATSAT Rhea: Terms 68
Module Titan.dll ............. [Build 100215, API 100212]
SATSAT Titan: Terms 100
Module Iapetus.dll ........... [Build 100215, API 100212]
SATSAT Iapetus: Terms 605
Module Uranus.dll ............ [Build 100830, API 100830]
VSOP87(B) Uranus: Precision 1e-006, Terms 1827/5269
Module Miranda.dll ........... [Build ******, API 060425]
Module Ariel.dll ............. [Build ******, API 060425]
Module Umbriel.dll ........... [Build ******, API 060425]
Module Titania.dll ........... [Build ******, API 060425]
Module Oberon.dll ............ [Build ******, API 060425]
Module Neptune.dll ........... [Build 100830, API 100830]
VSOP87(B) Neptune: Precision 1e-006, Terms 391/2024
Finished initialising world
Module Spacecraft3.dll ....... [Build ******, API 060425]
---------------------------------------------------------------
>>> WARNING: Obsolete API function used: VESSEL::SetBankMomentScale
At least one active module is accessing an obsolete interface function.
Addons which rely on obsolete functions may not be compatible with
future versions of Orbiter.
---------------------------------------------------------------
>>> ERROR: No vessel class configuration file found for:
---------------------------------------------------------------
>>> ERROR: Multistage\Multistage2
>>> [Vessel::OpenConfigFile | .\Vessel.cpp | 252]
---------------------------------------------------------------
>>> TERMINATING <<<

It occurs to me that the most likely scenario is that I possibly installed Vinka's Spacecraft3 and Stage plug-ins incorrectly. I thought I followed the instructions correctly, but then I'm not so sure of that definitively.

I have tried and succeeded at 'playing' other add-ons that don't require these plug-ins, so I think that I installed these plug-ins incorrectly.

If anyone could help me, I would appreciate it.

:hailprobe:
 
You need multistage2 that can be found here http://users.swing.be/vinka/

Also, since the release of multistage2, Orbiter has undergone a major revision (from Orbiter 2006 to Orbiter 2010), so you will need a "fix", otherwise when the rocket stages, parts will vanish.

[ame="http://www.orbithangar.com/searchid.php?ID=4661"]Stage.dll for Orbiter 2010[/ame]
 
And of course I know a minority of users knows it. There's no will from myself to be condescending, I can assure. I don't pretend to be anything else than a messy amateur. I learned because I wanted to have access to the incredible possibilities of Orbiter's API. What I suggest you is that writing .dll modules opens you a lot of doors, allowing you to make your launcher less "generic", by adding all sort of custom effects and features you can only dream of now. ;)

Via P.M.:
PhantomCruiser said:
If there were some generic dll template and a good walkthrough for a rocket, I'd sure be taking a look at it. But there's not. What there is, is several examples in multistage, and even more in velcro.
 
Back
Top