• Content count

  • Joined

  • Last visited

Community Reputation

3269 Excellent

About Shadowmage

  • Rank
    Sr. Spacecraft Engineer
  1. Creating an external plugin -- seems like a good way to go about it. Removes the compile-time problems you are having with c#6, as you can just link in the existing .dll. -Might- be some code-side things that I would need to adjust in order to make it all link in a bit better (might need to move some field accessors from internal to protected/etc). It should be entirely possible to write a new / alternative / replacement steering module that could be patched into the existing parts. As most of the modules in KSPWheel function independently, you should be able to plugin in any module-based steering solution. Same with any of the other modules; the entire thing was written to be as compatible as possible regarding different module combinations. If/when you get to the coding phase and would like or need a few pointers, please send me a PM. Hopefully the overall layout/structure of the wheels system should be evident from reading the existing code, but I'll gladly explain anything that needs it. AGs interfering/duplicating -- that all comes down to how the code is handled on the back end. Action-groups are already symmetry aware / called in symmetry from the stock code, so you simply don't do symmetry updates when writing the action-group handling code.
  2. Just finished adding recoloring support to the StationCore parts. Basic setup, but effective: That just about wraps up the recoloring system work, at least the major planned portions of it. From here the rest of the work is cleanup and bugfixing, possibly adjusting a few things based on feedback from testing.
  3. @SpannerMonkey(smce) pretty much nailed all the big points. You must have some suspension in order for the wheels to function (either stock or KSPWheel; both require at least some suspension travel). Stock wheels will absolutely not support multiple wheels on the same part. They either have to be made as separate node-attached parts, or you can use KSPWheel if you need them integrated. Stock wheels also will not function unless oriented properly in relation to the main model of the part (more specifically the rigidbody that gets assigned to it at runtime; wheel collider must align to the rigidbody). Rigging hierarchy depends on what system you are using (stock/KSPWheel), but should be similar regardless; the stock wheels are a good place to start looking at hierarchies (Use Sarbian's DebugStuff mod to view the models from inside the KSP editor). If you end up wanting to use KSPWheel and need more detailed/specific instructions, feel free to send me a PM and I'm sure we can get it all working for you.
  4. In the current testing versions (from dev branch), they null-ref in the editor and are generally unusable (can't build, can't resize, can't change textures, etc). Just pushed an update (like <2 mins ago) that should fix them up + add recoloring support.
  5. Yep, is available directly from the 'dev' branch (link: ). Note/Warning -- these releases are craft/vessel/save breaking, and also several parts are simply not working/broken (notably the cargo bays/trusses, and the stock-based fairing parts). So I would recommend against trying to use the dev releases for any actual playing, they are currently only intended for testing of the new features. (Even when finished there will be quite a few potentially craft-breaking changes, which is why the initial release of the recoloring system is slated for KSP 1.3+)
  6. Welcome to the forums, and thanks The system certainly isn't perfect, but is very usable for most purposes. Hard to do much better without access to the physics back-end. I would have to have quite a bit more information in order to even begin trying to debug what is going on. Ideally I would need the craft file (assuming stock+KF only parts), but alternatively I would need to know what the spring/damper settings are on the wheels in the right-click menu, AND what all of the wheel spring/damper/compression values read on the debug GUI while you are landing (kind of needs to be a video to see what is going on.... which is why providing the craft file is the ideal for debugging this kind of stuff). Your first problem sounds like an issue with spring/damper settings. As in too much of one and/or both. Does it only manifest when you adjust the motor settings on the wheels (on/off/???)? Could also be related to the second problem (joint sloppiness causing improper feedback on the suspension code). More information would be needed to see what/where the problem is. The second problem sounds like stock joints doing their thing, being sloppy. Try turning on auto-struts for, well, nearly the entire craft (and/or using some manual struts). Trying to land 500 tons on just a couple of wheels will put enormous strain on joints that are normally not loaded horizontally (most 200t+ craft that I build are rockets, where the joints compress vertically), and can/will lead to joints breaking loose and unscheduled disassembly of the craft. Actually had problems with my shuttle parts in SSTU where the wings would fall off seemingly at random due to joint failures between the wings and fuselage. Adding some struts (auto, manual), and/or increasing the 'breakingTorque' and 'breakingForce' in the config files fixed it up nicely. If you open up the flight log after it has occurred, does the log show that the joints broke first, or something else?
  7. I'm not sure on that -- ModuleToggleCrossfeed is a stock module, and I have no idea what most of its controls/etc do (no source access). Should be doable, yes, but I'm not sure on what fields you would need to setup for it. Please let me know if you can narrow down the cause or problem. Nothing in my brief tests would point towards actual mod compatibility problems between the two, but it is certainly possible that having them both installed might manifest problems on others' hardware (memory, gfx capabilities), which might also depend on what other mod(s) are installed. Glad it is working out well for you so far Don't think the functionality will change much from what you see currently, but more parts and masks/layouts for some parts will be added over time. No clue on the -force-opengl parameter, but I do know that it works with OpenGL at least on OSX (which does not use/support DirectX). It could be that I'm not intentionally compiling OpenGL shaders on the Win64x shader bundles, as I believe they default to building directx only. Will see about taking a look at it for one of the upcoming dev versions.
  8. @ThePhoenixSol I'm guessing that 'G-Effects' is a mod, and that you are not referring to the stock G-effects? As was stated by others, the best thing you can do is to file an issue on the Github repo, including the details of what is going on, and any log files. (Logs are useful for more than just exceptions and errors; they tell quite a bit about the environment (hardware), and other mods that are installed). At the very least having it on the repo makes sure that others can see that it is a 'known issue', and gives a centralized place to collect information regarding the problem. Please include as much information as possible. Craft files if they are stock+SSTU only are greatly helpful. Otherwise a description of the craft, part-count, and what you were doing at the time the problem manifested. Basically I need the exact steps to replicate the problem on a stock+SSTU (+g-effects) only install. If I cannot replicate the problem, I will not be able to fix it. Without knowing what 'G-Effects' is or does, I would guess that they are doing something with either quite a bit of CPU or GPU overhead. Custom shader effects and rendering routines would be the primary candidate. Its quite easy to implement rendering routines in Unity that will break down under specific situations or hardware combinations. Edit: As I was curious what could be going on here, I downloaded G-effects and installed it in my dev install, and did a bit of poking about in their source code. I did not notice any slowdowns, regardless of the craft being used. I tried the 'mk1 pod' as listed above, and also tried a couple SSTU-only craft designs. The only difference was a very minor drop in FPS with G-effects installed, about equivalent to their use of a full-screen post-processing filter/shader setup (unavoidable, it is the cost of doing a full-screen post-processing). With G-effects - ~202 FPS with Mk1 pod only, Without G-effects - ~210 FPS with Mk1 pod only With that information, I can tell you that it is not SSTU alone that is causing the slowdown you are seeing. Could be a multi-mod interaction problem (what other mods are you using?), or could be hardware limitations for your setup. A bit confusing is the fact that you say you experience the problem with only a mk1 pod? SSTU does not touch the MK1 pod, and should have zero active code running if the scene does not contain any SSTU parts. If you remove just the SSTUTools plugin (but keep the parts/textures/etc), does the problem go away?
  9. That would appear to be an error in the config. Looks like I didn't catch that the part was using non-standard scale/rescale factors, which alter several of the calculations for speed and motor rpm. Have opened a bug report regarding the problem, which you can track the status of through: Thanks for catching that, should be fixed up for the next release (no ETA, sorry). In the meantime, this small patch should put things a bit closer to usable: @PART[KF_TrackRBIInverting] { @MODULE[KSPWheelBase] { @maxSpeed = 38 } } (that '38' should get multiplied by the scale factors; if it is incorrect, feel free to tweak it a bit to get it closer to what is needed) Alternatively you can turn down/off the speed-based damage in the in-game difficulty settings (under the KSPWheel tab).
  10. No worries on the testing; I fully understand having a busy schedule Releasing for 1.2.2 would be zero extra work -- my dev setup is still using the KSP-1.2.2. libraries. My main point of hesitation on doing it for 1.2.2. it is that it -will- be craft/save breaking. Perhaps if it gets to a more stable point, and we are still waiting for KSP-1.3, I'll look into packing up official/public 'testing' releases of the new version for use with KSP 1.2.2. -- if nothing else it would help make sure there are no more breaking changes when things are updated for 1.3. Atmospheric horizontal landers -- yeah, I'm still giving them a bit of thought. Still not sure how to handle the aeroshell setup and/or if it will even work in KSP (might end up being a visual-only thing, KSP's drag system really can't accommodate partial shielding). Ideally I would like to make a new stand-alone 'aero-shell' part, that could be resized and customized for use with any payload/lander setup; alternatively it might be procedurally-generated fairing, using the existing procedural generation code. The big problem either way still comes back to how to handle holes for engines/etc -- such a setup almost needs to be part-specific, with no support for scaling or customization. General Development Updates: Still more recoloring system work. The last few days saw the MSRBs converted to allow for recoloring (plugin/textures/configs). Possibly a few config-level things to adjust on them, but they are working and finished from a functionality perspective. Yesterday's work went into converting the NodeFairing system to allow for recoloring -- updating the plugin, texture set configs, and remaking the actual textures. Seems likely that I'll be upping the texture resolution on them, at least doubling it in the X-axis, which should reduce the 'blur' between different colored sections, and bring the texture density-per-meter closer to what is used by the rest of the parts (it is currently about 1/4 to 1/2 density compared to tanks/etc). Today's work is going into code-side changes to allow for recoloring on the rest of the procedurally generated parts (ISDC, IPA, PDC, PPC). Progressing well so far, hoping to get them finished up this afternoon/evening. Once those parts are finished the last parts needing reworking will be the StationCore series of parts. Will likely be doing a fairly simple initial set of textures for these, probably consisting of only a single mask / set of textures (except those where multiple sets already existed -- COS/DOS). Can always add more masks/sets at a later time now that all the rest of the support is in place. In regards to RO / RSS / RealFuels / FAR compatibility (as I keep seeing this stuff pop up) -- is there anyone who regularly uses the RO suite and wouldn't mind getting their hands dirty with a bit of compatibility testing, and who is also familiar with the RO patch setup? I would like to do a pass over the SSTU plugin code to make sure there are no low-level incompatibilities, but the amount of setup time needed to do even simple testing on it has been prohibitive, and my lack of familiarity with the use/setup of RealFuels has not been helpful either. Basically what I'm asking is -- is there anyone out there who would like to undertake the role of being the SSTU-RO compatibility master? (possibly I should ask in the RO thread?) Duties/tasks would include setting up configs, fixing configs, submitting PRs to RO to merge configs, keeping track of/responding to any SSTU-RO issue tickets (on either repository), and working closely with me during development and testing to iron out any plugin-side changes or fixes that need to be made. If there is anyone interested in contributing to the SSTU-RO compatibility setup, please send me a PM and we can discuss it further / work out the rest of the details. This would hopefully allow me to move RO/RSS/RF/FAR support from the 'unsupported - bugger off' state that its currently in, into a more friendly, organized, and officially supported state.
  11. Yes, for cloning the stand-alone parts at custom diameters -- take a look at the differences between the DP-1 and the DP-0. They both use the same MODEL, but use different scalings/positions. Notably the parachute has a bunch of stuff that will need adjusted for the scale. For cloning/making new models for the station-core part use, it would be much as I explained in the earlier post -- clone the SSTU_MODEL, and update the various fields for the new scale.
  12. RO is not supported -- you'll need to take any issues you find while playing using RO over to the RO thread. The precise reason for the loss of function is you are missing some model files: "ERROR: Could not locate model data for name: Adapter-1-1x2-Short" This means your install is messed up somehow; either a bad actual install, or other things are messing with the SSTU setup/files/configs. If you can replicate the problem on a clean install, feel free to file a bug report on the SSTULabs tracker, otherwise you'll need to find support through RO.
  13. Stand-alone parts, or as docking port options for the station-core parts? Vastly different setups and systems at play there (and different modules/etc). Ahh, yep, apparently I lost the last digit somewhere in my hasty-typing. So probably all of the calculations in that above patch/config are a bit off. Was more intended as an explanation than anything that could be directly used, so hopefully the overall point came across as to what bits needed scaled, and why
  14. You are comparing apples and oranges. The docking ports in SSTU are stock sizes, and have no real-world equivalents. Dock Medium = 1.25m, Dock Small = 0.625m. They are not intended to represent any real docking ports, and are simply a docking port model built for game use.
  15. If there is anyone else who would like to help test out the new 'recoloring system', please send me a PM. At this points most parts support recoloring, with the last few expected to be converted within the next couple of weeks. -Tons- of back-end code/module side changes that need testing, as well as all of the new texture sets/coloring configuration options that need a good looking over. Would love to have a couple more sets of eyes going over it to make sure that the initial release of the new system is as good as it can be. General Development Updates: Still working on the recoloring system. Shaders are done, MFT tanks and engine mounts are done. MUS, nosecones, and adapter textures are mostly done (need some texture side cleanup). MSRB parts are WIP, with the StationCore scheduled for a bit later in the week. Last up is a bit of code-side work to enable recoloring for all of the fairing types used by SSTU (NodeFairing, ISDC, resizable stock fairings); should be some simple changes to get those working, mostly just adding in the persistent fields to track the user-configured colors. Debating whether to release the recoloring stuff as a final 1.2.2 update, or wait for 1.3 to be officially available. As there are quite a few potentially craft/save breaking changes, I would prefer to hold off for the KSP update, but things could go either way depending on the timing of the 1.3 release and how quickly the rest of the work (and testing) gets completed. One highlight of the recent work that I can share is the consolidation of the MSRB parts into a single in-editor part, using the same type of 'variant' system that is in use by the MFT-A tanks. Not a huge change, but fixes something that has bugged me for awhile on those parts.