bcqJC
-
Posts
123 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by bcqJC
-
-
Sorry if this is off-topic... As a general rule, is it "troublesome" to have multiple copies of a DLL in the GameData folder?
I just took inventory of mine and there are:
- lots of copies of MiniAVC.dll.
-
3 copies of KSPDev_Utils.1.2.dll spread over:
- EasyVesselSwitch
- KAS
- KIS
Should I be concerned with those?
-
3 hours ago, allista said:
-
Added Show button that displays content hint for a short time
- this is actually a step toward user-controlled orientation of the payload
Thanks!
-
Added Show button that displays content hint for a short time
-
Yes it can.
- Set throttle to zero.
- Bring up the SmartRCS MJ module and turn on the option to use RCS when thrusters are offline.
- Turn on RCS (toggle with "R" key).
And you're ready. Personally, I keep RCS off until after I've finalized the maneuver node and oriented by probe to the maneuver using SAS. Otherwise, things get jerky. Also, depending on the mass of your probe, set the RCS max throttle to a low value.
Don't forget to turn things off after the maneuver is complete. Otherwise, MJ will use RCS for any sort of maneuvering and use up all your propellant.
-
I updated to 1.7.2 today and have played using my save from 1.7.1. My ships that use the OPT parts are ok. Do you have all 3 OPT mods?
- OPT Space Plane 2.0.1
- OPT Legacy 1.3.1
- OPT Reconfig 1.5
-
@allista. I really appreciate you taking the time to consider our opinions. I hope I'm not overstaying my welcome.
You don't have to worry about texturing. As you can see below, I cobbled up a couple of OPT parts and Hangar parts and placed a Mk2 Cockpit inside the Hangars to illustrate my point.
Because you provided us with the option to change the size and aspect of some of the parts, if I want to use the upwards opening of the OPT KH Cargo Bays, I can place the Inline Hangar inside and resize it to fit. From the outside, it looks like the Inline Hangar is part of the OPT Cargo Bays.
If instead, I want a ship that just has the cargo ramp, I can use either the Radial Hangar or the Ground Hangar and place them inside the cargo bays. Although for this, I'd prefer the Radial Hangar because it has the option to change the Size and Aspect.
So if you can provide us with a version of the Radial Hangar where the doors are along the long axis, like the Inline Hangar, then we'll have a boxy hangar that we can place inside cargo bays.
And another icing would be the option to change the orientation of the payload on deployment - as @MaxPeck mentioned. I'm thinking ahead here. If you give us a Radial Hangar with doors along the long axis, I can look forward to using the MarkIV Spaceplane mod. That mod has cargo bays that open downwards instead of upwards. That's when having the ability to change the orientation of the payload will be crucial.
As you can see, the texture of the Hangar parts won't matter if we have the flexibility to place them inside existing parts; resize them as desired; and change the orientation of the payload on deployment.
Here's an image showing how flipping the Radial Hangar changes the orientation of the payload. If you go through with having a door on the long axis, away from the radial attachment point, if we want to use the part as a downward opening hangar, the payload would be upside down when deployed. Unless we have the option to change the orientation.
Again, many thanks for your attention.
-
20 hours ago, allista said:
Combining two hangar parts so they act like one would be too difficult to implement; wouldn't even know where to start actually.
What I can do though is to make conversion for OPT cargo bays, turning them into resizable hangars. That'll solve both the aesthetics and the length problems.
Oh... I wasn't asking for functionality to combine hangar parts. Just having hangars that can be resized (already existing functionality), have different bay door placement, and thinner walls.
Below is an example of one of my recent ships. Note that I placed an Inline Hangar inside 2 OPT Cargo bays. Then I resized the Hangar to fit snugly inside. I was able to carry 6 small satellites in 1 flight using this setup.
A Ground Hangar would have been a better fit because it is a box (not a cylinder like the Inline Hangar), but the bay doors open along the axial plane. Also, the Ground Hangar has thinner walls.
So to summarize, at least for me, there's no need to code for combining hangar parts. The existing parts are ok. Just give us options/flexibility on the door placement - for example, a boxy hangar with doors that open vertically like the Inline Hangar.
Also, that way, there's no need for you to do a conversion for each type of cargo bay out there.
Thanks.
Edit: Also just noticed that there's the option to push out the payload from the Hangar on deployment. Thanks for that. I've been using Kerbals on EVA to nudge the payload out when in orbit.
-
On 6/10/2019 at 12:07 PM, allista said:
Can't help noticing that the Hangar is by far the least popular of my mods.
Naturally, I wonder why: is it just a narrow ecological niche, since part count is not such a big problem now?
Or some points in the mod have to be drastically improved to make in more usable?
Please count me as one of the grateful users of Hangar. However, it took a while for it to grow on me. Main reason for my reluctance is aesthetics. I like the OPT mod a lot. So I use it to design my ships. So when it comes time to actually use the ship to bring something up to orbit, I have to rework my ship and payload so that the hangar fits the ship and the payload fits the hangar.
What would be nice is if you can take the concept a bit further. For example, if I want a long cargo bay, I can connect 2 OPT KH cargo bays together. Right now, I can place an Inline Hangar inside the combined cargo bay, change the size an aspect of the hangar so that it fills up the combined OPT cargo bay, and use the Hangar as designed. The down side is that I cannot fully utilize the space in the OPT cargo bay because I'm limited by the size of the Inline Hangar. Also limited by the shape of the hangar. It's round; inside is hex; and the walls are thick that the payload size is restricted. So now, I have to change my payload to fit.
I can use a Ground Hangar. But it opens along the axial plane. The Inline Hangar is nice because it can open on the dorsal or ventral planes.
So... A boxy hangar like the Ground Hangar that opens on dorsal or ventral planes would be nice. The walls won't be as thick as with the Inline Hangar. The current feature of being able to change the size and aspect is perfect.
Also, having the ability to change the payload's orientation when it exits the hangar would be nice. Right now, if I use the Inline Hangar in a cargo bay, when I deploy the payload, the payload is lying on its side. Not an issue when in outer space. It's an issue on the ground. I designed a drone payload that would fly out of the cargo bay. When it came time to deploy, it was on its side.
Please take the above as requests for "icing-on-the-cake". Without them, I'm happily using the mod. If they get incorporated in a future release, it would be a boon. Thanks.
-
I've recently discovered WaypointManager and have been using it to mark spots on the map and store the locations. When it comes time to use it with landing guidance, I just bring up Waypoint Manager so I can see the coordinates of the waypoint and enter them into Landing guidance.
-
Oscillating and exploding craft... I had to deal with one of those last night in my attempt to learn how to use the new parts. I was trying to build an "Osprey" like craft.
I finally got things to work by not using any symmetry related functions on any of the servos and rotors I used. That also meant building each engine assembly individually instead of using Alt-LMB to copy stuff. And yes, no autostruts.
-
Thought I'd help out in the search for parts with duplicate attributes:
@PART[FusTekKirsDockingModule] specified 2x in FusTek_TweakScale.cfg
@PART[NP_couplerp_375m_5x125m_Plate_slim] specified 2x in NP_TweakScale.cfg
@PART[orbitaiespod] specifed 2x in AIES_TweakScale.cfg
@PART[part_URM_1_25_Cowling_NA_2J] specified 2x in KOSMOS_TweakScale.cfg
@PART[part_URM_1_25_InterStage_NA] specified 3x in KOSMOS_TweakScale.cfg
@PART[part_URM_1_25_L04] specified 3x in KOSMOS_TweakScale.cfg
@PART[URM_2_5_P_Fairing_Base_SSPP] specified 2x in KOSMOS_TweakScale.cfg -
6 hours ago, infinite_monkey said:
Hmh. But if I add lights, won't it cost even more performance? Would it also cost performance if there were 2 options - cosmetic and actual illumination?
Something I learned from the IndicatorLights mod... Cosmetic lights are just bright neon patches. Since they don't illuminate anything in their vicinity, your pc just has to draw a bright patch without worrying about the other stuff around the patch.
But if something illuminates, then stuff around the light source has to be redrawn accordingly. The pc has to calculate the light source's effects on their surroundings - what stuff gets lit up and what stuff produces a shadow, which then darkens other stuff.
-
Found out why the ThunderHawk MFDs are not working for MechJeb. The screenWidth, as defined in the NearFutureProps RPM patch that came packaged with the MarkIV, must be changed to a higher value.
The screenWidth is currently set to 2 (see below). I changed it to 92 - a guesstimate after taking into account the ratios of the other width and height settings.
/ Adds RPM support to NFProps MFDS
@PROP[NF_RPM_CNSL_MFD_Bezels]:NEEDS[RasterPropMonitor]
{
MODULE
{
name = RasterPropMonitor
screenTransform = ScreenTransform
fontTransform = ASET/ASET_Props/MFDs/Fonts/mainfont
textureLayerID = _Emissive // Name of texture layer to work with on the screen surface.
screenWidth = 2 // Screen width in letters.
screenHeight = 40 // Screen height in lines.
screenPixelWidth = 736 // Width of the generated screen texture in pixels.
screenPixelHeight = 800 // Height of the generated screen texture in pixels.
fontLetterWidth = 16 // Width of a font character.
fontLetterHeight = 32 // Height of a font character.
cameraAspect = 0.892
fontDefinition = ASET/ASET_Props/MFDs/Fonts/fontDefinition.txt -
On 9/15/2018 at 12:16 AM, IgorZ said:
KAS.JS1 is stackable. If it's not in your game, it means some other mod is adding an incompatible module to this part (e.g. kOS).
My apologies mate, for sending you on a wild goose chase. To make up for it, I tracked down the offending mod. It was FMRS. The MM patch for FMRS was adding module FMRS_PM to all parts...
@PART[*]
{
MODULE
{
name = FMRS_PM
parent_vessel = 0
}
}And KIS doesn't like that somehow. So I placed the override in the FMRS MM patch instead.
Thanks.
-
Just wanted to share this...
I'm just starting to use KAS+KIS. I tried them out a few weeks ago. However, last week, after downloading the latest versions of KAS and KIS, I noticed that I can no longer stack the sockets and hooks in both current and legacy parts.
After much time searching, I found out that KIS allows other mods to override its stackable item logic. So I changed GameData\KAS\Patches\MM-KIS.cfg to add the section in bold below to force KIS to allow stacking of the affected parts. I didn't bother adding the legacy parts because they're deprecated.
KAS already defines the stackable items in the @StackableModule portion. However, KIS has its own checks that ignored that. Hence, the need to override those checks.
@KISConfig:AFTER[KIS]:NEEDS[KAS]
{
@StackableModule
{
moduleName = KASLinkTargetBase
}
@StackableItemOverride
{
partName = KAS.CH1
partName = KAS.JS1
}
} -
I recently discovered TweakScale - in addition to the other mods I'm using - and it got me wondering, why not just make TweakScale a standard? The mods I'm using have different kinds of containers that come in different sizes cluttering up the parts catalog.
CCK helps a lot sorting them out by mod. But wouldn't it be simpler if the modders just create 1 part that we can customize the size via TweakScale; and markings via B9PartSwitch? For example, SSPXR lets me change the container type and the decals on the container changes to reflect the contents.
I understand that TweakScale is not a global solution. For example, using it on command pods doesn't make sense. I don't do it, but I'm glad I can make a Tardis-like cockpit if I want to :) But for tanks, containers, decouplers, stack separators, etc., I think that it makes absolute sense.
Hopefully, less clutter on the parts list translates to less work for modders. -
I'm on KSP 1.4.5 Win10. Yes it works. Toolbar button shows up fine, even if my vessel doesn't have a docking port installed
Just like with any other mod, get the latest version of ModuleManager and install that first. The ZIP file I got had MM 3.0.6 bundled. I just copied the NavyFish folder and ditched the bundled MM 3.0.6 because I already have MM 3.0.7.
-
I'm on KSP 1.4.5 Win10. Screenshot below shows the exact version and build number - in-game version stamp near the lower left corner at the bottom.
The installed mods are Vessel_Viewer_Continued-0.8.7.zip (JSI-RPM is included) , ToolbarControl-0.1.6.14.zip (do not confuse this with 000_Toolbar), Click_Through_Blocker-0.1.6.7.zip, and ModuleManager-3.0.7.zip.
-
Holy clap, I never knew!!! I just finished building a shuttle using the mk4cockpit-2/Vulture pod. I see now what I'm missing.
All the MFDs work! I didn't complain about the mk4cockpit-1/Thunderhawk displays before because I think it'll be awkward to fly using IVA anyway. The 60x30 MFD screens for MechJeb don't display the menus for some reason. And I have to "turn on my seat" to reach the auxiliary toggles/controls on the side.
But with the Vulture, everything is front-and-center for the pilot. And all the MFDs work! Granted, visibility is limited. It's like looking through arrowslits of a castle. But that makes total sense in a spaceplane.
Does anyone have a VR rig and played using the Thunderhawk? This mod makes me wish I have one now. I have a MSI-GS63VR with NVidia GTX70-MaxQ. I think it will support a VR setup. Something to think about when Black Friday sales start
Anyways... time to actually take the Vulture out for her maiden flight.
-
Regarding the mk4cockpit-2...
I'm on KSP 1.4.5. I'm a dev myself (boring business software, not the bleeding-edge game dev like the modders). So I understand the frustration of trying to support users who use an application on an unsupported release. So I accept that I'll have to live without it until @nertea is able to fit it his schedule. I have to say, @nertea, I admire your ability to juggle all the mods you're supporting.
Back to the cockpit-2 issue... Having looked at KSP.log, I see that the textures for cockpit-2 are all successfully loaded. So there should be no reason why KSP errors out later, when it loads the cockpit-2 model.
However, just after the cockpit-2 textures are loaded, the mk4crewcabin-1 textures are loaded. And there, KSP generates an exception. Which gets me thinking, maybe it's the mk4crewcabin-1 that has issues and it is messing up mk4cockpit-2 somehow.
So I tried removing mk4crewcabin-1 from the Parts/Pods folder - placed it in a temp folder outside of KSP. It worked. I can now see and use mk4cockpit-2.
So... If you can do without the mk4crewcabin-1, nix it and you get mk4cockpit-2.
I've already used mk4crewcabin-1 in my personnel transports. And I have mk4cockpit-1 to use, so missing mk4cockpit-2 is not an issue for me.
EDIT: 1 hour later, I decided to chase this rabbit.
Finding out that mk4crewcabin-1 caused it is 95% of the solution. The fix is to resolve the issue with texture mk4common-1-blank-n. It looks like the "blank" textures are all 4x4, except mk4common-1-blank-n, which is 2x2. Something about that is not kosher with KSP.
So I renamed mk4common-1-blank-n.dds in GameData\MarkIVSystem\Parts\Pods\mk4crewcabin-1 to mk4common-1-blank-n.dds.orig.
Then I made a copy of mk4common-1-blank.dds and renamed the copy to mk4common-1-blank-n.dds to give KSP a valid texture to load.
I haven't done a side-by-side comparison on how different the mk4crewcabin looks like now after the change. But I do get the mk4cockpit-2 now, together with the mk4crewcabin.
-
I had the same issue before. Fixed it by re-reading the dependencies. Installed Click Through Blocker and ToolbarController as specified. It's working for me now.
-
Sorry for the delay...
I uninstalled all mods; then added back the ones packaged with SSPXr 1.0.5. Below are images I took of the issue. The images are out of order - sorry about that.
The last 2 were taken before I installed the Collide-o-scope mod to show the meshes.
You can see there that when retracted, the B-EX-2 port behaves as if it's still extended - it's propping up the airframe in the pictures.
I then installed Collide-o-scope to show the collision meshes. The rest of the pics show that the collision mesh for the B-EX-2 are the same when retracted or extended. The mesh for the B-EX-1 retracts and extends as intended.
Album a/q6JIpMz will appear when post is submitted
-
1st time I saw the images of the parts, the detail blew me away.
I just downloaded version 1.0.5 of SSPXr. I see that the collider mesh for B-EX-1 Extensible Crew Tube has been fixed (I used to have 1.0-A3 installed). Can you also fix the B-EX-2? No biggie. I'd even say the issue is cosmetic since the B-EX-1 has been fixed.
Many thanks!
[1.1.2] Orbital Utility Vehicle v1.2.4
in KSP1 Mod Releases
Posted
Wouldn't the cooling effect be a function of how much propellant is left? As the propellant gets used up, it will reach a level where an external device is needed to assist the cooling. Further depletion of the propellant places more burden on the external device. Or the engine's max throttle can adjust to compensate as the propellant gets used up and the cooling effect drops.