Nertea

[1.8.x] Near Future Technologies (1.8 updates November 6th)

Recommended Posts

@Frag2000 What you are asking for (fuel cell behavior), Nertea is likely not going to deliver. Nuclear reactors aren't fuel cells and in practice do not switch on and off so conveniently. Go full nuclear and send up nuclear fuel drums and a Whirljig Reprocessor or two (this part can recycle Enriched from Depleted Uranium).

Share this post


Link to post
Share on other sites

@Nertea Have you seen this thread, trying to develop a rotatable truss section for your octo-truss System, very much similar to the rotatable truss sections on the ISS?

Have you thought about implementing something like that with the Infernal Robotics plugin?

 

Share this post


Link to post
Share on other sites
On 2018. 01. 26. at 1:20 PM, Streetwind said:

@LEGIONBOSS - ist that with or without spacecraft in flight?

Can you give us detailed reproduction steps that reliably lead to you experiencing said issue in a clean 1.3.1 install with only NF Spacecraft and its dependencies present? (Please include even the really obvious steps.)

Weird, the clean install didn't do that. Must investigate further...

Share this post


Link to post
Share on other sites
5 hours ago, KSPanier said:

@Nertea Have you seen this thread, trying to develop a rotatable truss section for your octo-truss System, very much similar to the rotatable truss sections on the ISS?

Have you thought about implementing something like that with the Infernal Robotics plugin?

Check out SSTU which has an ISS solar truss that follows the sun on two axes like the ISS.

station_part3.jpg

Share this post


Link to post
Share on other sites
Just now, Jimbodiah said:

Check out SSTU which has an ISS solar truss that follows the sun on two axes like the ISS.

station_part3.jpg

Well, I hoped to attach radiators to the orthogonal side of the truss very much like it's done on the ISS.

Share this post


Link to post
Share on other sites

Unless that is part of the solar panels, it cannot be done in KSP. Check the "Part Idea" thread you posted :wink:

Share this post


Link to post
Share on other sites
6 minutes ago, Jimbodiah said:

Unless that is part of the solar panels, it cannot be done in KSP. Check the "Part Idea" thread you posted :wink:

Unless the part has the infernal robotics plugin, as far as I know, this is able to handle such kind of tasks.

Share this post


Link to post
Share on other sites

Would be very nice to use Tweakscale on the Near Future Launch Vehicles, specially in the 5m cargo bays and adapters.

I'm trying to write the patches, but I'm very confused. Someone has already write this patch or could help me with it?

I did that and it didn't work:
 

Spoiler

@PART[cargo-5-1]
{
    %MODULE[TweakScale]
    {
        type = stack
        defaultScale = 5.0
    }
}

@PART[cargo-5-2]
{
    %MODULE[TweakScale]
    {
        type = stack
        defaultScale = 5.0
    }
}

@PART[cargo-5-3]
{
    %MODULE[TweakScale]
    {
        type = stack
        defaultScale = 5.0
    }
}

@PART[cargo-5-4]
{
    %MODULE[TweakScale]
    {
        type = stack
        defaultScale = 5.0
    }
}

@PART[cargo-nose-5-1]
{
    %MODULE[TweakScale]
    {
        type = stack
        defaultScale = 5.0
    }
}

@PART[service-bay-5-1]
{
    %MODULE[TweakScale]
    {
        type = stack
        defaultScale = 5.0
    }
}

Thanks!!

Share this post


Link to post
Share on other sites
1 hour ago, KSPanier said:

Unless the part has the infernal robotics plugin, as far as I know, this is able to handle such kind of tasks.

That would make Infernal Robotics a hard dependency for NF Construction, and although I am not Nertea, I'm preeeeetty sure that is going to be a hard "no".

...Unless it was done via a MM patch that detects the optional presence of Infernal Robotics. But then the part would have to be useful even without IR present. Else there's be no reason to create and ship it, and you'd once again arrive at "no".

Ideally, one of the existing parts would qualify as being able to take on that functionality. If you can find such a part, try patching it with the required IR functionality. If you can make it work, you can submit the patch to Nertea's Github repository with a pull request, and there'll be a high chance that it will be included in future relases for everyone to enjoy.

If you cannot find an existing part that can be believably modified to support this, you're going to have to help us solve the riddle of coming up with a new part that still fills a useful role even without the IR functionality... and then convince Nertea to sit down and model it.

 

Edited by Streetwind

Share this post


Link to post
Share on other sites
43 minutes ago, kerbalfreak said:

I did that and it didn't work (...)

I don't know how TweakScale works, but I can give you a few pointers on Module Manager in general.

First, if you're going to make the same modification to multiple parts, you can group them together - via a list of part names, and/or by using a wildcard. For example, @PART[cargo-5-*,cargo-nose-5-1,service-bay-5-1] is useful in your case.

Second, make sure the patch doesn't trigger when it's not supposed to (i.e. when Tweakscale isn't present). Add :NEEDS[TweakScale] after the PART declaration.

Third, while it's usually not necessary, it's considered good style to declare the patch pass order. Specifically, for personal tweaks, it's convention to specify the last pass. So I recommend you add :FINAL after the NEEDS declaration. This also prevents other mods from overwriting your changes in a later pass. You can't always keep track of what everything does - I've seen mod installs with more than 10,000 patch applications during startup.

Fourth, if you're using the modify-or-create operator (%) on a node, it makes no logical sense to only have create statements inside that node. You might end up finding an existing node and then creating duplicate entries inside it if you do it this way. In such cases, make sure to apply the % operator to everything inside the node as well.

Finally, if you are creating a node that's supposed to be named, you actually need to name it. The square brackets are a search term that looks for the name field inside the node; they don't assign a name. If you were to write just MODULE[TweakScale], that would be invalid syntax. At best the square brackets would be ignored, at worst the patch would fail to fire (I've never actually tried it). You wrote %MODULE[TweakScale], and I think it will work here because you're searching for existing nodes before creating a new one; but it's still only a search term. This command should translate into: "look for a node of type MODULE that contains name = Tweakscale, and edit it. If you can't find one, create a new node of type MODULE." You'll notice that naming the new node TweakScale is not actually part of that. You have to do that yourself.

So, all in all - I have no idea if this works because I don't know anything about TweakScale, but I recommend trying this patch instead of what you wrote:

@PART[cargo-5-*,cargo-nose-5-1,service-bay-5-1]:NEEDS[TweakScale]:FINAL
{
    %MODULE[TweakScale]
    {
        %name = TweakScale
        %type = stack
        %defaultScale = 5.0
    }
}

 

If that doesn't work, then %MODULE[TweakScale] might also be invalid syntax after all. In that case, try the following variant that achieves the same goal by first deleting any existing TweakScale nodes and then creating a new one:

@PART[cargo-5-*,cargo-nose-5-1,service-bay-5-1]:NEEDS[TweakScale]:FINAL
{
    !MODULE[TweakScale] {}

    MODULE
    {
        name = TweakScale
        type = stack
        defaultScale = 5.0
    }
}

 

Edited by Streetwind

Share this post


Link to post
Share on other sites

did near future props receive an update at some point in the recent past?

Share this post


Link to post
Share on other sites
3 hours ago, Streetwind said:

I don't know how TweakScale works, but I can give you a few pointers on Module Manager in general.

First, if you're going to make the same modification to multiple parts, you can group them together - via a list of part names, and/or by using a wildcard. For example, @PART[cargo-5-*,cargo-nose-5-1,service-bay-5-1] is useful in your case.

Second, make sure the patch doesn't trigger when it's not supposed to (i.e. when Tweakscale isn't present). Add :NEEDS[TweakScale] after the PART declaration.

Third, while it's usually not necessary, it's considered good style to declare the patch pass order. Specifically, for personal tweaks, it's convention to specify the last pass. So I recommend you add :FINAL after the NEEDS declaration. This also prevents other mods from overwriting your changes in a later pass. You can't always keep track of what everything does - I've seen mod installs with more than 10,000 patch applications during startup.

Fourth, if you're using the modify-or-create operator (%) on a node, it makes no logical sense to only have create statements inside that node. You might end up finding an existing node and then creating duplicate entries inside it if you do it this way. In such cases, make sure to apply the % operator to everything inside the node as well.

Finally, if you are creating a node that's supposed to be named, you actually need to name it. The square brackets are a search term that looks for the name field inside the node; they don't assign a name. If you were to write just MODULE[TweakScale], that would be invalid syntax. At best the square brackets would be ignored, at worst the patch would fail to fire (I've never actually tried it). You wrote %MODULE[TweakScale], and I think it will work here because you're searching for existing nodes before creating a new one; but it's still only a search term. This command should translate into: "look for a node of type MODULE that contains name = Tweakscale, and edit it. If you can't find one, create a new node of type MODULE." You'll notice that naming the new node TweakScale is not actually part of that. You have to do that yourself.

So, all in all - I have no idea if this works because I don't know anything about TweakScale, but I recommend trying this patch instead of what you wrote:


@PART[cargo-5-*,cargo-nose-5-1,service-bay-5-1]:NEEDS[TweakScale]:FINAL
{
    %MODULE[TweakScale]
    {
        %name = TweakScale
        %type = stack
        %defaultScale = 5.0
    }
}

 

If that doesn't work, then %MODULE[TweakScale] might also be invalid syntax after all. In that case, try the following variant that achieves the same goal by first deleting any existing TweakScale nodes and then creating a new one:


@PART[cargo-5-*,cargo-nose-5-1,service-bay-5-1]:NEEDS[TweakScale]:FINAL
{
    !MODULE[TweakScale] {}

    MODULE
    {
        name = TweakScale
        type = stack
        defaultScale = 5.0
    }
}

 

The first one worked, many thanks!! I was seeing the files and couldn't understand why some had a "*" in the name, and others don't.

If I create other ones, only changing the names between the [ ], it should work, right?

Now I can prune all the bays and use only NFT, which has the best textures and models by far.

Fitted perfectly in my plane :)

4b0iqG0.png

kY1IY5r.png

Share this post


Link to post
Share on other sites
3 hours ago, RaiderMan said:

did near future props receive an update at some point in the recent past?

Yep, yesterday.  Can be found here on Nertea's Github.

Share this post


Link to post
Share on other sites
2 hours ago, kerbalfreak said:

If I create other ones, only changing the names between the [ ], it should work, right?

Yes, the basic structure should be identical for all such patches.

Share this post


Link to post
Share on other sites

So, a while ago I posted a message about stock monoprop tank and certain heavy  RCS thrusters wanting to be put together...

Here is a config that makes it happen.

Spoiler

// Combined 3-way heavy RCS module with integrated RCS tank.
// made by throwing together Stock Stratus-V RM Tank and Nertea's NFLV RQ-5x1 RCS Thrusters
PART
{
	name = rcs-heavy-3way-tank-1
	module = Part

  MODEL // base radial tank model
	{
		model = Squad/Parts/FuelTank/RCSTankRadial/model
		// this model has weird scalling
		scale = 0.8, 0.8, 0.8
	}
  MODEL // first thruster, bottom vertical
	{
		model = NearFutureLaunchVehicles/Parts/RCS/rcs-heavy-1way-1
	        position = 0, -0.21, 0
	        rotation = 0, -90, -90
	}
  MODEL // second thruster, left
	{
		model = NearFutureLaunchVehicles/Parts/RCS/rcs-heavy-1way-1
	        position = -0.135, 0, -0.135
	        rotation = -90, 135, 0
	}
  MODEL // third thruster, right
	{
		model = NearFutureLaunchVehicles/Parts/RCS/rcs-heavy-1way-1
	        position = 0.135, 0, -0.135
	        rotation = 90, 45, 0
	}

	scale = 1.0
	node_attach = 0.0, 0.0, 0.25, 0.0, 0.0, -1.0
	TechRequired = specializedControl
	entryCost = 3000
	cost = 2000
	category = Control
	subcategory = 0
	title = RQ-5x3T Heavy RCS Block
	manufacturer = #LOC_NFLaunchVehicles_manufacturer_post-kerbin_title
	description = The RQ series parts are heavy maneuvering thrusters for extra-large vessels. This model has 3 nozzles and an integrated RCS tank.
	attachRules = 0,1,0,0,1
	mass = 0.23
	dragModelType = default
	maximum_drag = 0.3
	minimum_drag = 0.3
	angularDrag = 2
	crashTolerance = 12
	maxTemp = 1500
//	PhysicsSignificance = 1
	bulkheadProfiles = srf
	tags = #LOC_NFLaunchVehicles_rcs-heavy-1way-1_tags  #autoLOC_500612 //#autoLOC_500612 = fuel fueltank mono propellant rcs

	RESOURCE
	{
		name = MonoPropellant
		amount = 60
		maxAmount = 60
	}

	EFFECTS
	{
		running
		{
			AUDIO_MULTI_POOL
			{
				channel = Ship
				transformName =thrustVector
				clip = sound_rocket_mini
				volume = 0.0 0.0
				volume = 0.1 0.0
				volume = 0.5 0.025
				volume = 1.0 0.1
				pitch = 0.0 0.75
				pitch = 1.0 1.5
				loop = true
			}
			MODEL_MULTI_PARTICLE
			{
				modelName = NearFutureLaunchVehicles/FX/rcs-mono-plume-large
				transformName = thrustVector
				emission = 0.0 0.0
				emission = 0.1 0.0
				emission = 1.0 1.0
				speed = 0.0 0.8
				speed = 1.0 1.0
				localRotation = -90, 0, 0
			}
		}
	}

	MODULE
	{
		name = ModuleRCSFX
		stagingEnabled = False
		thrusterTransformName = thrustVector
		thrusterPower = 4
		resourceName = MonoPropellant
		resourceFlowMode = STAGE_PRIORITY_FLOW
		runningEffectName = running
		atmosphereCurve
		{
			key = 0 240
			key = 1 100
			key = 4 0.001
		}
	}
}

 

g9ykgH0.png

Edited by Psycho_zs

Share this post


Link to post
Share on other sites
On 29/01/2018 at 5:49 PM, Stone Blue said:

lol... yes... YUGE update, with MUCH new stuff... to see eamples of a lot of it, see the SSPr release thread:
https://forum.kerbalspaceprogram.com/index.php?/topic/170211-131-stockalike-station-parts-redux-january-28th/

His repo shows 0.3.0 version.

On ckan shows 0.9.5 lol.

I am new with mod stuff. How can I install Netea's mod directly from github?

Share this post


Link to post
Share on other sites

You click the big green button then Download ZIP. You will then have to take a 25-question quiz that judges you even though it isn't alive.

@Apoc

Edited by DeltaDizzy

Share this post


Link to post
Share on other sites

Just a suggestion, is it possible and/or plausible to make it so that the un-retractable solar panels in NF Solar are manually retractable by Kerbonauts on EVA?

Share this post


Link to post
Share on other sites

That might be interesting, but I would likely have to do some plugin work there, not super keen on that. 

Edited by Nertea

Share this post


Link to post
Share on other sites

Hello,

I have a small question about the DecayingRTGs... Does it support the RTG of the Coatl Aerospace ProbesPlus ?

 

Thank you

Share this post


Link to post
Share on other sites

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.