Halflife Admin Mod

I would vote for an XML style (there are some nice parsers we can use) 
as the default, with a DB option available if wanted. Using a DB to 
store config files is a nice way to manage data. There are even some 
db's designed to injest (and store smartley) XML formatted data, but I 
don't think we want to go that far...


Ravenous BugBlatter Beast wrote:
> Has anyone given any thought to the medium(s) in which Titan should 
> store its configuration settings and those for its plugins?
>  
> Obvious areas to consider are databases (mysql, others)?, flat files 
> (same style as HL cfg, windows ini format, xml)
>  
> Then there is the question of whether a server has its own private 
> configuration data store or if we should consider server farms were some 
> configuration is specific to individual servers and other configuration 
> is common accross the group.
>  
>

Alfred wrote:
>I would vote for an XML style (there are some nice parsers we can use) 
>as the default, with a DB option available if wanted. Using a DB to 
>store config files is a nice way to manage data. There are even some 
>db's designed to injest (and store smartley) XML formatted data, but I 
>don't think we want to go that far...
<snip> 

LOL Alfred, I've seen you keep pushing XML for a long time now.  Even before the Log standard.  I don't know what is typically required on Linux, but most win32 servers have XML parsers already installed.  So, XML would be a good choice.  It also allows for easier integration with websites or even across platforms.

As for the database option, this may be something best used as a plugin.  For example, you could have a MySQL plugin.  Now, we come to the question of whether to have a data abstraction plugin at the same level as the language interpreter.

HoundDawg

Alfred wrote:
>> am also maintaining Botman's monster DLL. All of this is at
>> http://www.ravenousbugblatterbeast.pwp.blueyonder.co.uk
>That has to one of the longest hostnames I have ever seen....
>
>Your not Welsh are you? (in case I am being too obtuse, the Welsh are 
>famous for extremely long names...)

You know, I never pay attention to these things until someone like Alfred makes a comment.  Then, I can't help but smile and laf. =)

HoundDawg

Will Day wrote:
>Hmm, so insteaad of:
>   smscript.amx <-> AMX plugin <-> titan core <-> ...
>
>it would be:
>   plugin.amx <-> AMX driver <-> titan core <-> ...
>   plugin.dll <-> C driver <-> titan core <-> ...

Would a language layer really be needed for high-level languages like C++?  I can see for compiled scripts like AMX, but I don't see why we need to have an extra layer for the others that could hook directly into the TITAN Core.

>In some ways, it seems like a difference of semantics and labels - whether
>a module that sits between script.amx and the Core is called a "Titan
>plugin" or a "language driver".
>
>That said, the whole idea of having "plugins to plugins" is a non-trivial
>source of confusion, and even a simple change in semantics could help
>alleviate that.  Plus, I think it does help conceptualize the
>modularization a bit better.  Also, it would probably provide a more
>standard and well-defined framework for adding additional language support,
>as language drivers could be considered to have certain requirements that
>"plugins" might not (expose the whole API, etc).

Yes, I think that it would be great if we all came up with a naming standard.  Often, within our CM and SM teams, we get hung up on whether something is considered a config, addon, plugin or script.

HoundDawg

"nick@..." wrote:
> 
> Yes, I think that it would be great if we all came up with a naming standard.  Often, within our CM and SM teams, we get hung up on whether something is considered a config, addon, plugin or script.

Did we have this discussion on the hlds_apps list? Can't remember. But
we started at AM to try and establish the term 'plugin' for MM plugins
and the term 'script' for Small scripts loaded by AM for this exact
reason.

On the subject of multiple languages and plugins to plugins to Titan
(what does Titan stand for btw?):

A language layer is probably a good idea so that we can support plugins
for Titan in more than one language. In the case of interpreted
languages this would include the interpreter.

But I don't think that not having "plugins for plugins for Titan" (let's
call them scripts for now) is an option. The reason for this is that
Titan should only provide an API which exposes hooks into and for the
game/MOD. Coding for this API is at a different level than writing
scripts for a plugin which takes care of the more troublesome things.
Hmm, doesn't get very clear, I think. Lets make an example.

Metamod exports the HL API on a C level. Plugins like AM or SM have to
be coded for this API. Sending a message to a client includes the whole
START_MESSAGE(), WRITE_BYTE(), END_MESSAGE() stuff. This is over the
head for a number of users. 
That is why Admin Mod provides a simpler function which takes care of
the internals of using the game API. Scripters can then code in a
simplified envirounment which already takes care of many things. 

I guess that the same would be true for Titan unless you want to include
such a simplified API as part of the Titan API. But I would feel that
that would overload the Titan API. You'll ever fight over where to stop.
Let's keep the Titan API simple and lean and let plugins to Titan take
care of providing a simplified coding envirounment.

Florian.

-- 
Want to produce professional emails and Usenet postings?
http://www.netmeister.org/news/learn2quote.html

>But I don't think that not having "plugins for plugins for Titan"
(let's call 
>them scripts for now) is an option. The reason for this is that Titan
should 
>only provide an API which exposes hooks into and for the game/MOD.
Coding for 
>this API is at a different level than writing scripts for a plugin
which takes 
>care of the more troublesome things. Hmm, doesn't get very clear, I
think. Lets 
>make an example.

>Metamod exports the HL API on a C level. Plugins like AM or SM have to
be coded 
>for this API. Sending a message to a client includes the whole
START_MESSAGE(),
>WRITE_BYTE(), END_MESSAGE() stuff. This is over the head for a number
of users. 
>That is why Admin Mod provides a simpler function which takes care of
the internals 
>of using the game API. Scripters can then code in a simplified
envirounment which 
>already takes care of many things. 

There are two distinct issues here:

1. Whether the small language interpreter layer provides a simpler API
to a small plugin than a C++ plugin would get from the C++ language
interpreter (maybe interpreter is the wrong word strictly but it saves
us from calling something else a module,API or plugin :)

2. The multiplicity - to we have many instances of the small
interepreter with 1 plugin each, or one instance with many plugins.

They are independent of each other - the small API could still be
simplified to a similar level as adminmod does whilst running each in a
separate instance of the small interpreter. Running multiple instances
is my preferred architecture so that it is not necessary to reimpliment
the plugin list configration / plugin management inside each language
interpreter and the titan core can see all of its plugins in a uniform
way.

As for the language interpreter for C++ plugins as Will says it wouldn't
do much - a bit of code to load the DLL containing the plugin, and
The ability to pass the interface pointers back and forth. However its
existence also removes the need to come up with a different terminology
for C++ "plugins" and small "plugins" as they are conceptually the same
thing. 

So our current class model in terms of the number of classes of each
type implemented:

Game <1==1> Game Driver <n==1> Titan Core <1=n> Language interpreter
<1=n> Plugin

And in terms of number of objects created at run time:

Game <1==1> Game Driver <1==1> Titan Core <1=n> Language interpreter
<1=1> Plugin

Ravenous Bugblatter Beast wrote:
<snip>
>So our current class model in terms of the number of classes of each
>type implemented:
>
>Game <1==1> Game Driver <n==1> Titan Core <1=n> Language interpreter
><1=n> Plugin
>
>And in terms of number of objects created at run time:
>
>Game <1==1> Game Driver <1==1> Titan Core <1=n> Language interpreter
><1=1> Plugin

How much additional overhead in resources are we looking at if we load a separate instance of the Language Interpreter per plugin?  Are we looking at running multi-threaded processes at the Titan Core level then?

HoundDawg

> How much additional overhead in resources are we looking at if we load a
separate instance of the Language Interpreter per plugin?  Are we looking at
running multi-threaded processes at the Titan Core level then?

On a generic level (i.e. ignoring specific languages), virtually zero. It
doesn't imply multiple threads.  It simply means the titan core creates more
than one instance of the interpreter class. Therefore any memory this class
uses for data members is duplicated.

Titan would load a language interpreter DLL the first time it finds a plugin
to be loaded written in that language.  It would then make a call to create
an instance of an interpreter and tell that instance to load a particular
plugin.  If it finds another plugin in that language it will make another
call to the DLL it has already loaded to create another interpreter object
and tell it to load the new plugin.

However if there is an overhead to creating interpreters for the language,
inside the DLL when the first call is made it may create a single instance
of a "real" internal interpreter class. What is presented to Titan as the
interpreter just an interface to the real interpreter which holds details of
which plugin it is the interface for.  When the 2nd interpreter is created
it can re-use the same "real" interpreter.

The important part is when treating the interpreter class as a black box, to
both titan and the plugin it should appear that the plugin has its own
interpreter - what goes on inside the box is the interpretor implementors
business and is unlikely to introduce any overhead,


----- Original Message -----
From: <hounddawg@...>
To: <halflifeadmin-titan@...>
Sent: Thursday, January 30, 2003 11:40 PM
Subject: RE: [Titan] Re: Language for Titan Plugins


> Ravenous Bugblatter Beast wrote:
> <snip>
> >So our current class model in terms of the number of classes of each
> >type implemented:
> >
> >Game <1==1> Game Driver <n==1> Titan Core <1=n> Language interpreter
> ><1=n> Plugin
> >
> >And in terms of number of objects created at run time:
> >
> >Game <1==1> Game Driver <1==1> Titan Core <1=n> Language interpreter
> ><1=1> Plugin
>
>
> HoundDawg
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Halflifeadmin-titan mailing list
> Halflifeadmin-titan@...
> https://lists.sourceforge.net/lists/listinfo/halflifeadmin-titan

<snip>
> The important part is when treating the interpreter class as a black box, to
> both titan and the plugin it should appear that the plugin has its own
> interpreter - what goes on inside the box is the interpretor implementors
> business and is unlikely to introduce any overhead,

You have hit the nail on the head. Its all about black boxes :) That way 
we can be flexible in the future.

This brings up the question of how to best get in as many people as possible
who need to read this as early as possible, without letting this list turn
into
something resembling the Steam list before new posts were locked.

My best suggestion currently is for each party in this discussion to post
news
on their respective sites, and then to filter the people who respond to that
post
into those who need to be here and those who don't. Anyone who doesn't have
the time to dredge through the responses can send them to:
info@...
or TiTan Feedback: http://forums.unitedadmins.com/index.php?s=&act=SF&f=109

In the early stages of conception and design, a large influx of
inexperienced
users could seriously damage this project, which can easily be avoided by
making sure that the people on the list need to be here.
I'm going to post regular updates with extracts from posts on this list in
the
TiTan forums, and vice versa if I see any good posts in the forums, the
discussion may be running in 2 places, but its better than it not happening
at all.

Vampire
UA PR Director

> Sounds like a reasonable plan of attack to me.
>
> One the API has been designed we can break out into smaller teams to
> handle the various parts.
>
> Before any serious work is done on the API design we need people from
> all corners of gaming to make sure we don't miss anything (i.e mod
> developers, 3rd party tools, plugins, engine developers if possible).
>
>

Will Day wrote:
>That would be neat, yes.  I'm not convinced that we can successfully
>generalize diverse engine API's into one common API.  One engine could
>offer functionality that another one doesn't, or on an entirely different
>level or depth, etc.  I haven't personally looked at the API's provided by
>other engines, but I didn't get the impression other (current) engines were
>quite as flexible or as open as Half-Life's.

I agree.  This is where we're going to need some good planning in this part.  I believe there will be a "common" general set that could be achieved across the board.  Still, some engines won't have support for that.  The TITAN Core will need to provide feedback to the plugins as to what the game supports or doesn't.  This could be handled in feature dependencies on behalf of the plugin requesting a required feature.  If that feature isn't available and is required, the plugin can disable itself after posting a warning/error message.  

The other idea is that features can originate from different places.  For example, some game engines identify each player with some unique ID (e.g. HL has the WONID).  Meanwhile, other game engines may not have this ability.  This could be supplied by a TITAN Plugin though.  So, the source of a feature may not necessarily come from the game engine directly.

Does this make sense?

HoundDawg

Lets go for the opengl model rather than the directx one, as a 
programmer I know which one is much easier to write for :)

OpenGL has a standard set of interfaces that all cards must support. If 
they don't do it in silicon then they emulate it in software (this is 
where the opengl miniport idea came from). This means as a graphics 
developer I have one consistant interface to work with.
DirectX has "capability sets" which tell you what features the card does 
(and does not) support. You quickly get spaghetti by trying to handle 
all the different situations.

So, my vote is for a constant API with someway for a plugin to give it 
minimum required capability set (some things can't be emulated) on 
startup and from then on things are constant.

<snip>
> 
> I agree.  This is where we're going to need some good planning in
> this part.  I believe there will be a "common" general set that could
> be achieved across the board.  Still, some engines won't have support
> for that.  The TITAN Core will need to provide feedback to the
> plugins as to what the game supports or doesn't.  This could be
> handled in feature dependencies on behalf of the plugin requesting a
> required feature.  If that feature isn't available and is required,
> the plugin can disable itself after posting a warning/error message.
> 
> 
> The other idea is that features can originate from different places.
> For example, some game engines identify each player with some unique
> ID (e.g. HL has the WONID).  Meanwhile, other game engines may not
> have this ability.  This could be supplied by a TITAN Plugin though.
> So, the source of a feature may not necessarily come from the game
> engine directly.
> 
> Does this make sense?
> 
> HoundDawg
> 
> 
> 
> ------------------------------------------------------- This SF.NET
> email is sponsored by: SourceForge Enterprise Edition + IBM +
> LinuxWorld = Something 2 See! http://www.vasoftware.com 
> _______________________________________________ Halflifeadmin-titan
> mailing list Halflifeadmin-titan@... 
> https://lists.sourceforge.net/lists/listinfo/halflifeadmin-titan

Will Day wrote:
>Okay, let me see if I'm following.  It sounds like the basic path is:
>
>   compiled plugin <-> titan core <-> game driver <-> game engine
>
>Where:
>
> - Compiled plugins are C,C++,Delphi,Java.
>
> - Titan core provides a generalized API to the compiled plugin, which
>   could encompass:
>
>    - Game-related hooks (HL's DLLAPI, NEWAPI), ie routines provided by the
>      plugin, and called by the game.
>
>    - Game-related functions (HL's EngineAPI), ie routines provided by the
>      game, and called by the plugin.
>
>    - Utility functions (motd?), routines provided by a plugin, and called
>      by another plugin.
>
> - Game driver translates the generalized API to the game-specific API.

Yes, this is pretty close.  I just didn't think about dividing up the TITAN Core with a Game Driver between it and the game engine.  I suppose it would make for re-useable sense.  Although, couldn't both be compiled into the TITAN Core, which would be the server-side game engine hook anyway?

>>plugin support (small language) and create a TiTan plugin out of it, which
>>would enable AM plugins to adapt to TiTan.  This becomes more of a TiTan API
>>to AM API integration plugin.
>
>So, it sounds like this would then have:
>
>   smscript -> amxplugin -> titan core
>
>Where:
>
> - Smscript would be a Small script, compiled into an amx file.
> 
> - Amxplugin would be like Olo's AMX Mod?, exposing the Titan API to Small
>   scripts.

Yes, this is what I had in mind anyway.

>
>Or do you mean:
>
>   AMscript -> AMplugin -> titan core
>
>Where:
>
>  - AMscript would be an existing AdminMod script
>
>  - AMplugin would be like porting AdminMod to Titan.
>
>Or, I suppose, both.  The first is more generally useful, and I guess the
>latter is intended to provide immediate transition to running under Titan.

Yes, to get immediate adaptability, you would need both.  Basically, the AMX TITAN Plugin and the AdminMod TITAN Plugin will both be integration translators that re-map the existing API in each to the TITAN API.

>Right, so basically porting them to Titan, while providing the same
>functionality to the user.

Yes.  We really want to get out of duplicate functionality.  There's no sense why CM should try to add in plugin support when a better solution can be developed.  So, with TITAN, the nice config scripting features of CM and the "small" plugin features of AM could be provided and work together.  We're all busy with full-time work in RL and spend all this time developing addons on the side.  

With more addons duplicating features (e.g. the console MOTD, which can be found in HLG, CM, SM, AM and others) it makes more sense to just pool the resources together and develop a game server addon framework system and then each can code specialized plugins with unique features.

I'm more of an advocate for re-use than reproduction of work.  Although, some will argue that this project is re-inventing many wheels, I'd like to refer to it as evolving the many wheels into something more beneficial to addon developers and the server admins.

/me moves on from his rambling...

>There would definitely have to be a decision on how much functionality is
>bundled into the core, versus functionality provided by plugins, with the
>general tendancy to modularize to plugins where feasible.

Agreed.  I don't want to over-burden the core and turn it into bloat ware.


>The steps I see are:
>
> - Design Titan plugin API, which should:
>    - Attempt to expose existing game engine functionality (HL and others).
>    - Also, Idealize a desired game plugin API, which game developers could
>      be encouraged to use. :)
>
> - Implement (design, develop, etc):
>    - Titan core which provides this API to plugins.
>    - Titan game engines for HL and others.
>    - Ports of existing Metamod plugins to Titan.

Nice breakdown.


HoundDawg

Alfred wrote:
>Before any serious work is done on the API design we need people from 
>all corners of gaming to make sure we don't miss anything (i.e mod 
>developers, 3rd party tools, plugins, engine developers if possible).

As we make our contacts to various individuals, maybe we can keep the team here up to date on the responses (positive and negative)?

HoundDawg

<snip>
>> - Compiled plugins are C,C++,Delphi,Java.
>> 
>> - Titan core provides a generalized API to the compiled plugin,
>> which could encompass:
>> 
>> - Game-related hooks (HL's DLLAPI, NEWAPI), ie routines provided by
>> the plugin, and called by the game.
>> 
>> - Game-related functions (HL's EngineAPI), ie routines provided by
>> the game, and called by the plugin.
>> 
>> - Utility functions (motd?), routines provided by a plugin, and
>> called by another plugin.
>> 
>> - Game driver translates the generalized API to the game-specific
>> API.
> 
> 
> Yes, this is pretty close.  I just didn't think about dividing up the
> TITAN Core with a Game Driver between it and the game engine.  I
> suppose it would make for re-useable sense.  Although, couldn't both
> be compiled into the TITAN Core, which would be the server-side game
> engine hook anyway?
> 
<snip>
I would prefer it to be broken up. We don't need to distribute each part 
seperately, but if each exists as a seperate .dll/.so then it makes it 
easier to develop in parallel and it makes us thing hard about our 
interfaces :)

Alfred wrote:
><snip>
>I would prefer it to be broken up. We don't need to distribute each part 
>seperately, but if each exists as a seperate .dll/.so then it makes it 
>easier to develop in parallel and it makes us thing hard about our 
>interfaces :)

Good point.

Alfred wrote:
>Lets go for the opengl model rather than the directx one, as a 
>programmer I know which one is much easier to write for :)
>
>OpenGL has a standard set of interfaces that all cards must support. If 
>they don't do it in silicon then they emulate it in software (this is 
>where the opengl miniport idea came from). This means as a graphics 
>developer I have one consistant interface to work with.
>DirectX has "capability sets" which tell you what features the card does 
>(and does not) support. You quickly get spaghetti by trying to handle 
>all the different situations.
>
>So, my vote is for a constant API with someway for a plugin to give it 
>minimum required capability set (some things can't be emulated) on 
>startup and from then on things are constant.
>

Then, what we need to do is identify what the minimum engine requirements are.  But, are you saying that we have a set engine requirements and for those games that don't have that functionality, they don't get supported?  So, they're left in the cold until they adapt?

Just curious as to the full concept that you're thinking here.... 

For example, for game engines that don't have a unique ID, they don't get supported?  What if there is something unique that engine provides that an addon coder wants to use but is not supported by TITAN because we first base our features off of HL?

<snip>
> Then, what we need to do is identify what the minimum engine
> requirements are.  But, are you saying that we have a set engine
> requirements and for those games that don't have that functionality,
> they don't get supported?  So, they're left in the cold until they
> adapt?
> 
Things that a game engine doesn't support natively will either be 
emulated in software or when plugins load they will simply fail with an 
error about the unsupported feature.

> Just curious as to the full concept that you're thinking here....
> 
> For example, for game engines that don't have a unique ID, they don't
> get supported?  What if there is something unique that engine
> provides that an addon coder wants to use but is not supported by
> TITAN because we first base our features off of HL?
> 
This is something that could be emulated :)

<snip>
> Then, what we need to do is identify what the minimum engine
> requirements are.  But, are you saying that we have a set engine
> requirements and for those games that don't have that functionality,
> they don't get supported?  So, they're left in the cold until they
> adapt?
> 
Things that a game engine doesn't support natively will either be 
emulated in software or when plugins load they will simply fail with an 
error about the unsupported feature.

> Just curious as to the full concept that you're thinking here....
> 
> For example, for game engines that don't have a unique ID, they don't
> get supported?  What if there is something unique that engine
> provides that an addon coder wants to use but is not supported by
> TITAN because we first base our features off of HL?
> 
This is something that could be emulated :)

Sorry for the double post :(

<snip>

Alfred wrote:
<snip>
>> For example, for game engines that don't have a unique ID, they don't
>> get supported?  What if there is something unique that engine
>> provides that an addon coder wants to use but is not supported by
>> TITAN because we first base our features off of HL?
>> 
>This is something that could be emulated :)

Ok, where would you put this "emulation"?  In the Core (or Game Driver) or a Plugin?

In the game interface, as the game interface exposes a standard set of 
functionality to the titan core :)

hounddawg@... wrote:
> Alfred wrote:
> <snip>
> 
>>>For example, for game engines that don't have a unique ID, they don't
>>>get supported?  What if there is something unique that engine
>>>provides that an addon coder wants to use but is not supported by
>>>TITAN because we first base our features off of HL?
>>>
>>
>>This is something that could be emulated :)
> 
> 
> Ok, where would you put this "emulation"?  In the Core (or Game Driver) or a Plugin?
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Halflifeadmin-titan mailing list
> Halflifeadmin-titan@...
> https://lists.sourceforge.net/lists/listinfo/halflifeadmin-titan