I seem to recall that I still get more gpfs in fgs than with dejavu's version of minimtl, but now that I found the thread for it Ill try to compare more, to see if it can be better.

Also, looking forward to sexy fanart of ANNA.

Good luck on your mod man when you get all the kinks out of it. I wouldn't mind putting it on my ATDM server.

All noticed bugs seem to have been fixed in version 101. (See bug-list on the first post of this topic)
Version 100 was a prototype version, being tested on FGS-altfire, FGS-0aug and Bowen server.
Version 101 will be the first public version is everything goes straight.
So, I'll keep you informed.


EDIT:

Version 101 of ANNA is finished.
It's hosted on FGS-Altfire and the Bowen server already and hopefully it will be hosted on FGS-0aug soon too.
It will be released for public within 4-5 days, if no major issues occur meanwhile.
It's primary aim was the fixing of bugs that were perceived in version 100.

CTF would be an awesome addition.

Will it be extendable?

chin.democ. wrote:CTF would be an awesome addition.

I don't think that's the point of ANNA? lol

There are many gpfs now lol (mostly it says something about augmentations for me)

Mastakilla wrote:

chin.democ. wrote:CTF would be an awesome addition.

I don't think that's the point of ANNA? lol

Yeah very true, perhaps a seperate mod then???

chin.democ. wrote:CTF would be an awesome addition.

Maybe later..
ANNA's primary purpose is to fix bugs/hacks. When everything runs smooth, additional extensions can be considered.

Poor wrote:Will it be extendable?

As expandable as MTL, since it bases on it.

Mastakilla wrote:I don't think that's the point of ANNA? lol

At least not for the near future. What we explicitly don't want is that ANNA gets TOO FAT!

[FGS]Kalman wrote:There are many gpfs now lol (mostly it says something about augmentations for me)

You could actively contribute in fixing those problems, if you posted DeusEx.log files of the sessions that ended with a GPF.

I'll post it next time, now my DeusEx.log seems ok

Alright, there are news!

They're related to Poor's question about modifiability/extensibility.
As we know, ALL DXMTL based mods face the problem that they're not simply extensible because of DXMTL's UCC hostility.

To solve that problem without sophisticated extenders and stuff, we solemnly invent: E M M A
EMMA is a co-existing modification along with ANNA.
It's purpose is to provide a powerful module interface for extending game functionality by custom modules.
This enables the game to be altered without the need of defining new gametypes or playerclasses.
The concept is similar to the Mutator system, where the Mutator chain is triggered when a certain event is instigated.
So for instance, if a player joins the game, ANNA informs EMMA about that event.
EMMA triggers the chain of registered custom modules.
The first module in the chain that has defined some code for that event, executes the code.
The module can even decide, whether the original code of that event (defined in ANNA) shall be executed yet. (e.g. if the module extends the ANNA code or completely overrides it)

If one of the older DXers remembers.. 6-7 years ago, when I worked on DXMTL160, I was developing a new Mutator base class that gave the mutator system much more power in the hands because the new Mutator base class defined far more functions that were called at certain game events.
However, from what I know the new mutator was never used because mods extending it would have had to extend MTL160, which was as UCC hostile as MTL152.
So to get back to EMMA.. here we don't have the problem because EMMA does NOT extend DXMTL is any way!
This is performed by ANNA talking to EMMA but not the other way around.
Mods with custom modules base on EMMA and are not dependent on ANNA.

We're currently debating about what functions we should provide for the module interface...

Currently we're having the following already:
- A function 'ScoreBoard' where a module can define which scoreboard class shall be used.
- A function 'FindPlayerStart' which is redirected from the 'FindPlayerStart' function in the game class.
- A function 'PreLogin' which is redirected from the 'PreLogin' function in the game class.

We're planning to add more functions which are redirected from the actual functions within the game- or the player-class.
So.. if somebody (especially ambitious modders) got ideas/suggestions about further function, feel free to express it so we can put it in the todo list.

Alright, I'll just throw out some stuff that might be useful.

For game classes:

CheckVictoryConditions - Essential for games that don't have a time or point limit.
Killed - Mutators have ScoreKill but most of the scoring and death notifications are done before it.
ChangeTeam - Sometimes we don't want to allow the player to switch teams.
RestartPlayer

For player classes:

The ability to specify a main menu class.
The ability to specify initial inventory.

~][FGS][Nobody~ wrote:Currently we're having the following already:
- A function 'ScoreBoard' where a module can define which scoreboard class shall be used.
- A function 'FindPlayerStart' which is redirected from the 'FindPlayerStart' function in the game class.
- A function 'PreLogin' which is redirected from the 'PreLogin' function in the game class.

Yes, awesome! this would be epic!
can't think of anything to suggest, but just wanted to say that... YEAAAAAAAAAAAAAAAAAAAAAAH

Ye, me hopes too it will be awesome!

@Poor: Alright, your input has been recorded.

There's no wep drop lag at all on altfire, it seems very smooth in every way, is this an update? Congrats.