Question sun.dll -- Is there a way to make a new sun/star?

[GLS]

The constructor of MyPlanet has an argument...

 

[gattispilot]

Yes, not sure why the errors

#define ORBITER_MODULE
#include "MyPlanet.h"

MyPlanet::MyPlanet(OBJHANDLE hObj) : CELBODY2(hObj)
{
	

// add constructor code here
}
void MyPlanet::clbkInit(FILEHANDLE cfg)
{
	// read parameters from config file (e.g. tolerance limits, etc)
	// perform any required initialisation (e.g. read perturbation terms from data files)
}
bool MyPlanet::bEphemeris() const
{
	return true;
	// class supports ephemeris calculation
}
int MyPlanet::clbkEphemeris(double mjd, int req, double *ret)
{
	// return planet position and velocity for Modified Julian date mjd in ret
}
int MyPlanet::clbkFastEphemeris(double simt, int req, double *ret)
{
	// return interpolated planet position and velocity for simulation time simt in ret
	return 0;// or whatever should it be
}
DLLCLBK CELBODY *InitInstance(OBJHANDLE hBody)
{
	// instance initialisation
	return new MyPlanet;
}
DLLCLBK void ExitInstance(CELBODY *body)
{
	// instance cleanup
	delete (MyPlanet*)body;
}
DLLCLBK void InitModule(HINSTANCE hModule)
{
	// module initialisation
}
DLLCLBK void ExitModule(HINSTANCE hModule)
{
	// module cleanup
}

3 IntelliSense: no default constructor exists for class "MyPlanet" c:\orbiter100830\Orbitersdk\samples\NEWSUN\MyPlanet.CPP 32 13 MyPlanet
Error 2 error C2512: 'MyPlanet' : no appropriate default constructor available C:\orbiter100830\Orbitersdk\samples\NEWSUN\MyPlanet.CPP 32 1 MyPlanet

 

[Face]

Yes, not sure why the errors

If a constructor has arguments, you need to fill them in a "new" call. Your MyPlanet constructor takes one OBJHANDLE, but you just do "return new MyPlanet;". That's the problem.

 

[gattispilot]

Thanks. Not sure what i need to put in the constructor

 

[Face]

Thanks. Not sure what i need to put in the constructor

Well, since the constructor needs an OBJHANDLE argument, you'd have to put an OBJHANDLE argument in there. So instead of "return new MyPlanet;" you can do "return new MyPlanet(hBody);", because "hBody" is the OBJHANDLE you give as argument to the InitInstance() method.

 

[gattispilot]

#define ORBITER_MODULE
#include "MyPlanet.h"

MyPlanet::MyPlanet(OBJHANDLE hObj) : CELBODY2(hObj)
{
	

// add constructor code here
}
void MyPlanet::clbkInit(FILEHANDLE cfg)
{
	// read parameters from config file (e.g. tolerance limits, etc)
	// perform any required initialisation (e.g. read perturbation terms from data files)
}
bool MyPlanet::bEphemeris() const
{
	return true;
	// class supports ephemeris calculation
}
int MyPlanet::clbkEphemeris(double mjd, int req, double *ret)
{
	// return planet position and velocity for Modified Julian date mjd in ret
	return 0;
}
int MyPlanet::clbkFastEphemeris(double simt, int req, double *ret)
{
	// return interpolated planet position and velocity for simulation time simt in ret
	return 0;// or whatever should it be
}
DLLCLBK CELBODY *InitInstance(OBJHANDLE hBody)
{
	// instance initialisation
	//return new MyPlanet;
	return new MyPlanet(hBody);
}
DLLCLBK void ExitInstance(CELBODY *body)
{
	// instance cleanup
	delete (MyPlanet*)body;
}
DLLCLBK void InitModule(HINSTANCE hModule)
{
	// module initialisation
}
DLLCLBK void ExitModule(HINSTANCE hModule)
{
	// module cleanup
}

no errors.
then I made a new cfg.

; === Configuration file for star Sun ===
Name = Gargantuanew
Module = SunG
ErrorLimit = 1e-6
SamplingInterval = 1497        ; interpolation sampling interval [s]
                               ; (interpolation error ~1m)
Mass = 1.9889194444e+30
Size = 5.0232e7     ; mean radius

the name of the dll is SunG

; === Configuration file for solar system ===
Name = Interstellar

Star1 = Gargantuanew
Planet1 = Miller
Planet2 = Mann
Planet3 = Pantagruel
Pantagruel:Moon1 = Edmunds

So how can we make the SunG show a new star with a different texture?

 

[Thorsten]

I'm certainly no expert on the Orbiter API, but shouldn't your C++ code, like, do something? Read the config file for instance?

 

[gattispilot]

Thanks:

void MyPlanet::clbkInit (FILEHANDLE cfg)
{
 // read parameters from config file (e.g. tolerance limits, etc)
 // perform any required initialisation (e.g. read perturbation terms from data files)
}

; === Configuration file for solar system ===
Name = Interstellar

Star1 = Gargantua
Planet1 = Miller
Planet2 = Mann
Planet3 = Pantagruel
Pantagruel:Moon1 = Edmunds

then the cfg for Gargantua
; === Configuration file for star by Anroalh12 ===
Name = Gargantua
Module = SunG
ErrorLimit = 1e-6
SamplingInterval = 1497 ; interpolation sampling interval
; (interpolation error ~1m)
Mass = 1.9889194444e+30
Size = 5.0232e7 ; mean radius



But what tells it do be a planets,star,.... So what we want is the Gargantua to be a star but use a different texture than star.dds

 

[Thorsten]

The code snippet you posted has two commented out lines which tell you what should be inside the function. I gather the idea is that you write some code in there which reads the file and sets the parameters accordingly, it won't happen automatically.

So the answer to your question is - right now nothing tells the code to even use your config file, it would seem you have to provide the code to do this yourself - there sure is working code by e.g. Martin, but, as written above, that's not an open source - so you have to ask someone nicely if you want that kind of source code.

 

[gattispilot]

Thanks.

void MyPlanet::clbkInit (FILEHANDLE cfg)
{
 // read parameters from config file (e.g. tolerance limits, etc)
 // perform any required initialisation (e.g. read perturbation terms from data files)
}

So this reads the info from the cfg, right?
this is what I have for MyPlanet.cfg

; === Configuration file for star Sun ===
Name = Gargantua
Module = MyPlanet
ErrorLimit = 1e-6
SamplingInterval = 1497        ; interpolation sampling interval [s]
                               ; (interpolation error ~1m)
Mass = 1.9889194444e+30
Size = 5.0232e7     ; mean radius

And then:

; === Configuration file for solar system ===
Name = Interstellar

Star1 = Gargantua
Planet1 = Miller
Planet2 = Mann
Planet3 = Pantagruel
Pantagruel:Moon1 = Edmunds

When I run it it show the star but we want a different texture.

 

[mrozigor]

Thanks.

void MyPlanet::clbkInit (FILEHANDLE cfg)
{
 // read parameters from config file (e.g. tolerance limits, etc)
 // perform any required initialisation (e.g. read perturbation terms from data files)
}

So this reads the info from the cfg, right?
this is what I have for MyPlanet.cfg

This is the function which is proper for initialization. But you have to fill it with code you want. Those two lines are only comments.

 

[gattispilot]

Thanks. But not sure what goes there

Can't seem to find an example

 

[martins]

Thanks. But not sure what goes there

Well, it depends entirely on how you calculate your ephemerides. For example, the VSOP87 objects read the data files with the coefficients of the series expansion here. They also read the config files (provided by the FILEHANDLE parameter) to check the required tolerance limits and how often to compute a full solution (rather than an interpolation).

Since you haven't actually implemented your ephemerides code yet ("return 0") I can't say what you need. Note that clbkEphemeris() should probably do better than just return 0. Not returning any state vectors may lead to undefined behaviour. In the best case it will just keep your object in the origin, which should be a fairly good approximation for a massive star or a black hole, depending on what is orbiting it. But you better check that this is really what's happening, since it is undocumented.

You may want to read the API documentation (Orbitersdk\doc\API_Reference.chm) for the CELBODY and CELBODY2 classes. This tells you what the various callback functions are expected to return.

On another note: I may have lost the plot somewhere in this thread, but did you say that you want to generate a DLL just to change the texture? This is not what the celbody DLL does. It is meant to provide the object's state vectors (via clbkEphemerides) on demand, and if required, the atmospheric parameters at a given point, using the CelBody2 interface. The texture file is currently hard-coded to star.dds. I can change that if required, but it's really just eye-candy. Currently stars don't even use a mesh, just a billboard texture.

 

[gattispilot]

Thanks. Well I think we need 2 stars. One that uses the star.dds for the orbiter solar system and then another that uses a new star texture for the interstellar world.

int MyPlanet::clbkFastEphemeris(double simt, int req, double *ret)
{
	// return interpolated planet position and velocity for simulation time simt in ret
	return 0;// or whatever should it be
}

I think if we had a way to have star1 use star.dds and star2 use another texture

 

[BenSisko]

Gattispilot has been working with me and a few other Orbiteers to create the look (if not the physics) of the Gargantua-Pantagruel system ultimately for an add-on of the ships from Interstellar. We're using add-ons from Anroalh12 https://www.orbithangar.com/searchid.php?ID=6745 for the Interstellar system and olrik jhor https://www.orbithangar.com/search_q...15&submit.y=11 for the Gargantua texture. Anroalh12 has set up the system well but the only way to achieve the appearance of Gargantua is to replace the star texture (star.dds) with the Gargantua texture. Unfortunately, this makes all the primary planetary system stars in your Orbiter installation appear as Gargantua. We were looking for a way to create the "eye candy" of Gargantua only for the Gargantua-Pantagruel system yet not alter the primary star for any other system that might be in one's Orbiter installation.

 

[martins]

OK, I understand. As I said, in Orbiter 2016 the star texture is a billboard hardcoded to read from star.dds. I can change this in the next SVN commit to allow a config-defined file name. This will still be a billboard, so will look OK only if the object is spherically symmetric (which I understand may not be the case for your project) and as long as you don't get too close.

Eventually I would like to support mesh-based visuals for the central star(s) as well to fix these limitations, but that is a bit further down the line.

 

[gattispilot]

Thanks. But we were working in Orbiter2010

 

[martins]

Thanks. But we were working in Orbiter2010

Then you are out of luck.

 

[gattispilot]

Then you are out of luck.

oh. Well then we may have to wait for svn upgrade then for 2016.

And do a switch for 2010