Server Help

[Kliff]

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

[Cyan~Fire]

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.
_________________
This help is informational only. No representation is made or warranty given as to its content. User assumes all risk of use. Cyan~Fire assumes no responsibility for any loss or delay resulting from such use.
Wise men STILL seek Him.

[Mine GO BOOM]

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]

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.
_________________
Hyperspace Owner

Smong> so long as 99% deaths feel lame it will always be hyperspace to me

[Smong]

[Mine GO BOOM]

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:

[Kliff]

That would be a great idea. Nice example to.

[Smong]

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:

[Grelminar]

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.