Tilion

Hey. Thanks for mentioning the issue. I found the problem and the fixed version should appear on the dev branch in the next update.

Hey, editor re-categorization has just recently started. It's ongoing and will be for several more days. The state you saw yesterday was the beginning; defining main categories for baseclasses. As we process all units, you will see the categories fracture into several smaller ones (like Men). More concrete information will appear in dev branch changelog once it starts resembling the final state. Feel free to post any feedback and ideas; just keep in mind that the state you see on dev branch now is not final.

Indeed. There is a whole set of scripts, all in that same location: // Taru without a pod Heli_Transport_04_basic_black.sqf Heli_Transport_04_basic_camo.sqf // Taru with bench pod Heli_Transport_04_bench_black.sqf Heli_Transport_04_bench_camo.sqf // Taru with fuel pod Heli_Transport_04_fuel_black.sqf Heli_Transport_04_fuel_camo.sqf // Taru with any other pod Heli_Transport_04_pods_black.sqf Heli_Transport_04_pods_camo.sqf // Standalone bench pod Pods_Heli_Transport_04_bench_black.sqf Pods_Heli_Transport_04_bench_camo.sqf // Standalone fuel pod Pods_Heli_Transport_04_fuel_black.sqf Pods_Heli_Transport_04_fuel_camo.sqf // Other standalone pods Pods_Heli_Transport_04_pods_black.sqf Pods_Heli_Transport_04_pods_camo.sqf The reason the black Taru variants are not in editor is that we didn't want to "overclutter" (that's a word, right? ;)) the Air category.

:couch:

The lights are on landing gear so they actually turn on only with gear down. Thanks for catching this one, I'll nag our artist about it :)

Hello, it should now be possible to configure custom blinking patterns. An example config: class MarkerLights { class PositionRed { ... blinking = true; blinkingPattern[] = {0.1, 0.9}; blinkingStartsOn = true; blinkingPatternGuarantee = true; }; }; blinkingPattern is an array of durations of flashes and pauses (or pauses and flashes when blinkingStartsOn = false;). blinkingPatternGuarantee is a little tricky. If you set durations in your pattern that are shorter than one frame, it could happen that that element of the pattern will get skipped. To prevent this, you can set this parameter to true, which enables detection of skipped elements and if it triggers, it steps back on the pattern's timeline to the skipped element. However, that means that you lose the guarantee of the pattern's period. So, long story short, blinkingPatternGuarantee affects only situations when you use very short durations in the pattern and/or your fps is very low. The default value is false for backwards compatibility, but generally speaking, you want it set to false only in situations when you want several synchronized markerLights, because then the possibly prolonged pattern periods could desync your markerLights.

As far as I know, this should be now fixed (in the development branch). So you can have destrType = "DestructNo"; and lights should still work if configured right.

The memory point you assign to position parameter is where the light source itself will be. The one you put to direction is the way your light will shine. The cone itself is set using innerAngle, outerAngle and coneFadeCoef.innerAngle sets the cone in which the light has it's full intensity. outerAngle sets the cone outside of which the light has zero intensity. coneFadeCoef is a coefficient that describes attenuation of the light between innerAngle and outerAngle. 1 equals linear attenuation, higher or lower value changes it, meaning how sharp/blurred will the edge of the lightcone as a whole be. Note that both the angles represent full angle of the cone, not just "angular offset" from direction of the light. If you set it to 90 degrees, it means the cone is 45 degrees to the "left" and 45 to the "right" of the direction specified by your memory points. In your case, having the direction memory point directly above the position means your light is pointed up in the sky. If you want an "all-direction" light, you might want to use MarkerLights instead of Reflectors (Reflectors are spotlights) that are configured somewhat similarly. 360-360 cones for reflectors can do it, though you may encounter some artifacts "behind the light" because as a spot light, reflectors are not made for cones above 180 degrees.Some time ago we made changes to the lighting system to allow for higher light variety during night time. One of the effects it had on configs of lights was that you need to set higher intensity than before the change to get the same results. About blinking: that parameter slipped into the config of reflectors due to copy-paste from MarkerLights. If you want to have blinking reflectors, you could probably do it by running a script to periodically setHit it form 0 to 1 and back (destroying the light and mending it again). But if you want to have a blinking all-direction light, I'd just use MarkerLights instead.

Eureka! :) It seems that destrType = "DestructNo"; causes lights to not function. I'll consult our programmers to see if there is a reason for this behavior or if it's a bug. You can hotfix it by deleting that line from your config - which means it will inherit destrType = "DestructDefault";

Sorry for the silence on my end. I've tried your config and it seems the solution is to boost up the intensity some more. I added two more zeros ( intensity = 1000000; ). Other than that, I only changed model, position and direction parameters (all just to fit the model I was testing it on). If you can't see the light even with the intensity changes, then my next hunch would be that selection names for the position and direction parameters don't match the names used in your model. Let me know if it still doesn't work, we can try figure out something else. :)

If you check the ingame config viewer, can you see the classes you've created?

I assume that your lights are part of the offroad model? If so than you want their configuration to be in config class of the car, not an object on it's own.Assuming you do want the lights to be a standalone object (eg. for testing purposes), you could try the following (please keep in mind I'm writing this from the top of my head, so there may be things I overlooked :) ): 1. I've highlighted in yellow parameters that you probably don't need to worry about while getting the lights to work at all (maybe except for vehicleClass, if you do want to have it in a specific category in editor). 2. Don't use class Thing as a parent, because that means you will inherit simulation=thing and that simulation doesn't support dynamic lights. Class Building has simulation=house and that simulation includes dynamic lights (eg. lighthouse or streetlamps). 3. Class Reflectors should be part of the object's definition; you had it outside of it because of the two }; just before it. 4. In terms of which parameters are needed for the light to work, try copypasting the lighthouse reflector ones (the code by Divinitize posted above) and just adjust the values for your model. If this still doesn't work, then there are two possible reasons. Either there is still something wrong about the config or the light is there but just too dim to be visible. Don't be afraid to overshoot the light intensity for testing purposes to confirm whether the lights are working or not. Check out configurations of some existing objects in the Config Viewer (accessed by the "Cog" button in ingame editor) for inspiration. If you have the lights as part of the offroad model, just put the class Reflectors into the config class of your car like this: [color=#7f00ff]class[/color] cfgVehicles { ... [color=#7f00ff]class[/color] MyOffroadCar: <parent class> { displayName = [color=#8f8f8f]"My Offroad"[/color]; model = ...; ... [color=#7f00ff]class[/color] Reflectors { ... }; }; }; You don't need to inherit class Reflectors from the parent class if you define all mandatory parameters. Good luck! <insert a disclaimer about the game still being in development and stuff possibly changing> :)

I have made some changes to the lighthouse model. You should now be able to use the following set of commands to control the lights in the top cabin: object setHit ["Light_1_hitpoint", 1]; object setHit ["Light_2_hitpoint", 1]; object setHit ["Light_3_hitpoint", 1]; object setHit ["Cabin_illumination_hitpoint", 1]; The first three lights are the reflectors illuminating outside terrain (numbered counterclockwise in top-down view). Each of these control given dynamic light, light shaft outside the cabin and a circular glow on the surface of the cabin windows. The fourth light (cabin illumination) controls the dynamic light that illuminates interior of the lighthouse cabin and emissive materials on the main lamp. In other words it doesn't represent a "standalone" light source; it has only a support role to achieve the overall visual impression. That means you will probably want to turn this one off when (and only when) all three of the reflectors are off as well. These changes should be now available on Steam in the Development build. I should note though that nothing is final and things may still change anytime before the release (eg. adjusting the amount of dynamic lights on lighthouse).