Then I used a xmarker and I linked it to the box
then I linked to the xmarker all braziers , ashes and lights and set all of those ( xmarkers only ) to initially disabled
et in the properteis the fade in and the player only but nothing ..
This may be a totally silly remark, and I apologize for it from the start, but if I take what you describe literally, I am compelled to ask: Did you add the xmarker to your lights as an enable parent or as a mere linked reference (as your post kind of implies)? The former should work better than the latter.
Also, if I were you, I would temporarily replace the xmarker with some simple visible object, like a standing stone or something, just to see if the triggering script works as intended, and once that is established, then proceed to get the lighting working.
P.S. I am also under the impression, that apart from fading not effecting lights, as suggested above, fading is not even passed through enable parent linkages for any kind of object. I agree that you may need to have each light individually managed by your script along the lines of what JustinOther described.
P.P.S. A couple of points on efficiency (to the best of my understanding, others might disgree):
1.
if (!PlayerOnly) || (triggerRef == Game.GetPlayer())
would be better than
if (triggerRef == Game.GetPlayer()) || (!PlayerOnly)
because the second test is skipped if the first one is enough, and Game.GetPlayer() is more resource demanding.
2.
If you refer to your set of lights in a script in some master object or whatever (like through an ObjectReference property or variable) those lights can easily become persistent in memory. Some people might argue that would be a needless use of resources, others might be indifferent. (It works the other way around If you set an enable parent in an object, as it references some master object, which alone needs to be persistent).
If I were you, I might consider adding to each light a script, that runs from when the cell is attached, and begins to periodically monitor the distance of the the player from some trigger point (or the enable state of an xmarker that uses your trigger script). When the player closes in on the trigger point (or the xmarker is enabled by your trigger script), the script launches the fade-on process and then shuts down. That should probably work without the lights having to become persistent.
I might actually try something like this on the lights (adapted from the script above by JustinOther), although I haven't tested it in practice
Spoiler ScriptName LightFadeOn extends ObjectReferenceObjectReference property EnableMaster auto{Monitored to initiate gradual switch-on}float property fMaxScale auto{Maximum extent of light}int property iSteps auto{Number of growth steps}; This should usually equal the number of frames used for transition, but that may not necessarily be an absolute truth.bool Lit = FalseEVENT OnCellAttach()if Lit returnendifSetScale(0.0)RegisterForSingleUpdate(1.0)endEVENTEVENT OnCellDetach()UnregisterForUpdate()endEVENTEVENT OnUpdate()if EnableMaster.IsDisabled() RegisterForSingleUpdate(2.0) returnendiffloat fDelta = fMaxScale / iStepsint iCounter = 0while iCounter < iSteps iCounter += 1 SetScale(fDelta * iCounter)endwhileLit = True ; allows the light to remain on once litendEVENT
» Fri Jan 11, 2013 6:54 am 
So yes, it works. It should work on any character that matches the list of races selected in the ArmorAddon.
