[1.12.X] Feline Utility Rovers v1.3.4 (28. April 2022)

[Nils277]

@canisin Yes, to add the hover ability to the engines you only need to add the ModuleKerbetrotterEngine to it. 
As you discovered the capitalization of the transform for the thrust should also important (one thing i should definitely improve to be consitent at least for all engines of FUR)

The height transform (heightTransformName) can indeed be the thrust transform. I separated them for the controller because the thrust transform is also tilted via the ModuleKerbetrotterEngineControl Module  and therefore can change its orientation. The height transform will always look to the ground.
The fuel consumption is properly calculated by the engine itself. The ModuleKerbetrotterEngine only changes the throttle of the engine.

@Electrocutor

For now i have use the following material "names"

Base for the base material
Metal for the darker parts
Plate for everything that looks like a metal plate with structure
Handle for the door handles and hinges
Underbody for the lower darker material and footboards on the parts 
Lights for the lights
Plaque for the parts that change their appearance depending on the carried resource
Windows for all windows
(and some special ones that are specific to certain parts e.g. Rubber for the wheels or Shiny metal for the docking ports)

The normal maps won't be a problem, using a plugin for gimp to generate them from a "height map" of the textures works pretty well". In addition to the normal maps i also will take a look how much Ambien Occlusion maps can improve the visual appearance of the rover.
I'm afraid that i will not add different material settings for now. This will be a bit too much work at the moment.

Edited February 6, 2018 by Nils277

[canisin]

Quote

Yes, to add the hover ability to the engines you only need to add the ModuleKerbetrotterEngine to it. 
As you discovered the capitalization of the transform for the thrust should also important (one thing i should definitely improve to be consitent at least for all engines of FUR)

The height transform (heightTransformName) can indeed be the thrust transform. I separated them for the controller because the thrust transform is also tilted via the ModuleKerbetrotterEngineControl Module  and therefore can change its orientation. The height transform will always look to the ground.
The fuel consumption is properly calculated by the engine itself. The ModuleKerbetrotterEngine only changes the throttle of the engine.

What does the ModuleKerbetrotterEngineControl module do then? Is it the one that enables the hover engines to be stowed? And also as discuess does the direction / rotation of the transform really matter for the height calculation? The code seems to reference only its position.

[Nils277]

@canisin Currently the direction of the height transform is not important. In one of the previous versions the "Up" vector of the height transform was used to get the direction of the check but this is not the case anymore.

The ModuleKerbetrotterEngineControl enables the control of the hover engines (accelerating/deceleration, steering, breaking, and moving laterally). The ModuleKerbetrotterEngine only allows the engine to hover.

Edited February 6, 2018 by Nils277

[Electrocutor]

40 minutes ago, Nils277 said:

@canisin Yes, to add the hover ability to the engines you only need to add the ModuleKerbetrotterEngine to it. 
As you discovered the capitalization of the transform for the thrust should also important (one thing i should definitely improve to be consitent at least for all engines of FUR)

The height transform (heightTransformName) can indeed be the thrust transform. I separated them for the controller because the thrust transform is also tilted via the ModuleKerbetrotterEngineControl Module  and therefore can change its orientation. The height transform will always look to the ground.
The fuel consumption is properly calculated by the engine itself. The ModuleKerbetrotterEngine only changes the throttle of the engine.

@Electrocutor

For now i have use the following material "names"

Base for the base material
Metal for the darker parts
Plate for everything that looks like a metal plate with structure
Handle for the door handles and hinges
Underbody for the lower darker material and footboards on the parts 
Lights for the lights
Plaque for the parts that change their appearance depending on the carried resource
Windows for all windows
(and some special ones that are specific to certain parts e.g. Rubber for the wheels or Shiny metal for the docking ports)

The normal maps won't be a problem, using a plugin for gimp to generate them from a "height map" of the textures works pretty well". In addition to the normal maps i also will take a look how much Ambien Occlusion maps can improve the visual appearance of the rover.
I'm afraid that i will not add different material settings for now. This will be a bit too much work at the moment.

For simplistic options, you could simply allow the white-colored Base material to have color options for people, as this is very easy.

// Russian Green
PROPERTY {
	name = _Color
	color = 0.4,0.57,0.4,1.0
}

Since the base color is white or near-white in the diffuse, then the tinting from _Color is a direct color match. In the above example, you could also increase the actual numbers if it is too dark while maintaining the RGB ratio.

The reason it is easy is due to Module Manager allowing the copy command +KSP_TEXTURE_SET[original] so you only have to edit the name of the TextureSet and _Color for the mesh=Base part; everything else will be the same.

+KSP_TEXTURE_SET[FelineDefault] {
	@name = FelineRussian
	@title = Russian
	@TEXTURE:HAS[#mesh[Base]] {
		@PROPERTY[_Color] {
			@color = 0.4,0.57,0.4,1.0
		}
	}
}

Addendum:
While doing this, don't forget that the _Color has to be brightened to compensate for whatever _Metal value you have to prevent it from getting dark.

Edited February 6, 2018 by Electrocutor

[canisin]

1 hour ago, Nils277 said:

@canisin Currently the direction of the height transform is not important. In one of the previous versions the "Up" vector of the height transform was used to get the direction of the check but this is not the case anymore.

The ModuleKerbetrotterEngineControl enables the control of the hover engines (accelerating/deceleration, steering, breaking, and moving laterally). The ModuleKerbetrotterEngine only allows the engine to hover.

In that case, I guess I would need to add that as well to get full hover capability on other engines (I am imagining hovering on Minmus on spider or twitch engines :)), I would need to add this module as well, but it seems that would be a somewhat lost cause, as this module references one additional transform, a possibly hard coded reference, and an additional transform. I am still feeling that it would be possible, but I am not sure that I have enough time at my hands to figure it out.

But even only the hovering can be quite useful to get my hovering Minmus rover if I use RCS for translation

Thanks a lot!

Edited February 6, 2018 by canisin

[cowmoomoonoob]

I love this mod, but how do I disable the reflective windows? It's too laggy for my potato to run

[Sebra]

8 hours ago, Nils277 said:

• The hover engine now has two modes - "Hold Terrain Distance" and "Hold Altitude"
• Hover engines now use stock modules (allows compatibility with mods like TCA and MechJeb)

So your hover engines do not increase effectiveness near surface.

[Electrocutor]

2 hours ago, cowmoomoonoob said:

I love this mod, but how do I disable the reflective windows? It's too laggy for my potato to run

If you have reflective windows it is from TRR and Windowshine, not this.

[Nils277]

16 hours ago, cowmoomoonoob said:

I love this mod, but how do I disable the reflective windows? It's too laggy for my potato to run

Like @Electrocutor said, it is added by Windowshine. Either uninstall this Windoshine to remove all reflecitve windows  or delete the "GameData\KerbetrotterLtd\FelineUtilityRover\Patches\WindowShine.cfg" file to delete the reflective windows of FUR only.

14 hours ago, Sebra said:

So your hover engines do not increase effectiveness near surface.

No. They also never did this in the previous setup. I know i once considered adding this but the efford needed to do that would not be worth the benefit. Only very few would have recognized at all that this behaviour even exists.
I think the benefit from being able to use other mods to controll the engines (like MechJeb or TCA) is way higher  

[armegeddon]

On 2/6/2018 at 2:07 AM, Nils277 said:

Hover engines now use stock modules (allows compatibility with mods like TCA and MechJeb)

Unfortunately, this is is not accurate.  Attaching the side mounted hover engines cause TCA to spam NREs. 

Here is a log from a clean game with only FUR, TCA and their dependencies installed through CKAN. Went into the SPH, selected a Mk2 inline cockpit, attached the radial rocket engine to make sure TCA was working, which it was. Then removed the engine and attached the side mount hover engine and TCA never activated, and checking the log showed the start of NRE spam.

https://www.dropbox.com/s/lgkap27767pahum/output_log.txt?dl=0

[Nils277]

On 8.2.2018 at 7:18 PM, armegeddon said:

Unfortunately, this is is not accurate.  Attaching the side mounted hover engines cause TCA to spam NREs. 

Here is a log from a clean game with only FUR, TCA and their dependencies installed through CKAN. Went into the SPH, selected a Mk2 inline cockpit, attached the radial rocket engine to make sure TCA was working, which it was. Then removed the engine and attached the side mount hover engine and TCA never activated, and checking the log showed the start of NRE spam.

https://www.dropbox.com/s/lgkap27767pahum/output_log.txt?dl=0

Hmm, it worked like a charm in the tests before i made the release. Will take a look at what is causing the problem and fix this for the next release

[Starwaster]

Resilient little sucker...

[Derb]

 

Anyone else having a problem with flags and the off color of the truck cockpit?

[Nils277]

Update to 1.0.8 ~Throttling up~

Changelog:

Quote

Bug Fixes:

• Fixed compatibility with TCA
• Fixed log spam of hover engine
• Fixed flag and color of the truck cockpit

Download:

 

@Derb You are right, fixed in this version.

[MaximumThrust]

I noted a very small misalignment in that part in the roof fuel cell.

Would be nice if it, and the Science Jr., supported Indicator lights: 

 

[Nils277]

34 minutes ago, MaximumThrust said:

I noted a very small misalignment in that part in the roof fuel cell.

[SNIP]

Would be nice if it, and the Science Jr., supported Indicator lights: 

 

Huh, how could that have happened?  Will add it on the list of things to fix.

Will also take a look at indicator lights.

[Derb]

@Nils277  Thanks for the update, looks perfect now. I must say this is quickly becoming one of my favorite mods, along with KPBS.

I also found that the small fuel tank doesn't change its badging for different fuel types for me, and the thin one is badged as LF for EC. Sorry I didn't wrap that in one post, but I just noticed it.

 

 

[MaximumThrust]

If anyone wanted a reactor, the USI-Core has one that fit perfectly inside the small cargo bay. It produces 36 Ec/s, which is not too absurd for a Rover. It works with Near Future. The mod also have vacuum tanks that looks surprisingly good, better than any other mod I saw.

Don't forget to put the reactors as close as possible to the Kerbals, they really like the warm and how they glow.

 

23 hours ago, Nils277 said:

Huh, how could that have happened?  Will add it on the list of things to fix.

Will also take a look at indicator lights.

It's something very small, I used it a long time before noticing.

I'm also having a problem with the small tanks, the textures don't change when changing the tank type. But I'm using the last version with 1.3 KSP, could be that.

 

[Nils277]

@MaximumThrust Yep, this has been already reported in the post before yours. Will fix that in the upcoming version. 

[Apaseall]

Hi, I am a getting a bit of this:

Spoiler

PartLoader: Compiling Part 'KerbetrotterLtd/FelineUtilityRover/Parts/Coupling/ExtendibleDockingPort/Lynx_DockingBayPort'
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42)

Module ModuleDockingHatch threw during OnLoad: System.NullReferenceException: Object reference not set to an instance of an object
  at ConnectedLivingSpace.ModuleDockingHatch.IsRelatedDockingNode (.ModuleDockingNode dockNode) [0x00000] in <filename unknown>:0
  at ConnectedLivingSpace.ModuleDockingHatch.CheckModuleDockingNode () [0x00000] in <filename unknown>:0
  at ConnectedLivingSpace.ModuleDockingHatch.isInDockedState () [0x00000] in <filename unknown>:0
  at ConnectedLivingSpace.ModuleDockingHatch.OnLoad (.ConfigNode node) [0x00000] in <filename unknown>:0
  at PartModule.Load (.ConfigNode node) [0x00000] in <filename unknown>:0
 

Log: https://www.dropbox.com/s/0apsa8bxya1wjig/saves for FelineUtilityRover.1.output_log.txt?dl=0

[Nils277]

17 hours ago, Apaseall said:

Hi, I am a getting a bit of this:

  Hide contents

PartLoader: Compiling Part 'KerbetrotterLtd/FelineUtilityRover/Parts/Coupling/ExtendibleDockingPort/Lynx_DockingBayPort'
 
(Filename: C:/buildslave/unity/build/artifacts/generated/common/runtime/UnityEngineDebugBindings.gen.cpp Line: 42)

Module ModuleDockingHatch threw during OnLoad: System.NullReferenceException: Object reference not set to an instance of an object
  at ConnectedLivingSpace.ModuleDockingHatch.IsRelatedDockingNode (.ModuleDockingNode dockNode) [0x00000] in <filename unknown>:0
  at ConnectedLivingSpace.ModuleDockingHatch.CheckModuleDockingNode () [0x00000] in <filename unknown>:0
  at ConnectedLivingSpace.ModuleDockingHatch.isInDockedState () [0x00000] in <filename unknown>:0
  at ConnectedLivingSpace.ModuleDockingHatch.OnLoad (.ConfigNode node) [0x00000] in <filename unknown>:0
  at PartModule.Load (.ConfigNode node) [0x00000] in <filename unknown>:0
 

Log: https://www.dropbox.com/s/0apsa8bxya1wjig/saves for FelineUtilityRover.1.output_log.txt?dl=0

Seems to be a naming error i made in the CLS patch. Will take a look at it

[Apaseall]

@Nils277 Thanks for the reply, much appreciated. Every little helps as they say. I am trawling through the output log for some patch work I am doing to mess with some other mod and keeping down the errors is most helpful.

[MaximumThrust]

On 2/14/2018 at 8:12 AM, Nils277 said:

@MaximumThrust Yep, this has been already reported in the post before yours. Will fix that in the upcoming version. 

Please make that update compatible with 1.3.1  It's the only mod I'm waiting for an update, and don't plan to go to 1.4 anytime soon.

[Nils277]

On 7.3.2018 at 10:48 PM, MaximumThrust said:

Please make that update compatible with 1.3.1  It's the only mod I'm waiting for an update, and don't plan to go to 1.4 anytime soon.

Will wait until 1.4.1 and decide what to do once it is released. You can fix this bug pretty easy in your install yourself. Just open the file: GameData\KerbetrotterLtd\FelineUtilityRover\Parts\FuelTank\FuelTank_Small.cfg in any text editor and change line 74 from
transformName = Badge
to
transformName = Plaque

[Derb]

20 hours ago, Nils277 said:

Will wait until 1.4.1 and decide what to do once it is released. You can fix this bug pretty easy in your install yourself. Just open the file: GameData\KerbetrotterLtd\FelineUtilityRover\Parts\FuelTank\FuelTank_Small.cfg in any text editor and change line 74 from
transformName = Badge
to
transformName = Plaque

I've been trying to figure this one for ages! My fuel trucks thank you @Nils277!