[WIP] Nert's Dev Thread - Current: various updates

[Nertea]

Found one texturing issue to look at - this is the shortest Mk4 cargo bay (top-loading) piece:

https://dl.dropboxusercontent.com/u/59567837/Mk4_cargotexture.png

Second small thing - I think this is another seam issue, on the tail cargo ramp - it's kind of hard to see in the image, so I put red around it:

https://dl.dropboxusercontent.com/u/59567837/mk4_tailseam.png

If I could make a suggestion for a part sometime down the road, like 2.2 or 2.9 or whatever you want - it might be neat to have a fuel-tank like part that you could attach to the bottom of other Mk4 bits, especially the hollow stuff. Would make the floor thicker, effectively, and then you could surface attach stuff without having it clip through the floor. Green bit in the image is supposed to be a stack node, blue part is the cross-section of the piece, landing gear for example. Bonus: geometrically simple to model, hopefully simple to texture! Maybe they could be auxiliary tanks, or specialized tanks for LH or Argon or somethingorother.

https://dl.dropboxusercontent.com/u/59567837/mk4_suggestion.png

Another minor issue: the engine pods' attach node is flipped so that the parts' default orientation on surface attachment is inside the surface of the thing they're attached to rather than outside:

https://dl.dropboxusercontent.com/u/59567837/mk4_podinverted.png

Fixed the node, easy enough. Cargo bay though... well that's pretty weird. Looks like some kind of model export error. Many vertices are missing.

As to your idea, eh... I'll think about it? It's a problem that is i guess kinda in need of solution sometime.

[Captain Sierra]

TESTING REPORT:

Dudley:

Much improved. Using a similar plane to my previous tomfoolery, I was able to easily get up to 13,000 meters and cruise maintaining an 8* AoA. I was also able to break Mach at level flight below 9000 meters (though the fact I had 4 of them when 2 probably would have sufficed for most tasks definitely contributed).

Cargo Ramp:

The new sliding part and its folding 'finger' ramps do not have colliders on them. I assume you're aware of this and I'll reserve any official advice until we have a completed model for it. 45 seems to be the magic number for it using the 'large gear under blister' configuration many of us are. While the fingers are cool, I sense they may present a problem for vehicles with very low ground clearance. Anything that requires a 0 setting may get high-sided on that hinge. Memory serving, didnt the old cargo ramp extend perfectly straight (minus the main hinge on the door)? Actual testing will be required (I have not deployed rovers through it yet).

FAR Patch:

At least for me, the FAR patch was functioning even without the presence of FAR. Something was definitely screwy with my install in general with noticeable symptoms of messed up thermal sim so I will verify on my newly reinstalled version to be certain. If someone else can verify this, however, that'd be great.

Heavy SSTOs:

I ran into issues with take-off on heavy SSTOs. Often they'd have a hard time pulling up and thus pick up more speed on they runway than they needed to (often 200m/s+). The planes don't handle pitch-up maneuvers ASL at those speeds gracefully (and by not gracefully, I mean RUD-level ungraceful). This may be partially correctable by adjusting the node sizes (which are currently size 3) to 3.5 (since KSP does use that to some effect in joint strength calculations).

EDIT:

It appears I somehow messed up my install of Claw's Stock Bug Fix Modules which apparently did massive damage to KSP while it was running. Removing it has fixed the problem. Will probably reinstall later and try to deduce what I broke.

EDIT 2:

TESTING REPORT CONT.:

High Altitude Planes:

Did a high-alt supply/crew carrier designed to go anywhere on Kerbin, terrain providing for landing. It works quite well and can make it to the south pole, land, and return to KSC in under 40 minutes. For benchmark, thats less than 1/5th the time it took with my old Javelin science aircraft.

Cargo Practicality:

I'm about to begin construction on a Kerbin South Pole base partly as a shakedown for K&K base parts, and for Mk4 delivery planes (considering the use of IR here but IR and I have a bad history). I will definitely be showcasing that project.

Edited July 19, 2015 by Captain Sierra

[Nertea]

The colliders on the tail bay were accidentally set to trigger mode. Ooops. They are actually intended to fix the cargo ramp zero elevation thing. At zero elevation the bulge of the actual fuselage part causes difficulty getting onto the ramp. So hence the small pieces, which allow you to make a zero elevation ramp work.

[Captain Sierra]

The colliders on the tail bay were accidentally set to trigger mode. Ooops. They are actually intended to fix the cargo ramp zero elevation thing. At zero elevation the bulge of the actual fuselage part causes difficulty getting onto the ramp. So hence the small pieces, which allow you to make a zero elevation ramp work.

Once the colliders work, it appears to be viable. THe animation on it is slick too.

So far have yet to really play with the yellowjacket so I cant give feedback on VTOLs.

[Nertea]

New test release. Probably the last one!

Mostly looking for feedback on balance and performance.

Fixes:

• Added mostly completed IVA to the Mk4 crew compartment
  
• Fixed bypass doors on BROADSWORD opening for wrong engine mode
  
• Fixed attach node for dual and triple engine pods being inverted
  
• Fixed colliders for cargo tail door being incorrectly set as triggers
  
• Fixed cargo tail not shielding contents sometimes
  
• Fixed a smoothing error on the crew compartment
  
• Fixed messed up model export on short cargo bay
  
• Set all attach nodes for mk4 crossections to size 4
  
• Adjusted crash tolerances for most parts; will match mk3 set better now
  

Remaining issues:

• Advanced Shock Intake doesn't always animate correctly (can't really figure out when though, works most of the time)
  
• Cargo tail ramp can't alter its angle in the VAB yet
  

[Captain Sierra]

Thanks man, you're on fire.

Sorry for not calling out the bypass door thing earlier (I wasnt sure if that was intended or not though my physics brain was questioning).

THe shock cone animation seems to be occurring less, though I'll note that it is triggered more easily if it is closed when in a vacuum, or exposed to a vacuum and returned to atmo before reopening.

As for balance, outside of the Dudley everything has always felt good. The Arcadia feels great, and I havent tested the broadswords too rigorously. Dudley is in a good place now matching the performance of the stock jet quite well (though requiring less than you might immediately expect to achieve such performance, and thus overperforming the Wheasely often which is good).

I'll give the BROADSWORD a proper shakedown tomorrow.

[jonrd463]

Just wanted to give a quick "Thank you!" to you, Nertea. I'm giving SSTO's a rest for now, but as with .90, the Mark IV system works great for conventionally launched space shuttles. I'm in the middle of building out a station using nothing but shuttle-delivered modules. Here's a shot docking to the station after delivering and connecting the second module. Pay no mind to the weird wing textures. Wonkiness with symmetry and the B9 procedural wings. I decided to make both sides heat tiles.

[westy]

I love this mod development. The animations, textures, emmissives and features are fantastic! A well thought out mod, and not far from perfection.

I have encountered the following, apologies if previously reported or if they are my fault:

1. Asymmetric thrust generated from the 2m Turbojet, with the MkIV double ended piece. Port engine was kicking out twice as much thrust as Stbd from take off. This could be a user and symmetry error, but those engine effects are beautiful.

2. VTOL Engines are awesome, although possibly a little weak, as I was struggling to VTOL a Small MkIV with 4 of them .

Thanks Nertea! Amazing work.

[SmashBrown]

it all looks, soooo pretty!

[AccidentalDisassembly]

One more small issue - sorry! =(

The ends of the blisters/tanks on the shortest ventral cargo bay and the tail ramp are untextured on the default setting. LFO/LF etc. have textures.

Additionally - something odd happens with the tail ramp when reverting to launch. It can be reproduced:

1. Make a craft with tail ramp, attach arcadia jets via adapters (or whatever you want) to ramp's side blister stack nodes. Put on runway, take off.

2. Revert to launch - ramp is open now. When closed, jets think they are stowed so won't start, but are not stowed when ramp's open.

Edited July 20, 2015 by AccidentalDisassembly

[Captain Sierra]

Still in need of plenty of tuning . . .

(better ascent profile, more LF, less LFO, actual payload proofing, RCS?)

[SmashBrown]

Still in need of plenty of tuning . . .

(better ascent profile, more LF, less LFO, actual payload proofing, RCS?)

http://i.imgur.com/ASZGNqu.png

That is one beast of a plane! I hade mine set up with 2 broadswords on the back and then 6 scimitars under the wings attached to pods. Wings were similar except i used two shuttle fins on the back.

[Captain Sierra]

That is one beast of a plane! I hade mine set up with 2 broadswords on the back and then 6 scimitars under the wings attached to pods. Wings were similar except i used two shuttle fins on the back.

pics or no cookies.

[Yemo]

Great parts, looking forward to full release.

Report: The KE-90 Dudley attachment node seems to be too small for the diameter when compared with the other 2.5m engines.

[SmashBrown]

pics or no cookies.

I didn't take any

It also flipped out and the back engines flew off as i pitched up to hard once i went subsonic

[ozraven]

Nertea, I've been following the dev of Mark IV since the first go-round and this 2.0 reboot is even more amazing. Excellent work, I'm looking forward to rebuilding my Mark IV stuff with the new system.

I've found a side affect of the /MarkIVSystem/Patches/MkIVFAR.cfg patch, however. Due to the :FOR[FerramAerospaceResearch] pass specifier, this inadvertantly creates a FerramAerospaceResearch pass in ModuleManager, triggering other mods' :BEFORE[FerramAerospaceResearch] and :AFTER[FerramAerospaceResearch] patches. Environment's with FAR installed, this behavior is simply benign. However, in my case (and others?) it's causing an unfortunate interaction with B9 Procedural Parts:

This causes the B9 Procedural Parts control surfaces to stop working - their function can't be configured in the editor, because the FAR environment isn't installed and B9's own ModuleManager patch has mistakenly removed ModuleLiftingSurface.

Proposed Solution

Updating your MarkIVSystem/Patches/MkIVFAR.cfg to use :BEFORE[FerramAerospaceResearch] instead of :FOR[FerramAerospaceResearch] then it resolves the issue. I've tested this change on my own install, and if it saves you the time, here's my updated MkIVFar.cfg [Dropbox].

NullReferenceException: Object reference not set to an instance of an object
  at WingProcedural.WingProcedural.CalculateAerodynamicValues () [0x00000] in <filename unknown>:0
  at WingProcedural.WingProcedural+<updateAeroDelayed>d__11.MoveNext () [0x00000] in <filename unknown>:0

[ModuleManager] Applying node MarkIVSystem/Patches/MkIVFAR/@PART[mk4cockpit-1]:FOR[FerramAerospaceResearch] to MarkIVSystem/Parts/Pods/mk4cockpit-1/mk4cockpit-1/mk4cockpit-1
... <snip> ...
[ModuleManager] Applying node MarkIVSystem/Patches/MkIVFAR/@PART[mk4tail-2]:FOR[FerramAerospaceResearch] to MarkIVSystem/Parts/Fuselage/mk4tail-2/mk4tail-2
[ModuleManager] :AFTER[FERRAMAEROSPACERESEARCH] pass
[ModuleManager] Applying node B9_Aerospace/FARVoxPatch/@PART[B9_Aero_Wing_Procedural*]:AFTER[FerramAerospaceResearch] to B9_Aerospace/Parts/Aero_Wing_Procedural/wing_procedural_typeA/B9_Aero_Wing_Procedural_TypeA
[ModuleManager] Applying node B9_Aerospace/FARVoxPatch/@PART[B9_Aero_Wing_Procedural*]:AFTER[FerramAerospaceResearch] to B9_Aerospace/Parts/Aero_Wing_Procedural/wing_procedural_typeB/B9_Aero_Wing_Procedural_TypeB
[ModuleManager] Applying node B9_Aerospace/FARVoxPatch/@PART[B9_Aero_Wing_Procedural*]:AFTER[FerramAerospaceResearch] to B9_Aerospace/Parts/Aero_Wing_Procedural/wing_procedural_typeC/B9_Aero_Wing_Procedural_TypeC
[ModuleManager] Applying node B9_Aerospace/Patch/@PART[B9_Aero_Wing_Procedural_TypeB]:AFTER[FerramAerospaceResearch] to B9_Aerospace/Parts/Aero_Wing_Procedural/wing_procedural_typeB/B9_Aero_Wing_Procedural_TypeB

[blowfish]

That should be :NEEDS[FerramAerospaceResearch]

[ozraven]

That should be :NEEDS[FerramAerospaceResearch]

It already has :NEEDS[FerramAerospaceResearch], before the pass specifier.

[blowfish]

Right, then just delete the :FOR[FerramAerospaceResearch]. Also, NEAR is dead now so it's not necessary to include it in the patches.

[ozraven]

Right, then just delete the :FOR[FerramAerospaceResearch. Also, NEAR is dead now so it's not necessary to include it in the patches.

True, but an explicit pass specifier is suggested by the MM documentation; without one, it falls in the LEGACY pass.

[SmashBrown]

I can confirm that ozraven's .cfg has fixed the problem for myself. I was having the same issue.

[Captain Sierra]

Since on the topic of FAR, the patch is triggering even without the presence of FAR on my install. Can validate and repro on clean install.

[billkerbinsky]

I've found a side affect of the /MarkIVSystem/Patches/MkIVFAR.cfg patch, however. Due to the :FOR[FerramAerospaceResearch] pass specifier, this inadvertantly creates a FerramAerospaceResearch pass in ModuleManager, triggering other mods' :BEFORE[FerramAerospaceResearch] and :AFTER[FerramAerospaceResearch] patches. Environment's with FAR installed, this behavior is simply benign. However, in my case (and others?) it's causing an unfortunate interaction with B9 Procedural Parts:

This causes the B9 Procedural Parts control surfaces to stop working - their function can't be configured in the editor, because the FAR environment isn't installed and B9's own ModuleManager patch has mistakenly removed ModuleLiftingSurface.

I saw this over the weekend but was wrestling with a few other mods at the time and didn't have enough evidence for an unambiguous bug report. One of the other symptoms I noticed was failure of the procedural wings to affect the center of lift in the VAB (and total failure of the wings to provide lift in flight). Noticed exceptions in Player.log mentioning a missing ModuleLiftingSurface. The problem went away after I deleted MkIVFar.cfg (since I don't use FAR) but I made a few other changes at the time and so wasn't entirely sure it was MkIVFar.cfg.

[Streetwind]

True, but an explicit pass specifier is suggested by the MM documentation; without one, it falls in the LEGACY pass.

Yeah, but doesn't the NEEDS statement itself default to a certain pass? A huge amount of mods only ever call NEEDS and don't bother specifying a pass...

As for the issue with B9, that's probably a bug you should report to sarbian. By logic, a call of :FOR[ModName] should not even run if ModName is not present. You can bet that this would have created tons of problems long before the development of Nertea's MkIV system, so it may be unintended behavior introduced only recently in MM v2.6.6.

[Svm420]

By logic, a call of :FOR[ModName] should not even run if ModName is not present. You can bet that this would have created tons of problems long before the development of Nertea's MkIV system, so it may be unintended behavior introduced only recently in MM v2.6.6.

That is very wrong. :FOR[Foo] is for the mod Foo itself to use not outside mods they use :NEEDS[Foo] if you all are so bent on a pass name use :FOR[MK4]...