[1.12.x] IndicatorLights v1.8.3: Small, convenient, informative.

[Snark]

Hi gang,

I've released v1.2.10 of IndicatorLights.  The new feature is field@module syntax that allows targeting arbitrary fields on arbitrary PartModules-- any module, even if it's not an IndicatorLight one.

A quick FAQ about it:

• Q:  How does this affect me as a player?
• A:  It doesn't, not directly.  It's adding support for modders rather than players.
• Q:  Okay, so how does this affect me as a player who likes to use mods?
• A:  It means it's easier for people to enable more mods to work with IndicatorLights, if they are so inclined. 
• Q:  I'm a modder.  What can I do with the new syntax?
• A:  Target arbitrary fields on arbitrary modules.  For example, suppose you wanted to have an indicator on a wheel that says whether the motor is enabled or not.  You could have motorEnabled@ModuleWheelMotor in your syntax.
• Q:  So why's that such a big deal?  There were plenty of IndicatorLights controllers already.
• A:  Previously, it was impossible to have IndicatorLights interact programmatically with any module or field that Snark hadn't happened to get around to writing a specific controller for.  So, for example, there's not currently any built-in IndicatorLights support for ModuleWheelMotor (or any of the other wheel modules).  Until this syntax came around, it would have been impossible for you to add an indicator to a wheel that would show the wheel's state.  Now you can.  Also, it works with other mods, too-- so if another mod implements some custom PartModule, it's possible to add IndicatorLights config to work with that module's fields.
• Q:  Okay, so how would I actually wire this in to my mod's config?
• A:  Here's a working example.  Also, I've updated the wiki pages for toggle syntax and scalar syntax.

Thanks to @DStaal for the inspiration for this feature!  He was asking about IL support for another mod's custom part behavior, and I realized that it wasn't possible... but could be made so. 

[steedcrugeon]

 @pizzaoverhead Take a look here ^

@Snark this is immensely useful, its ability to interact with custom PartModules is the real clincher here, can this be used to target specific parts of a vessel? or is it vessel generic? For instance (using your wheel examples) say I had a six wheeled vehicle spread over 3 mk1 cabins. If I stuck and indicator atop each cabin and a pair of wheels underneath, could I get the indicator to only look at the corresponding pair of wheels?

Ignore me @Snark, I found the answer on your Github syntax page. Still interesting things could been extracted from the source code...

Edited June 5, 2017 by steedcrugeon

[HiddenKnowledge]

I just wanted to say, the amount of support and continued development you're putting into this mod are astonishing!

This is the kind of thing I'd expect from an AAA title (and often don't even get!), not from a mod!

Thank you very much for this amazing mod and thank you for being so helpful to your fellow modders.

p.s. Do you accept donations?

[Snark]

2 hours ago, HiddenKnowledge said:

Thank you very much for this amazing mod and thank you for being so helpful to your fellow modders.

p.s. Do you accept donations?

Aw, shucks.    Thanks, I really appreciate it.

No, I'm not set up to take donations, but thank you very much for asking.    I write code for a living on my day job, so modding is what I do for funsies and prefer to maintain my "amateur status" here, as it were.  At the risk of sounding corny, hearing happy reactions like yours is all the payoff I need.

[Snark]

9 hours ago, steedcrugeon said:

can this be used to target specific parts of a vessel? or is it vessel generic? For instance (using your wheel examples) say I had a six wheeled vehicle spread over 3 mk1 cabins. If I stuck and indicator atop each cabin and a pair of wheels underneath, could I get the indicator to only look at the corresponding pair of wheels?

Ignore me @Snark, I found the answer on your Github syntax page. Still interesting things could been extracted from the source code...

Just for the edification of any other modders who might be reading this:  the answer to the crossed-out question above is, "no".  IndicatorLights generally treats things on a "part-atomic" basis:  that is, every indicator light addresses only the part that it lives on.  So, for example, if you wanted to make some sort of status indicator for a wheel, you can totally do that... if the indicator is on the wheel itself.  But you can't put an indicator on some other part, that shows the status of the wheel.

Why is it that way?  I could go into technical details, but the TL;DR is because it's really, really freaking hard.    Once you start adding code that looks across parts on the vessel, right away you make life enormously more complicated.  First, because the code is just really complex, owing to the dynamic nature of vessels (they can add/remove parts in flight, such as when they dock, or when a part gets destroyed).  Second, because it raises the specter of some seriously ugly performance issues, because ships can be huge (potentially thousands of parts).  There's a potential O(N²) complexity problem that could throw performance in the toilet.  The only way to avoid that would be to add still more layers of complexity (various caching schemes) to the IndicatorLights code.  Switching metaphors for a moment, it's just an enormous can of worms.

To take an example:  Right now the only code anywhere in IndicatorLights that involves any inter-part functionality is the science indicators:  they blink when there's science to be acquired, but not if you already have that science stored somewhere on the vessel.  I put that feature in there because it was vital, from the user's perspective (otherwise your instruments are blink-spamming you all the time, and it's merely annoying rather than useful or informative)... but holy freaking galoshes that was a pain in the posterior to implement.  Took me an entire week of tearing my hair out.

I do have in mind a potential future feature for some sort of cross-part indicators.  Imagine a standalone part, like the BL-01, that you can stick on anywhere, and which can provide some sort of status indication for another part (either just "the part you attach it to", or, more ambitiously, some way of specifying some other part on the craft).  However, if I ever do get around to doing that, it would be a huge chunk of work, which is why I haven't done it yet and probably won't be getting around to it soon.

[AR3S_TGL]

*Sees the name snark*

Oh my god. It's Black Mesa.

 

Edited June 6, 2017 by AmpsterMan
Resized image

[Snark]

On 6/5/2017 at 1:55 PM, AR3S_TGL said:

*Sees the name snark*

Oh my god. It's Black Mesa.

Alas, no.  Both the name "Snark" itself, and my usage of it as an online nickname, predate the existence of Valve by a fair number of years.  (Over a century, in the case of the former.  Rather less than that, for the latter.)

[Darth Jeb]

@Snark@Snark

I am going to make a lightsabre model. My idea is to make the blade (the glowing part) not as a cylinder but as a long octagonal/hexagonal prism. 

So, the question is how can I make the sides of the prism-shaped blade glow ?

[steedcrugeon]

2 hours ago, Darth Jeb said:

@Snark@Snark

I am going to make a lightsabre model. My idea is to make the blade (the glowing part) not as a cylinder but as a long octagonal/hexagonal prism. 

So, the question is how can I make the sides of the prism-shaped blade glow ?

if you are making the model yourself this is not to difficult. Ensure whatever part you want to glow is a separate object (in the model) from things that you don't want to glow. Ensure to remember the name of the object you wish to glow. if you look in the IndicatorLights patch for the JX2 mod you will see that all three models (which are all separate .mu) call to the same name of mesh. This is because @Snark suggested this would be cleaner/simple for config purposes. I was easy for me to re-name those meshes in Unity before 'exporting' to .mu and work perfectly for IndicatorLights.

When you UV map it set the texture colour to be quite dark (all my model meshes targeted to IndicatorLights are dark grey). Then when you get to Unity the object in your model that you want to glow set the shader to KSP/Emissive/Diffuse (do not use Emissive/Specular it does very weird things).

If you need any other pointers with getting emissive meshes to work in the model (or multiple emissive meshes - see SpaceDock mod indicator lights patches) just give me a shout.

[Bit Fiddler]

in the SXT mod there is an antenna with a retractable mast.  it is the "Communotron DTS-R4", would it be possible to put an indicator light on the tip of the extending part?  such that it will light up and act as a warning light to show where the antenna tip is when it is extended.

[Snark]

3 hours ago, Bit Fiddler said:

in the SXT mod there is an antenna with a retractable mast.  it is the "Communotron DTS-R4", would it be possible to put an indicator light on the tip of the extending part?  such that it will light up and act as a warning light to show where the antenna tip is when it is extended.

Not unless it's "built-in" to the model by the author, I believe.

Here's the deal:  For a part to be able to have an IndicatorLights light on it, it needs to happen one of two ways:

1. The part itself has a built-in mesh that IndicatorLights can work with.
2. A mesh can be added to the part, after the fact, by tacking one on via ModuleManager.

In the case of #1, the mesh can be anywhere on the part, including on an animated part that moves.  You can see an example of this in the JX2Antenna mod.  However, that only works because @steedcrugeon made a point of making the antenna models "IndicatorLights-compatible" by supplying a suitable mesh for the transmitter indicator.

However, in the case of tacking on an additional mesh via ModuleManager, such as what I've done with the stock antennas, then the added mesh can't move.  It's not part of the built-in animation of the part, so it just stays put.  This is kind of unfortunate, but there it is.  For example, look at what I did when I added the meshes to the stock Communotron-16 and HG-5 antennas.  Both of those antennas are animated deployable antennas.  For both of them, the place I would have liked to put the mesh would have been on the deployable tip.  But since I couldn't make it move, I had to settle for putting the IndicatorLights mesh on the stationary base of the antenna, instead.

So, I believe the only way you could get the effect you're looking for would be if the SXT author chose to include a mesh on the part to make it IndicatorLights-compatible, which I'm guessing he hasn't done.  (If he, or any mod author, is interested in makign their mods IL-compatible, I'm happy to chat with whoever's interested about what the technical requirements to do so would be.  It's pretty simple.)

You could always ask the SXT author, but if you do, be sure to ask nicely and please don't pester-- I have no idea whether he'd be interested in this at all, nor is there any reason he particularly should be unless he just happens to find the idea cool.

Other than that, though, I think you're out of luck.  You could easily add an IL mesh to give a transmission indicator to the antenna, but you'd have to put it somewhere stationary on the antenna that doesn't move.  If you're interested in doing that, please check over in the IndicatorLights Community Extensions thread.  That's where I maintain a list of community-supplied patches to make IL play nice with various other third-party mods.  Would love another contribution, if you're interested in supplying one. 

 

[Bit Fiddler]

ah well the SXT author is not really the author, he is just maintaining the mod after Lack stopped.  And he has said many times he has no modeling experience so there can be no hope there, but thanks for the reply.

[Snark]

Howdy folks,

I've released v1.2.11 of IndicatorLights.  This is a minor update that adds indicators to the SENTINEL Infrared Telescope, since that's part of the stock game now in KSP 1.3.

The telescope has two indicators:

• Science:  Little round indicator (green in the above screenshot).  This is the same type of indicator you're already used to seeing on all the other science instruments-- i.e. flashes at you when there's fresh science to be had.
• Activity:  A ring around the telescope lens, which slowly pulsates reddish-orange while the telescope is actively tracking.  When tracking isn't turned on, it's unlit.

Aside from adding indicators to the telescope, this release also updates to the latest ModuleManager version, 2.8.1 (was previously 2.8.0).

(Modder's note:  I'm actually kinda jazzed that I'm already reaping the benefit of the field@module syntax I added in 1.2.10.  Thanks to that feature, I was able to add the indicators to this telescope without needing to write a single line of code-- just needed a new config file, that was it.)

Enjoy!

[Bit Fiddler]

ok so a question.  how is emissive defined?  is it defined on the model specifically or with a texture set to a specific alpha or something?  as in to add emissive to part can this be done by editing the alpha on a texture like other games do?  or does it require some tag to be set on the model itself?

 

and secondly if I have a runway made up of tiles from a mod and wanted to add "animated" lights to it that would run in a "chase" down the runway is this possible just by adding the light part to the runway in the editor? or would the runway and all light parts need to be "welded" into a single part and then setup the light animation on that one part?

[steedcrugeon]

3 hours ago, Bit Fiddler said:

1) ok so a question.  how is emissive defined? 
2) is it defined on the model specifically or with a texture set to a specific alpha or something? 
3) as in to add emissive to part can this be done by editing the alpha on a texture like other games do? 
4) or does it require some tag to be set on the model itself?

I have reordered you quote to better answer this.

A1) An 'Emissive' in this context is a material assigned to a mesh, the material comprises a texture and a shader which is built in Unity. The shader used comes form the KSP PartTools asset bundle and the it is "KSP Emissive/Diffuse"

A2) It is defined in Unity, there are multiple ways to define which colour the emissive is when it comes out of Unity. The Alpha of a texture can change some of the appearance of the emissive but you don't have to have an Alpha mapped, it will just give a uniform colour and brightness across the emissive element.

A3) How IndicatorLights works is by overriding the original _EmissiveColor with that determined in the IndicatorLights config. The example below will help explain. Changing the colour/alpha on the original texture will NOT make it work with indicator lights. The mesh material you are targeting has to be KSP Emissive/Diffuse to begin with, otherwise the mesh will not have the _EmissiveColor property in its shader and IndicatorLights cannot target it.

A4) To my knowledge its not possible to change the shader of the material after it has been exported as a .mu [clarification needed from someone more, as it may be possible?] as such the attribute in the shader must be defined in Unity before it's 'wrtitten'.

3 hours ago, Bit Fiddler said:

and secondly if I have a runway made up of tiles from a mod and wanted to add "animated" lights to it that would run in a "chase" down the runway is this possible just by adding the light part to the runway in the editor? or would the runway and all light parts need to be "welded" into a single part and then setup the light animation on that one part?

In response to this question let me run you through how these 'running lights' on the MiniDock work, they are driven by IndicatorLights:

The above space dock uses multiple objects, which are animated, some with colliders, some without. none of these things interfere with how IndicatorLights work.

When IndicatorLights is not present then the blue strobing indicators appear as simple dark grey lugs, that are attached (parented) to the 'arms' that run along the bottom but are separate objects.

In order for them to work as they do they are separate objects from each other and more importantly separate materials (this bit is critical as they share a .mu and KSP cannot determine between the same material on the same .mu, if you use multiple models in the part config this Is not an issue). However because (unlike in blender) Unity can have multiple instance of the same component names, whilst they are separate objects they have similar mesh names. This is the Patch that's drives the effect seen above:

@PART[miniDock]:NEEDS[IndicatorLights] 
{ 
     	MODULE 
 	{ 
 		name = ModuleControllableEmissive 
 		target = ledLower 
 		emissiveName = dockingLEDs	 
	} 
	MODULE 
 	{ 
 		name = ModuleEmissiveArrayController 
 		emissiveName = dockingLEDs 
 		toggleID = ModuleToggleLED	 
 		activeColor = blink(#08E8DE, 200, $Off, 800, divide(index, 5)) 
 		inactiveColor = $Off 
 	} 
 	MODULE 
 	{ 
 		name = ModuleControllableEmissive 
 		target = ledLowerB 
 		emissiveName = dockingLEDs2	 
 	} 
 	MODULE 
 	{ 
 		name = ModuleEmissiveArrayController 
 		emissiveName = dockingLEDs2 
 		toggleID = ModuleToggleLED	 
 		activeColor = blink(#08E8DE, 200, $Off, 800, subtract(0.8, divide(index, 5))) 
 		inactiveColor = $Off 
 	} 
 	MODULE 
 	{ 
 		name = ModuleToggleLED 
 		status = false 
 	}	 
} 

From the above the arms on one side have a small emissive lug called "dockingLEDs" and on the other side they are called "dockingLEDs2". Now we couldn't have them all called "dockingLEDS" because the array controller fires each sequentially and the effect would leap frog from side to side.

Interestingly enough, and only found through trial and error, if the code was the same for both sides they do not run together. Instead one side ran a slight delay (one LED in fact) behind the other so when one running sequence was at the end, the other was at the start. Also worth noting is that when using the ModuleEmissiveArrayController, IndicatorLights will determine the direction in relation to the origin of the part, which means that the array for one side needed to be told to be negative and run in the other direction, to appear as though its mirroring its counterpart array on the opposite side. The 0.8 is used to offset the start of the sequence for one side.

Now, if you are still with me at this point good going, I will try to expand on the answer to 3);
you can see from the code that we are targeting the meshes named "dockingLEDS" and "dockingLEDS2". they both use ModuleToggleLED so despite being two separate controllable emissives the toggle in the part controls them as one.
In the ModuleEmissiveArrayController we actually define the colour we want to change on the targeted mesh. This is to say that for that mesh, we are changing the value of _EmissiveColor of the shader in that mesh's material. It is for this reason that each mesh must have its own material (if they are all on the dame .mu) because if all of the emissive shared a material then when one mesh was toggled, all the meshes that shard that material would change colour too. So for the running lights in the above config, if all the "dockingLEDs" used the same material, despite being separate objects in unity, when the LED was toggle on then all the lugs would appear to be constantly on, their would be no sequence.

To put this into terms you could use for the custom runway. If it were me and I was building this in Unity, I would added the 'LED's I wanted to use for my running lights over the original model. I would have all the objects on one side with the same name, than all the objects on the other side with a similar name. Each of the 'LED's gets its own material, a duplicate of the material is fine but it must have its own name (for instance runwayEmisMat1, runwayEmisMat2, etc.).
If you were trying to implement this through a patch alone, you could use the BL-001 model (.mu) to give you your 'LED's, then you wouldn't need to worry about Unity at all.

[Bit Fiddler]

ok so the emissive is a material defined in the .obj ( I assume unity imports an .obj any way) an the actual texture is not the important bit.  this makes sense, and means that basically after market adding of emissive is very unlikely.  and the bit with making the lights from separate parts is good news.  I was afraid I would have to weld it all together into a single part to make it work.  I guess I will press on with my runway as that example video is exactly the effect I was looking for.  just in a runway format.

[Snark]

9 hours ago, Bit Fiddler said:

ok so the emissive is a material defined in the .obj ( I assume unity imports an .obj any way) an the actual texture is not the important bit.  this makes sense, and means that basically after market adding of emissive is very unlikely.

Adding an emissive to the original model is going to be unlikely, unless the model just happens to have an emissive material sitting there that you can use.  Has to be in the model, a texture won't do the trick.  However, you can certainly add new meshes to the model of your own, like I do to the stock parts in IndicatorLights.  For example, if you look at the docking ports (to take just one example),

...none of those have emissive meshes on the original models.  I use .cfg files (via ModuleManager) to add new meshes to them, which I can control, and which I can put where I want.  So you can certainly do something like that.

9 hours ago, Bit Fiddler said:

and the bit with making the lights from separate parts is good news.

Yep.  You can certainly have lights that run in sequence (like lights that go one after another "running" down the runway), even on different parts.  @steedcrugeon's example doesn't quite apply, since he's on one part and therefore can use the ModuleEmissiveArrayController, which works in the context of a single part.  But you can get pretty much the same effect across multiple parts, it's just a bit more tedious to set up.  All you need to do is to give them a blinking animation, and use the "phase" control manually so that each successive light has a slightly different phase. 

[Bit Fiddler]

ah ok... that may work out.  I wanted it to be modular in the fact that I was not tied to a pre made part but could build runways and taxi ways etc. on the fly in the editor and place the lights along the edge to make markers and animate them to do the chase pattern like the example.   I will just have to look at it more and see what I come up with.  it is too bad KSP does not use the texture to control emissive like other games do.   it makes this sort of thing so much easier to just make a new texture and not have to deal with the underlying model.

 

[Snark]

13 hours ago, Bit Fiddler said:

I wanted it to be modular in the fact that I was not tied to a pre made part but could build runways and taxi ways etc. on the fly in the editor and place the lights along the edge to make markers and animate them to do the chase pattern like the example.

You can still do that, at least something approximately like that.  Other than adding lights to stock parts, IndicatorLights does include one new part of its own, the BL-01 Indicator Light.  It's a small round light that's radially attachable pretty much anywhere.  Here's one stuck to the side of a HECS probe core:

It has a lot of customizability-- you can control the color, you can make it blink, you can control the timing of the blink.  Also, there's an additional option not visible in the screenshot above (since it was added after that screenshot was taken), which is "phase".  That's the thing that lets you have them blink in sequence.  So if you wanted to, you could lay out a bunch of parts along a runway, and add BL-01 lights to them, and set the "phase" settings on the lights to make them blink in sequence.

13 hours ago, Bit Fiddler said:

it is too bad KSP does not use the texture to control emissive like other games do.   it makes this sort of thing so much easier to just make a new texture and not have to deal with the underlying model.

Well, it's not quite true that KSP doesn't use texture at all to control emissives.  The actual appearance of emissives on a KSP part comes from the combination of two things:  the material, and the emissive mask.  And the "mask" is, in fact, a texture.  Technobabble about this in spoiler section.

Spoiler

• Each mesh on a model is made out of a "material".  A material is a simple object with a set of properties, such as "which shader does it use" and what are the properties of that shader.  Note that a material has no texture per se; it's a homogeneous "stuff".
• For an object to have any emissive "glow" at all, it has to have a material that supports emissivity.  The "emissive color" on that material specifies how brightly it glows, and in what color.
• However, that alone doesn't control the appearance on-screen.  There's also an "emissive mask", which is a grayscale texture that "masks" the emissive color.  Think of it as "paint" of varying opacity that's covering up the glowing "stuff" that the object is made out of.  Where the mask is white, the underlying emissive color shines through 100%.  Where the mask is black, none of the emissive color shines through at all.  For gray values in between, the glow shines through partially.
• Example of this in use:  Engines glow when they get hot.  But they don't all shine a uniform "flat" color, right?  Parts of the engine bell glow more brightly than others.  They achieve this visual effect by having an emissive-mask color.  When the engine gets hot, the game cranks up the emissive color on the material, but it's brighter or darker on various pieces of the engine because of the emissive mask.
• Another example is where certain crewed parts, such as the Hitchhiker container, have light-up spots that turn on (e.g. around the crew hatch) when you activate the cabin lights.  They don't have to model that as a bunch of separate glowy meshes-- they can just make the whole part glow, except that most of it is masked out and you can't see any glow except in those spots where the emissive mask lets the glow peek through.
• IndicatorLights works purely by controlling the emissive color on the underlying material.  It doesn't do any animated changes to the emissive mask at all.  If the part happens to have an emissive mask, then IL will "work" with it, in the sense that the game will use the mask to affect how the emissive color (which IL is controlling) ends up shining through.  But IL itself is completely unaware of the emissive mask; it doesn't do anything with it.
• Therefore, any animation that you do with IL (such as lights blinking in sequence) is all done by having different meshes so that IL can animate their emissive colors.  That's not a limitation of the game, it's just how I happened to implement IndicatorLights.
• I don't actually use emissive masks in any of my own modeling work.  All of the meshes I've added to the stock parts (and on the BL-01 light) have very simple one-pixel emissive masks that are pure white.  Essentially, I'm just letting the naked material shine through; I don't get fancy with masks.
• I'm guessing (though I've never done this) that if you can animate a texture in Unity, you could therefore animate an emissive mask, and use that to create the visual effect of moving lights.  Even if that's possible, though, it has nothing to do with IndicatorLights, and you wouldn't have any particular reason to use IndicatorLights in that case.  (Unless you wanted to use IL as a sort of "master switch" for turning the lights on and off, or tying their control to something in-game.)

 

[steedcrugeon]

13 hours ago, Snark said:

I'm guessing (though I've never done this) that if you can animate a texture in Unity, you could therefore animate an emissive mask, and use that to create the visual effect of moving lights.  Even if that's possible, though, it has nothing to do with IndicatorLights, and you wouldn't have any particular reason to use IndicatorLights in that case.  (Unless you wanted to use IL as a sort of "master switch" for turning the lights on and off, or tying their control to something in-game.)

You can animate a texture or rather in this case the UV map which is where you'll have your 'Alpha' mask which is the layer for the texture that allows emissive colour to come through, although from experience I found this sort of thing harder to setup than to have simple emissive controllers.

[Bit Fiddler]

ah so the texture does indeed control the emissive at leas to some degree.  I still have to set up the material in the .obj file to be an emissive however? the emissive texture only controls how bright and the color of the emissive.  I am used to making parts for games that to make a part emissive I just make a texture with an alpha channel to control brightness and a diffuse texture to control color.  and indeed these are usually the same texture.  you just add alpha to your diffuse texture to make it all in one go.   I am just getting started in  making 3d assets for KSP so I still have not figured out all the unity import stuff yet.  but one day...  lol if I ever decide to put in the time I will get it all sorted out.

[Snark]

6 hours ago, Bit Fiddler said:

still have to set up the material in the .obj file to be an emissive however?

Yes.  Make sure that you use a shader that has an emissive component.  "Emissive diffuse" is a good shader to use.  Don't use "emissive specular" because the shiny reflection tends to drown out the emissive color and it's hard to see.  Don't use "unlit" (like the shader on the stock Z-100 battery's LED), because that's something different.

6 hours ago, Bit Fiddler said:

the emissive texture only controls how bright and the color of the emissive.

No.  The material controls the color and brightness.  The texture only masks which parts of the emissive material can shine through, and to what degree.  Think of the texture as being opaque paint applied to the surface of a glowing material, and you get the idea.

6 hours ago, Bit Fiddler said:

I am just getting started in  making 3d assets for KSP so I still have not figured out all the unity import stuff yet.

Still not completely clear to me if you're trying to do something with IndicatorLights in particular, or modeling in general.  If it's the latter, this thread probably isn't the best place for that, since this thread's about IndicatorLights specifically (and in any case I'm not an expert modeler; I'm a programmer, not an artist).    However, there's a forum specifically for the kind of stuff you're trying to learn, Modeling and Texturing Discussion.  Probably the best thing for you to do is to post your questions in your own thread over there-- that's exactly the forum where the experts hang out and can help you with any problems or questions you may have.

[Bit Fiddler]

ah doing both...   the lights on the runway are exactly this mod.    but since you were talking about the 3d models and how emissive works I was just asking some questions.   the modeling I am doing is for something completely different.  and in fact would have no emissive on it at all.

[The_Joe]

Hello, I love the idea of this mod!  Im having a conflict though, I was hoping you might be able to help.

I use "Seti Probe Parts" which features some stock parts scaled down, including a science jr.   This mod broke those items for some reason...?

[Snark]

7 hours ago, The_Joe said:

This mod broke those items for some reason...?

Define "break"?  Broken how, exactly?  Also, got a link for the mod you're using?