Stone Blue

@Watermel00n Looking at the bugfix release, you still have other lines in the .cfg that specify a /Linbol/ folder, yet there isnt one present in your mod. Is there supposed to be some other mod that needs to be installed that has that folder in it?

i read this: Then i saw *this*: ....And I immediately thought, "Oh!.. Kewl!.... it will split open, like an accordian, with a clear, ribbed, tube, as a greenhouse..."

Kewl.. I'll wait for the release Thanx!

@linuxgurugamer So, I poked the model on one of the EDP ports I've been testing KURS with... Wondering if this could be the issue?: The part on the left is the stock Jr port.. One on right is the EDP Jr. Note it has *two* nodes defined in the model hierarchy. One is the *topside* (should be the dockingnode, and one on the bottom side, which should be the *attachnode*. In the model, the top one is named "nodeTop", bottom one is "nodeBottom"... How does KURS determine the name of the docking node to use? Cuz it seems it could be grabbing the *bottom* node here, which could explain the incorrect orientation of the camera view? And why manual changes in the cfg keys for the KURS patch arent applying? If KURS is looking for the first available node, and does so alpha-numerically, "nodeBottom" would be before "nodeTop".. vOv Here is the relevent excerpt from the ModuleDockingNode in the part cfg: MODULE { name = ModuleDockingNode nodeTransformName = nodeTop referenceAttachNode = Top Also, this is specified in the part .cfg, defining both nodes as attachment nodes, as well as having a "node_attach" key defined. Could these be interfering with definig/using the same node in the docking module? NODE { name = Top transform = nodeTop size = 1 method = FIXED_JOINT } NODE { name = Bottom transform = nodeBottom size = 1 method = FIXED_JOINT } // attachment rules: stack, srfAttach, allowStack, allowSrfAttach, allowCollision attachRules = 1,1,1,0,0 node_attach = 0.0, 0.0, 0.0, 0.0, -1.0, 0.0 stackSymmetry = 2

Sorry, I posted in the wrong thread...doh!

Yup... pointing out the bottom of the docking parts... I see changing the variables in the forward/up keys has no effect

@Coldrifting @Silvia Dragoness Here's the HullCam patch, if you want to test/tweak it: // Add HullCamVDS support @PART[*]:HAS[#manufacturer[Interlink?Dynamics],!MODULE[ModuleParachute]]:NEEDS[HullCameraVDS] { MODULE { name = MuMechModuleHullCameraZoom cameraName = DockingCam cameraForward = 0, 1, 0 cameraUp = 0, 0, -1 // cameraPosition = 0, 0.07, 0 cameraFoVMax = 60 cameraFoVMin = 20 cameraMode = 1 } }

A while back, @JonnyOThan had been able to modify the PCR code to allow for using with *manned* IVAs, IIRC... Hopefully he may have some thoughts to share... Both on PCR compatability, as well as Reviva itself... I know *he* is a huge IVA player

@Silvia Dragoness It might be, that if a mod needs to have its own patch for KURS, that differs from the generic KURS patch to add to all parts, the mods' patch is being over-ridden by the KURS patch, due to it having :FINAL, which runs last and over-rides any other patch... Idk for sure... I will be poking the issue

@Silvia Dragoness I'll be testing KURS, once I get the HullCam patch set

@610yesnolovely yup... I was working on a couple variants of MacLuky's Lander Can IVA... One was a stock IVA, with just a 3rd seat & some aesthetic props added, one a basic analog RPM IVA, and one was a moar advanced, full-on, digital/glass ASET variant... It kinda sucked that you would have to mess with moving the .cfg files in/out of GameData, *BEFORE* starting the game to choose between them... With Reviva, I might go bac and finish those Now if we could just get this to work with Probe Control Room... Especially, since I *know* its possible, tho possibly buggy, that PCR can already be switched on *manned* IVAs, *in-game*, to use either PCR or the part's existing IVA

@linuxgurugamer Is the mod already capable of being able to use any transform or gameobject, if said object is specified in the .cfg with a key? Say a "cameraTransform"? If so, could it also over-ride using the docking/grapple node transforms, if the key is present? I've been poking around the stock Grapplers, and the issue seems to be the camera gets stuck using the docking node, which does not move (not animated with the grapple claw mesh), thus its occluded by the claw mesh. If the mod could be pointed at a transform/object that was childed in the claw hierarchy, the camera would animate with it. I think the mod *can* specify location coords, to offset it from a docking node, meaning you *could* place it out in front of the limit of the animated meshes, so it wouldnt be occluded by the meshes... But that seems unrealistic, and wouldnt be quite accurate when whatever part is retracted. I would ask if, and say that the same applies to KURS? IIRC, NeptuneCamera has code to specify specific transforms in .cfg, with "cameraTransform", if you need to peek at it... vOv

FINALLLYYY!!! :O

@Coldrifting Since @darthgently had a really good request for support, I'm currently testing a HullCam patch, then I'll do a KURS Docking Camera patch... They will be super small, so if you want to include them in EDP, I'll just copy them to a post here in the thread, instead of going thru the hassle of doing a full Github PR

He means a .zip within a .zip causes an issue when installing via CKAN

The issue is, the HullCamera & KURS modules both need to define a specific gameobject name for reference to use as a camera transform, *or* someone needs to fiddle around with finding good x,y,z coords and orientation to specify in the patch. Patches to add camera support to existing parts is pretty easy, *if* there is already a suitable gameobject in the model to use. Docking ports are generally easy, since you can just piggyback/use the transform the model uses for docking reference. Might have to tweak the position on on one axis to get the "depth" right, so the view is not occluded by the mesh, but pretty easy to add support. @darthgently I would recommend bringing up HC/KURS/Neptune camera support, on those mods' respective threads. Like I said, its very easy to add the necessary support patches. and those mods' devs would be most familiar with their models, and would be easier for *them* to add support on their end, and take a load off LGG, who has plenty of other work to do.

Blender/BFA both have Maya keymaps, IIRC... Just sayin And I know a certain Discord server, where a good portion use Blender, so the help would be there... "Come to the Dark Side, Obi-Wan @akron..." .. lol

Large hydro-dynamic "doors" to cover them, such as you have on the lower portion next to the kkerbal? vOv If doors would be too cumbersome to cover two boxes, maybe instead of 4x rack, rotate the node for the box 90°, and just go with a 2x rack? vOv I'm gussing the box is 1m square?... have a 1.25m rack for 1x box, 1.875m rack for 2x boxes, and the 5x for 2.5m..?? Seems a little better balanced, than just one box difference between the 1.875 & 2.5? Maybe have the 1.875m have a slightly larger/greater Lab Time/battery capacity/core functionality, than the 2.5m, to help balance the pros/cons of 1.875 vs 2.5m racks? vOv

@linuxgurugamer When you get around to dtoxic's fix, might want to also edit the thread title to show [1.12.3, 1.9.1] compatability

Yes... there are several mods that can do this... i just cant remember what any are called, right now.. But a bump to your thread, at least, so it moves up the stream , where someone will hopefully point you to these mods

No idea for sure, but it doesnt look like it.... Prolly better to ask on thier threads, so you get a better answer... possibly even a reply from the devs

Nice! I'll have to give this a try... Looking at the .cfg, my OCD applauds you on a very well formatted, clean, and easily understood file. Very nice addition that you already have JNSQ support :thumbs_up: You should add JNSQ as supported in the OP.... Peopple who also see that, but use other rescale/planet packs, may be encouraged to add community support

I would post this instead to the MAS- MOARdV's Avionics Systems thread, or the RPM- Raster Prop Monitor Adopted thread(s)... Those would be the mods that would have best chance of adding [x]Science support... *IF* they dont already have it...

@MrLibeRation You dont mention if you have OPT Reconfig installed? *Or* B9 PartSwitch, for that matter

I could be wrong, but I get the feeling KSP.log is better for part mod devs, .cfg & MM issues.. Player.log for plugin/coder devs... But generally, good practice seems to be to post both up, & let the dev decide