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

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.

divVerent wrote: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.

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.

divVerent wrote: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.

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.

divVerent wrote: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.

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.

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.

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.

divVerent wrote: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.

Why not making it vice versa? The users then shouldn't have to care how bsp is called if the server has proper mapinfo files. Repacking problem will also be solved and it would be clearly seen whom the map belongs to.

Because some commands, like "chmap", need the name of the bsp file and this can't be changed, as these commands are sometimes used without any QC code being loaded that could provide that functionality.

Agree with above. Actually this sucks, cause neither bsps can legally be renamed nor we can use mapinfo to wrap around.

Why can't they legally be renamed?

If people already to repack them, add shaders and texture images ripped from a COMMERCIAL GAME (Quake 3 Arena), and add your own advertisement txt file... then renaming the BSP should be the least of their legal worries.

Heck, many of the maps that people DID repack allowed not even modifying the pk3 AT ALL - even just to ADD files - in their included "license" txt file.

Then repacking of those maps is illegal also.

That's my point.

I've yet to see a map which allows you to repack it with additional data (like mapinfo, radar image, ent file), but not to rename the bsp file.

All this repackaging "unknown" aka "alphagod" did is illegal. He simply assumes that neither the mappers nor Id Software care. Maybe they really don't - but maybe they do, and then he'd get sued to death for it.

I guess that they don't. Most of them probably don't play quake anymore either. When was quake3 released? IIRC, it was for 2000 Christmas. That's nine years. I even wonder how would they like better: map is left untouched and left to die or revamped and adapted for Nexuiz.

I guess thats not the point.. being an opensource game developer or player one should care for such things. What would work however is to create an extra pk3 with all the changes to shaders, ent files and maybe (legal) extra textures.

The 36 map pack on nexuiz.com that Strahlemann did took so much time to do because he contacted every single map author and asked for permission to do just that. So you see such a thing IS possible and even legally if done right.

Why do mappers, by default, use the standard propretary license? I remeber I did this when I was 12 and 13 making maps for unreal and unreal tournament. I remeber propretarty ness as being "cool" and everyone hating on peeps that "ripped" them off or anyone off. I also remeber people thinking socialism and communism and community-organizing were _awsome_ anti-establishment things and that we must always forever struggle against the "rich and powerful" and try to make their lives misearable somehow and raise up those in the gutter to where the rich were and cast down the rich into the gutter... I remeber agreeing with this aswell way back then (10 years ago).

Now I see proprietaryness (especially in art) as similar to a certain "alternative lifestyle choice" and somewhat linked to it. I also notice that many proprietary artists are very concerned about "the man" or the "buzzwazeee" making "commercial" use of their items and they only want poor people to beable to even use(look at, play (if a game)) their work. This disgusts me: the way many proprietary-only artists have such hate and jelousy.

Why do they harbor these grudges?

I wanted to bring this topic back up to the top for discussion.

Here is a thread that reminded me of this issue.
http://forums.alientrap.local/viewtopic.php?p=64141#64141

Please not, it will make calling map votes harder if you'd never even SEE these cryptic bsp names.

No. Maps should simply not HAVE such cryptic names. Period.

I have not read the entire thread.

Imho mappers are responsible for naming the maps they make. Cryptic names help no one map picture or no. Name your map by its full name + version and everyone knows whats going on.

And if you feel a need to abbreviate, keep them guessable, like:

eggandbacon -> eggnbacon
dieselpower -> dpower
minimans_kitchen -> mmkitch (possibly, better: mmankitch)