[DS]

I'm just curious as to how you're planning on implementing the ability to make plugins using C++.

I'm already guessing they will compiled into a DLL or SO or some similar form in the end. And I'm assuming SourceMod will be modular as AMXX is to an extent with the different modules (core, engine, fun, regex, array, etc). And I'm sure many of the functions of AMXX will probably make their way to SourceMod. Obviously we can't be 100% sure as we don't have the SDK yet. But I think it's a pretty safe bet a lot of the stuff we can do with HL1 server side mods could be done with Source server side mods. So I'm guessing you may be planning similar modules.

But are C++ plugins going to importing functions from these [assumed] modules like a Windows application might use some functions from a DLL? Will the modules be exporting these functions like a DLL does? (I'm assuming these modules will compiled as DLL/SO)

...Or will these C++ plugins be more like modules in that they would use functions directly from the supposed source version of metamod?

Maybe my real question is more of how MetaEng is going to be working... As I believe you mentioned that it was responsible for allowing different languages to be used for scripting plugins. And I know you mentioned wrappers for the different languages as well, but I guess I'm still not quite grasping how all this is going to work.

I can understand if you don't to say much about MetaEng at this point. But I was just curious as I'm looking forward to coding plugins in C++ instead of Small.

[BAILOPAN]

MetaEng works by attaching interfaces to a central API. This API has functions like "LoadPlugin" and "ForwardCall", trivial things that are necessary for basic scripting functionality.

For example, the C++ "scripting engine" loads a plugin with LoadLibrary/dlopen. It hooks a call with GetProcAddress/dlsym. It gets function natives through a metaeng utility pointer.

You will see once I get a basic MetaEng structure in CVS, it's quite simple. The only complex part are the scripting engines, which themselves can get quite complicated.

One of the big obstacles I just solved was variadic calling (i.e. the opposite of va_arg, pushing variable numbers of arbitrary parameters). So you'll see that making C/C++ plugins will actually be quite simple (there will be a nice little SDK).

MetaEng has a central repository for a big function map, which includes native and forwarded functions (technically these are the same thing). Because of this, there is no distinction between modules and plugins. But I'll try to separate things for organization...

it's pretty complicated, I'm hoping it will work

[Kamikizzle]

hehe, sounds awesome! i can actually half-way script in C++....so maybe i'll finally be able to create plugins....;)

[imported_malex]

Now we just have to convince Bailopan to include perl support in the stock SourceMod distribution and we'll be all set. We also need SOAP or XMLRPC support in the stock distribution also, to have the plugins run on other machines. That would be pretty cool.

\malex\

[Geesu]

bah who uses perl =P J/K

C++ scripting is going to be sooooo sooo nice

[XxAvalanchexX]

I dunno, I kinda prefer SmallC to C++ for the simplicity.

[Dygear]

Pearl is mainly used for stutus, its one command, and an a simple output.
I really dont see how this could be used for plugin scripting.

[imported_malex]

Do you mean Small, the language used in AMX Mod X, AMXMod and Admin Mod? Small has no dynamically allocated variables, no structs, no pointers, and it smells funny. Adding something like perl would fix all those, and bring in a large existing base of modules for things like DB access and funky math functions and many other usefuls.

\malex\

[Dygear]

No I ment Pearl. I have only seen Pearl used for status scrips.

[BAILOPAN]

Perl is a very dynamic and powerful language.

Alas I don't know if I want to use it.