Project M-III launch vehicle

[orb]

1>LINK : error LNK2001: unresolved external symbol __DllMainCRTStartup@12

Is it being linked with Orbitersdk.lib? Is ORBITER_MODULE defined?

 

[Pipcard]

Actually, I found the solution.

---------- Post added at 02:31 AM ---------- Previous post was at 02:14 AM ----------

But now there's a new problem:

That .dll shouldn't be 3 kb, it's already got several hundred lines of code (mostly from F9R) on it. And the mesh isn't even showing up in Orbiter now.

I even had set up all the property sheets prior to this.

Is it being linked with Orbitersdk.lib? Is ORBITER_MODULE defined?

I have no idea if or how the "__DllMainCRTStartup@12" is linked with Orbitersdk.lib. And if you mean "#define ORBITER_MODULE" being there and having no red underlines, then yes, it is defined.

 

[orb]

Is ORBITER_MODULE defined before you include header files? Have you changed any other project properties than the output type? If you did reset them to default (inherit from parent or project defaults).

 

[Pipcard]

Is ORBITER_MODULE defined before you include header files?

I think so.

#define STRICT
#define ORBITER_MODULE

#include "orbitersdk.h"
#include "PayloadManager.h"
//#include "OrbiterSoundSDK40.h"
#include <cstdio>
#include <cmath>
#include <string>
#include <stdio.h>

Have you changed any other project properties than the output type? If you did reset them to default (inherit from parent or project defaults).

 

[orb]

Restore "Ignore All Default Libraries" to default.

Any reason you are using delay loading?

 

[Pipcard]

Restore "Ignore All Default Libraries" to default.

I did that, the .dll is still 3 kb (with VS 2008), instead of ~100 kb (as it should be) when I compile it with VS 2015.

Any reason you are using delay loading?

It's from the Payload Manager SDK doc.

3. Define the PayloadManager.dll as a delay loaded dll. If you are using MS Visual Studio open project properties and add to Linker/Input/Delay Loaded DLLs value PayloadManager.dll.

But I still get this warning...

1>LINK : warning LNK4199: /DELAYLOAD:PayloadManager.dll ignored; no imports found from PayloadManager.dll

...even if it is defined via a filepath.

1>LINK : warning LNK4199: /DELAYLOAD:C:\Users\user\Desktop\Orbiter\orbiter_m\Modules\PayloadManager.dll ignored; no imports found from C:\Users\user\Desktop\Orbiter\orbiter_m\Modules\PayloadManager.dll

Having nothing defined as a delay loaded .dll doesn't change the .dll being only 3 kb.

---------- Post added at 11:47 PM ---------- Previous post was at 06:03 PM ----------

It is basically compiling as if the property pages aren't even there.

---------- Post added 02-06-16 at 11:38 AM ---------- Previous post was 02-05-16 at 11:47 PM ----------

Okay, the real mistake I made was starting a new project in VS 2008 and selecting
"General -> Empty Project" instead of
"Win32 -> Win32 Console Application"

I was wondering why I required something called "stdafx.h" (sorry for not telling you about that)

:facepalm:

The .dll is now at a reasonable size, and everything works except Payload Manager is still not showing up in the scenario editor. I even made sure to follow every direction in PayloadManager_SDK.pdf, such as adding this:

//Scenario Editor definations
DLLCLBK void secInit (HWND hEditor, OBJHANDLE hVessel){
/* Here you can define your own Scenario Editor vessel-specific pages .........
.........
.........
*/
// Define PayloadManager Scenario Editor interface PayloadManager::DefineScenarioEditorPage(hEditor, hVessel);
}

and adding this to my .cfg file.

EditorModule=[My_vessel_dll_name]

I even included the "Now it is necessary to tune Payload Manager for your ship" parameters from the PM_demonstrator code.

Also, certain words aren't showing up in blue. Does that have anything to do with the problem?

---------- Post added 02-07-16 at 11:32 AM ---------- Previous post was 02-06-16 at 11:38 AM ----------

Finally found the source of the problem: I didn't define the EditorModule in the .cfg file properly.

EditorModule=[My_vessel_dll_name]

(I had put EditorModule=[M-III] when I should have put EditorModule=M-III/M-III, as that was where I put my .dll: */Modules/M-III/M-III.dll)

---------- Post added at 02:00 PM ---------- Previous post was at 11:32 AM ----------

I compiled the same code with VS 2015. And it also works there.

 

[IronRain]

Great work!

 

[Pipcard]

Great work!

(Just remember that most of the code is by BrianJ [with some parts by Kulch], modified by me.)

What Loru said about .dll-based add-ons:

...I could admire meshes and textures (from what I've seen so far are pretty good), and hope for you teaming up with someone to create dll-ed version or regret if it stays as velcro/multistage.

Now, not everyone has the time to "team up" to make the .dll. Which is why I thank BrianJ for making his add-on open-source.

 

[fred18]

This is remarkable. Also the ms2015 source is open, give a look to it, or feel free to ask if you need help, i'd be glad to help! Cheers

 

[Pipcard]

All I'm wondering is what function in the PayloadManagerSDK allows you to shift the location of the currently loaded payloads (not the default location), such as when the vehicle is staging and the COG changes location. Whatever it is, it works with [ame="http://www.orbithangar.com/searchid.php?ID=6036"]Themis-A[/ame].

 

[Pipcard]

After the Themis-A stages, the payload location relative to the center of gravity relocates itself. But with my rocket, after staging, it keeps the relative coordinates the same.

Can "PM_SetSlotAttachmentParams" do this relocation? Because in the SDK doc, it only talks about it setting or resetting the "default" position, not the position of the current payload(s).

I'm also not sure whether the payload placement auto-adjust is related to the way Payload Manager is implemented, or whether it has to do with the custom separation functions of the add-on.

For example, [ame="http://www.orbithangar.com/searchid.php?ID=3262"]Universal Cargo Deck[/ame] (which is based on Payload Manager) takes into account changes in the center of gravity with the stock Space Shuttle Atlantis (such as booster and external tank separations) but doesn't seem to with Falcon 9R.

 

[fred18]

I don't know the payloadManager actually. So sorry if I'm making you loosing time, but I don't understand what is wrong with the picture, it seems perfect to me, and if position reference changes accordingly keeping relative distances correct it seems exactly what should happen. what is the target that you want to achieve?

 

[Urwumpe]

Can "PM_SetSlotAttachmentParams" do this relocation? Because in the SDK doc, it only talks about it setting or resetting the "default" position, not the position of the current payload(s).

Yes, it can.

 

[Pipcard]

I don't know the payloadManager actually. So sorry if I'm making you loosing time, but I don't understand what is wrong with the picture, it seems perfect to me, and if position reference changes accordingly keeping relative distances correct it seems exactly what should happen. what is the target that you want to achieve?

Nothing is wrong with that picture, that is how it is supposed to work.

But with my rocket based on the F9R code, Payload Manager does not compensate the payload placement after a change in the location of the center of gravity.

When Universal Cargo Deck (based on Payload Manager) is added to the stock Space Shuttle, it is able to compensate for changes in the center of gravity (again, that is how it is supposed to work). This is why I am wondering if the issue is related to Payload Manager or the parts of the vessel code that are responsible for the jettisoning of stages.

 

[fred18]

could you post here the staging routine? if not, do you call ShiftCG? when in the code?

 

[Pipcard]

Actually, I messaged woo482 about it, and he told me how it works.

for(int i= 0; i< PayloadCount; i++){
            pldofs = PM_GetDistantVectorToPayload(i)
            ofs = pldofs -_V(0,0,cgdif);
            PM_SetSlotAttachmentParams(i,ofs,_V(0,0,1),_V(0,1,0));
        }

"Where 'cgdif' is how far you want to move the payload."

and so I slightly modified that for use in the F9R-based M-III. It would go within the "JettisonStg" function.

//Payload placement compensation during staging (thank you woo482!)
int PayloadCount = PM_GetMaximumPayloadsNumber();

for (int i = 0; i < PayloadCount; i++)
{
	VECTOR3 pldofs = PM_GetDistantVectorToPayload(i);
	VECTOR3 ofs = pldofs - STG1STG2_OFF; //subtracts payload offset vector by stage 01/02 offset vector
	PM_SetSlotAttachmentParams(i, ofs, _V(0, 0, 1), _V(0, 1, 0));
}

 

[Pipcard]

I just realized...

When the VESSEL2 class is being used, the custom HUD text (using the "TextOut" function as described here) doesn't work with other rendering clients (e.g. D3D9).

No wonder Themis-A uses an MFD for launch control...


I'm also having some difficulties with getting the F9R's launch autopilot to work with my stages. Apparently, the different mass ratios and thrusts of my rocket are enough to make the autopilot do things such as pitch up too much after first stage separation, resulting in an apogee tens of kilometers above the target altitude, and overcompensate by pointing below the horizon (resulting in significant cosine and payload losses - i.e. only 16 tonnes of payload could be launched into LEO instead of 19 tonnes with the same launcher using Velcro Rockets). At other times, the first stage pitches too low and too early. So I'll have to figure that out somehow. At least it can get to the correct inclination.

 

[fred18]

I don't know for sure, but if you took the guidance program from BrianJ falcon I think it's derived from my guidance of Jarvis because I passed it to him and he said he used it.

Try to make an inclination very close (like 0.1 degree) from your launch latitude and tell me if it works or if it fails.

Anyway if that is derived from my routine I can help you to calibrate it for your launch vehicle. Otherwise I have the general PEG algorithm working for MS2015 that I can use to help.

 

[Pipcard]

At launch, the rocket is at 3.91 deg. The targeted orbital inclination is 3.92. (Currently the HUD interface is ripped off from F9R but I might have to replace it with an MFD like Themis-A if I can figure out how to get an MFD to interface with a specific type of vessel.)

At first stage separation, the rocket pitches up too much.

The rocket then pitches down because the ApA is too high. I had compiled the code with the F9R's mass ratios and engine thrusts, and it didn't have that problem.

But yes, the inclination is very accurate. And in the end, it has the proper perigee and apogee.

 

[fred18]

That is exactly the same issue I encountered when coding the various type of jarvis. I solved it with the general guidance solution of MS2015.
The problem was the multistage peg algorithm that still wasn't perfect at that time.

Basically the first stage pitches down too much and gives you not enough vertical speed but too much horizontal speed. Then the second stage tries to correct the vertical energy but of course a big correction if not properly dampened result in big oscillations. My suggestion is to work on the first stage guidance, especially its final states.

If you don't know where to start post the code and I'll try to help there.

edit: could you try to launch from an higher latitude with the same small difference? something like 45 deg with 45.2 inclination and tell me if it gets there?