Server Help

ASSS Questions - settings

xor eax - Wed Aug 31, 2005 1:57 pm
Post subject: settings

Now I'm having problems with ?quickfix/?setsettings. I don't even have the turf modules loaded, and those new TurfReward settings are being included in the server.set file, but ship settings are not.

I really miss a settings definition scheme, something like template.sss subgame file. This basic subgame model can be extended in asss for each arena to have its own "template.asss" file (some kind of Itemplate interface would take charge of it). My point is... the whole subgame config scheme would fit perfectly in asss, and can be extended too. But, for some reason you decided to broke it. I still can't think on a good reason to put the whole config scheme upside down as you did.

Smong - Thu Sep 01, 2005 6:06 am
Post subject:

The config help is broken in asss 1.4.0. It gets compiled into the program, from cfghelp.inc which is in turn auto generated from a script that scans source files for specially formatted comments.

Chambahs - Thu Sep 01, 2005 3:09 pm
Post subject:

oh yea...we still need to fix that smong....lol

Grelminar - Thu Sep 01, 2005 3:22 pm
Post subject:

Oops, I just realized why the ship settings are missing: the "clientset.def" file got moved as part of the whole reorganization thing, and I forgot to update the line in the makefile that passes it to extract-cfg-docs. The fix: in core/core.mk, change "*.def" to "core/clientset.def".

Regarding your nonsensical ranting, please take a look at what's there first. There is a settings definition scheme that contains the exact same information as template.sss, plus more. The only downside is that it's not dynamic, it's compiled into the asss binary. If you can come up with a concrete design for a dynamic scheme that's just as easy to use as what's there, I'd consider including it.

Chambahs - Fri Sep 02, 2005 1:43 am
Post subject:

so that would fix the problem i told you about before grel? about esc + C not showing all the settings?

xor eax - Fri Sep 02, 2005 11:11 am
Post subject:

No no no no. It's half non-sensical only.

I looked at "what's there" and "what's not there" before making my post. A template system "is not there". You can't call it template if it's not dynamic. A bunch of literals hardcoded in an exe are not a template system. The current asss "settings definition scheme" is worse than the subgame one, I expected something better than that. A setting maintenance tool for asss can't be done with the present state of things.

It is obvious to me that a dynamic scheme for settings must be implemented per arena, not per zone. It is easy to design such model, the hard part would be implementing it into an already almost developed program as asss is. These things must be designed since the beginning of the project. So I better shut up and get out of here. I'll save you my nonsensical speeches. Good luck.

Cyan~Fire - Fri Sep 02, 2005 3:29 pm
Post subject:

xor wrote:

You can't call it template if it's not dynamic.

Of course you can. A template is just a way of displaying data, it sure can be static.

Anonymous - Sat Sep 03, 2005 10:29 am
Post subject:

Cypher, I admit a template can be static (what I meant is that it is not an useful model for asss settings) but a template is not a way to display data. English is not my main language but I think that a template is just a model used in any kind of replication, definition, creation. It is not only related to computers. And talking about the computer side of the concept, thay're much more than "a way to display data".

Cypher, instead of playing with semantics... can you tell me what is with modules implementing new settings? How can these settings be included in a static template? By emailing them so they will be included in the static template of the next asss release?

xor eax - Sat Sep 03, 2005 12:55 pm
Post subject:

Cypher = Cyan
guest = xor eax
... :p

This is the model I propose, if anybody is still listening:

An interface (Itemplate) shoud be made to perform this task. This interface will provide functionality to add, remove, edit, list settings definitions. It must check the integrity of template files too.

All arenas should have their own template file. If not, the default arena template will be used.

The user can add custom settings to these files (just like MGB did with subgame 1.34, which was a good thing that doesn't fit in the current model).

The "real" settings (those which have an implementation at server or client) are added by modules or by core, at run time, using Itemplate interface. It implies that modules must handle its own specific settings through Itemplate interface when they are loaded (per zone settings) or attached to arenas (per arena settings).

After the module loading process, all settings that were in use but are not currently in use should't be removed from the template file, just commented.

Dr Brain - Sat Sep 03, 2005 1:14 pm
Post subject:

xor eax wrote:

All arenas should have their own template file. If not, the default arena template will be used.

The user can add custom settings to these files (just like MGB did with subgame 1.34, which was a good thing that doesn't fit in the current model).

I don't think this will work. As an asss sysop, I can say that the last thing I want to do is have another file to keep track of in each arena.

Smong - Sat Sep 03, 2005 1:41 pm
Post subject:

I think he wants the modules to add (via a code interface) to the current list of settings sent with esc+c. Anyway even if it did read from another file, that file is going to be optional.

Quote:

How can these settings be included in a static template? By emailing them so they will be included in the static template of the next asss release?

To answer this question, many custom modules come with documentation describing any new settings. If you really want these in the current list then just make sure the code is commented with properly formatted doc strings and recompile the appropriate modules (and that shouldn't take more than 5 minutes).

xor eax - Sat Sep 03, 2005 2:37 pm
Post subject:

Dr Brain wrote:

I don't think this will work. As an asss sysop, I can say that the last thing I want to do is have another file to keep track of in each arena.

You won't have to take care of anything as a server operator. You won't have to look or edit the template files manually. They will be used internally by the server so the right set of settings will be sent to clients in response to a ?getsettings command. Template files can be used as a useful reference too.

Smong wrote:

... many custom modules come with documentation describing any new settings. If you really want these in the current list then just make sure the code is commented with properly formatted doc strings and recompile the appropriate modules (and that shouldn't take more than 5 minutes).

A question... will asss include these new settings in the SET file after that?

Anyway, I don't think that gathering settings through modules and documentation is a good thing. That's why i'm proposing some kind of centralized system (Itemplate interface). Modules should deal with settings implementation only, and let the settings definition for a specialized interface.

Smong - Sat Sep 03, 2005 3:01 pm
Post subject:

Asss will send the new settings after recompiling. For example delete the new turf source files, recompile and their settings won't be in esc+c anymore.

I don't know if it's worth the hassle of going through every module that uses settings, and editing them so they call some Itemplate function for each setting they use. What if one setting is shared by many modules?

Also a compromise where a template module would add settings to the internal list wouldn't work too well. What if a custom module called the function to add a new setting definition, and also had a doc string that got recompiled into the server? (Ok so the developer should not use both interface and doc string in their module).

Recompiling doesn't take long, and the modules you have loaded don't vary often. If they do then chances are you are developing them and know the settings off by heart anyway.

xor eax - Sat Sep 03, 2005 4:53 pm
Post subject:

Smong wrote:

Asss will send the new settings after recompiling. For example delete the new turf source files, recompile and their settings won't be in esc+c anymore.

Ok, another question. What is with the modules that are not being compiled into asss body? Can I pretend the new settings of an external dll module to be included in the SET file?

Smong wrote:

I don't know if it's worth the hassle of going through every module that uses settings, and editing them so they call some Itemplate function for each setting they use. What if one setting is shared by many modules?

Of course it's a hassle to do it now. The model i'm proposing would have been considered at the beginning of the asss project, I'm afraid it has too much impact right now. Anyway I think you're getting me wrong (which could be my fault because my english sucks). I don't pretend for every module to have to register each and every setting, just the new settings they are implementing. The basic set of settings can be taken from a "master template" file, which shouldn't be edited by users (same as template.sss in subgame). When arenas are created the basic set of settings is included by asss in their templates. After that, modules can register specific settings for these arenas when they are attached to them. What I propose is something similar to the model implemented for commands. You can think of my "AddSetting" call as you would think of the "AddCommand" call. Hrmm... I should start making diagrams to explain my model.

About settings shared by many modules they are not a problem at all. Since settings are unique, and the setting is already added to the template file, the second and subsequent calls to "AddSetting" will fail, returning an "ALREADY_EXIST" exit code, which must be considered successful by the caller.

Smong wrote:

Also a compromise where a template module would add settings to the internal list wouldn't work too well. What if a custom module called the function to add a new setting definition, and also had a doc string that got recompiled into the server? (Ok so the developer should not use both interface and doc string in their module).

Yes, I'm talking about substituting those strings by a more flexible model. Trying to put both models together would be a nightmare.

Smong wrote:

Recompiling doesn't take long, and the modules you have loaded don't vary often. If they do then chances are you are developing them and know the settings off by heart anyway.

Once again, you're talking about settings implementation, and my whole point is about settings definition. It's about what the client receives in response to ?getsettings/?quickfix command. Knowing settings by heart doesn't put them in SET files...

I don't pretend my model to be perfect, or the best model around, but I think this discussion must be started as soon as possible for the sake of the project.

I would like asss to be a little bit more friendly with the final user. I think you guys are so deep into the project that you have forgot the perspective of final users. Maybe I'm just wrong and you pretend it to be operated by developers only.

Grelminar - Fri Sep 09, 2005 3:41 am
Post subject: my proposal

Ok, now I have a better idea of what you're proposing. The problem with your proposal is, as you note, everyone writing a module with settings would have to add a bunch of extra code to register and unregister their settings. It's a lot easier to do that for commands, because they have to be registered and unregistered anyway, so it's just a matter of adding an extra parameter. Settings don't have to be registered, so forcing a register/unregister for them is awkward and annoying.

Also, the parsing out of the setting type, range, default values, etc. would have to happen in the server, not in an external script. Command help text doesn't have to be processed, which is why that's easier to do.

I do have an idea for how dynamic config help could work, although it's a little complicated and sort of ugly. There are two parts of the scheme: one for C modules and one for python modules.

For C modules, we hack the build system: whenever it tries to compile a .c file into a .o, it also runs a script on the .c file. That script (an enhanced version of extract-cfg-docs.py) looks for specially formatted cfghelp comments and if it finds any, outputs something similar to the contents of cfghelp.inc to a temporary .c file, which defines an exported symbol based on the module name, that points to static data containing the processed cfghelp. Then we somehow compile both .c files into the .o file (either concatenate the .c files before compiling, or compile them separately and do an incremental link). Then, when loading a C module, we look for the cfghelp pointer, and if we find it, pass it to the cfghelp module (which is enhanced to be able to deal with dynamic data). On unload, we again pass it the pointer so that it can unregister the settings for the module being unloaded.

For python, we hook into module loading, and run a script (again a modified extract-cfg-docs.py) over the module source at load time. This requires the script to be present while the server is running, but that's not a big deal. The script will somehow communicate the cfghelp that it finds to the cfghelp module (I can think of a few ways to do this).

I haven't implemented the system I've described, but I think it would work, and it would have all of the properties you want, plus the important one that none of the current cfghelp text would have to be changed. It has a few big disadvantages, though: it would take additional effort to get the build system hacks to work on windows, it requires a lot of special-casing of the cfghelp module in what is now very generic code (cmod.c and pymod.c would both require code changes specific to cfghelp), and in general it's pretty ugly, especially the C module part. However, it might be possible to add the hooks in cmod.c and pymod.c in generic ways, which would alleviate some of the too-much-special-casing concern.

Comments? Improvements? Alternatives? Do people really want this enough that it's worth all the ugliness?

Smong - Fri Sep 09, 2005 4:53 pm
Post subject:

What about an sss directory and each custom module can be distributed with an optional modulename.sss file? You already have to edit modules.conf to install a new module, so dropping some file in another directory shouldn't hurt too much.

If new settings are hidden away inside the code people might not know about them. A seperate file might make the curious look at it. Alternatively if you go ahead with your idea maybe you could alert the person that did the ?insmod (or first staff to login if from modules.conf) with some text like 'modulename has new settings under somename category'?

Actually if you feel that is too user friendly you could just send the output from ?modinfo when you ?insmod (shouldn't be too hard to add that).

xor eax - Fri Sep 09, 2005 11:28 pm
Post subject:

Well.. thank you grelminar, for thinking about it (specially considering i was being an ass in my firsts posts). I think most people is focused on modules and they don't need to care much about this. I came across this "problem" because I was thinking on writing a GUI tool for asss setting edition. What I really need, and everyone else i guess, is a well-formed SERVER.SET. And it can be solved by building asss in the right way... so maybe is better to forget about this.

Instead of being an offline editor, my editor can be a bot which uses ?getsettings/?quickfix and ?setsettings. This way it'll need the server.set file only.

xor eax - Sat Sep 10, 2005 11:29 am
Post subject:

Just to clarify... I think your idea is ok, grelminar, and i still think that a dynamic model is better than a static one, but i don't want you to change it just because of me. It looks like 99% of asss programmers won't ever need more than they have now.

I like more Smong idea, it is very similar to what i proposed. But it requires some drastic changes that put our theories close to fantasy and far from reality.