Alternative map names in voting list

[Dokujisan]

I posted this question before. I can't find my other thread related to this from last year. Basically, the issue is with maps appearing in the voting list as their bsp filename, which is usually archaic. Some maps use really bad filenames. It would be ideal to use a name value from within the mapinfo file, if it's available. I think Blub talked about incorporating that into his client side voting code. I don't remember what the conclusion was about this.

I just setup a server with the recent set of Quake3 conversion maps. Unfortunately, all of them use names like cpm4a_nex_r1. Yet, the maps all have actual map names that they should use instead of the cpm file name.

Thanks

[divVerent]

As long as these names are still required for "suggestmap" and "vcall chmap", it's good that the BSP names appear.

I'd rather suggest that mappers should give their maps non-cryptic BSP names.

Otherwise, you'd want to vcall chmap a map, but have never seen its file name... and you have the same problem then.

Add to this that many maps still don't have a title in the mapinfo file.

The only thing that can be done is showing the title additional to the map BSP name.

[Dokujisan]

The only thing that can be done is showing the title additional to the map BSP name.

That would work well, as long as there is a more recognizable name shown (when available) in addition to the bsp filename.

The thumbnails in SVN help a lot in getting maps recognized during map voting, but having recognizable map names would be the next step in improving that. If map makers saw that title/name value in mapinfo files being used for something, they might be more likely to use it.

[divVerent]

They are used for the menu, isn't that enough?

And seriously, the whole issue exists only because some idiot mappers insist on using cryptic names for their BSP files that nobody can remember. Just give maps proper names, and it's all fine.

Adding this to the voting screen would encourage cryptic names. Not sure if we want that.

[SavageX]

And seriously, the whole issue exists only because some idiot mappers insist on using cryptic names for their BSP files that nobody can remember.

Just to cheer things up: Remember the days when official Nexuiz maps had descriptive names like nexdm13?

However, we *stopped* using such names - and I think mappers should do so, too.

[[-z-]]

Is everyone going to get themselves in a twist if I were to suggest a CSQC interface for BROWSING maps on the server? A visual frontend for the lsmaps command that would allow a user to visually select a map to be suggested or vcalled (we'll have to think about potential for abuse here ).

What I mean is something similar to the "create" tab except maps would fill the whole thing (maybe have a filter search like the "servers" tab).

Here's my ASCII mockup where [ ] is a map image

Code: Select all

filter: ____
[  ]  [  ]  [  ]  [  ]
[  ]  [  ]  [  ]  [  ]
[  ]  [  ]  [  ]  [  ]


The filter would then (theoretically) be able to search both bsp and "real" name in the filter while also giving equal opportunity for suggesting or vcalling maps.

[Dokujisan]

And seriously, the whole issue exists only because some idiot mappers insist on using cryptic names for their BSP files that nobody can remember. Just give maps proper names, and it's all fine.

There are a mix of opinions on what should go into a BSP name. Mappers have made up various conventions because none were officially established by the Nexuiz developers. If there are official conventions, I haven't seen them. AFAIK, it was all left up to the mappers to establish their own conventions for map filenames.

We should establish conventions for map file naming right now (a discussion I've had with -z- many times because of his map repository project). That means we would go through the various maps and "fix" them. A server admin can simply override their mapinfo file with a proper name entry. That would be a pretty simple fix. Or can we repack them. We're having to repack them for things like adding in the radar image anyway. We're also repacking them to add in proper mapinfo files to the maps that are lacking them.

An alternative fix...

is if there was a way for a server admin to define aliases for map names (using the alias command perhaps, I dunno) in their server config. Then that would appear in the voting display instead of the "real" BSP name AND it would apply to vcalling.

So, in my server.cfg, I might have

Code: Select all

mapalias map_facing_worlds_nex_v2 "Facing Worlds v2"


behind the scenes, the maplist can still use BSP names.
But people could actually do this...

Code: Select all

vcall chmap "Facing Worlds v2"


They would also see "Facing Worlds v2" in the map voting display.

[divVerent]

Part of that convention is unenforcable (like the pk3 name prefix).

As for the bsp file names - that's unenforcable too. People just WANT to be able to install Q3A pk3 files without changing anything inside, and Q3A mappers ARE retards who prefer cryptic names. Forget it.

By the way, repacking maps without adding value (a "REPACKED BY THE GREAT NINJAZ" note is NO added value) is disrespectful towards their authors. If you add value (and be it just fix an ACTUAL bug in the map, like the floating items on flipzone and tripzone), go ahead. If you just want to spread your name by doing it, forget it, you're ripping off the work of others. Out of respect, I add NO such stuff and, if anything, JUST an extra radar image. No glory for it should go to me, as all I did was running "sv_cmd radarmap --loop" with all the maps loaded.

BTW, I disagree with the map- prefix for all map pk3s. It's redundant, as MOST pk3s are maps. Unneeded clutter. What I would agree with is coming up with new file extensions for different types of packs, and making the engine treat them all as if they were pk3s (at least for now, later it can be used for advanced functionality).

.nxw = Nexuiz "worldmodel"
.nxm = Nexuiz model zip/pk3
.nxs = Nexuiz "server package"
.nxc = Nexuiz "client package"
.nxp = Nexuiz "generic package"

As for advanced functionality that could be added later:

NXW files (world models) could get not loaded on startup, but loaded when a BSP file of the same name is requested, and unloaded when unloading the map. That way, map packs won't interfere with each other.

NXM and NXS files could get automatically added to sv_curl_serverpackages. As a special rule, if a NXM misses a txt file in the root directory, it'd use the first model file in models/player.

NXC files could get ignored by the dedicated server, and only loaded by clients. Would e.g. be nice for texture packs (like, Nexuiz could come with the data pk3 split up into client and server part, so dedicated servers don't need to load textures and sounds).

NXP files would behave just like PK3s do now.

Of course, PK3 would stay supported, but have none of this "smart" behaviour.

The exact file extensions of this don't matter - what matters is that that info is stored IN the file extension, as that's the "standard" (as set by Microsoft, and commonly followed on *x systems) for specifying the purpose of a file and how it is treated. Treating pk3s specially by file name PREFIX is something LordHavoc will never allow into his engine - for good reasons.

Anyway, the issue isn't pk3 or bsp names with missing or weird versioning. That's no problem. The issue is cryptic bsp names. And for this no technical means is possible. Out of respect to the original mapper, I'd not rename bsp files of others - but I'd not encourage playing such maps by showing a "nicer" name, but rather tell the original mapper to use descriptive names in the future (and only with his permission, I'd do that then). There is no need, and no desire, to waste lines of code on this.

[Alien]

adding values to mapinfo:
repacker: someguy (author tag is left and displayed on the menu screen)
fixes: brief description of what you've done
bspref: 6gvf78yu_v2_r99.bsp
other required fields
and giving mapinfo name like "blind worlds" could lead to making a mapinfo file as a data wrapper for a bsp, map image, radar image file, etc...
This way all relevant information could be exctracted from mapinfo file and people would vote for mapinfo files and not bsp files.

vcall changemap "blind worlds"

Separating content into separate archives seems like a good idea.

[divVerent]

No, mapinfo can't point to the BSP. The game must find the associated map info from the BSP file name upon loading a map. That's why they currently have the same name.

Anyway, you can add more fields to mapinfo without any problems. Menu simply won't show them, but can later be extended to support them.