Shadowmage

Members
  • Content count

    2450
  • Joined

  • Last visited

Community Reputation

3370 Excellent

About Shadowmage

  • Rank
    Sr. Spacecraft Engineer
  1. Thanks for having the patience to work with me to get the problem figured out I've opened an issue ticket on the OpenGL compatibility, and will be looking into it for the next full release (unknown ETA). https://github.com/shadowmage45/SSTULabs/issues/477
  2. Hmm... @DrVonBraun have you tried running KSP without the -force-opengl flag? OpenGL mode should no longer be needed now that x64 is a realistic option; in earlier KSP versions it was used to reduce memory footprint, but 64-bit mostly eliminated the memory concerns for most reasonably modded installs. Oh, you also get higher FPS with DirectX compared to OpenGL mode (at least I always have). Still looking through the rest of the log, but I'm not seeing anything that would point to errors. Your hardware should be adequate (gfx supports shader model 5), so I could not really think of what else could be causing it other than OpenGL mode (note: the custom shaders I use were compiled for DirectX9 only for use on Windows; openGL is only supported on OSX and Linux builds; though I would have thought that there would have been errors when loading/assigning the shaders to the parts or materials if it was unsupported). Its already scheduled to do some testing of the custom shaders using openGL (to fix some OSX related problems), but with my current work (and life) schedule, I probably won't get around do doing any testing on it for a couple of weeks. Please let me know if removing the -force-opengl flag fixes the problem; that will at least let me know where I need to begin investigating for proper solutions, and I can add all of the information to an issue ticket to keep it from getting lost.
  3. Thanks, looking over things now, will let you know what I find (if anything). Seeing as how it is a shader related problem, there should, in theory, be something simple that is preventing the shader from working on your system/setup/install (whether it is hardware/software/configuration related though is... unknown).
  4. Would you be able to post an updated KSP.log file? Hopefully without all of the various plugin-folder-related errors, it should be easier to spot any other potential problem areas. Thanks, and hopefully we can get this fixed up and working for you soon (just need to find what is going on first).
  5. As @blowfish stated, you have a ton of stuff in KerbalSpaceProgram/Plugins -- that folder should be empty (it looks like you installed the SSTU source code into that folder?). That alone could be causing problems, as there are a whole bunch of Unity .dll's and scripts in there that should not be loaded by KSP. This has also caused it to try and load at least 4 copies of the SSTUTools.dll, which is an additional potential cause for your problems. Try removing the contents of that Plugins folder, and retrying things. Please let me know if the issue persists, and I can investigate a bit more.
  6. As others have pointed out, you will need to post at least your KSP.log file; all I can tell from the screenshot is that there is a problem -- I have no way to tell what the problem might be, or what might be causing it (both of which will need to be known in order for a solution to be found). By posting your log file, it includes your mod-list (so no game-data screenshot needed), and it also tells me your basic graphics/hardware setup so that I can see if there are any problems in that area. From a guess -- I would have to wager that your PC is having problems with the custom shaders. But I would need more information to even guess at more than that (my next... guesses... would be that you are running DX11, or perhaps really old video card that doesn't support shader-model 3+; none of which was tested or really supported on those shaders)
  7. I see what you are referring to now. And yes, they -are- one engine as far as KSP is concerned, which is why TCA sees them as one engine (single part, with only one ModuleEngines module). @blowfish has the correct answer below, along with a bit of explanation on why it is not likely to happen. Yeah, as TCA works by controlling different ModuleEngines on the craft, and not manipulating the per-transform thrust of any given module (or per gimbal transform), it would be....very difficult.... to get it working on the individual engines' in a cluster. I think the only way this could work is if the modules' manipulated the per-transform-thrust split in the engine module in combination with adjusting the main throttle for the module/part. But I'm unsure how well the stock code would cope with runtime adjustments to the thrust-splitting. Either way, not something that I will be implementing. If TCA wants to implement it... everything that is needed is available to them, nothing should be needed on this end.
  8. I was unaware of any problems with TCA (nothing has been reported previously). Are the engine clusters not working properly with TCA, or is there some other issue?
  9. From my (admittedly unresearched) understanding of the problem, the mod (API/framework?) in question that was taken down was in violation of the EULA regarding reverse engineering. (Supposedly they used 'clean room' tactics to derive equivalent behavior rather than decompiling the existing code, but that is a defense that has spotty records of holding up in court). Nothing to see here, pretty standard stuff. I would have expected SQUAD to do the same had KSP mods blatantly disregarded the KSP-EULA as well (and they probably have). Unless/until Take-Two issues an official formal statement regarding modding on KSP (or its lack of), anything else is going to be speculation at best and contribute little to the community.
  10. Guessing you are using RO (or some other setup using RealFuels/ModuleEngineConfigs)? (Clusters work great in stock) But anyhow, reports such as that need to be filed on the bug-tracker or there is zero chance of them ever being fixed.
  11. Thanks for the links; I'll open up an official issue ticket for this, and hopefully have time to investigate it within the next few days/week (probably over the weekend). (ticket link: https://github.com/shadowmage45/KSPWheel/issues/43 )
  12. Do you have a craft file that I could use for debugging? (preferably stock+KF only) I've been trying to track down this issue (along with a time-warp related one), but the time needed to create test craft that exhibit the issue has been prohibitive.....
  13. Seeing as how it states in the OP that FAR is not supported.... it is not likely; you are really asking in the wrong place. -I- won't be making them (do not use FAR, not going to take the time to install it just to try to make patches that I have no idea what they do/are for). From the OP: However, if someone who -does- use FAR wanted to submit a PR for some patches, I would more than likely be willing to include them in the releases (I used to have some community provided FAR patches many months ago). (Hint, hint.... if really you want to see them, its probably best if you make them up yourself)
  14. In Real Life -- Spherical tanks have the highest ratio of surface area-to-volume of any standard three-dimensional geometric shape. This is important for space applications as the surface area is a major contributor to structural needs / skin mass. They also have an inherently self-supporting structure, and follow ideal gas expansion/pressurization consistency across the skin (making them good for pressurized tanks, or for withstanding external pressure). However they are not the most efficient use of -space- given existing rocket designs; which is why we have cylindrical tanks with domed end-caps. I think it was the N1 that used spherical tanks with conical/cylindrical shrouds on them, which ended up with a worse mass-fraction because of it (lots of extra fairing/structural panels with empty space inside). Not as much of a concern for orbital/vacuum use, as I think those shrouds were mostly for aerodynamics during the launch; in space it might be a simple external truss structure, where you could take advantage of many of the pros of the spherical tanks. Basically, they can be better from a mass-fraction perspective, but worse from a utilization of space perspective. As with most things rocket related, it is all about the tradeoffs and situational uses that would make one more desirable than the other for any given use. >90% sure that I can make it happen. Already doing everything that would be needed in the station parts / MUS, would merely be adapting the code to be used with a different set of models and for use as stand-alone parts. Not entirely sure on the feature set yet, or even if it will be a thing, but currently I can see the utility of the parts and could have used them for quite a few builds that needed...odd... rcs balancing. Also the ability to mount the RCS on extensions (possibly even deployable/adjustable length?) seems like it would be very useful for tugs/freighters/station-assembly with nose-mounted payloads. At this point the biggest thing keeping it from happening in the short-term is models / time needed for modeling (or lack of). The code side of things should be fairly quick to get working once models are available.
  15. General development/status update: Slow going as of late due to real-life constraints; still undergoing some restructuring at work, and likely will be for the rest of the summer, don't foresee things getting any less-crazy until fall/winter. That alone has been keeping me from making too much real progress in modding; hard to do modding when your brain feels like mush by the time you get home. I have however still been working on what I can as time permits. Fixing up bugs and general cleanup looks like it will be the theme for the next month or two. Probably won't be able to start on any of the new part concepts until at least the end of summer. That should give a nice 'stable' period for the mod though as I don't see there being any major/breaking changes coming down the pipeline for quite awhile. When I next have time to get back into the swing of things, I think that the next series of parts to be tackled will be one of three things -- Modular-RCS, Service Modules, Probe Cores, or the Lander Core rework/refresh. Still undecided on which to work on first, but I do plan for all four to be completed eventually. SM's and Probe-cores could nearly be done with the existing models/textures and would just need a bit of additional back-end plugin support for specific features. RCS stuff is still a bit early in the concept development phase. Lander Core as well is still early in the concept development and planning stages for the new parts (existing parts probably won't change too much). One thing that is being worked on currently (with the help of @tater and @Jimbodiah) is setting up an official SSTU-Craft and Patches repository. This will be a single centralized place where various craft packs and 'overhaul' patch sets can be downloaded for the mod. Still working on figuring out the organization and structure of everything but it looks like there will be at least several different lines of craft being offered (stock, various rescale), as well as quite a few different patch sets for even further customization (rebalance for rescales, new/changed models and textures, entirely new parts using other mods' models). Will post more information on this as things get figured out. Probably at least a few weeks out from having anything ready for download.