[Anonymous]

I have used the plugin system successfully before, don't miss understand me, I'm trying to get feedback on how to achieve the following:

I'm working on an application manager capable of starting Marauroa applications in a prettier GUI (at least than the command prompt). One of its features besides starting and stopping the server, is to visually show information about the server instance. For example I would like to show the zones it has and probably the objects within it (I know it can be many but I will control how many or not displaying all if more than certain amount). For games like Stendahl with visual representations of objects and zone I would like to show those in the visual map.

What's the best way to achieve this? These are the options I have so far:
1) Special user with access to all that
2) Special action to retrieve this info
3) A type of listener for all perceptions

Keep in mind that at some point I would like to add zones and objects from the GUI as well in order to have something like a live "Dungeon Master" controlling the action.

But that's for later. Right now I want to show what's going on in the server and add more functionality later.

I cannot offer a perfect solution, so just some thoughts here.

Please keep the GUI separate from the server in a way that allows the marauroa server to be run on a real server without Window system. But I think you are already going into this direction anyway.

I'd go for the second approach: RPActions with a special user permission check on the server and RPEvents as answers.

Mirroring perceptions might be easier to get a complete state of the word as seen by all clients. But it has a number of drawbacks: You get all the details, but many of them might be irrelevant for the task at hand. There are no perceptions on empty zones.

In Stendhal we only have some debugging and raid "scripts": For example DeepInspecting a player object, searching for entities of a certain type anywhere on the world, summoning creatures and NPCs.

We call them scripts because they can be loaded and unloaded at runtime, but they are real compiled java programs. I went into some details on that in a gamedev posting.

There is a /script RPAction to invoke such scripts and the server side checks that the user is allowed to invoke them. At the moment most Stendhal scripts are very basic and send simple text messages back to the client. But the answers should be RPEvents so that you can process them easily. The script that dumps the FSM of Speaker NPCs, uses this approach.

[Anonymous]

I'm not modifying the way the server is ran, just adding an option.

I agree the second option might be the best but that would require support from Marauroa side for the special user. Think you can help me there? I want to avoid being invasive if I don't need to.

I guess I can handle the rest with a plugin and events/actions.

What do you think about a multi layer approach:  The monitoring thing is an extension to Marauroa, but games may provide an extension to it?

So the games can decide if a user has permission to execute those special actions? The games may be able to prepare some information before they are sent to the client in a context specific manner. There could be some reasonable defaults if the game does not implement the interface. For example the user with database id 1 might be admin.

[Anonymous]

Sounds good but brings me to something that has bugged me for a while, the definition of admins and such on a text file. Why is not this managed in a database to add more flexibility? Or at least be possible to override by games? I guess that would be the type of approach to identify users with those capabilities.

I guess this is what we are talking here:
1) I would provide an interface to be incorporated in Marauroa as a plugin
2) You, or someone in the team, would provide a permission scheme for me to use.

Do you agree? Should I open feature requests for those?

Hi Javy,

as kymara said on #arianne, the text file is just the initial mechanism used by Stendhal for the very first admin. Normally it is done using the /adminlevel command.

Marauroa currently does not have any permission support, but completely delegates that to the games. I'd prefer to not add that quickly without proper planning. This hesitation might be based on my experience at work where we spent almost a year on getting the concept for permissions right. Marauroa is supposed to support a wide variety of different game styles. So such a mechanism needs to be pretty generic.

[Anonymous]

Created a feature request for that: http://sourceforge.net/tracker/?func=detail&aid=3276585&group_id=1111&atid=351111

How will the permission scheme be addressed then?

[Anonymous]

Here's a WIP requirement documentation for the application.

https://sourceforge.net/apps/mediawiki/simple-marauroa/index.php?title=RCP_Server_Manager

Take a look at the preview of how the application does look now. The zones and objects within the zone are dummy values pending the implementation of the plugin discussed here.

I would appreciate any feedback/comments on it. Also other features you might like to see are more than welcomed!

Hi,

How will the permission scheme be addressed then?

With the suggestion above

So the games can decide if a user has permission to execute those special actions?

, Marauroa does not need permissions support.

[Anonymous]

I'm already working on the proposed approach. Any comments on the link?

Hm, I'm sorry I don't have any helpful suggestions right now for the link but if you have specific questions I'd try to answer. (Time is precious right now.)

Will developers who don't use or like Netbeans still be able to contribute or would they have to learn this IDE too?

[Anonymous]

That's a good point. I'll add an alternate method to defining applications. Probably using jars and xml configuration file.

For adding functionality to the tool there are no other options than using the NetBeans IDE. The same would happen if Iused Eclipse RCP (which I don't like).

Added REQ-011 to track this.

I have a particular interest in databases. Can you elaborate any further on

REQ-009: DB Layer: Access to embedded database used for internal purposes.

By embedded database, do you mean something to do with your application manager, or the Marauroa database tables such as account, loginEvent, RPObject, etc, and any game extension? The latter could be interesting.

How did you envisage providing access, with an in-built GUI editor, or with command line SQL?

[Anonymous]

I meant something to do with the application manager for internal use. The interesting option can be easily done with extensions IMO. Registering DAOs in the extensions. Probably adding an extension point for the engine classes i.e. having RPWorld give a chance to all registered listener to execute code.

Right now access is done implementing a client on my application (already working). See: https://sourceforge.net/projects/arianne/forums/forum/3192/topic/4484314 for a related question.

[Anonymous]

Another related post: https://sourceforge.net/projects/arianne/forums/forum/3192/topic/4453500