-
Posts
9,282 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by Starwaster
-
[1.12.3+] RealChute Parachute Systems v1.4.9.5 | 20/10/24
Starwaster replied to stupid_chris's topic in KSP1 Mod Releases
Sweet! Boldface italics!!! That means its a done deal!!!!!111one -
[1.0.5] Reflection Plugin Continued 2.0
Starwaster replied to Starwaster's topic in KSP1 Mod Releases
You'll probably want to increase the resolution of the cube map. Kerbals are a little grainy. I think the default is 128x128? I forgot about that. That means I can increase resolution on my drop tank. -
[0.21.x] ReflectiveShader Plugin (Version 1.2)
Starwaster replied to Razchek's topic in KSP1 Mod Releases
I released an updated version of this with source. Changes include the ability to have non-realtime reflections so that it only updates periodically. Obviously if you want a realtime mirror you wouldn't want that. But if you just want environment mapping that changes with scenery then you would want to use that. Reflection Plugin Continued -
[1.0.5] Reflection Plugin Continued 2.0
Starwaster replied to Starwaster's topic in KSP1 Mod Releases
Example usage MODULE { name = ReflectiveShaderModule // Lower values for performance, higher values for aesthetics (you shouldn't ever need to go higher than 1024). CubeMapSize = 128 // How deep the reflection will be ("how far the reflection camera will view") FarClipPlane = 500000000 // How far away must something be before it is reflected //NearClipPlane = 1 // Set to false to render all 6 faces of the CubeMap at once (six times slower~) OneFacePerFrame = true // The shader to find. The reflective shaders are: // Reflective/Diffuse // Reflective/Specular // Reflective/VertexLit // Reflective/Bumped Diffuse // Reflective/Bumped Specular // Reflective/Bumped Unlit // Reflective/Bumped VertexLit // Reflective/Parallax Diffuse // Reflective/Parallax Specular ShaderName = Reflective/Bumped realTimeReflection = False updateRate = 300 // The height of the parallax map. Values are accepted between 0.005 and 0.08. ParallaxHeight = 0.005 // How reflective the reflection will be (Weakest 0.0 - 1.0 Strongest). ReflectionStrength = 1.0 //ReflectionColor = 0, 0, 0, 0 // Use this variable to specify which meshes to apply the shader to. // Not using this variable will default to the first found mesh. // Use the actual mesh name for the value. Or you could use: // all - to replace the shader on all meshes in the model. //MeshesToChange = polymsh,polymsh_detached,polymsh_detached1 // How shiny the specularity will be (if specular). // This value will be automatically set if it already exists on the previous shader and is not defined here. Shininess = 1.0 // These variables should be used together only. // These values will be automatically set if they already exist on the previous shader and are not defined here //SpecColorR = 0.5 //SpecColorG = 0.5 //SpecColorB = 0.5 //SpecColorA = 0.5 } Alpha channel controls reflection strength! -
[1.0.5] Reflection Plugin Continued 2.0
Starwaster replied to Starwaster's topic in KSP1 Mod Releases
1.3.0 Official update for KSP 1.0.x Ensure that camera transform position is updated to match vessel/parts Fixed bugs with black/blue color replacing expected reflections. MeshesToReplace defaults to all now Known issues: VAB / SPH reflections not working properly. (or maybe they are......) First version is designated SW-1.0 (to differentiate from Razchek's) NearClipPlane = -1 //(not KSP/Unity3D default; -1 is a flag that says not to set nearClipPlane of the camera. Positive values should be in meters) realTimeReflection = True updateRate = 300 // Requires realTimeReflection to be set to False ReflectionColor = 0.5, 0.5, 0.5, 0.5 // Requires ReflectionStrength to be set to -1. Default value mimic's Razchek's default setting of 0.5 SW-1.2 - Attempted fixes for reflection bugs. (blue or black replacing missing reflection or not updating when not at warp) SW-1.1 Missing shaders restored. Uses proper shader names (Reflective/Bumped, Reflective/Bumped Specular, etc) updateRate bug fixed. updateRate was not properly working in SW-1.0. To activate set realTimeReflections to false. This will basically turn reflections into procedural environment mapping. In addition to updating every updateRate game seconds (NOT real life seconds) the reflection will refresh whenever SOI changes. (might be of limited value since it will likely refresh long before you get close to a new body to notice) Changelog for 1.2.0 Restored missing shaders (compiled versions) Increased default FarClipPlane value to 1000000000f (!!!!!) Mark refresh map as dirty when coming of rails. Caps reflection map refresh rate when time warping. (shouldn't lag when time warping now, BUT NEED FEEDBACK SO I KNOW IT WORKS FOR PEOPLE WHO ARENT STARWASTER. THIS MEANS YOU!!!!) Removed unnecessary debug messages. Enhanced exception handling and shader fallback. Added Starwaster/Bumped Specular shader (reflective, WIP, highly experimental, use at your own risk) Fed the cats. -
This is an updated version of the Reflection Plugin created by Razchek with some additional features and fixes that provide more control over reflective materials and non-realtime updating for performance increases. The original thread is to be found here: [0.21.x] ReflectiveShader Plugin (Version 1.2) This plugin is released as Public Domain as was the original plugin by Razchek. Plugin and source downloads: Latest Download! (for KSP 1.0.5) Reflection Plugin github repository Confirmed working with 1.0.5 Version 2.0.1 for KSP 1.1.2 in progress Not available yet. Version 2.0 Fixed long standing detached transform bug Fixed rendering artifacts Switched to multi-pass rendering (as done in Texture Replacer... MULTI-PAAAASSSS) Compiled for KSP 1.0.5 Included version file BETA Version 1.2 See Changelog in next post Changes from the original: Can use ReflectionColor in place of ReflectionStrength. If ReflectionStrength is less than 0 then ReflectionColor is used instead. Default behavior retained. NearClipPlane added. Set this to if unwanted portions of your Part are being reflected. UpdateRate added. This is the number of seconds in GAME TIME (not real time) between environment map updates. Eliminates realtime reflection and increases performance. Texture scaling bug fixed. (if textures were scaled in original material, it wasn't carried over to reflective material) Known issues. The reflection camera may reflect parts of the model to which it is attached. Use NearClipPlane to eliminate unwanted reflections. (value should be set to distance in meters. If the part of your mesh that is showing up in reflections is 1 meter away from the center of geometry then set NearClipPlane to 1 or greater) updateRate is not working properly in SW1.0. The cubemap is updated continuously. As soon as I get the update rates properly sorted I'll be releasing a new version that also restores all missing shaders. Alpha channel controls strength:
-
Yes, ModuleManager is very much my friend in fact. I've made configs exactly like that in the past. Thank you for posting that.
-
Science Lab Module migration problem
Starwaster replied to wrexecute's topic in KSP1 Mod Development
Correct, you would want an @ to avoid a duplicate command module For ModuleManager 1.5.6+ there's also the % which acts like a @ unless the part lacks the specified module in which case it adds it. So if you had put a %MODULE[ModuleCommand]{//stuff} then it would have edited the existing ModuleCommand on the sci module. As far as order goes, most of the time order is irrelevant but there are instances where some plugins cause errors if a given PartModule isn't loaded in expected order. If you ever run into a situation where an existing craft mysteriously breaks but an identical launched craft is ok, then the expected order might have changed rendering existing craft in your save file invalid. It's a bizarre situation that even editing of the craft in the save file is difficult or nigh impossible to remedy. But I digress. Order in this situation shouldn't matter except that the science lab was coded in a way where the code depends on the science container being in a given ordinal location in the part. A better way for Squad to have done this would be some sort of tag variable that could be set on the container module node and a corresponding variable on the science lab. That would have been immune to any order changes. -
Science Lab Module migration problem
Starwaster replied to wrexecute's topic in KSP1 Mod Development
You need to check output_log.txt when something like this happens because you can't rely on some grumpy yet benevolent person to come along and try it for you. (error below) My guess is that it's getting hung up on containerModuleIndex which probably literally means the Nth module in the part of the science container module. You'll note in the original, the science container is the first module (index 0) I've played around with it trying index 3, 4 and 5. I tried those numbers because according to the database, the science container was the 5th module. Then later I tried 4 because I deleted the command module as the Fustek science part already had one. I looked at the quicksave to see where in the part the module was according to that and it was number 3, but that doesn't work either. I've got a bunch of mods loaded and some of them are adding modules to parts so I'm not quite sure what order the science container really is. So, the TL;DR of all that is that the science lab expects to have the location of the container passed to it in its MODULE node and if the indexed number doesn't match the location of an actual science container then it will throw an exception. Delete your ModuleManager configuration that adds the science stuff and edit the actual part.cfg Insert the science modules before ANY OTHER MODULES. Or if you put them somewhere other than up in front then make careful note of where the container module is and change the index in the science lab to correspond. Ordinarily I wouldn't tell someone not to use ModuleManager for this, but the way Squad set that up means that if you want to do it with ModuleManager you'll have to positively identify the correct index of the container and if the ordinal location of the container changes for any reason then the science part will BREAK all over again. (Thanks Squad) Edit: Also, you had a command module in your patch file but the Karmony Science Lab already has a command module NullReferenceException: Object reference not set to an instance of an object at ModuleScienceLab.updateModuleUI () [0x00000] in <filename unknown>:0 at ModuleScienceLab.onPartActionUI (.Part p) [0x00000] in <filename unknown>:0 at EventData`1[Part].Fire (.Part data) [0x00000] in <filename unknown>:0 at UIPartActionWindow.CreatePartList () [0x00000] in <filename unknown>:0 at UIPartActionWindow.Setup (.Part part, DisplayType type, UI_Scene scene) [0x00000] in <filename unknown>:0 at UIPartActionController.CreatePartUI (.Part part, DisplayType type, UI_Scene scene) [0x00000] in <filename unknown>:0 at UIPartActionController.SelectPart (.Part part, Boolean allowMultiple) [0x00000] in <filename unknown>:0 at UIPartActionController.HandleMouseClick (UnityEngine.Camera cam, Boolean allowMultiple) [0x00000] in <filename unknown>:0 at UIPartActionController+.MoveNext () [0x00000] in <filename unknown>:0 -
PorkWorks dev thread [Habitat Pack] [SpaceplanePlus]
Starwaster replied to Porkjet's topic in KSP1 Mod Development
B9 has a nice retractable surface mounted port... panels slide apart and out comes the port. -
An interesting idea. Has anyone done anything similar for other crew pods?
-
Thanks for the work. I pretty much stress tested it by throwing things at it that I probably wouldnt do in actual practice but I figured it was best to give it some harsh conditions. Though the thrusting away thing happened to me under fairly normal conditions. Just happened again though the second time was with docking parts I'm working on that might not have the right transforms... when force rolling what axis is the port trying to align?
-
observations re: build 179 Overall improvement in some areas including coasting instead of constant thrusting. Better RCS fuel consumption (see above) Avoids moving forwards until near docking axis but not quite on axis so can still hit dock at angle. Now the bad: Easily confused if asked to start when controlling port is facing away from target. On my first attempt I had either the wrong target port or wrong controlling port and the craft started thrusting away on RCS until I shut it off and approached the target manually. (MJ increased distance by over 200 meters) If I undock and change ports (target and/or control) and engage AP it does not back off from the target port or axis. Such close proximity combined with the need for rotation should trigger backing off. It might back off a little but typically starts 'move forward' while still too close and before rotation (to face target) is complete. I use identical standardized docking targets for testing. Basically a probe core with tanks on each end, solar panels and ports on the tanks. RCS on the probe core 1 set or 2 sets on each tank.
-
There's a setting in Maneuver Planner that controls how precise MJ tries to make its burns in m/s. The default is pretty low 0.5? 0.05? Setting it higher will let MJ decide 'ok that's close enough' which will also stop that bit where it keeps turning 180 to trim the delta-V because it overshot. Of course sometimes you do want accuracy such as for re-entry burns in which case you you either impose throttle limits or use RCS to manually trim your velocity. Hyper Edit also makes precise orbits btw Edit: And WOW. See this is why Starwaster shouldn't post before his morning coffee. I totally said the same dang thing as one of the people I quoted just rephrased. Sorry Mystique.
-
It stores Kerbals. Is there something else you think it should store?
-
This is an overly generalized way of stating things but, yes, the further you are the more you'll drift. The real answer is more complex depending on variables, but all else being equal that statement is more or less true. There's not much you can do except station keeping corrections and continue with your docking. that can work and in real life they'll do that maybe but depending on how close you are you might not want to bother. That sort of maneuver is something you might do in anticipation of results after an orbit? or two? And yes, it would be tricky because you would lose some altitude so you need to plan for that in advance. And use RCS for that. Watch your Map from time to time. You can see when you'll hit your closest approach and how close that will be by glancing at the map. Not sure... don't think so. Not on stock and I'm not sure any mods do either..... (though MEchJeb has a screen that tells closest approach and time without going to map) Not sure there's a question there...? I'm gathering you don't use MechJeb or you'd know it could keep the other ship stable. Usually. But what you can do with only stock is to time warp just long enough to put that ship on rails. That will zero out all rotation unless you're victim of phantom forces.
-
Congratulations! Next step.... Deadly Re-entry (though, re-entry through Mars / Duna atmosphere is a little more forgiving than Earth/Kerbin. Except for the part where you get through re-entry and realize you're still going way too fast. Just thick enough to be a hazard. Not thick enough to slow you down...)
-
I have a local hacked copy where instead of else { //we're not extremely close in z, so keep moving in z but slow enough that we are on docking axis before contact zVelocityNeeded = Math.Min(zVelocityNeeded, (Math.Max(zSep, 2) * lateralVelocityNeeded.magnitude) / lateralSep.magnitude); status = "Moving toward the docking axis and dock at " + lateralVelocityNeeded.magnitude.ToString("F2") + " m/s."; } I do this else { //we're not extremely close in z, so keep moving in z but slow enough that we are on docking axis before contact zVelocityNeeded = Math.Min(zVelocityNeeded, (Math.Max(zSep, 2) * lateralVelocityNeeded.magnitude) / (lateralSep.magnitude * lateralSep.magnitude)); status = "Moving toward the docking axis and dock at " + lateralVelocityNeeded.magnitude.ToString("F2") + " m/s. Dist: " + zSep.ToString("F2"); } Trivial alteration to a single line with non-trivial results. Pretty much guarantees that it will align before arriving at the dock. I'm happy with it.
-
Yes, it can be fixed and I sent Porkjet some information to help with that
-
Well, not necessarily. Remember that the shield still continues to reflect a certain amount of heat regardless of whether there is ablative material left or not. I have run out more than a few times but my velocity had slowed enough that either I was ok if I kept the shield pointing prograde or I had JUST exited the danger zone when I ran out. (even so though, if you're actually at the point where the shield is still ablating then you can imagine it's still cutting it close. I imagine the interior was a bit toasty for the Kerbals. Jeb couldn't care any less but Bill and Bob panic a little easier)
- 5,919 replies
-
- reentry
- omgitsonfire
-
(and 1 more)
Tagged with:
-
PorkWorks dev thread [Habitat Pack] [SpaceplanePlus]
Starwaster replied to Porkjet's topic in KSP1 Mod Development
Oooooo. Looks like ModuleAerodynamicLift is not something recent.... it dates back to 2012. Not sure what the implications are. Formerly used and outdated? Except that I don't recall ever having seen it at all. Implemented but never adopted? Anyway I found this post http://forum.kerbalspaceprogram.com/threads/7529-Plugin-Posting-Rules-And-Official-Documentation?p=156431&viewfull=1#post156431 That gives some explanation for the variables and some example usage. But those transformname variables could imply additional setup in the mesh. You might be better off sticking with 'module = Winglet'. Or maybe this is still worth looking into. I just don't know. -
PorkWorks dev thread [Habitat Pack] [SpaceplanePlus]
Starwaster replied to Porkjet's topic in KSP1 Mod Development
Ok, sorry I didn't realize all the stock wing parts were still using Winglet. That's odd because there is a PartModule for lift now. Maybe they just didn't get around to switching them. But the module is ModuleAerodynamicLift Below is a list of properties that can be set for it. The list comes from the class metainfo but in the absence of example usage I'm not sure what good values would be for it. I haven't done a forum search for that yet but I'll see if I can find out something. { public string centerOfLiftTransformName; public FloatCurve dragAoA; public float dragFactor; public FloatCurve liftAoA; public float liftFactor; public float planformArea; Not everyone has FAR or wants it. There should be a stock solution implemented if at all possible in the default download. FAR should be considered optional only. -
PorkWorks dev thread [Habitat Pack] [SpaceplanePlus]
Starwaster replied to Porkjet's topic in KSP1 Mod Development
I don't think there's any valid reason to use the module variable for anything. That's just legacy functionality they left in. It's superseded by MODULE{} type nodes. (typically when things are deprecated they're left in place so as not to break any old assets) There's MODULE functionality for lifting/controls surfaces and that's what Porkjet needs to use