[WIP] Nert's Dev Thread - Current: such nuke, wow

[Nertea]

On 2/3/2018 at 10:23 AM, Electrocutor said:

@Nertea If you're interested in nit-picking, I can help find small issues for polish.

 

I'm not, but you did lead me to this interesting fact: https://answers.unity.com/questions/34697/texture-alpha-channel-not-importing.html which is why you are seeing some of the problems you are. The rest aren't really things I care about a lot. 

[Electrocutor]

6 hours ago, Nertea said:

I'm not, but you did lead me to this interesting fact: https://answers.unity.com/questions/34697/texture-alpha-channel-not-importing.html which is why you are seeing some of the problems you are. The rest aren't really things I care about a lot. 

Will do; this is easy to adjust with multipliers as long as your original alpha gets loaded (thanks for the link by the way: didn't know this was a thing; I had thought that when you selected a shader that didn't have transparency, it would always just ignore it).

[RaiderMan]

the extendable clamp-o-tron...it doesnt have an attachment node at the business end like the original clamp-o-tron, making it difficult to mount vehicles that have this as their attachment method to any booster stack.

case in point, I tried to update the docking method used on the phoenix in the knes mod, and discovered I could not mount the booster because there's no attachment node on the extendable clamp o tron.

[DStaal]

2 minutes ago, RaiderMan said:

the extendable clamp-o-tron...it doesnt have an attachment node at the business end like the original clamp-o-tron, making it difficult to mount vehicles that have this as their attachment method to any booster stack.

case in point, I tried to update the docking method used on the phoenix in the knes mod, and discovered I could not mount the booster because there's no attachment node on the extendable clamp o tron.

I believe that's a mostly-unavoidable limitation in KSP.  The attachment node can't move when the part extends, so you'd have to define it either with the part retracted or with the part extended and have the attached part either clip or hang in mid-air.  I'm not sure if there are any good workarounds.

[Nertea]

7 hours ago, Electrocutor said:

Will do; this is easy to adjust with multipliers as long as your original alpha gets loaded (thanks for the link by the way: didn't know this was a thing; I had thought that when you selected a shader that didn't have transparency, it would always just ignore it).

It's a load issue - if a psd format file (what I load into Unity) has any transparency at all in it when flattened, Unity will ignore the explicit alpha and try to get the alpha from the flattened image's transparency. The textures you pointed out must have some tiny partially transparent pixel somewhere in them... it'll be resolved in the next release. 

 

1 hour ago, RaiderMan said:

the extendable clamp-o-tron...it doesnt have an attachment node at the business end like the original clamp-o-tron, making it difficult to mount vehicles that have this as their attachment method to any booster stack.

@DStaal is correct. 

[Wahgineer]

@Nertea is the download file supposed to be 258MB?

[Nertea]

Somewhere around there.

[RaiderMan]

there's a robot arm in knes that has a fixed attachment node thats only active when the arm is 'armed' so, are you 100% sure you cant work it similar? I'm just asking..cause the extendable clampotron is otherwise limited in that regard..

[DStaal]

38 minutes ago, RaiderMan said:

there's a robot arm in knes that has a fixed attachment node thats only active when the arm is 'armed' so, are you 100% sure you cant work it similar? I'm just asking..cause the extendable clampotron is otherwise limited in that regard..

Grapplers/claws can be only active when 'armed'.  Or Infernal Robotics can do it.  But not in the base game, as far as I know.  (Note the only extending part in the base game is the shielded clamp-o-tron - which also has no attachment node on the end, just the docking node.)

[The-Doctor]

Sorry if I came off as a bit of a jerk Nertia

[The-Doctor]

@Nertea truly sorry for coming off like a jerk

[dlrk]

Just wondering, is Far Future still in work?

[Nertea]

1 hour ago, dlrk said:

Just wondering, is Far Future still in work?

On hold until (I dearly hope) 1.4 fixes some of KSP's heat system bugs. 

[Finnyk]

so does FFT actually works in 1.3.1 ksp?

[Nertea]

Yeah generally.

[Finnyk]

On 16.02.2018 at 1:34 AM, Nertea said:

On hold until (I dearly hope) 1.4 fixes some of KSP's heat system bugs. 

what does that mean? is there something broken in FFT mod for 1.3.1?

[Krakatoa]

4 hours ago, Finnyk said:

what does that mean? is there something broken in FFT mod for 1.3.1?

FFT runs very hot, as a general rule, which means the current stock heat bug effectively turns FFT craft into time bombs. The mod works in 1.3.1, but because of that bug, you have to be super careful with time warp, as the engine heat will insta-allocate out to the whole craft, and there will be 'splosions.

[Finnyk]

what exactly parts do that?

[Nertea]

2 hours ago, Finnyk said:

what exactly parts do that?

Any part that has a high thermal energy content (mass*temp approximately). This can happen in stock too, but it's more common here as the very heavy FFT engines get high temperatures easily.

[Finnyk]

is it essential to use your heat control mod?

[TiktaalikDreaming]

4 hours ago, Finnyk said:

is it essential to use your heat control mod?

It doesn't matter. The averaging temperatures over the craft is stock behaviour during time warp.  Any mod with parts that run hot will cause explosions. I've had exactly the same thing without a single nertea mod installed (which is a tragic state for ksp to be in).

[Saltshaker]

(for FFT)

http://www.projectrho.com/public_html/rocket/enginelist.php#mif

EDIT: or is this the MPD-T already in NF Propulsion?

Edited February 23, 2018 by Saltshaker

[Finnyk]

is there an option to temporary lower heating of that partsin cfg, until 1.4?

[domassimo]

15 hours ago, Finnyk said:

is there an option to temporary lower heating of that partsin cfg, until 1.4?

I think that could work, there is a heatProduction value in the engine section of the config files. However, there may still be some heat unless you set it to 0 and with the high mass of engines, that equates to quite a bit of thermal energy. Another issue, if I'm not mistaken, is that radiator panels don't work very well in 1.3.1. Any thermal control system (thus, the ones that can cool any part anywhere on the ship) are not utilised well (or rather, parts demand more cooling than these should, rendering radiators ineffective). This means that even if your ship could deal with the heat, the second bug prevents the ship from actually doing so. Apparently, using only radiators panel that cool just nearby parts sidesteps that issue. The suitable stock radiator panels are too small to properly cool any FFT engine, but you could set a large panel from Heat Control to only cool nearby parts to help you get by until this bug is addressed.

[Jimbodiah]

WIP mod is WIP. Use at own risk.