User talk:Elei-Mi-Shill

Questions

Please don't put questions on the article itself, put them on the Discussion page (see Discussion tab at the top). I moved (and answered) your question on the OnAdd page.
--Qazaaq 06:43, 2 August 2009 (EDT)

You misunderstood I think. It's not about the question itself, it's about the lack of infos in the page. When you use a Blocktype (it's better to call it EVENT), you should also say how some other functions works with it! In example getSelf (really usefull) and getContainer. And it's not an info to add in a discussion, but something worth putting in the main article!

For reference, do you know how much I struggled against the OnAdd BlockType (event) in order to get the scripted item reference? And still I have to use the OnActivate BlockType (event) 'cause I didn't find a solution iet

This is something that is much less related to blocktypes than you may think. How functions like GetSelf and GetContainer behave is entirely dependent on what type of form the script runs on. If it's a reference, GetSelf will return the reference it's currently running on. If it's an inventory object then GetContainer will return the reference that contains this inventory object. GetSelf will of course return nothing in this case, because the script doesn't run on a reference. This has little to do with the blocktypes, code in a GameMode block can run on a reference and on an inventory object; the response of these functions depends on which type of form the script is currently running.

It's interesting how the GetSelf funcion works in the OnActivate block and not in the OnAdd block. Nonetheless the worning is still issued, but it works.

It's true that some blocktypes only make sense on certain types of forms. Adding an OnEquip block to a Activator makes little sense, but if that makes you happy, go ahead. You can put a GetContainer call inside that OnEquip block and still no one will complain. But the code will never be run, because when the script is evaluated the form is never in a state of being equipped.

Also, I don't think events would be a better name. With an event you assume something happens, but a block(type) doesn't happen. It's a statement that describes the situation in which the code block is valid and should be executed. Just like an if-statement. The entire script is evaluated when an object is processed, but only the lines in the appropriate blocks are executed.

I can assure you that the "Event" is the correct term. In fact Event in OOP is called a block of code that is executed when something happens (a trigger for instance). And, just to say, the "OnEquip" blocktype is executed when somebody equips an item. So it works just like an event. The same goes for GameMode and MenuMode even if it's not as visible as for OnEquip and similar blocks

I think I understand what you mean, but this information should be available on the GetSelf and GetContainer pages, not on each blocktype page. I know exactly how those functions should behave, and as far as I'm concerned the function pages describe their behavior perfectly fine. If you disagree (I think you do) I ask you to make the changes you consider necessary. Assuming you now know everything you need to know.

I just think on how I browse the informations in search of what I need. In fact it should be put in both descriptions. Well, that is if the language was something serious and not that ****ty thing we all know. In fact I find frustrating that I can't know both who perfomed an action and the target of the action. I could do the example of a special spell that I created: you select a target and if you hit that target in a given arc of time, it's an istant kill (something like you hit the vital spot). I wasn't able to know if the caster of the spell was the one who hitted the target... rather frustrating! Not only that! It seems to me that that language has been created to make impossible even the simpliest tasks!

--Qazaaq 18:45, 2 August 2009 (EDT)