Phineas Freak

@h0yer The best thing to do, as you found out, is to explicitly set the manufacturer tag inside the global engine configs. And no, it will not break anything! Just manually check if the actual global engine config doesn't already set that field. Also, if you have the time and the will, would you like to do so for the actual RO engine configs? Just clone the repository and do a PR with your changes, i surely would appreciate that!

@sir raftalot These functions are dependent on the actual RSS assembly in order to operate. RSS is version locked, meaning that the KSP 1.2.2 version will not run under KSP 1.3. You will need to recompile the source code for that. Also, only the time warp rates list is needed for what you want, everything else is not needed: REALSOLARSYSTEM { timeWarpRates { rate1 = 10 rate2 = 100 rate3 = 1000 rate4 = 10000 rate5 = 100000 rate6 = 1000000 rate7 = 6000000 } }

IDK. Scatterer has proven that if you are getting graphical issues with it then the version used does not match the KSP version. I would double check to see if the version of Scatterer installed is really the "b" and not something else. I almost did that mistake when setting up a dev environment...

Sorry but this has nothing to do with RSSVE. This is a known bug with the normal maps that are currently used in by PFFE for these fairings and it has already been fixed. What @Observe probably meant was that the shadows of the parts are too strong. But this can happen anyway if the sun is low on the horizon. For any interested party i would suggest to disable the EVE integration feature for now.

Currently no. Incidentally, i had the same conversation with @Heady978 about it and in the end it seems that disabling the EVE integration would be the better solution (users can easily enable it again via the Scatterer main menu). What is the latitude of the launch site, the season and the time of the day? I am asking because RSSVE does modify the sun light intensities but i actually increased them (IIRC stock uses 0.85 and i am using 1.0 for them).

Real Scale Boosters

No, KJR works fine with both PF and stock auto-struts. I can spot some internal struts though between the interstage and the upper stage tank. Can you test it without them? Also, the overall rigidity of the Falcon + transport structure. If it is too rigid then you will get similar results.

@michal.don Try and disable the PF "autostuts" of the interstage adapter. They do not play very well with the new "auto-strutting" features of KSP.

As far as i know both the stock CommNet and RemoteTech support multiple antenna modules within a single part. Also, since CNC is a test-bed for RT 2.0, does this means that RT will lose this multi-antenna feature?

Shhhh...don't tell anyone that i cannot read... Anyway, i opened a new issue at the RSS repository for it.

@raxo2222 From the RSS GitHub repository: pressureCurve { key = 0 0.0165 0 -1.11539E-06 . . . } So yes, the surface pressure is correct.

Sources are always more reliable than the forum tags/"metadata": https://github.com/KSP-RO/RSSTimeFormatter/releases

Goodbye Cassini! And thank you for everything!

You are missing Ven's Stock Revamp that does exactly that. VSR is more or less a requirement nowadays by RO (and especially RP-0).

@metalpoetza There is no need to recompile the source code, the code changes required for the KSP 1.3 release are already compiled. If you download the "KSP-1.3-Update" branch in the form of a .zip file you will have a ready to go RSSVE installation for KSP 1.3 (same installation instructions as with the previous ones). In fact, since it is a dev version you do not actually need the RSSVE assembly. But, do not expect any kind of user support. We are also getting off-topic so if you have any questions or suggestions it would be better to continue the discussion about RSSVE to the main RSSVE thread.

@Theysen Mark my post as useless. I failed to notice that you specifically mentioned RO and not the whole suite. Both of these mods are RP-0 dependencies...

That branch is the one that it is compatible with KSP 1.3. All you have to do is to replace the .dll file of the RC4 release with the one from the repository. I also have a small table in the RSSVE OP that lists the proper versions of the dependencies and it includes a KSP 1.3 section. There is no inherent "difficulty" regarding RSS visuals, it is just that i prefer to spend the extra time to get it right the first time. I could have easily released what i had 3 or 4 months ago and/or mark the latest version as an official one but: I would not have included everything that I wanted from the release to have (still the Uranus rings did not make it) I added some new things that required testing and would need some feedback from the users before making them part of the official releases (simple terrain textures, rings, DX11/OpenGL patchers, proper/accurate Scatterer configs - i had to write a custom external program for the Scatterer configs and that also took some time) I opted to wait for the official KSP 1.3 RSS/RO/RP-0 releases to get it out of it's "dev" cycle (as i have noted in the RSSVE thread)

@h0yer Yes, you guessed correctly, it is the volumetrics: EVE sets the opacity of the particles according to the opacity of the main cloud layer, meaning that transparent areas are still full of them but they are invisible. The horizontal axis also "contains" a lot more particles than the vertical one when you account the view distance. Also, dat 4K resolution... Semi-offtopic but other things that really affect the frame rate are the RealPlume particles, the amount of engines and the existence of TestFlight configs for them (more engines --> more failure checks per cycle --> larger CPU load --> lower frame rate). I am happy by the positive reports from all of you guys/gals for the latest version: it means that the KSP 1.3 update will be much smoother! And that the time spent on QA was well worth the +4 month delay...

@Theysen At least two, Custom Barn Kit and MagiCore (specifically for RP-0), have their KSP 1.2.2 releases overriden by the KSP 1.3 ones. Everything else seems fine at the moment.

@avi Thank you! I do also hope that someone will take an action to fix the SS detail textures (or add it as a separate mod). Even a single detail texture (like here) makes a tremendous difference in the overall visual result. At least now they are not a huge performance hog like it was before, i am learning! And that's a really nice Zenit!

@Steven Mading The quick way (no costing or tech tree placement) @PART[myPart]:FOR[LaserDist]:NEEDS[RP-0] { %RP0conf = True } The FOR pass is completely hypothetical, you can change it as required or even remove it.

Remove AmpYear and you should be good to go.

@Heady978 EVE cannot parse some of the cloud configs. I also have no idea why this happens to you (i think you reported that one before): EVEManager: Issue loading PQSManagerClass! Error: UnityEngine.UnityException: Unable to apply node! ---> System.NullReferenceException: Object reference not set to an instance of an object at PQSManager.PQSManagerClass.ApplyConfigNode (.ConfigNode node) [0x00000] in <filename unknown>:0 at EVEManager.EVEManagerBase.Apply () [0x00000] in <filename unknown>:0 --- End of inner exception stack trace --- at EVEManager.EVEManagerBase.Apply () [0x00000] in <filename unknown>:0 at EVEManager.EVEManagerBase.LoadConfig () [0x00000] in <filename unknown>:0 at EVEManager.GenericEVEManager`1[PQSManager.PQSWrapper].StaticSetup () [0x00000] in <filename unknown>:0 at EVEManager.GenericEVEManager`1[T].Setup () [0x00000] in <filename unknown>:0 at EVEManager.GlobalEVEManager.Setup (Boolean late) [0x00000] in <filename unknown>:0 and: EVEManager: Issue loading CloudsManager! Error: UnityEngine.UnityException: Unable to apply node! ---> UnityEngine.UnityException: Unable to apply node! ---> System.NullReferenceException: Object reference not set to an instance of an object at PQSManager.PQSManagerClass.ApplyConfigNode (.ConfigNode node) [0x00000] in <filename unknown>:0 at EVEManager.EVEManagerBase.Apply () [0x00000] in <filename unknown>:0 --- End of inner exception stack trace --- at EVEManager.EVEManagerBase.Apply () [0x00000] in <filename unknown>:0 at EVEManager.EVEManagerBase.LoadConfig () [0x00000] in <filename unknown>:0 at EVEManager.GenericEVEManager`1[PQSManager.PQSWrapper].StaticSetup () [0x00000] in <filename unknown>:0 at PQSManager.PQSManagerClass.GetPQS (System.String body) [0x00000] in <filename unknown>:0 at Atmosphere.CloudsPQS.Apply (System.String body, Atmosphere.CloudsMaterial cloudsMaterial, Atmosphere.Clouds2D layer2D, Atmosphere.CloudsVolume layerVolume, Single altitude, Vector3d speed, Vector3d detailSpeed, Vector3 offset, Matrix4x4 rotationAxis, Boolean killBodyRotation) [0x00000] in <filename unknown>:0 at Atmosphere.CloudsObject.Apply () [0x00000] in <filename unknown>:0 at Atmosphere.CloudsManager.ApplyConfigNode (.ConfigNode node) [0x00000] in <filename unknown>:0 at EVEManager.EVEManagerBase.Apply () [0x00000] in <filename unknown>:0 --- End of inner exception stack trace --- at EVEManager.EVEManagerBase.Apply () [0x00000] in <filename unknown>:0 at EVEManager.EVEManagerBase.LoadConfig () [0x00000] in <filename unknown>:0 at EVEManager.GenericEVEManager`1[T].Setup () [0x00000] in <filename unknown>:0 at EVEManager.GlobalEVEManager.Setup (Boolean late) [0x00000] in <filename unknown>:0 Do also note that the KSP 1.3 branch is experimental so it can have bugs. I do not officially support any other version than the 1.2.2-RC4 one.

@Mr. Quark For future reference, i have written an extensive "How To" guide, along with a "FAQ" section.

@Jaeleth I posted a temporary patch for that: It is also part of the next RO release so you can also grab it from the RO repository.