nli2work

Transform is the most basic GameObject in Unity. it stores position, rotation, and scale information. All other behaviors are components added to a GameObjects. e.g. a GameObject with light component becomes a light/shadow casting object ; a GO with mesh filter and mesh renderer components become a visible 3d object; etc. a max dummy will become an empty Unity GameObject. but if you are place them as thrustTransforms or RCSThrusters, it's better to add them in Unity. Max and Unity has different orientation system and it can be a little confusing importing objects from Max to Unity

Glad to hear! I noticed you had some props from ALCOR in your screenshots. you wanna consider making separate Internal config using non-mod props, then using MM to configure the part to use the appropriate internal based on the Mods available. https://github.com/Mihara/RasterPropMonitor/wiki/Making-an-IVA-that-works-both-with-and-without-RasterPropMonitor apropos your IVA, you'd make one that :NEEDS[ASETProps] (or something to that effect, I'm not sure how Alexustas has the props organized) and maybe another one that :NEEDS[RasterPropMonitor] for an IVA that has MFDs and RPM functionalities; but not using ASETProps and a third using only stock, plus your own props if you included them.

Okay I see. thanks! I got a little optimization work to do.

Yeah, They'd be more useful with little more thrust. I deliberately erred on the low thrust side for fear of them being "OP!"

Ah okay, I think I'm starting to understand it now. the mesh that stick out are seen as flat discs against the forward direction and so generate extra drag. Adjusted the mesh, problem solved. one last thing regarding basic drag model... Surface Area is the area of entire part? or just the portion that faces airflow? Thanks very much!

yes the stack nodes are slightly inside the volume of the tanks on the Y. so if I understand what yous said correctly... This is something related to the location of the stack nodes? the stack nodes should be where the front/rear most vertices are? or just outside? the smaller tank is not being calculated as a part by itself, but as a part of another piece? the larger tank has the correct drag value? also re basicDragModel S = 20 //Surface Area ... localUpVector = 0,1,0 //a unit vector defining "up" for this part; 0,1,0 is standard for most stock-compliant parts localForwardVector = 1,0,0 //a unti vector defining "forward" for this part; 1,0,0 is standard for most stock-compliant parts For a non-wing part, a cylinder fuel tank for instance, S is surface area of the entire object? or just the area that deflects airflow (like the large flat area of wings)? Up and Forward Vectors are in X,Y,Z yes? so a part with the above values, it's localUpVector is Up in VAB; or Foward in SPH? and localForwardVector is toward the launchpad in VAB; Right in SPH? or is this only after Launch, where +X is East, +Y is radial out?

this is x86 BTW. both meshes are identical, 1800 vertices; 3024 triangles. Unity setups are identical. http://i.imgur.com/9aLBRx6.jpg config files are identical except for node locations and mass. http://i.imgur.com/C5vgfSg.jpg when setting up drag model, which pivot does FAR use? mesh object's pivot? or the root pivot of the part? Changing mesh object's orientation before export doesn't appear to make any difference. Is this because the part doesn't explicitly have a FAR drag model?

hey ferram4, I'm a little confused at the drag numbers on the tank part here. they are identical in terms of mesh objects, collision meshes, part modules, and stack nodes (1 front 1 back, both are used). only different in mass and length. short tank is 1/2 the length of the long one. but long tank's drag is 10 times the drag of the short one. changing their attach order doesn't change anything. what's happening? http://i.imgur.com/wT17sB5.jpg

it is already compatible with 0.25, http://snjo.github.io/

All I ask is good module documentation like Snjo or Mihara. nothing more frustrating than great plugins with next to no documentation.

try this, import the alcore mfd or JSI's example mfd into unity, them remove the prop script. then you can select the pieces of the prop and see some information about it ( but you can't see the hierarchy or edit the parts), check the shader used on the screen objects. The example MFD uses KSP/Emissive with a black texture. I'm betting the white texture is washing out the screen to 100% emissive, any additional emissive doesn't create any contrast and so nothing appears on the screen.

Ya got me there. I have no idea how it works. I find mechjeb's hover function more intuitive to use. for transition I use the basic versions that slowly rotate.

yea I just found it too. damn brackets

Aha! Thanks so much! a missing square bracket.

What does this error message mean? something wrong with the config itself (Syntax error, etc)? or something wrong with a part the config is modifying? [ModuleManager] ModuleManager: 837 patches applied, found 1 error 1 error in GameData/RetroFuture/Patches/RF_DRCPatch.cfg

yeah, I can't find anything specific in the logs. All I find is "1 error in RF_DRCPatch" if you see something that's little more informative please let me know.

it'd be either engineMount or engine engineRotation is just an animation clip I got rid of the NREs... VTOLrotator requires propellerAtmosphericNerf module. Try adding this to the part config; the deployAngles will take some trial and error. MODULE { name = FSVTOLrotator deployedAngle = 0 maxDownAngle = 0 stepAngle = 22.5 targetPartObject = engine availableAngles1 = 0, 45, 90 availableAngles2 = 0, 0, 0 startInverted = True steerDirection = -1 } MODULE { name = FSpropellerAtmosphericNerf disableAtmosphericNerf = true } MODULE { name = FScopterThrottle }

@ Mekan1k - I think that's a display thing with RCSBuild Aid. stock thrust indicator updates correctly in Editor; and flight behaviour indicates the thrust points move properly when the engine rotates. RE: small Probe Core, Will fix, somehow colliders got lost in the prefab. @ sebi.zzr - All true. I don't know how long it'll take for FSVTOLrotator configs though, its not documented. Only references I have are the B9 parts, and their config isn't commented either. I got nothing to go on to set up FSVTOLrotator. All I get is a ton of NullRefs. I can't even look at the FS module in MonoDevelop. personally I just use the stock animategeneric setup. ATM is processing all the textures from what I can tell in the logs, I'll create a config for ATM just in case.

well, not quite. IVA isn't rendered when you are outside unless you are using TransparentPod module. so faking collimated HUD could work if you place the HUD plane far ahead of the IVA and scale it up accordingly.

The probe has same IVA as mkX31. a remote cockpit as it were. unfortunately the way KSP treats it, it's not really remote. The Probe Control Room mod would be useful here. I should look into it. remove this part from RF_RPMPatch.cfg if you just want a simple probe core. @PART[rfProbeCoreSmall]:NEEDS[RasterPropMonitor] { CrewCapacity = 1 INTERNAL { name = UnIVA } MODULE { name = RasterPropMonitorComputer } }

Thanks! make sure you have 1.7.1c. Had a couple stupid mistakes I had to fix in quick succession make that 1.7.1d... yet anotehr dumb mistake.

so I made a new MM config ... MM says there's 1 error in the config; but when I search output_log for all instances related to the new config file; I don't see any error messages. any thing I can try to track this error down?

very cool!

optical infinity as in what... covering the entire game window? or just some projection on no apparent plane in space? the HUD is painted on a plane, you can place it anywhere, even outside the IVA; with or without the frame; transparent or opaque; it's just a matter of configuration and prop setup.

PART{} Modules don't work for PROP{}; or vice versa. far as I've seen, there aren't any stock PROP{} modules that call animations. it won't hurt to have animations in the PROP{}, you can easily configure an RPM version that runs the animation and a non-RPM version that's static.