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

Elei-Mi-Shill 12:53, 2 August 2009

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.

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

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.

Elei-Mi-Shill 19:55, 2 August 2009

I don't quite understand how this is interesting. For me it is very clear that GetSelf returns 0 in an OnAdd block. I'll try to explain:

GetSelf returns a reference the script runs on. References exist only in the 3D game world. Nothing outside the 3D game world is a reference. So an inventory object, which the OnAdd block runs on, is not a reference. Calling GetSelf when the script is attached to an inventory object could generate an exception or return 0, null, none, etc. Exception handling isn't part of the scripting language so the last option is used. It returns 0 because there is no reference the script is currently running on. Just like GetContainer returns 0 when the script doesn't run on an inventory object, because it isn't currently inside any container.

The name of the function is perhaps a bit unfortunate, as one would expect it to return the form it is currently running on. It doesn't, it only returns the reference it is currently running on and none if there isn't any.

--Qazaaq 08:26, 3 August 2009 (EDT)

Well, it's interesting how the script mantain memory of himself regardless being linked to a 3D object or a list object as long as they are 2 distinct items (and works in distinct ways). So I'd say that the 3D object exists as individual even if it's in the list and stacked with similar objects. What I need to do now is to create the auto-repair function. Do you know of somebody who achieved this result without using RemoveItem/AddItem trick?

--Elei-Mi-Shill 0:47, 4 August 2009 (EDT)

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.

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

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

Elei-Mi-Shill 19:55, 2 August 2009

Event would better describe what it does, as opposed to how it's handled internally. However, changing the terminology now, after 3 years, would hurt more than it helps. Perhaps the explanation on the Begin page could be expanded though.

--Qazaaq 08:26, 3 August 2009 (EDT)

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.

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

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!

Elei-Mi-Shill 19:55, 2 August 2009

I guess you're correct here. You're the one using the Wiki and searching for information, so it should be optimized to meet your needs. Your frustration about the scripting language is understandable, and part of the fun for some. If you have any questions on how to accomplish things you should ask them at the Forums. There are a lot more people there and they're very helpful.

What you're trying to do is possible, but you'll have to keep an eye on what the caster's weapon hits, not whatever hits the victim. You could do this by adding a poison or an enchantment, or modifying on of those if it already exists.

--Qazaaq 08:26, 3 August 2009 (EDT)

I went for a poison that checks if the target hit has the targeting enchantment on hit. If it has then it kills the target, otherwise, the poison has no effect. But i had to create a bunch of things where, in other games, with 2 single lines I could have obtained that result in a more clean way. It pisses me.

I added signatures to the above discussion, to keep track of who said what.
--Qazaaq 08:26, 3 August 2009 (EDT)