RUS New site

Advanced search

[ New messages · Forum rules · Members ]
Page 206 of 221«12204205206207208220221»
Forum » SpaceEngine » Archive » Work progress and public beta test - 0.9.7.4
Work progress and public beta test - 0.9.7.4
JCandeiasDate: Friday, 08.07.2016, 18:02 | Message # 3076
Pioneer
Group: Translators
Portugal
Messages: 382
Status: Offline
Nope. It doesn't work that way. What happened with my moon if proof of that. The moon, Kuma, has as parent body Goyra, a planet, which in turn has as parent body the star Kiru, which is declared in catalog\stars. And yet the moon highjacked the very barycenter of the 24 Draconis star system, which has no parent body.




They let me use this!
 
HetairosDate: Friday, 08.07.2016, 19:11 | Message # 3077
Observer
Group: Users
Poland
Messages: 18
Status: Offline
More star mass shenanigans, this time the opposite way.


Attachments: 6669156.jpg(64Kb)


Edited by Hetairos - Friday, 08.07.2016, 19:14
 
JackDoleDate: Friday, 08.07.2016, 19:25 | Message # 3078
Star Engineer
Group: Local Moderators
Germany
Messages: 1737
Status: Offline
JCandeias,
Of course this is a mistake in the catalog.
Non-unique name as 'Kuma' should not be used in the official catalog files as 'ParentBody'.

It should always be used unique names, so for example the HD number or the HIP number. Or 'NU Dra', in the case of 'Kuma'.

Then there could not be such confusion.

But as long as the catalogs are not checked and corrected in this regard, remains only the solution to give your moon a different name! Of course, you could also check and correct the catalogs! dry





Don't forget to look here.



Edited by JackDole - Friday, 08.07.2016, 19:26
 
steeljaw354Date: Friday, 08.07.2016, 19:26 | Message # 3079
World Builder
Group: Users
Pirate
Messages: 862
Status: Offline
That is the lowest for Y dwarf stars, I have seen like 5 stars with that EXACT same mass.
 
JCandeiasDate: Friday, 08.07.2016, 19:47 | Message # 3080
Pioneer
Group: Translators
Portugal
Messages: 382
Status: Offline
Quote JackDole ()
But as long as the catalogs are not checked and corrected in this regard, remains only the solution to give your moon a different name! Of course, you could also check and correct the catalogs!


Thing is: I don't know every single name celestial objects have, nor do I know every single name addon-makers decide to give their objects. Nobody does. So situations like this will happen again, unless something is done to prevent them. I made two suggestions towards a solution (inclusion of possible name collisions in the logs and/or a system of name complementation). SpaceEngineer will know which one is more feasable or if some other solution is better. But a solution will be needed; it won't be just a matter of updating catalogs.





They let me use this!
 
AngelicaPicklesDate: Friday, 08.07.2016, 20:03 | Message # 3081
Observer
Group: Users
United Kingdom
Messages: 17
Status: Offline
Not sure if these issues are 0.9.7.4 specific but here's a list:

- Docked ships do not always stay docked when re-loading game? I'm sure I read a thread somewhere about this but cannot find it, I think it was Harbinger that suggested that the game loads before the docked ships are loaded? But is there any fix for this or a planned fix?

- Ships in orbit are often not in orbit when re-loading game? They often end up somewhere far from the object, on the surface of the object or simply drifting into deep space.

Other small issues are:

- Some textures do not match up on some gas giants and asteroids.

- Some Brown dwarfs are visible behind planets. (An old issue I know)
- Also Brown dwarfs in a binary systems can sometimes disappear if the main star (A) is hidden behind an object.

- Sometimes I cannot select planets from the dark sides?

- I still have intermittent problems with the shuttle and skylone becoming uncontrollable for no reason while trying to take off and leave atmospheric planets. They can spin widely out of control for no reason and the kill rotation switch cannot be activated, also the move left, right, and rotation keys get locked out. The thrusters and engines can still be controlled. Disabling aerodynamics prevents the issue.
 
sinsforealDate: Friday, 08.07.2016, 20:06 | Message # 3082
Space Pilot
Group: Users
United States
Messages: 129
Status: Offline
Hetairos, Oi thats a sexy brown dwarf.




"Man once looked up at the stars and wondered, Now all we do is look at our hands and hesitate"
 
JackDoleDate: Friday, 08.07.2016, 20:19 | Message # 3083
Star Engineer
Group: Local Moderators
Germany
Messages: 1737
Status: Offline
JCandeias,
You could also this:

Code

Remove "Kuma1" {ParentBody "Kuma"}
Remove "Kuma2" {ParentBody "Kuma"}

//Kuma;spanish wiki, prof. jim kaler website stars

Star "Kuma1/NU1 Dra/24 Dra/HIP 85819/HD 159541"
{
    ParentBody "NU Dra"
    Class      "A6 V"
    AppMagn    4.86
    MassSol    1.7
    Orbit
    {
        Period          44223.9909
        SemiMajorAxis   941.411
        ArgOfPericenter 0
        MeanAnomaly     0
    }
}

Star "Kuma2/NU2 Dra/25 Dra/HIP 85829/HD 159560"
{
    ParentBody "NU Dra"
    Class      "A4 V"
    AppMagn    4.89
    MassSol    1.7
    Orbit
    {
        Period          44223.9909
        SemiMajorAxis   941.411
        ArgOfPericenter 180
        MeanAnomaly     0
    }
}

put to the beginning of your planetary system script.





Don't forget to look here.

 
SpaceEngineerDate: Friday, 08.07.2016, 20:21 | Message # 3084
Author of Space Engine
Group: Administrators
Russian Federation
Messages: 4799
Status: Offline
Quote SpaceHopper ()
I would really love Carbon stars, Zirconium stars, and Wolf-Rayet stars to be procedurally generated

Added.

Quote JCandeias ()
Because there's this annoying bug, you see? A bug that seems to be ignored, by which a brown dwarf in a regular planetary orbit around another star turns the star it orbits into another brown dwarf of the same type and size. It kind of contaminates it, zombifying it.

This is because you didn't described the Sun itself in the planet catalog. If there is some stars in planet catalog, SE scans them and determines the whole system spectral type and luminosity by the most bright star. In this case, it is a brown dwarf Jupiter. This is doing at catalog loading stage. So whole Solar System have not T5 spectral type. Then planetary system is being generated (at program runtime), SE generates default star in the system center (because you have described sytem as "Star" in the star catalog), which class is T5 according to calculation in the catalog loading routine. After that, SE adds all other planets, moons and stars (Jupiter) to the system.
To fix that, you must also add the Sun script to the planet catalog. Look into SolarSys.sc and copy/paste/remane it. Here I changed Jupiter to T5 dwarf in the SolarSys.sc just to test it, no problems:


Attachments: 8178413.jpg(337Kb)





 
SpaceEngineerDate: Friday, 08.07.2016, 20:58 | Message # 3085
Author of Space Engine
Group: Administrators
Russian Federation
Messages: 4799
Status: Offline
Quote yaqdark ()
Hi, my question got lost so just restating it: Will you be releasing Oculus Home (and Vive?) support for SE when 9.7.4 goes live?

No. This is for the next version/patch. I have no time for this now.





 
SpaceEngineerDate: Friday, 08.07.2016, 21:04 | Message # 3086
Author of Space Engine
Group: Administrators
Russian Federation
Messages: 4799
Status: Offline
Quote JCandeias ()
In fact, this version is showing some pretty weird behaviour regarding some (and only some) stars. An example: the star of one of my custom systems is defined like this:

Code
Star  "Kiru"   // Wart 247
{
    RA  20 0 48.624384
    Dec  -72.273373
    Dist  7069.493936
    Class  "M5V"
    AbsMagn  14.42627959
    Obliquity  18.73848696
    EqAscendNode  2.700162405
}


You have mixed up stars catalog and planets catalog. The first 5 parameters are belong to stars catalog, the last 4 - to the planets catalog (Class and AbsMagn can be used in both, but not the other parameters).





 
JCandeiasDate: Friday, 08.07.2016, 21:05 | Message # 3087
Pioneer
Group: Translators
Portugal
Messages: 382
Status: Offline
Quote SpaceEngineer ()
To fix that, you must also add the Sun script to the planet catalog.


Aaah! I see. I thought we needed to have something in the star catalog to sort of "reserve" the place for the star system. What you're telling is that whole systems, including the stars themselves (and even barycenters in multiple systems?) can be defined in a single file, no matter where it's placed, is it? That's really nice to know.

Added: hm... apparently not, as per the next answer. Now I'm confused. Again.

Added later: Right, I guess I sorted it out. Sorry, man, I'm sure you must have had good reasons for it, but I find this way of doing catalogs needlessly redundant and clumsy. One looks at the Sun's barycenter in the star catalogue and finds

Code
    Lum     1
    Class  "G2V"
    MassSol 1
    RadSol  1
    Age     4.57
    FeH     0


Then one checks the Sun's planet catalogue and there it is:

Code
Class      "G2V"
Luminosity  1.0
Age         4.57
FeH         0.0

MassSol     1.0
RadSol      1.0


Come on! Surely there must be a better way to do this. Surely it's a waste of resources to reload the same thing twice...

JackDole, my problem is solved: I changed the way I defined the moon -- that's what the tests I made were about. What I'm discussing now is not that specific problem, but how to avoid similar issues in the future, be it with my own addons or with anobody else's.





They let me use this!


Edited by JCandeias - Friday, 08.07.2016, 21:32
 
SpaceEngineerDate: Friday, 08.07.2016, 21:30 | Message # 3088
Author of Space Engine
Group: Administrators
Russian Federation
Messages: 4799
Status: Offline
Quote JCandeias ()
Aaah! I see. I thought we needed to have something in the star catalog to sort of "reserve" the place for the star system. What you're telling is that whole systems, including the stars themselves (and even barycenters in multiple systems?) can be defined in a single file, no matter where it's placed, is it? That's really nice to know.

No. SE needs at least 2 files:

1) The script in addons/catalogs/stars/ defines the planetary system itself, ie it's coordinates, brightness and color (spectral type). This info is used to generate the stars in galaxy - ie points on screen, which can be clicked. You can use two options to define the planetary system:
Star{} - adds a planetary system with default star in it's center, with luminosity/class/mass/radius/temperature which can be also defined in this script. If there is no planets/stars/other bodies defined in the planet catalogs, the procedural planets will be generated.
StarBarycenter{} - adds a planetary system without default star in it's center. SE assumes what you will define the single central star in the planets catalog (as Sun in the Solar System with no Orbit{} tag), or define binary/multiple stellar components with this StarBarycenter as a parent and a proper Orbit{} tags. No procedural planets will be generated.

2) The script in addons/catalog/planets/ defines all components of the planetary system, ie planets, moons, multiple stars or (optionally) a single central star. If a single central star is not defined, it will be generated using data provided in the star catalog (only luminosity/class/mass/radius/temperature, all other parameters such as rotation will be procedural).

I hope this now clarifies how catalogs works in SE.





 
SpaceEngineerDate: Friday, 08.07.2016, 21:44 | Message # 3089
Author of Space Engine
Group: Administrators
Russian Federation
Messages: 4799
Status: Offline
Quote JCandeias ()
Added later: Right, I guess I sorted it out. Sorry, man, I'm sure you must have had good reasons for it, but I find this way of doing catalogs needlessly redundant and clumsy. One looks at the Sun's barycenter in the star catalogue and finds

Come on! Surely there must be a better way to do this. Surely it's a waste of resources to reload the same thing twice...


If you think more, it's vise versa! It is not a waste of resources, but a way to make a massive stars-only catalog with correct mass/radius/temperature data. In older version, stars catalog can't have this data, so stars has procedurally generated mass/radius/temperature, not always correct. The only way to avoid this was defining needed stars as StarBarycenter, then add a planet catalog with needed data. There was a catalog of famous supergiants and close red dwarfs made this way. Now this is not needed, SE catalogs became more compact. Even HIPPARCOS.sc have a columns for mass/radius/temperature (not filled yet thoug), so huge amount of stars will have correct parameters in the future (then I decided to uptdate the HIPPARCOS catalog).

You may not use these data in the stars catalog, if you wish. You also may not use Class and Luminosity/AppMagn/AbsMagn, if you defined them in the planets catalog for all system stars. SE automatically sums up their luminosity and determines the system's spectral class as the spectral class of the most bright star in the system. So, it is another way to "compress" the catalogs, and get rid of boring manual calculations.





 
JCandeiasDate: Friday, 08.07.2016, 21:50 | Message # 3090
Pioneer
Group: Translators
Portugal
Messages: 382
Status: Offline
Quote SpaceEngineer ()
I hope this clarifies how catalogs works in SE now.


Yeah, I get it. I don't get why everything worked fine before and only started to cause these problems in recent versions (which is why SolarSys3000 was as it was without the need for a barycenter for it to work just fine) or why it had to be changed, but hey, you're the boss and I guess I'm in grumpy old man mode.

One note, though: replacing the star in the star catalog with a barycenter changes the way the main star is rendered in the planet browser. Compare Mosfet's image in message #3062 with JackDole's in #3064 or mine in #3066. It's the same star, with the same characteristics, but the way it's rendered is totally different.

Edit: and our messages crossed paths again. You've explained as I was writing this.

Re-edit: Nope. Strike that. No changes. Those differences were due to the highjacking of Kuma. The planet browser was assuming the diameter of an A V star as basis for the rendering of the main star. An M star is tiny by comparison, hence the images in #3064 and #3066. So false alarm.





They let me use this!


Edited by JCandeias - Friday, 08.07.2016, 22:17
 
Forum » SpaceEngine » Archive » Work progress and public beta test - 0.9.7.4
Page 206 of 221«12204205206207208220221»
Search: