Server Help

xor eax · Posted: 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 · Posted: 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 · Power attack Joined: Jun 19 2005 Posts: 820 Offline

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

Grelminar · Creator of Asss Joined: Feb 26 2003 Posts: 378 Offline

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 · Power attack Joined: Jun 19 2005 Posts: 820 Offline

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

xor eax · Posted: 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 · Posted: Fri Sep 02, 2005 3:29 pm Post subject:

Guest · Offline

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 · Posted: 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 · Posted: Sat Sep 03, 2005 1:14 pm Post subject:

Smong · Posted: 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.

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

Smong · Posted: 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 · Posted: Sat Sep 03, 2005 4:53 pm Post subject:

Grelminar · Creator of Asss Joined: Feb 26 2003 Posts: 378 Offline

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 · Posted: 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 · Posted: 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 · Posted: 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.