Topic: AGS Easy Plugin (v0.8a): Create a full engine plugin in one click-TESTERS NEEDED

[monkey_05_06]

Well the C++ classes themselves would be the backing data, so for a plugin I wouldn't even define those. I'd only define them if I was writing code using attributes in native AGScript (which I do all the time, all of my most recent modules rely on them). So in reality, I wouldn't expect to see those "extra" properties in the file being fed into your exporter (and wouldn't worry about handling it as a special case).

Edit: Hey, if nothing else this is a good place for me to dump some of the information I've learned about the engine's capabilities that 99% of other users know nothing about (and even CJ himself has been surprised by some of).

[Monsieur OUXX]

Hey, if nothing else this is a good place for me to dump some of the information I've learned about the engine's capabilities that 99% of other users know nothing about (and even CJ himself has been surprised by some of).

Yes, that's why I was trying to make you spit it out I've noticed you know all the tricks about AGS scripting language, that drive me crazy every time because I have to re-learn them by trial-and-error after each 6-months break in AGS programming, when I've forgotten it all.

What do you think about that "Create" thing? There can be a Create function only for the base class, so I'm not sure how to implement constructors for the children. I'll go with creating constructors with different names for each child class, but my senses tingle, there's got to be another way...

[monkey_05_06]

Well you actually got me really hoping that I would be able to override static methods, but no such luck. Because the original method would be static, but then the extender method overriding it would be non-static, you can't call it statically. Presumably if we had static extender methods then this would be possible.

By the way, in order for the polymorphic override to work (not just compile, but actually be called) it has to be in a separate script from where the original function definition is at (see, I learn new stuff all the time).

Having to cast the pointer (read as: call the AsXXX property) every time you create a member of a derived class seems ridiculous, but for now I can't think of a better way to get around this than simply having differently named constructors. Perhaps the exporter should (for the time being) generate constructors such as "Class.CreateClass" rather than just "Class.Create". It does seem redundant, but this is probably the best we've got (for now).

[Monsieur OUXX]

Perhaps the exporter should (for the time being) generate constructors such as "Class.CreateClass" rather than just "Class.Create". It does seem redundant, but this is probably the best we've got (for now).

Yes, that's the naming "convention" I was going to adopt in case I'm going that way.
Now I have to find the motivation to do all the scripts tests to be 200% sure of what works and what doesn't, regarding extenders overriding/overloading :-) :-( :-) :-(

 

[Monsieur OUXX]

Code: Adventure Game Studio

1. //Imagine this:
2. Point2D* p = Point3D.Create();
3. p.foo(66); //it calls the code of "float foo(this Point3D*, int newParam)"
4. p.foo(); // what happens? Was "Point2D::foo()" definitely overridden by the extender, even with this prototype, or only overloaded?
5.  
6. //if I declared "foo2(this Point3D*, int newParam)":
7. p.foo2(); //what would this do? Was "int foo2(this Point2D*)" only overloaded by "foo2(this Point3D*, int newParam)", or completely overridden?

Interesting points, I don't think I actually fully tested them, but my gut instinct would be that they have been completely overridden and the parameterless methods would in this case be inaccessible.
One note though, you cast the Point3D into a Point2D pointer. In AGS this means that the base class functions would be called, not the derived class functions (again, this is something that goes against true polymorphism, but CJ never intended this behavior to begin with ).

OK, part from the fact that this is giving me a headache, I just wanted to mention that I tested the code above (Not with a pointer obtained via Point3D.Create(), though, but instead with "Point3D p;" for the time being).
the Point2D versions of the functions are indeed entirely replaced. The AGS compiler forbids the call to "p.foo();" AND to "p.foo2();". In both cases, the parameter-less version is gone.

[monkey_05_06]

To be honest, that's exactly what I expected. I just wasn't sure that I had personally tested those specific cases.

[Monsieur OUXX]

One note though, you cast the Point3D into a Point2D pointer. In AGS this means that the base class functions would be called, not the derived class functions

I wonder what happens with this :

Code: Adventure Game Studio

1. Point2D* p2d = Point3D.Create();
2. Point3D* p3d = p2d;
3. p3d.foo();
4.  

It will call Point3D::foo() I suppose (I'll double-check later today). So, it always calls the function defined in the apparent type, doesn't it?

[monkey_05_06]

Code: Adventure Game Studio

1. Point2D* p2d = Point3D.Create();
2. Point3D* p3d = p2d;
3. p3d.foo();

That doesn't make any sense. The line:

Code: Adventure Game Studio

1. Point3D* p3d = p2d;

Is invalid. AGS doesn't allow casting to derived-type pointers. Hence the need for the AsPoint3D property (which for the record *I* suggested, in my original code snippet ). And yes, AGS always calls/links functions based on the calling ("apparent") type, not necessarily the underlying object type (which I have noted as a regression against true polymorphism, but, as I noted before, also provides the only way to call base class methods, at least until proper polymorphism can be implemented).

[Monsieur OUXX]

That doesn't make any sense. The line "Point3D* p3d = p2d;" is invalid because AGS doesn't allow casting to derived-type pointers. Hence the need for the AsPoint3D property.

Yeah, yeah, you got the idea; that was just a quick example of switching back to Point3D* to make the apparent type match the real type.