don't know what it is about papyrus, but for some reason, i just can't seem to get a hang of it - and for some other reason, i find it hard to really understand (beyond retyping what it says there) anything from the wiki - don't know what it is, never had any such problems with the geck-wiki...
anyhow, i hoped that, if i managed to piece together a few simpler scripts from scratch, i'd certainly get it all on the way, but that's only partly true -
good news is, got some working scripts. bad news is, don't have too much of an idea, _why_ they work.
i still just don't get large parts, mainly (but not only) of the whole properties-concept, so i hoped maybe some of you could light up a bit of my darkness.

for example, i got this basic light switch setup, a scripted activator with an enabling master as a linked ref.
i've added the script as a property to the activator in it's reference-tab (not to the base-object) - this was obviously necessary, because before that, it didn't work.
else, i tried to do the same like i would have in the old language: store the linked ref in a variable on load, enable/disable linked ref (via variable) on activate.

the script that does that goes like:

ObjectReference property objSelf auto hiddenObjectReference LightMasterEvent OnInit ()    LightMaster == GetLinkedRef ()EndEventEvent OnActivate (ObjectReference akActionRef)    if LightMaster.IsDisabled ()        LightMaster.Enable ()    else        LightMaster.Disable ()    endifEndEventObjectReference Property LightMaster  Auto

this works, like i said, it's just that any parts about properties are just trial-and-error-pieced-together bits & pieces from what i read in the wiki and various tutorials (thx 2 cipscis) without any real understanding of what i've been doing, still all confused about the properties-thing.

so, i understand i have to inform (=property) the script about any game objects it should affect, as well as any scripted object about it's script of course. fine.

confusion starts in the first line already: what's this objself property about? do i really need this in this case, or just if i want to do stuff with the scripted object itself (like disable etc)?

next, the ObjectReference LightMaster -part: i actually thought, this would create something similar to a reference variable in the old language, but only readable for this one instance of the script? (or does this whole internal-external-thing only go for numeric variables?)
but then, the "ObjectReference Property LightMaster Auto" line at the end suddenly was there when i reopened the script, i mean i've had _very_ long nights about this, but i swear i don't even remember having added this!?
but apart from giving me serious concerns about my mental state , i take from this, "LightMaster" (the linked reference) obviously _has_ to be a property and it's not enough to make it what i thought to be a "=ref-variable" and i can kick the "ObjectReference LightMaster" at the start, is that right?

another thing (non-properties) i don't quite get is, when it says
Event OnActivate (ObjectReference akActionRef), what's the "akActionRef" for (if, like here, i don't care who or what activates it)?
and what's, in this case, the "ObjectReference" good for if the whole script extends ObjectReference* already? -
this is generally a thing i find rather disturbing about papyrus, that you can't use every kind of block in every script -
i understand that it's kind of like a tree(?), like you can't, iirc, use OnInit in an Activator-type script, but you can in an ObjectReference-type script which is stg like "parent" to the activator-type, did i basically get that right?
so what i thought was, you'd use something like the "objectReference" in my line here if you wanted to use a block type in another than it's own "branch", so according to this, i thought "EventOnActivate ()" should do here, but it doesn't...?

i'd be happy about any help understanding this stuff (including links to any kind of "understanding properties for hopeless morons"-tutorials , got some heavier scripting than light switches ahead and i really dislike the idea of stumbling through (and bugfixing ) any more complex kind of script than this without really knowing what i'm actually doing

Think of a Property as a reference to an object outside the script. The script is your set of instructions. But that's all it has, instructions. In order to give an object the instruction, it has to be known by the script. That's where properties come in. It's your way of saying "Ok script I want you to activate an object. (add your property) and this is the object I want you to activate".

Without telling the script what the object is, the script doesn't know what to do.

The game sends events to different objects when things happen in the game. Any ObjectReference may get an OnActivate event, for example, but only Actors can get OnDeath events. And when an actor gets an OnDeath event, the game sends information about who the killer was in a parameter of the OnDeath event. So if you have a script extending an actor, you could put code in an event handler to say what to do when the OnDeath event is received:

Event OnDeath(Actor akKiller)    if (akKiller == Game.GetPlayer())        Debug.Trace("We were killed by the player!")    endIfendEvent

But there is no obligation on you to use the akKiller information, it's just there in case you want it. Same with the akActionRef parameter of OnActivate, which is just there to tell you which objectreference activated your object.

At the moment you have a Lightmaster variable which you try to fill in at runtime using code, and a Lightmaster property, which needs to be filled in the CK. Either technique is ok: you can think of properties as variables you set the value of at compile time. You create properties, and set their values, using the Properties button, which is enabled when you have a script selected somewhere (not within the script editor itself); you also use it to clear properties (it is important to clear them and compile, before deleting the line of code declaring them).