Jump to content

[1.2.2] B9 Aerospace | Release 6.2.1 (Old Thread)


bac9

Recommended Posts

This mod pack...it...it is...awesome...:D

Just one thing. Even with KJR (Kerbal Joint Reinforcement) the radially attached parts are wobbling like whatnot...i am no modder, but i guess the joint for those tanks are too weak. :/

Link to comment
Share on other sites

Just one thing. Even with KJR (Kerbal Joint Reinforcement) the radially attached parts are wobbling like whatnot...i am no modder, but i guess the joint for those tanks are too weak. :/

You're gonna have to learn to strut, until 0.25 brings the new node system to all nodes, not just stack nodes of size > 1.

1. Place any part in the VAB or SPH whose nodes can be toggled on or off. Can be the root part of a craft or not, same things happen.

2. Upon placement, no errors are thrown.

3. Pick the part up, and do one of two things:

If its just B9, that's normal - NodeToggle currently spews a few harmless errors into log. It'll be fixed at some point, by the author, but has no effect on gameplay.

Link to comment
Share on other sites

Well, got my first ever spaceplane into orbit, never actually had one that made it more than 4000m up before something happened and it crashed. Loving the new MK2 pieces and the ability to have cargo bays and crew tanks hold fuel makes designing working SPs much easier!!!

Now to get all I need for the HX parts so I can build a super carrier!!!

Link to comment
Share on other sites

@Tav: i am strutting^^

just wanted to mention it. My actual carrier weighs in about 4k tons in 500 km orbit around kerbin...gotta refuel and dock the surface shuttles, though.

Thanks for your hard work, so darn epic :D

Link to comment
Share on other sites

I dont know if anyone else has has these issues but when using the B9 wheels on the runway, they have no friction what so ever so my plane slides a little on the runway with the brakes on and im able to turn the aircraft (with HL parts) on the spot almost due to the frictionless wheels. Once i get the engines on and im moving the aerodynamics keep it on course so its not a problem but still thought i'd mention it.

Link to comment
Share on other sites

I dont know if anyone else has has these issues but when using the B9 wheels on the runway, they have no friction what so ever so my plane slides a little on the runway with the brakes on and im able to turn the aircraft (with HL parts) on the spot almost due to the frictionless wheels. Once i get the engines on and im moving the aerodynamics keep it on course so its not a problem but still thought i'd mention it.

The B9 R5.0 wheels do not have the problem you are describing. With near 100% certainty, you have an inappropriate cfg file somewhere which was trying to fix the wobble issue which existed prior to final R5.0. Get rid of the old fixes, they don't work with the final release, and actually break things. The culprit is likely very inappropriate values for "sidewaysStiffness", which don't work with the other friction parameters in R5.0.

Link to comment
Share on other sites

The B9 R5.0 wheels do not have the problem you are describing. With near 100% certainty, you have an inappropriate cfg file somewhere which was trying to fix the wobble issue which existed prior to final R5.0. Get rid of the old fixes, they don't work with the final release, and actually break things. The culprit is likely very inappropriate values for "sidewaysStiffness", which don't work with the other friction parameters in R5.0.

This. Search for the B9GearFix.cfg in ur data.^^

almost forgotten: is it possible to get some decouplers in "WTF-Size"? :) I love staging, and as for know i am using docking ports + struts due to wobblyness, but its ... meh. :D

Edited by Tyren
Link to comment
Share on other sites

You're gonna have to learn to strut, until 0.25 brings the new node system to all nodes, not just stack nodes of size > 1.

If its just B9, that's normal - NodeToggle currently spews a few harmless errors into log. It'll be fixed at some point, by the author, but has no effect on gameplay.

Well.. I don't know for sure that it was causing the gradual slowdowns I was experiencing (looks like it was maybe one small factor among others), but it spawned thousands (possibly tens of thousands) of those errors over the course of building one ship! My logs became ... very large. Good to know though, I can add the DLL back! Huzzah.

Link to comment
Share on other sites

Completely didn't see this one coming. Many thanks :D

Ok, seems I was overexcited...

I am running pretty heavily modded game x64. Adding this causes game to crash when starting/loading a career game.

Sandbox works just fine. Shame.

Edited by Aedile
Link to comment
Share on other sites

Well, one thing to report at least. I am not positive, but I believe the errors I've been getting have to do specifically with parts whose nodes may be toggled on or off. Here's how I have been able to replicate the problem so far:

1. Place any part in the VAB or SPH whose nodes can be toggled on or off. Can be the root part of a craft or not, same things happen.

2. Upon placement, no errors are thrown.

3. Pick the part up, and do one of two things:

3.a. If it's the root, simply click to put the part back down, anywhere. Many "Input is null" errors thrown.

3.b. If it's not the root, place the part successfully in any configuration attached to another part - if it's set down and shaded red, meaning not placed successfully (or however you call it), errors won't occur.

Each time 3.a. or 3.b. happens, "Input is null" errors occur. The number of errors is equal to 2x the number of nodes that can be turned off or on.

Hope that's vaguely helpful.

EDIT: Also seems to occur when another part - possibly any part - is attached to one of the node-switching parts. Happened when I stuck a mechjeb box onto one of the 2x1 bays...

Also, I should clarify before, TweakScale does not correctly judge the mass of mesh-switching/mass-switching parts in real-time, but it may do that on reload, not sure. My ships seemed roughly as ludicrously massive as they ought to be, but that doesn't mean the masses were correct after reloading. In real-time, it does the same thing it does for tank-swapping parts: if you put the tank in or swap the mesh, THEN scale, the scaled values will appear correct. If you scale, THEN swap, it will revert to whatever the non-scaled mass or tank capacity is for whatever you just switched to.

EDIT AGAIN: This particular problem is not related to TweakScale; removed it and nothing changed. But it may be any of my other 9385492835 mods. Sigh.

Whats the output_log say?

Link to comment
Share on other sites

The hatch on the MK2 crew tank 2m always reports for me "Hatch is obstructed, can't exit". Maybe that's just the way it is for now?

Whops, Unity 4.3 was fighting me when I tried adding the window emissive, so I copied the part over into 4.2, somehow the airlocks and ladders had their part trigger layer removed in the process, was a quick fix:

https://www.dropbox.com/s/z1zxi8y864jl9v8/mk2cthatchfix.rar?dl=0

Just slot that into your gamedata folder and the hatches and ladders work as intended, I'm sorry about this.

Link to comment
Share on other sites

I know ATM can be used for .86 systems, but there's some reduction pack for this 5.0 version? Actually I had tried the OLD reduction pack, but still uses 2.3 Gb RAM.:(

ATM is superior to reduction packs, so no. Old pack wouldn't work since a lot of textures have been renamed or moved, you're more likely to add ram usage than reduce.

Link to comment
Share on other sites

I know ATM can be used for .86 systems, but there's some reduction pack for this 5.0 version? Actually I had tried the OLD reduction pack, but still uses 2.3 Gb RAM.:(

try the active texture management mod. i have a massive modded ksp (about 3,5k patches with module manager :D) and it works just fine. Not possible without that mod...^^

Link: http://forum.kerbalspaceprogram.com/threads/59005-0-24-Release-3-3-1-Active-Texture-Management-Save-RAM-without-reduction-packs!

but not the normal, the agressive version is better imho.

Link to comment
Share on other sites

I left a ship in orbit, saving and restarting the game and when I came back to it, all the action group switches in the cockpit were deactivated and I had to press the ones that used to be active twice in order to toggle the group again. Also, is it just me being stupid, or is there no way to get back out of VesselViewer menus on these MFDs?

My screens on IVA's dont work. It always says when I go to the launchpad "RasterPropMonitor: INITIALIZATION ERROR, CHECK CONFIGURATION" does anyone here know how to fix this?
Yes, you probably have an older MFD configuration lying around somewhere that doesn't work with the newest version of RasterPropMonitor. I had this problem recently with the modified Hyomoto MDF config I'm using, and could fix it by correcting the texture file paths used in its .cfg.
I know ATM can be used for .86 systems, but there's some reduction pack for this 5.0 version? Actually I had tried the OLD reduction pack, but still uses 2.3 Gb RAM.:(

ATM is superior to reduction packs, so no.

Can ATM reduce the sizes of textures coming from specific mods by individual factors each? I am currently very much pushing the RAM limits of my 32-bit install with both ATM and LOD in use, so that would be helpful to me.

Edited by Hurry, Starfish!
Link to comment
Share on other sites

I left a ship in orbit, saving and restarting the game and when I came back to it, all the action group switches in the cockpit were deactivated and I had to press the ones that used to be active twice in order to toggle the group again.

Good catch, spotted the cause, the animations are linked to pushing the button, not the state of the action group itself, fixed it.

Also, is it just me being stupid, or is there no way to get back out of VesselViewer menus on these MFDs?

Some menus that need a "back" button to get out of a selection inside need to make use of the "back" button and thus blocks that from general navigation, but the top and bottom menus still work.

Target menu also uses back, cameras uses back and home etc.

Link to comment
Share on other sites

Neither is better than the other, you're trading texture quality for RAM, aggressive looks very blurry to me, basic less so.

hmm with full res textures the difference is not that great...and its just a small trade off to getting a working KSP, or not^^

Link to comment
Share on other sites

ATM works a treat and the effect of the basic version on graphical fidelity is negligible.

its still too much for my game and i had to cherry pick the wanted parts :) no problem for me because i am not into space planes, but the HX fuselage is a godsend for large cruisers and stations. *looks at his 36.000 tons space station*

Link to comment
Share on other sites

This. Search for the B9GearFix.cfg in ur data.^^

almost forgotten: is it possible to get some decouplers in "WTF-Size"? :) I love staging, and as for know i am using docking ports + struts due to wobblyness, but its ... meh. :D

I have already removed the old files prior to installing the new update, still my planes slide with zero friction with and without the brakes enabled

Link to comment
Share on other sites

I have already removed the old files prior to installing the new update, still my planes slide with zero friction with and without the brakes enabled

If the B9 parts are all generally working ok apart from lack of wheel friction, your B9 install itself is probably ok. That said, there's almost certainly a cfg file somewhere inside GameData which is a ModuleManager patch attempting to fix the historical wobble issue with B9 HDG. You need to find that cfg file and remove/disable it. The file is most likely not inside GameData/B9_Aerospace. Most likely is GameData/*.cfg, but it really could be anywhere inside GameData.

One approach you could use to find the problem cfg and/or diagnose what's going on, is to start a fresh GameData directory, with just the Squad & NASAmission folders plus B9 and the various other bits supplied with B9. Test that, and hopefully your wheels should have reasonable friction. If all is good, add your other things back into GameData one at a time, until the problem returns.

Link to comment
Share on other sites

Hello Folks

I'm having some trouble running KSP with B9 v5. In both cases (32 and 64 bit), the game crashes once the load bar reaches the end. When I run the 32 bit version I get out of memory errors in the crash log looking like this:

[ ALLOC_PROFILER ] used: 67212B | peak: 0B | reserved: 8388608B 
Could not allocate memory: System out of memory!
Trying to allocate: 22369620B with 4 alignment. MemoryLabel: NewDelete
Allocation happend at: Line:0 in Overloaded New[]
Memory overview
[ ALLOC_DEFAULT ] used: 211268489B | peak: 0B | reserved: 223911216B
[ ALLOC_GFX ] used: 981242149B | peak: 0B | reserved: 1003576096B
[ ALLOC_CACHEOBJECTS ] used: 222792B | peak: 0B | reserved: 12582912B
[ ALLOC_TYPETREE ] used: 0B | peak: 0B | reserved: 0B
[ ALLOC_PROFILER ] used: 67212B | peak: 0B | reserved: 8388608B
Crash!!!

When I run KSP 64, there are no memory related errors in the output log however the game is still crashing. The last few lines of the log are:

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)
[ModuleManager] ModuleManager: 1164 patches applied, 91 hidden items
(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)
PartLoader: Compiling Part 'B9_Aerospace/Parts/Adapter_C125/part/B9_Adapter_C125'
(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)
EffectList: Created 11 effect types
(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)
Crash!!!

Any ideas how to resolve?

Thanks :)

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...