Jump to content

[Min KSP 1.12.2] Buffalo: NASA Inspired Modular Space Exploration Vehicle

Angelo Kerman

By Angelo Kerman
in KSP1 Mod Releases

 Share

Recommended Posts

ComatoseJedi

ComatoseJedi

Posted
Posted

@Stone Blue Not exactly a cab. Just another texture of the docking port cap to put on the ends of the rover, if you aren't wanting it to connect to anything and just have a rover with more of a rear end on it rather than a flat space or a cap that appears to be a place to put something. Where'd you get those rovers? Never seen them before.

Link to comment
Share on other sites
Stone Blue

Stone Blue

Posted
Posted (edited)

@lynwoodm They are old BobCat rovers... There were 5 different ones, some have a few variants, also...

This thread only lists the 1st three...There is a MK4 & a MK5 as well... Do a Google for "Kerbal DEMV"...LOTS of youtube vids of them in action...

BobCat DEMV rovers

A few people did updates for them... I know they can work up to 0.90... I cant remember if I ever tried them in 1.0.0 or not...

Edited by Stone Blue
Link to comment
Share on other sites
  • 2 weeks later...
Angelo Kerman

Angelo Kerman

Posted
  • Author
Posted (edited)

0.2.5 Young Feathers

New Parts
- Added the M1A0 Bear Cub. This adorable wheel is used for small rovers.
- Added the WJ400 Jaguar, a micro-jet engine. It's a great booster engine for weighed down JetWings.
- Added a half-sized chassis. It has an integrated solar panel, but no KIS storage.
- Added a quarter-sized chassis. It too has an integrated solar panel and lacks KIS storage.
- Added the ATV Command Seat. It's just like the External Command Seat, except that it cannot be radially attached.

JetWing
- Reduced the engine ISP by half. Transcontinental flights are fun and all but you know, a wee bit OP...

Wheels
- Adjusted traction values to be more in line with stock wheels. This work is ongoing, some of the stock values don't work for these wheels. Many thanks to Taniwha for the scrips that gave me the values. :)
- Fixed a collider issue with the Grizzly. It shouldn't drag its feet now. Thanks for your help Beeks! :)
- Remove interim wheel

Edited by Angel-125
Link to comment
Share on other sites
zvergk

zvergk

Posted
Posted

fix Buffalo Crew Cab  support for TAC-LS. 108 days without resources to survive only in Buffalo Crew Cab  (then I just got tired of looking like they're keeper turned gray). In config file  for  BuffaloCab  i saw parametres for TAC-LS  how they activate ?

http://imgur.com/DFPVISu

 

Spoiler

@PART[WBI_BuffaloCab]:NEEDS[TacLifeSupport]
{
    @RESOURCE[ElectricCharge]
    {
        @amount = 350
        @maxAmount = 350
    }

//21 crew-days of life support
    RESOURCE
    {
        name = Food
        amount = 7.679
        maxAmount = 7.679
    }
    RESOURCE
    {
        name = Water
        amount = 5.075
        maxAmount = 5.075
    }
    RESOURCE
    {
        name = Oxygen
        amount = 777.266
        maxAmount = 777.266
    }
    RESOURCE
    {
        name = CarbonDioxide
        amount = 0
        maxAmount = 95.913
    }
    RESOURCE
    {
        name = Waste
        amount = 0
        maxAmount = 0.1
    }
    RESOURCE
    {
        name = WasteWater
        amount = 0
        maxAmount = 0.924
    }
}

 

Link to comment
Share on other sites
Angelo Kerman

Angelo Kerman

Posted
  • Author
Posted

There should be a couple of ModuleManager patches in the Buffalo/Parts/Command/BuffaloCab.cfg file and the Buffalo/Parts/Utility/CrewCab.cfg file. It looks like I goofed on the CrewCab, it should have a section that looks like this:

@PART[WBI_CrewCab]:NEEDS[TacLifeSupport]
{
    @RESOURCE[ElectricCharge]
    {
        @amount = 350
        @maxAmount = 350
    }

//21 crew-days of life support
    RESOURCE
    {
        name = Food
        amount = 7.679
        maxAmount = 7.679
    }
    RESOURCE
    {
        name = Water
        amount = 5.075
        maxAmount = 5.075
    }
    RESOURCE
    {
        name = Oxygen
        amount = 777.266
        maxAmount = 777.266
    }
    RESOURCE
    {
        name = CarbonDioxide
        amount = 0
        maxAmount = 95.913
    }
    RESOURCE
    {
        name = Waste
        amount = 0
        maxAmount = 0.1
    }
    RESOURCE
    {
        name = WasteWater
        amount = 0
        maxAmount = 0.924
    }
}

Link to comment
Share on other sites
zvergk

zvergk

Posted
Posted (edited)

just paste into CrewCab.cfg  instead of the initial value. All parameters were the initial resources.It has been tested

Spoiler

@PART[WBI_CrewCab]:NEEDS[TacLifeSupport]
{
    @RESOURCE[ElectricCharge]
    {
        @amount = 400
        @maxAmount = 400
    }

//21 crew-days of life support
    RESOURCE
    {
        name = Food
        amount = 15.358
        maxAmount = 15.358
    }
    RESOURCE
    {
        name = Water
        amount = 10.15
        maxAmount = 10.15
    }
    RESOURCE
    {
        name = Oxygen
        amount = 1554.52
        maxAmount = 1554.52
    }
    RESOURCE
    {
        name = CarbonDioxide
        amount = 0
        maxAmount = 95.913
    }
    RESOURCE
    {
        name = Waste
        amount = 0
        maxAmount = 0.1
    }
    RESOURCE
    {
        name = WasteWater
        amount = 0
        maxAmount = 0.924
    }
}

 

Edited by zvergk
Link to comment
Share on other sites
Fail-Man 3D

Fail-Man 3D

Posted
Posted

The JetWing just saved my butt in career mode; it's a wonderful little drone platform for high-margin contract farming of the "temperature scan in flight at $place" variety.
It has a few minor quirks (attach node orientation, kickstand getting stuck in the level-1 runway, off-centre CoT when used as definitely-not-intended), but they are easily worked around.

Overall, I give it a solid 9.5 out of 10; the JetWing may be a little rough around the edges, but it's the part I never knew I wanted.

Link to comment
Share on other sites
Angelo Kerman

Angelo Kerman

Posted
  • Author
Posted
On 1/17/2016 at 11:38 AM, Fail-Man 3D said:

The JetWing just saved my butt in career mode; it's a wonderful little drone platform for high-margin contract farming of the "temperature scan in flight at $place" variety.
It has a few minor quirks (attach node orientation, kickstand getting stuck in the level-1 runway, off-centre CoT when used as definitely-not-intended), but they are easily worked around.

Overall, I give it a solid 9.5 out of 10; the JetWing may be a little rough around the edges, but it's the part I never knew I wanted.

Glad it's working for you. :) It is a work in progress, but it's getting there...

Link to comment
Share on other sites
Technologicat

Technologicat

Posted
Posted

Hi Angel-125,

I was going through the list of Connected Living Space configs for the parts I have installed, and noticed that Buffalo does not currently support CLS.

Some context: CLS is a mod that adds immersion during missions, and some additional challenge to craft design, by imposing requirements on what kind of crew spaces are considered connected, i.e. traversable without EVA. With CLS, all parts (parts meant here in the VAB sense) are divided into crewable (have crew seats, Kerbals can stay there), passable (can be moved through, but cannot stay), and impassable (which, roughly speaking, is the default if there is no config).

Another mod called Ship Manifest then overrides the stock crew transfer system, calling into the CLS API to determine crew space connectivity, and imposing passability restrictions if configured to do so. I think this adds to the fun of designing especially large craft so that all the important crew spaces can be reached internally. Both CLS and SM are currently maintained by Papa_Joe. My role in this is that I've been looking into adding/fixing the last few missing/incorrect configs.

Which gets me to my question: Have there been plans to add CLS support to Buffalo, and/or is there interest for this?

Buffalo is of course not typically used for building large craft, but in a game save which has CLS and SM enabled, just having them causes (by default) the connection between the command cab and the crew cabin to be impassable internally.

I took a quick preliminary look at what would need to be done. Adding CLS support to some of the parts is simple, while others are more involved. Yet other parts, actually a majority of them, have no internal crew space or hatches, requiring no CLS config at all.

These are the easily configurable ones, which would benefit from CLS configs:

  • Buffalo Command Cab (WBI_BuffaloCab). This just requires a simple MM patch to add ModuleConnectedLivingSpace and configure which attach nodes should be passable and which should not. I think that (rather obviously) the door at the back should be internally passable to other parts attached to that node, while the other nodes should not, since the cab is cupola-ish and there are no other hatches. To make a config for this, I just need the name of the attach node corresponding to the door (figuring it's either "back" or "bottom", depending on the neutral orientation of the model).
  • Buffalo Crew Cabin (WBI_CrewCab). This is also simple: four visible hatches: front, back, left, right. Top and bottom impassable. Here too, just the node names are needed.
  • Buffalo Adapter (WBI_BuffaloAdapter). Non-crewable part with hatches, should be passable axially. Since the only attach nodes are placed axially, this should need just passable=True.

Now we get to the difficult part(s) (pun intended):

  • Tundra 200 (WBI_Tundra200)
  • Tundra 400 (WBI_Tundra400)
  • Wagon (WBI_Wagon2u)

First, I'd like to ask what the design intent is: is there always a solid crew tube running through these parts, or is the full volume of the part taken up by fuel if it is configured for use as a fuel tank?

I'm assuming that the internally accessible KIS storage can always be walked through (internal access being suggested by the absence of hatches on the outside).

If there is always a crew tube through these parts, this is simple: these parts can be simply tagged passable via the axial nodes marked by the 1.25m circles, similarly to the "easy" parts, and we're done.

But if the passability depends on the configured state, let's first consider the Tundra containers. These would need a way to switch their CLS config on the fly, depending on whether each particular instance is configured as a fuel tank or as KIS storage. The only way I can see that this could be done would be for WBIResource Switcher to call into the CLS API, telling CLS whether the part is now passable or impassable when the state changes. So this would require some coding.

Finally, the Wagon adds the additional complication of inflatability. In this case the rules would need to be whatever they are for the Tundra container, plus possibly a check on whether the part is currently inflated or not, depending on whether a passable crew tube can fit there when the storage is deflated. (I.e. if it won't fit, then the part must be in the "inflated" state to be passable, in addition to any other restrictions.)

If CLS for Buffalo is desirable, I can create the MM patches, but I'd likely need your help if WBIResource Switcher needs to be modified.

Thoughts/comments?

Link to comment
Share on other sites
Angelo Kerman

Angelo Kerman

Posted
  • Author
Posted

@Technologicat: Looks like a great analysis, thanks! :) I'd be happy to include your MM patches for the Buffalo. Technically the Tundras and Wagon are fully filled with stuff, but I could also see a small corridor built down the middle for crew access, so the easiest thing to do is just add the CLS modules to them.

Link to comment
Share on other sites
Angelo Kerman

Angelo Kerman

Posted
  • Author
Posted 
@PART[WBI_BuffaloCab]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
    {
        name = ModuleConnectedLivingSpace
        passable = true
		impassablenodes = bottom
    }
}

@PART[WBI_CrewCab]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
    {
        name = ModuleConnectedLivingSpace
        passable = true
		impassablenodes = top,bottom
    }
}

@PART[WBI_BuffaloAdapter]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
    {
        name = ModuleConnectedLivingSpace
        passable = true
    }
}

@PART[WBI_Tundra200]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
    {
        name = ModuleConnectedLivingSpace
        passable = true
		impassablenodes = top,bottom
    }
}

@PART[WBI_Tundra400]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
    {
        name = ModuleConnectedLivingSpace
        passable = true
		impassablenodes = top,bottom
    }
}


@PART[WBI_Wagon2u]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
    MODULE
    {
        name = ModuleConnectedLivingSpace
        passable = true
		impassablenodes = bottom
    }
}

 

Link to comment
Share on other sites
Technologicat

Technologicat

Posted
Posted (edited)
On 27.1.2016 at 10:10 PM, Angel-125 said: 

@PART[WBI_BuffaloCab]:HAS[!MODULE[ModuleConnectedLivingSpace]] 
{
...
}

 

Wah?! Already done?!

Seems you had more time for KSP this week than I did :)

Excellent, this is pretty much what I had in mind. Some small things:

  • WBI_BuffaloCab: for consistency with the stock cupola, I'd suggest making also "front" impassable (due to windshield).
  • WBI_BuffaloCab: "bottom" and "top" behave the wrong way around: impassablenodes = bottom makes the roof impassable, but leaves the floor passable. The CLS config is correct; this behavior is caused by BuffaloCab.cfg. In BuffaloCab.cfg, the second (i.e. y?) coordinate for the "bottom" node is -0.626 (suggesting positive y = up), whereas in e.g. CrewCab.cfg and Wagon2u.cfg it is 0.626 (suggesting negative y = up). Switching around the names node_stack_bottom and node_stack_top in BuffaloCab.cfg should fix this.
  • WBI_CrewCab does not have a "top" node, so impassablenodes = bottom is enough (unless you're going to add one later ;)).
  • Tabs instead of spaces on the impassablenodes=... lines, whereas other lines are indented with spaces.
  • One trailing whitespace after each PART line.

Making these modifications (except the one that needs to be fixed in BuffaloCab.cfg), the config becomes: 

@PART[WBI_BuffaloCab]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
    MODULE
    {
        name = ModuleConnectedLivingSpace
        passable = true
        impassablenodes = bottom,front
    }
}

@PART[WBI_CrewCab]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
    MODULE
    {
        name = ModuleConnectedLivingSpace
        passable = true
        impassablenodes = bottom
    }
}

@PART[WBI_BuffaloAdapter]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
    MODULE
    {
        name = ModuleConnectedLivingSpace
        passable = true
    }
}

@PART[WBI_Tundra200]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
    MODULE
    {
        name = ModuleConnectedLivingSpace
        passable = true
        impassablenodes = top,bottom
    }
}

@PART[WBI_Tundra400]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
    MODULE
    {
        name = ModuleConnectedLivingSpace
        passable = true
        impassablenodes = top,bottom
    }
}


@PART[WBI_Wagon2u]:HAS[!MODULE[ModuleConnectedLivingSpace]]
{
    MODULE
    {
        name = ModuleConnectedLivingSpace
        passable = true
        impassablenodes = bottom
    }
}

EDIT: Tested these modifications and the one to BuffaloCab.cfg. Works correctly.

Good point (implicit from configuration :)) about the top hatch in WBI_BuffaloCab, I'd forgotten it had one in the IVA. Clearly I need to build more space trucks!

Edited by Technologicat
Tested!
Link to comment
Share on other sites
Angelo Kerman

Angelo Kerman

Posted
  • Author
Posted
On 1/30/2016 at 1:52 PM, John The Physicist said:

Is it just me or is using the trailer ports impossible? I tried changing mass and how much the wheels went down by weight, and I got them perfectly aligned, and it still didn't work....

Docking on the ground can be a pain, I don't know of many solutions that are 100% effective, save for maybe KAS' winch system.

Link to comment
Share on other sites
Technologicat

Technologicat

Posted
Posted (edited)

Congrats for the new release!

By the way, the JetWing seems really nice for a low-partcount vertical exploration solution. I totally missed it in 0.2.5, just noticed now when downloading the new release. Might need to re-spec my manned Duna mission to pack a few of these...

I'm running into some small issues with the JetWing, but that may be caused by mod interaction or PEBKAC. I'll perform some more testing and get back on this.

 

EDIT: Testing done:

DW6WiBs.png

Turned out this was maybe 1/3 mod compatibility, 1/3 a case of using it wrong, and possibly 1/3 genuine small issues. Findings below.

General

  • I think the JetWing could use a separate README with instructions, maybe in the first post. It was surprising to (eventually) find the instructions in the changelog :)
  • Typo in endEventGUIName for the kickstand ("kiststand")

VAB/SPH

  • The correct mounting procedure of accessories (in the VAB/SPH) could use instructions. Is the JetWing intended to be field-assembly-only, or are the accessories intended to be attachable in the VAB/SPH?
  • In the VAB/SPH, on the left/right nodes of the JetWing, most accessories (mini jet engine, drop tank, parachute, cargo pallet) attach onto the top of the wing, while on the middle node, they attach onto the bottom (blocking the pilot "seat"). In each case, compared to the other accessories, the Outback container attaches on the exact opposite side of the wing surface (which to me looks more correct).
  • If the JetWing itself is attached to something, the middle node becomes reserved/blocked. (Although node_stack_back and node_attach share the same position, they have different "up" vectors; this doesn't seem to help?)
  • Short of using surface attachment, in the VAB/SPH there seems to be no way to place anything (except the Outback) onto the surface labeled as "Accessory mount" in the texture (and that only if the JetWing itself is not attached to anything).
  • Symmetry (mode: mirror) does not want to work for placing the drop tanks to the nodes; when hovering the tank over the left/right node so that it "clicks" into place, symmetry switches off. (I have EditorExtensions installed if that matters.) Symmetry works when using surface attachment.
  • The engine mode cannot be toggled in the VAB/SPH (the mode listed in the right-click menu won't change even if the toggle button is clicked). Toggling this in the editor could be useful for burn time estimates by KER, especially in mixed mode (both fuels).

In-flight

  • The drop tank decouplers actually decouple the drop tanks only if the tanks are attached to the nodes. If the tanks are surface-attached, nothing happens.
  • The Kickstand toggle, even if configured into a custom action group (e.g. group 1), seems to force-reconfigure itself to the landing gear button upon launch. Having the possibility to put it in a different group could be useful for flying craft which carry JetWings to be detached later.
  • The Decouple action can be fired again and again, even when the JetWing is not attached to anything, producing the decoupling sound and a puff of smoke. I suppose this is a side effect of how decouplers are implemented, given that in most other situations, decouplers end up on uncontrollable craft sections (and disappear from the staging diagram). I think I can see the intended use case here, though... reattach by magnet, and then fire decoupler again for the next flight?
  • As indeed suggested in the README, the drop tanks require a fuel balancer mod. I suppose KSP itself does not provide a way to make the drop tanks drain first, since they're on the side stacks, whereas the engines are part of the JetWing itself, on the center stack? (Short of having a smaller fuel line part just for this... and that wouldn't work with KAS.)
  • What is the Release button in the right-click menu supposed to do? Judging by the .cfg, it seems related to ModuleKISPartMount? I suppose it ejects all KIS drag'n'drop attached accessories?

Mod compatibility

  • KER seems to miscalculate the amount of monopropellant when cycling through the fuel setups, as if there was an extra 10 units of monopropellant somewhere on the craft. Tested with a simple craft with a Mk1 command pod, a stock girder, and a JetWing. (Yes, this is after accounting for the monopropellant in the Mk1 pod.)
  • Take Command: boarding JetWing at launch time causes a misaligned navball. The "nose marker" points down (where the pilot looks) insted of forward (where the craft goes). This causes also control misalignment; the controls do the intuitive thing on the navball, so considering the mismatch, yaw and roll controls become swapped, and the roll directions flip. Boarding normally after launch with the stock mechanism, the navball is aligned correctly, so Take Command must do something differently.
  • TextureReplacer's helmet reflections seem incorrect; a sideways kerbal silhouette is always seen on the helmet when viewed from front. This does not occur with the stock EAS-1 external seat. Maybe something has a different transform?

 

Edited by Technologicat
results of testing the JetWing
Link to comment
Share on other sites
ComatoseJedi

ComatoseJedi

Posted
Posted (edited)

Has anyone ran into any problems with the big A1 Grizzly wheels losing shape when you use Vessel Viewer from IVA? 

A quicksave and quickload solves this problem. Nothing to see here, move along. These are not the droids you are looking for. 

Edited by ComatoseJedi
Link to comment
Share on other sites
This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
 Share
Go to topic listing
×
×
  • Create New...