Shadowmage
-
Posts
4,628 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by Shadowmage
-
That pretty much -is- the workaround.
-
That does look odd, but that is an actual Light, and not an emissive. I really couldn't say where it is from. Does the engine light mod somehow cache the 'engine thrust transform' location (to determine where to place the light)? As that does change with those parts in the editor/etc, esp as compared to the prefab part. If you just place them on the RBDC, then yes they are 'centered' on the decoupler by default, and will be 'neutral' when decoupled. Aero forces will likely cause them to tumble inwards and hit the center stack. Moving the SRB downwards on the decoupler slightly forces the 'nose out' tendency upon decoupling, at which point aero forces seem to rip them away from the rest of the rocket. Don't offset too much though, or you can end up with the opposite problem -- the bottom of the SRB smacking into the center stack.
-
On the SRBs? Hmm... I don't even think -I- have any emissives on them. Yep, double checked. I have zero emissive modules/animations/etc in the part configs, and none should be being added by part-modules either. Have some of the names/further information on these errant emissives? (and are you referring to textures, or animations?) Generally is solved by offsetting the SRBs downwards slightly on the decoupler, so that the decoupler gives the tip an outward push; aero forces take care of the rest (the SRB COM is on the default surface attach position, so the minor offset is needed).
-
Sounds right. Or just flip the entire part around, and use the 'invert engines' button in the right-click menu. Either should work Edit: Yes -- that sounds correct. Originally the part was intended like the IC on the Saturn rockets, where it stayed attached to the 'upper' stage and was used as ullage, and then was discarded before/as engines were lit. So you would want the opposite staging setup to make the ISDC stick to the 'lower' stage. Can still use the 'invert engines' option if you would like, so that the separation motors push the lower stage away from the upper.
-
Interstage Decoupler -- SSTU-ISDC, in the 'payload' part tab (if I remember correctly). Basically a stand-alone interstage fairing, with built-in separation motors. You may be able to scale/disable the motors if not desired.
-
Stock has some issues when the 'root part' uses dynamic drag cubes. Not much I can do about that -- I'd file that bug on the stock issue tracker. SSTU parts have to use dynamic drag cubes, period, and that includes if the player decides to use an SSTU part as root. Again though -- is there an issue with JUST SSTU installed (no scatterer?). If yes, please let me know, as the issue exists in SSTU. If the problem only occurs with Scatterer, then it is Scatterer that is having problems, and again, I would suggest raising the issue there (I cannot solve problems in other mods). Notably, if you look at the stack-trace, the SSTU code is executing just fine and completes its function calls without error. No problems there. The exception is occurring in Scatterer code. "scatterer.ShadowRemoveFadeCommandBuffer.OnDestroy ()" Then use the ISDC? IIRC it does not have colliders on it, except on the engines. (The petal adapter has to do some funny stuff regarding colliders to make the part even work, which is likely the problem you are encountering; you might try and disable the colliders on the petal adapter and see if that solves your particular issue)
-
Uninstall the mod. No more dark icons! (or roll back to a previous version). (yes, I'm sick of people complaining about all of the hard-work I put into it; which is why I'm likely moving on from KSP in the very near future)
-
In that image, the interstage node will be positioned here (red dot/cross): It is intended to be used with the petal adapter or ISDC parts. Which looks like exactly what you need in this case (e.g. if you just want a longer fairing / space below the engine bells). Toggle the interstage node 'on' in the mount. Grap a petal adapter. Make it as long as you want (need to make it longer to use the top node, can shorten afterwards). Attach the TOP node of the petal adapter to the hidden interstage node inside the engine mount. Should end up looking like this:
-
You can still do dynamic part-destruction. Each part still has its own colliders; only difference is there is only one RigidBody, and thus only one 'body' for physics calculations (as opposed to the current state of one rigidbody and multiple joints per part, which is what kills on physics updates). When a collision is detected, you query for which colliders were involved, and destroy just that part if needed. If that part happened to be in the middle of the craft, the craft gets split apart, and now you have two craft each with a single rigidbody (but still consisting of multiple parts). A system very similar to this was implemented by the game TrailMakers, which also uses Unity. They do dynamic body welding of individual blocks to reduce the number of rigidbodies in a craft, while still allowing some 'flex' in the craft. As blocks in a craft are destroyed/added/removed, the rigidbodies are recalculated as needed. Rather than having 200+ rigidbodies for a craft, they are able to weld them down to 4-5 (and could go lower); mostly these splits are across moving parts such as hinges/rotors, which is the one place where multiple rigidbodies and joints would still be needed. TLDR: It would work. It would work well. It is entirely possible (and better for performance). SQUAD explicitly has decided not to go this route, because they like the floppy-ness that multiple joints gives. (though, with autostrut being added and player-usable, this is a far less compelling argument -- can't we just get single-rigidbody vessels already, and stop worrying about performance due to part-count? (I'd happily pay for that DLC, many times over... hint... hint...)
-
No, the new node will be -INSIDE- the engine mount, at the place where the mount tapers from standard stack-diameter to whatever non-standard diameter (the same place as the top of the fairing is when fairings are enabled on the mount). You have to use one of the mount options on the engine. It has to be a mount that has a fairing/interstage node defined You have to click 'toggle interstage node' on the engine to enable the node The node is INSIDE of the mount, usually not visible. It does work though. Could you show a screenshot of the craft, specifically with the right-click menu for the engine open?
-
I do not support RSS/RO/Etc. Only basic stock installs. With that being said -- your issue appears to be something in scatterer is crashing out when SSTU renders drag-cubes. [EXC 01:48:01.537] NullReferenceException: Object reference not set to an instance of an object scatterer.ShadowRemoveFadeCommandBuffer.OnDestroy () UnityEngine.Object:DestroyImmediate(Object) FlightCamera:Awake() UnityEngine.Object:Instantiate(Part, Vector3, Quaternion) DragCubeSystem:RenderProceduralDragCube(Part) SSTUTools.SSTUStockInterop:updatePartDragCube(Part) SSTUTools.SSTUStockInterop:FixedUpdate() This is something that is new in scatterer. Was not a problem in previous versions; would suggest you report the problem there. (basically, SSTU can do nothing about needing to render drag cubes; it has to. But scatterer should not be crashing when a drag cube is rendered)
-
You can import flags into the stock game, and use those for your mission flag. SSTU simply uses these mission flags, the same as the stock parts. If you are looking to add flags to parts that don't normally have them -- no, that is not something SSTU can do, but there are other mods that offer such functionality (sorry, don't know any on the top of my head).
-
Few words about the upcoming release (later this week/week-end): TU now uses the stock reflection probe and stock reflection system; to edit reflection quality, use the stock settings in the in-game options menu. This means that TU no longer has any 'runtime' component (e.g. no possibility for memory leaks; any runtime leaks now are due to stock code). Removed DX9 API check and warning. If people want their stuff to look terrible, go for it. Scatterer no longer present in reflections (changes to Scatterer code) (EVE still works). This is a stock/scatterer problem, and not one that TU can fix. Stock skybox not present in reflections (changes to stock skybox code -- they don't support the skybox with their own reflection probe, so not something I can fix).
-
I don't use IVA, so my motivation to fix that is close to zero. Feel free to figure out whatever weird crap KSP does regarding IVA positions and submit a PR with the fix though; I'll glady take a PR to fix it, but I'm not going to spend the better part of a week trying to figure out whatever retarded stuff KSP is doing regarding IVAs. I had it working in the past (after spending too much time to figure it out), and then SQUAD broke it. TLDR -- Contact SQUAD and tell them to fix it. Not my problem.
-
Take a look at SSTU and how its textures are setup. That mod uses the intended use of the texture switch setup in its entirety (and is the ONLY mod that uses TU correctly for recoloring). https://github.com/shadowmage45/SSTULabs/tree/master/GameData/SSTU/Assets Notably for recoloring -- textures need to be authored in grayscale for the DIFF/MET/GLOSS maps, and an additional 'recoloring' mask provided. Alternatively, you can use existing textures and provide a 'normalization mask' in addition to the recoloring mask. Either way works, but this is the important step nobody wants to do, because it requires real, and hard, work in order to create these masks (and configs). E.G. Here is the diffuse texture used for SSTUs fuel tanks, and its recoloring mask (one of them; lots of masks) https://github.com/shadowmage45/SSTULabs/blob/master/GameData/SSTU/Assets/SC-TANKS-DIFF-WHITE-P.dds https://github.com/shadowmage45/SSTULabs/blob/master/GameData/SSTU/Assets/SC-TANKS-MASK-STRIPES1.dds Basically the system takes the 'grayscale diffuse texture' and uses it for adding details on top of a user-selected color. If the original texture is not grayscale with a base of 127,127,127, the details cannot be extracted correctly, and the output visual will not match the recoloring selections in the UI.
-
Yeah, seems like it is a fairly stable version. To note -- SSTU should already be compatible with 1.7.2. I have not (yet) done a recompile, but the existing version should not have any new issues. Hoping to push out an update this weekend with a few fixes and integration hooks in it, but no guarantees.
-
Wheels use a special PhysX object, called a 'Wheel Collider' that calculates friction differently than standard collisions. This is very incorrect. https://docs.nvidia.com/gameworks/content/gameworkslibrary/physx/guide/Manual/Vehicles.html
-
Good to know Are you internally doing a try/catch on those code blocks that the exception doesn't blow up the outer KSP loading loop? I have a feeling that the issues being encountered are due to version mismatch or other mod/patch conflicts, which are of course not easy to track down simple log files. Yeah, there were some major changes in SSTU during the 1.4/1.5 update range (IIRC), where pretty much all parts were swapped around to use new modules, given new names, etc. Since then there have been no breaking changes to the mod; I've intentionally tried to keep things stable and compatible between the KSP updates as much as possible.
-
Technically, the friction in Unity engine is a combination of the friction settings for both of the colliding objects. Only half of the objects in KSP don't implement physics materials, and IIRC, the terrain is inconsistently setup as well. Some has lots of friction, some none. This wouldn't even be a simple part to make -- you need to not only have high friction on the part itself, but you need to adjust the friction of every material that part will come in contact with, and then reset those other materials when the part is no longer in contact. Massive, major, PITA, that will likely only cause more bugs than it resolves. Note: I've played with physics material friction settings extensively while creating and debugging KSPWheel. While the concept is sound (increase friction to decrease walker legs from sliding), the implementation ability from within Unity is handicapped by the two-sided nature of the problem, and that KSP never set the properties up properly in the first place for 99% of in-game assets.
-
I don't believe there were any breaking changes between 1.6 and 1.7 -- just bugfixes and QOL improvements. You can use it in any rocket you like. But the inner node is for 'payload', and the upper node is for your rocket and attaches to an interstage node -- its just how the part was designed. From your log: InvalidOperationException: Texture not found! at B9PartSwitch.TextureSwitchInfo+<CreateTextureReplacements>d__8.MoveNext () [0x00000] in <filename unknown>:0 at System.Collections.Generic.List`1[B9PartSwitch.TextureReplacement].AddEnumerable (IEnumerable`1 enumerable) [0x00000] in <filename unknown>:0 at System.Collections.Generic.List`1[B9PartSwitch.TextureReplacement].AddRange (IEnumerable`1 collection) [0x00000] in <filename unknown>:0 at B9PartSwitch.PartSubtype.FindTextureReplacements () [0x00000] in <filename unknown>:0 UnityEngine.DebugLogHandler:Internal_LogException(Exception, Object) UnityEngine.DebugLogHandler:LogException(Exception, Object) UnityEngine.Logger:LogException(Exception, Object) UnityEngine.Debug:LogException(Exception) B9PartSwitch.PartSubtype:FindTextureReplacements() B9PartSwitch.PartSubtype:Setup(ModuleB9PartSwitch) B9PartSwitch.ModuleB9PartSwitch:InitializeSubtypes() B9PartSwitch.ModuleB9PartSwitch:OnAwake() PartModule:Awake() UnityEngine.Object:Internal_CloneSingle(Object) UnityEngine.Object:Instantiate(GameObject) PartLoader:CreatePartIcon(GameObject, Single&) PartLoader:ParsePart(UrlConfig, ConfigNode) <CompileParts>c__Iterator1:MoveNext() UnityEngine.SetupCoroutine:InvokeMoveNext(IEnumerator, IntPtr) Apologies, its B9 Part Switch (which, AFAIK, also does fuel switching). These errors appear to be related to textures... but any error during loading of a part can cascade errors down to seemingly unrelated systems.
-
Unable to confirm in a stock install (KSP 1.7.0). You must have some other mod conflict going on (or version mismatch). Your log had a ton of exceptions for some fuel switch, which may well be causing the issue, but I did not see any exceptions from SSTU directly, which again points to some other mod causing the issue. Can you duplicate the issue on an otherwise clean 1.7 install? Here is how to assemble using the IPA and its top node with space-bar activated staging. 1. Grab your craft with an SSTU engine + mount. 2. Right click the engine + mount, and click 'toggle interstage node' 3. Grab an IPA and extend its length so that the lower/inner node does not interfere with placement 4. Attach the IPA to the interstage node on the mount (it is buried -inside- the mount) 5. Shorten IPA down to desired length/adjust diameters as desired 6. Profit!? For reference the internal node will not be activated through staging -- it is intended to be a right-click or action group function.
-
There very well could be something wrong with that part at the moment -- haven't checked it in quite awhile. I'll try to do some testing this evening to see what is up, and post some examples if it is all otherwise working. Would you mind posting a pick of your craft so that I might have an idea what I'm trying to replicate? (in case it is something non-obvious that is causing issues)
-
Right click on the engine, and press the 'toggle interstage node' button. That should enable the interstage node -- this is an attach node that is 'inside' of the engine mount, at the place where the engine mount bevels out to the stack-size chosen. You should then be able to attach the engine/mount to the top node of the IPA using the interstage node. I'll try and get some pics of this setup this evening and explain the process.
-
The IPA is specifically intended for use for Apollo type setups, where the inner attach node is for a lander. It will always decouple after the upper node. The intended use-case is to use the upper-attach node on the IPA to connect to the interstage-attach node on your engine mount (may need to enable the node on the mount). Then.. the staging should 'just work'. Edit: I'm not sure of the direct answer to your question. Haven't played KSP in so long, and haven't used that part in even longer... I don't even remember what about it could be causing you problems. I seem to remember it being quite simple to use and figure out (at least, when used as intended).
-
I meant nothing negative with my post, and agree with you fully. KSP modding isn't just complex, its on its own levels (more than one!). So bad that I constantly have to re-learn things when going back to older projects, because the API is just so obscure and nonsensical. Still applaud the effort you put into making these parts and textures -- I know full well what it takes, and its not minor. How did your naval combat game that you were working on end up going?
