Space Shuttle

[Thorsten]

Like in the manual, I tried to select Item 35 + 3 to have a Deorbit Burn solution for a steep entry AOA, but I don't know which Airfield is taken into account.
Solution seems unusable

If I remember correctly it's a very simplistic rule of thumb (that was before we could do PEG-4 on-board). And the assumed landing site for an AOA is the launch site.

LEO says 3200 Nm and OPS 3 REI is around 4200.

That is worrisome as they both ought to run the same algorithm, the only difference being that one is in C++ and the other in Nasal.

Also, I wanted to print the manual in a book, do you plan any changes soon to the last version of the manual Thorsten before I send it to the printer?

There's an update roughly every six months - so expect something new earliest next spring. So far it'll mainly be additions dealing with the OMS Kit options and new parameters to be i-loaded for the launch.

[GinGin]

And the assumed landing site for an AOA is the launch site.

Alright, that's why it made no sense for NOR
I will try it again for KSC then .

That is worrisome as they both ought to run the same algorithm, the only difference being that one is in C++ and the other in Nasal.

Might be very circonstential bug.

I checked my previous screens about AOA, and LEO REI and OPS 3 REI where the same within 10 % max
I will do some additional tests

Good thing is that after burn, real REI was as predicted by LEO

There's an update roughly every six months

Alright, I'll send it to Gutenberg then
If some are interested, it can be around 20 to 30 euros for more than 5 books order

I wanted to do the same with the SCOM, but that is almost 100 euros

I don't know if you know some better website/company for PDF printing into a book

[wlbragg]

Wow, sorry, I surly didn't check the obvious, the logs. The tank mesh's weren't pointing at the correct textures, osm vs oms. How that happened is strange to say the least. It looks to be saved that way in the .ac, but I corrected it in the blend.
Thanks for the fresh set of eyes. I've been looking at this too long.
I think that will fix any outstanding issues, with the exception of the specular darkmap portion.

[Thorsten]

I think that will fix any outstanding issues, with the exception of the specular darkmap portion.

Do you want to try this yourself? It's not hard to do...

[wlbragg]

OK, much better but I.m still not sure I have the dark map working.

Do you want to try this yourself? It's not hard to do...

Yeah, I'll look up any questions I might have on-line.

[Thorsten]

Since we're now testing highly eccentric and polar orbits... I'm re-doing the trajectory map. It's basically the first thing I ever did in canvas, and it's crap in more than one way, so there'll be a more orderly new version with better performance and more options.

This one can actually cope with high inclination orbits, and here's a test with an apogee of 9000 miles - you see how the slowdown at the apsis distorts the groundtrack from its sinusoidal form.



It's based on a series expansion of mean anomaly as a function of true anomaly and eccentricity, so it will also go wrong eventually (basically when eccentricity to the 4th power is no longer small) - but I believe out to geosync orbits this might actually work okay (and it benchmarks well against LEO targeting that has no series expansion in).

[eatdirt]

I'm re-doing the trajectory map

Oh man, thank you, this is x-mas!!!!

Yep, I wanted to say that, as Gingin, I observed some uncertainties in REI but only for big eccentricities, and now, even before I make a comment, this is fixed

@Wayne, I don't know what you're doing with the OMS tanks, but I have to say that all versions are beautiful, thanks so much. An with Florida detailed like this, Gingin is going to make fantastic youtube videos

[wlbragg]

@Thorsten, the multichannel lightmap looks wrong to me when using the darkmap.

Code: Select all

if ( lightmap_enabled >= 1 ) {
        vec3 lightmapcolor = vec3(0.0);
        vec4 lightmapFactor = vec4(lightmap_r_factor, lightmap_g_factor,
            lightmap_b_factor, lightmap_a_factor);
        lightmapFactor = lightmapFactor * lightmapTexel;
        if (lightmap_multi > 0 ){
            //lightmapcolor = lightmap_r_color * lightmapFactor.r +
                //lightmap_g_color * lightmapFactor.g +
                //lightmap_b_color * lightmapFactor.b +
                //lightmap_a_color * lightmapFactor.a ;
      lightmapcolor = lightmap_r_color * lightmapFactor.r;
      lightmapcolor = addLights(lightmapcolor, lightmap_g_color * lightmapFactor.g);
      lightmapcolor = addLights(lightmapcolor, lightmap_b_color * lightmapFactor.b);
      if (darkmap_enabled == 0)
         {
         lightmapcolor = addLights(lightmapcolor, lightmap_a_color * lightmapFactor.a);
         }

            } else {
                lightmapcolor = lightmapTexel.rgb * lightmap_r_color * lightmapFactor.r;
            }
        fragColor.rgb = max(fragColor.rgb, lightmapcolor * gl_FrontMaterial.diffuse.rgb * smoothstep(0.0, 1.0, mixedcolor*.5 + lightmapcolor*.5));
        }

Why do we eliminate "g" and "b" and only using "r" in the calculations when darkmap is enabled. Is that correct?

Code: Select all

if (darkmap_enabled == 0)
         {
         lightmapcolor = addLights(lightmapcolor, lightmap_a_color * lightmapFactor.a);
         }

            } else {
                 lightmapcolor = lightmapTexel.rgb * lightmap_r_color * lightmapFactor.r;
            }

[Thorsten]

Is that correct?

I suspect you slipped in the conditional.

If the darkmap is not enabled, we also add the alpha-channel encoded light (otherwise we do nothing with the alpha channel here and only use rgb) - the following 'else' refers to a different 'if' that asks whether we have a multi-channel lightmap.

[GinGin]

Awsome the trajectory and the work of Wayne on OMS.
I mostly fixed my problem with LEGO Tiles, it look so great

@Thorsten: I still observe discrepancis between REI and Leo tools.
Result after burn is still really close to what was forecasted by Leo.

Orbits are a tad eccentric, but from my screens of may, the two were matching closer.
It might come from the fixed tig.

I will do some more tests with fixed tig, and no tig and différents eccentricity .



What will be the new options with the new map ? ))

[wlbragg]

I suspect you slipped in the conditional.

Sure did, wow, I'm "slipping" all the way around!

That answered another question I had as well, thanks.

[wlbragg]

Thanks GinGin and eatdirt, there is still some application of effects needed to other objects in the bay. I noticed the airlock needs some TLC as well. I have yet to get the darkmap working on the OSM-KIT, I think it is an issue with the alpha channel in the lightmap I generated. I must not be doing it correctly. The darkmap effect should be working at least as well as it does on the RMS Arm, which actually works pretty well. You can really see it in action if you look at the RMS Arm from the payload bay station while the bay doors open.
It would be nice to have all the PB objects consistent in the effects department.

[eatdirt]

Maybe naive question, but I've been trying, for the first time, to load the delta state update from MCC in OPS 302 SPEC 50.
I do enter the Delta X, Delta Y and Delta Z there fine, but when I tried to LOAD the values with an ITEM 16, I get ILLEGAL ENTRY? Any clues?

@Thorsten, I am not able to reproduce the tracking issue, everything seems to work fine for at least 24 hours. I might have screwed some versioning of the SpaceShuttle module before, I don't know how.

[GinGin]

@EatDirt: To do that , you need to be past the entry interface in OPS 304 to perform a Delta State vector Update via Spec 50

[legoboyvdlp]

This is one JPG2000 tile with improved lakes, as well as the launchpad areas being mapped to a new material (which can be called Grass I suppose?) Or do I map it to Airport Keep in terragear?



Notice the default landclass in parts...

It's not much, but its a start.