Jump to content

[Most 1.12.x] Near Future Technologies (August 26)


Nertea

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).

Link to comment
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...

Link to comment
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

Link to comment
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!!

Link to comment
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
Link to comment
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
Link to comment
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

Link to comment
Share on other sites

3 hours ago, RaiderMan said:

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

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/

Link to comment
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
Link to comment
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?

Link to comment
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.

×
×
  • Create New...