Created attachment 1210 [details]
Patch against SVN872.

Created attachment 1219 [details]
Patch version 4 against SVN 872

Command syntax has been improved slightly. Commands like !layout load (layout) will now load the last layout if the layout name is omitted.

This patch fixes a very annoying spam bug where during edit mode non-admin clients would sometimes be spammed with "you are not permitted to edit" messages.

Thanks to vcxzet, this patch modifies G_buildItem slightly and is capable of building items on walls and ceilings.

The file format version has changed but the layout loader is capable of loading the old version 1 layouts.

Game settings can now be set through the layout loader. If the layout is edited manually, entries such as "set g_humanBuildPoints 200" will be parsed and executed. They must start with set and be followed by two tokens.

This is useful functionality, but imo the implementation should be much more simplistic.

A server command "layoutsave LAYOUTNAME" could save a file named "layouts/MAPNAME/LAYOUTNAME.dat".

This .dat file could just contain on each line:
(buildable_t) (x) (y) (z) (p) (y) (r)

In addition to the g_layoutAuto cvar, a server command "layoutload [LAYOUTNAME1 [LAYOUTNAME 2 [LAYOUTNAME3 ... ]]]" could be used to load up one of the named layouts selected at random.
 1) This command should create only the buildings listed in the .dat
    file that are allowed.  This means it should respect all the
    rules/settings normally used to create buildings and
    give warnings for buildings that could not be created.
 2) This command should invoke map_restart to prevent server admins
    from reloading a base during a game.

This command would give server admins the ability to manully specify which layout(s) they want to be used (using g_mapConfigs) if they don't like one
or more of the layouts that a map comes with or if they want to force one or more of their custom layouts.

I don't think this functionality needs a special editing mode, nor should it override any server settings or game-defined building rules.  It could also be useful to mappers who want to provide multiple base layouts with their maps.

(In reply to comment #3)
> This .dat file could just contain on each line:
> (buildable_t) (x) (y) (z) (p) (y) (r)

Actually pitch, yaw, and roll probably aren't necessary either.

TJW, first of all thanks for not rejecting it outright. :)

I've had this run on Balance mod servers for a while now so I have a good feel for how it works out. Please let me explain some of my reasoning.

(In reply to comment #3)
> A server command "layoutsave LAYOUTNAME" could save a file named
> "layouts/MAPNAME/LAYOUTNAME.dat".

I wanted to do this originally but this is not possble. Pure servers do not allow the game QVM to list folder contents.
 
> This .dat file could just contain on each line:
> (buildable_t) (x) (y) (z) (p) (y) (r)

This is not sufficient. Buildables on walls and ceilings require normals. To save turret orientation angles2 is also required. It is best to save all of that data to be compatible with whatever changes might come down to those variables in new buildables etc. These files do not get very large, misering for space here is not productive. Moreover these are not *configuration* files, they really are data files. The layouts are meant to be edited in game.

> In addition to the g_layoutAuto cvar, a server command "layoutload" ...

I am in favor of a separate !layout command with sub-commands because:
a) running it without arguments lists all layout commands
b) it doesnt spam !help with the 10 or so layout editing commands
c) commands are not any shorter by concatenating them

>  1) This command should create only the buildings listed in the .dat
>     file that are allowed.  This means it should respect all the
>     rules/settings normally used to create buildings and
>     give warnings for buildings that could not be created.

Buildables are created using normal game.qvm routines (a modified G_buildItem). They obey all rules. Doing things like creating multiple OMs is possible by editing the layout files manually. If a server operator wants to go this far, its his or her choice and we don't need to spoil their 'lolgame'. :)

>  2) This command should invoke map_restart to prevent server admins
>     from reloading a base during a game.

Another functionality of the !layout command is to recover deconned bases. Also the edit-and-test cycle of layout development would be greatly hindered.
 
> This command would give server admins the ability to manully specify which
> layout(s) they want to be used (using g_mapConfigs) if they don't like one
> or more of the layouts that a map comes with or if they want to force one or
> more of their custom layouts.

The !layout command is NOT for mappers, it is for server operators to customize their servers. To specify multiple layouts in a map we would create them through the normal channels (i.e. through the server code).
 
> I don't think this functionality needs a special editing mode, nor should it
> override any server settings or game-defined building rules.  It could also be
> useful to mappers who want to provide multiple base layouts with their maps.

Please play on a Balance mod server and give this a quick try. You will see that the special editing mode is invaluable for fast base design. I want to say again that this command is for server operators looking to customize their servers and not mappers.

An example: say your server has a player limit of 8 which is clearly too small for regular Tremulous. All regular maps and their layouts are designed for 16 or so. Solution: you use the !layout command to change the bases (move them closer etc) and put the fun back in your server.

If you have any more questions, please talk to me over IRC or email me at <cyren(at)mn.rr.com>.

the minimal set is
var output format
origin[0] int
origin[0] int
origin[0] int
angles[1] int
angles[2] int
origin2[0] float
origin2[1] float
origin2[2] float

> > A server command "layoutsave LAYOUTNAME" could save a file named
> > "layouts/MAPNAME/LAYOUTNAME.dat".
> 
> I wanted to do this originally but this is not possble. Pure servers do not
> allow the game QVM to list folder contents.

Oh, good point.  This however doesn't stop server admins from manually specifying a list of layout names they have created themselves.

> > This .dat file could just contain on each line:
> > (buildable_t) (x) (y) (z) (p) (y) (r)
> 
> This is not sufficient. Buildables on walls and ceilings require normals. To
> save turret orientation angles2 is also required. 

OK, I see origin, angles, origin2, and angles2 are all required.

> > In addition to the g_layoutAuto cvar, a server command "layoutload" ...
> 
> I am in favor of a separate !layout command with sub-commands because:
> a) running it without arguments lists all layout commands
> b) it doesnt spam !help with the 10 or so layout editing commands
> c) commands are not any shorter by concatenating them

I don't like the idea of putting this functionality on top of the g_admin system.  It's not the type of thing that should be happening during a game.  It encourages cheating and will confuse and annoy players.

> Another functionality of the !layout command is to recover deconned bases. 

Two wrongs don't make right :)

> the edit-and-test cycle of layout development would be greatly hindered.

I would think the ideal venue for creating a custom layout would be on a local
server anyway.

> The !layout command is NOT for mappers, it is for server operators to customize
> their servers. To specify multiple layouts in a map we would create them
> through the normal channels (i.e. through the server code).

Mappers have been asking for just this thing.  Being able to specify multiple
layouts with their maps which are selected at random would be well accepted.

> You will see
> that the special editing mode is invaluable for fast base design.

Why not just disable the build timer when cheats are enabled (to allow fast base construction).

(In reply to comment #7)
> > Pure servers do not
> > allow the game QVM to list folder contents.
> 
> Oh, good point.  This however doesn't stop server admins from manually
> specifying a list of layout names they have created themselves.

It sounds like the issue here is primarily choosing who gets to create map layouts. We have mappers, server owners, regular admins, and players to consider. I wrote this as a part of g_admin and created the edit mode so that regular admins would be included in this group and players could watch, comment, and not be completely left out.

I guess it is a matter of personal preference as to how lenient you want to be with regards to who can change the maps on your server. I feel that this is ultimately a server ops choice though as there are many who enjoy letting their admins edit the buildable layouts.

The current implementation can be used as you describe it already, creating layouts locally and without player interference. The permission level required to use !layout is the strictest possible. I do not see why we should go through the trouble of reimplementing the code to *lose* functionality.
 
> I don't like the idea of putting this functionality on top of the g_admin
> system.  It's not the type of thing that should be happening during a game.
> It encourages cheating and will confuse and annoy players.

I would like to point out that no admin command encourages cheating, commands merely enable it. Many admin commands can already be used to cheat extensively. I know you keep a considerable list of rules for proper usage of such commands on your own server. This does not mean these commands should not exist.

As for in-game editing, it has its charm. The Cube Engine for instance was created partly to enable collaborative multiplayer editing. I realize this is another game with another set of goals, but cooperative in-game editing is an enjoyable part of the game experience.

> > Another functionality of the !layout command is to recover deconned bases. 
> 
> Two wrongs don't make right :)

Whether you consider it a wrong or not, it is currently the *only* way to recover a lost base in all situations.
 
> Mappers have been asking for just this thing.  Being able to specify multiple
> layouts with their maps which are selected at random would be well accepted.

They should have it too, but why should mappers be the only ones to design bases? The players who spend so much time within their creations may have good ideas too.
 
> > You will see
> > that the special editing mode is invaluable for fast base design.
> 
> Why not just disable the build timer when cheats are enabled (to allow fast
> base construction).
 
Layout edit mode has much more extensive changes than that. Players may want cheats (god mode, no clip, whatnot) but that doesnt mean they want ALL of the layout edit mode settings (no damage, instant spawn buildables, free items/evolution, etc).

Created attachment 1220 [details]
svn875 g_layouts


This is the simplistic implementation I was suggesting.

server commands:

 layoutsave LAYOUTNAME
  saves the layout to layouts/MAPNAME/LAYOUTNAME.dat 

 layoutload LAYOUTNAME1 [ LAYOUTNAME2 [ LAYOUTNAME3 [ ... ] ] ]
  loads at random one of the named layouts ( ones that exist )

cvars:
  g_layouts [string]
    This is a latched cvar that is a space sperated list of allowed
    LAYOUTNAME's.  If this is empty any layouts found by g_layoutAuto will
    be used.

  g_layoutAuto [1|0]
    Determines whether or not the server should search for all valid layouts
    and select one at random (default 1)

Specifying layouts with maprotation.cfg:
   For server admins who want to disable certain layouts a map comes with,
   or want to force only their own layouts, a primitive "layouts" has been
   added to the maprotation.cfg file.  For example:

  rotation1
  {
    karith
    atcs
    {
      layouts "tjw tjw2"
    }
    niveus
  }

  This would allow only the layouts named tjw and tjw2 to be used when the
  map is started by the maprotation system.
  
Other changes:
  * buildings are created instantly when cheats are enabled
  * build timer is instant when cheats are enabled

  This is to make creating a layout less tedious.

Caveats:
  * as long as any layout .dat files exist, the maps built-in layout will be
    ignored from the random selection.  mappers wanting to use this feature
    to provide multiple layouts will want to include a layout file for the       
    built-in layout as well.

Created attachment 1224 [details]
svn877 layouts


* fixes an issue with creep not always showing around initial alien buildings
  ( removed buildTime adjustment in G_buildItem )

* cleaned up G_buildItem changes

Created attachment 1226 [details]
only use build timer when cheats are disabled

+
+      if( g_cheats.integer)
+        ent->client->ps.stats[ STAT_MISC ] = 0;
Perhaps not a substantial penalty, but this waits until after calling a few functions and then ignores the return values of them all.
This (uglier version) checks if cheats are disabled before ever calling those functions.

Created attachment 1227 [details]
svn878 layouts

* last patch broke all building on ceiling/wall :)
* better parsing of layouts directory list
* optimized build timer calculation when cheats are enabled :) (M. Kristall)

Created attachment 1228 [details]
svn881 layouts

* updated for new buildable tagging patch

* moved TR_BOUYANCY check from G_FinishSpawningbuildable to G_Build so that G_Build proper normals (s.origin2) are set in one consistent location.

Created attachment 1229 [details]
svn885 layouts

* add optional parameter to the !restart command "!restart [LAYOUTNAME]"
* add new !map command "!map MAPNAME [LAYOUTNAME]"
* add new !listlayouts command "!listlayouts [MAPNAME]"

applied at revision 886

(In reply to comment #9)
> Caveats:
>   * as long as any layout .dat files exist, the maps built-in layout will be
>     ignored from the random selection.  mappers wanting to use this feature
>     to provide multiple layouts will want to include a layout file for the      
>     built-in layout as well.
> 

I've added a special name for the map's built-in layout called "*BUILTIN*"  This name is added to the list for random selection and can be named in the list of allowed layouts.  Therefore, this caveat no longer applies.

This was added at revision 891