Server Help :: View topic - Changing ship settings

Server Help

ASSS Questions - Changing ship settings

Kliff - Tue Feb 10, 2004 4:17 pm
Post subject: Changing ship settings

Can you change ship settings while in the zone? (Like Esc C on subgame)

Cyan~Fire - Tue Feb 10, 2004 4:26 pm
Post subject:

Esc+C is how you change settings in-zone. If you try doing that on subgame, it won't do a thing.

Edit: Whoops, sorry, completely didn't notice this was in an ASSS forum.

Mine GO BOOM - Tue Feb 10, 2004 4:39 pm
Post subject:

The ?getsettings feature does not work in ASSS, because there is the problem of which file gets edited. In ASSS, you can load files inside of other files, so it gets complex of which setting you actually want to edit.

About a year and a half ago, I suggested to Grelminar and Priit a method of having Continuum editing these recursive files. Priit sort of like it, but since ASSS wasn't ready, he put nothing into it yet. Now, ASSS is getting close, but Priit is away on holiday it seems. For the past 9 months.

Dr Brain - Tue Feb 10, 2004 9:19 pm
Post subject:

It's ?quickfix <limiter>

A ?quickfix with no limiter is basicly a ?getsettings.

Why would it get complex? All ASSS does is append the changes to arena.conf anyway.

Smong - Wed Feb 11, 2004 2:58 am
Post subject:

Dr Brain wrote:

Why would it get complex? All ASSS does is append the changes to arena.conf anyway.

That's the complex bit, having to go through all the changes at the end of each week updating the master .conf's.

Mine GO BOOM - Wed Feb 11, 2004 10:38 am
Post subject:

Here is an old email I sent back in March of 2002, about a month or so after I started to even look at the ASSS source and such. My grammar has increased (but just by a bit) since then, but this is it unedited:

Quote:

Dear Developers of ASSS, Priitk, and Ekted:

As the developers or testers of the new server software that grel has made know, the setting files can get very confusing because of its abilities to 'include' other files in itself. So a subarena's duel.cfg could have just the following:
#include server.cfg
[Misc]
MaxPlayers=20

That subarena's settings would be exactly like the server.cfg, just have its max players change. But this causes a large problem with the client to edit settings in game. So below, and with the attach files, i attempted to explain a fix for possible ways of editing multi filed settings in a way so the zone's sysop can edit any needed file's settings easily. This does not include a way to add/remove/edit the #include lines, but they can view/edit any of the #include'd files in a simple method.

Of course, there can be a much simpler method by using the mouse in the Chat Window if ekted would make such a settings edit box designed for it, but this method below can work in game with some ease.

------------------------

I really would like to have in game client side editing of settings, so here is my stab at how a possible method of allowing this with the multi file design that Asss is after:

When the user does a ?getsettings, the server will make a renaname.sconf file to be sent to user. This file will contain all the information from all the files the arena itself uses for loading settings. An example of the files it loads from is in the included zip file. Since the server checks arena.conf first, it loads from top to bottom all included files first before including any of its own information into the .sconf. The arena\extras.inc is then checked for any include files, which it has one. So the arena\weapons.cfg file is first loaded into the .sconf. The .sconf starts with the file's location, and then a shortname for the file, which is defined as a #name in the file. If no #name defined, then just uses the file's name (weapons.cfg). This repeats down all the steps and such until the full .sconf file is setup. Then this file is sent to the client.

The client should always have a template.sss file locally. It seems pointless to constantly send these descriptions and even worse if some of the files will include each setting multi times. So there should be a ?gettemplate command maybe so clients can download new templates when server gets updated before a client upgrade is done.

The client will now make its display such as i have in the .bmp. A few major differences. There are now 2 columns for variables. The first column will be the actual settings sent to the client in game, or used by the server. These are the lowest settings in the .sconf for each doubled up ones. The second column is the file's setting for this key. Since some files will not contain certain variables, they are left blank. The images between these two columns helps the user find where the setting is from. A < means that they need to go 'down' in the .sconf, which is left on the bottom tabs, to find the file that contains the used value for this setting. A > means it is 'up' in the .sconf, and they need to go right on the bottom tabs to find the file that contains this setting. A = means that the file that they currently have in the tabs is the file that contains this used setting. The file-setting is the one that should be allowed to be edited. If they do edit a setting that is lower than the one used in actual, or is the file that uses it, then the actual setting will be updated. But if they update the bomb damage in the weapons.cfg file, it will not change the value displayed in the actual setting, since that value is from the weapons.conf (arena\duel\weapons.conf). But if they edit a value in the arena.conf, it will update the actual displayed bomb damage, since it is a lower level in the .sconf.

To be able to change between files, Home and End are a good choice between changing which file is going to be edited/viewed in the settings window. Shift Home/End can 'jump' like 5 or so files at a time. Maybe have Insert jump to the file that the actual setting uses.

When the client then saves its settings to be uploaded, instead of re-uploading the whole .sconf, it uploads another .sconf file that contains only the edited values. The server then looks through the .sconf, loads those #file's and makes the changes in those files, and continues down its list. Once all edits changed, it will re-load settings.

Confused? If needed, i can make a simple flash or animated gif file to show the possible ways for the client side to edit/view settings/files or explain my idea a bit more..

-Mine GO BOOM

And, for those that actually read the above, here is a sample of what I was talking about for what the ?getsettings could look like:

And what the .sconf file could look like:

Code: Show/Hide

#file arena\weapons.cfg
#name Bomb
[Bomb]
BombDamage=5000
BombAliveTime=10

#file arena\extras.inc
#name misc
[Misc]
MaxPlayers=255

#file arena\duel\weapons.cfg
#name Bomb
[Bomb]
BombDamage=900
BombAliveTime=600

#file arena\duel\arena.conf
#name Notes
[Notes]
SettingName=Resistance
Maker=enixile

Kliff - Wed Feb 11, 2004 11:44 am
Post subject:

That would be a great idea. Nice example to.

Smong - Fri Feb 13, 2004 6:37 am
Post subject:

That looks a little complex. Also it isn't fair on people using low-res (I know I use windowed mode a bit when working on an arena).

What I would like to see is asss overwriting settings after a certain comment in arena.conf. Otherwise you get stuff like this:

Quote:

Shark:TurretLimit=1
Shark:TurretLimit=0

When only one line was really needed.

How about a Python script where you tell it an arena.conf and files it is allowed to update?

Quote:

.../scripts/update-conf arena.conf ships misc

Code: Show/Hide

+arenas
|+myarena
||+arena.conf
||+misc
||+ships
+scripts
|+update-conf

That way you can prevent it from touching the files in conf/svs/* (the script won't follow #include's). If it couldn't find any matching keys in file 'weapons' or 'ships' to update it leaves the section:name=key at the bottom of arena.conf.

Grelminar - Fri Feb 13, 2004 4:18 pm
Post subject:

I never really intended to leave the config file stuff in the state it's in... not cleaning up the files means they just get longer and longer as you change settings. The one good feature is that you get a complete history of all changes made to the file. Although, it's easy to wipe out the history just by uploading a new copy.

MGB's suggestion struck me as very complicated, and harder to learn how to use than just downloading, editing, and uploading files.

Smong's suggestion sounds nicer to me, except I'd limit it even more: It would take an arena.conf file and just replace it with an equivalent file, with section:key lines placed in [section] blocks if the [section]s exist, and left alone otherwise. Of course ineffective lines (that get overridden later) would be removed, along with their comments. Or maybe it should just convert everything in the file into [section] blocks. Anyway, it would do something reasonable, and it could be run from a command or also on the server directly (or through the admin shell).

This sort of assumes that people aren't going to use #include stuff excessively. Like, there would be a standard #include for each "base set" of settings, like SVS, or EG-like. Then there could be #include files for other settings that are shared among a few arenas, like a basic flag game or ball game, or a special shark. Then each arena would have a few customizations on top of that. The point is that you can't edit the base sets and shared stuff without downloading and uploading them. I don't think that's such a bad policy, since they should change infrequently.

There's a whole other problem of access control that I've been avoiding to this point. A sysop might want to set up situations where a mod can, say, flip between the regular shark and a special set of shark settings, in certain arenas only. But the mod shouldn't be allowed to change flag settings, and certainly not any of the global shared base settings. Currently that's impossible without writing custom code for each case. I'm not sure if it's worth trying to work out a scheme for allowing really fine-grained access control like that.