Can I Really Programmatically COPY a Function from One .lua File to Another?

[Bidmaron]

It sounds like it. I don’t think the super and self references are in scope inside a lua code file only in an interface xml file. That is, only within scripts attached to controls. I could be wrong, but I cannot imagine the complexity in the code interpreter to try and derive the self-super context in a code file that could be called from an unlimited number of contexts.
I think what you are saying is the best you can hope for.

[Nickademus]

I could have sworn I used self. in one of my lua files...

[Bidmaron]

I admit I could be wrong. Maybe MW will chime in here? Or Trenloe?

[Moon Wizard]

Theoretically, the window class merge code does the same super/self variables and layering. However, the assumption right now is that scripts used in window class merges will completely replace all functions, so it hasn't been tested.

Regards,
JPG

[Minty23185Fresh]

....... the assumption right now is that scripts used in window class merges will completely replace all functions, so it hasn't been tested.

Not to be argumentative, especially with the master, but isn't that what we did in post 11 of this thread. In that post we replace the setCategoryHeader() function with one defined in the windowclass .xml.

I have since reworked it. Instead of replacing a function I supplement them.

Here are the first 6 lines of the power_group_header windowclass in the rulesets\5E\campaign\record_power.xml file:

	<windowclass name="power_group_header">
		<margins control="0,0,0,5" />
		<script file="campaign/scripts/power_group.lua" />
		<sheetdata>
			<hsc name="group" />
			<hnc name="level" />

There are seven functions in the power_group.lua file.

And then here are a few lines from my extension where I "supplement" the script:

   <windowclass name="power_group_header" merge="join">
      <script merge="join">
         function setHeaderCategoryForPsionics(rGroup, sGroup, nLevel, sName)
            name.setValue(sName);
            level.setValue(nLevel);
            group.setValue(sGroup);
            setNode(rGroup.node);
         end
      </script>
   </windowclass>

I realize that since I don't work for SmiteWorks that this is "anecdotal", and so it hasn't been verified.
(Please believe me, I am okay with this, it seems only prudent.)
But it does seem to be working the way I wish, as supplementing the script rather than complete replacement.

[Minty23185Fresh]

I could have sworn I used self. in one of my lua files...

I too have used self/super within the .lua file referenced in windowclasses. To this point just to list elements within super while developing code, rather than actually manipulating them, but I hope to graduate to that level of expertise.

[Bidmaron]

I don’t think you can use self and super in lua files not associated with controls. That is if you call a manager you create (e.g. MyManager.myRoutine) you cannot use self and super in that file. The lua has to be tied to a control, either as a script or referenced in a control. It is just like if you invoke a function in a different lua file you cannot get to locals declared in that lua file from where you invoked it. But I could be wrong....

[Minty23185Fresh]

I don’t think you can use self and super in lua files not associated with controls.....

I would completely agree. They would lack the layering context. It was easy enough to test too.

I was using some tiny "manager" scripts to try to derive a methodology for true function copying. That's what originally spawned this thread. I put some selfs and supers in the start up manager and in the managers called by managers. All selfs and supers were nil.

Not an unequivocal confirmation, but sufficient enough for me.

[Bidmaron]

Great. The world makes sense again. Good work!

[Minty23185Fresh]

... the assumption right now is that scripts used in window class merges will completely replace all functions, so it hasn't been tested.

Not to be argumentative, especially with the master, but isn't that what we did in post 11 ...

Never argue with the master! I believe I should recant. We didn't replace the function as we do in global, "manager type" scripts. We supplemented.

In both cases I mentioned above, the new script resides in the extension layer. If I were to iterate through the elements ("variables") of the extension the "replacement" function would be there and the "replaced" function would still exist in the ruleset layer. (That's what all my complaining was about in the other thread.)

You can teach me new tricks, it just takes a lot time for stuff to sink in.