Screenshot naming + gpp1 patch

[Ingar]

Update 2:
The number resets on date changes now, demos (except autorecord) and videos use the same naming convention.
http://ingar.satgnu.net/tremulous/files/tremulous-gpp1-screenshot_timestamp3.patch

Update 1:

The format is now
yyyy-mm-dd-nnnn.jpg (or .tga)

nnnn is a number from 0000 to 9999, the client will continue numbering shots one the same day. If you happen to be playing at 0h 00m, it will not reset the numbering until you restart the client. If you make more than 10,000 screenshots on a single day you'll get an error message.

http://ingar.satgnu.net/files/tremulous/tremulous-gpp1-screenshot_timestamp2.patch

Original post:

The default screenshot naming scheme isn't very convenient: if you like to make a lot of pictures and keep them organized it's easy get confused.

Personally, I like my screenshots to contain a timestamp. Such files are always neatly organised
in explorer and are much easier to find when you need them.

I propose the following format:
tremulous-yyyymmdd-hhmmss-nnnn.jpg or .tga

The nnnn part is somewhat interesting: it's a number from 0-9999 that gets reset to 0 every time
you start the client. That way you can have multiple screenshots per second and you also
have some kind of session numbering.

I made a small patch for gpp1 that does just that, you can find it here:
http://ingar.satgnu.net/files/tremulous/tremulous-gpp1-screenshot_timestamp1.patch
The patch also removes the delay you experience when you make your first screenshot because
the client doesn't have to search for the first available screenshot number.

[Norfenstein]

Would be nice to have the map name in there too, but maybe it's not worth making the file name even longer.

[David]

Why the tremulous- at the start?  Surely its being in ~/.tremulous gives that away?

Also with thousands of them, maybe splitting into folders could help?  eg folder per day or whatever.

[Demolution]

Substitute the "tremulous" part for a map name?

[mooseberry]

Also I'd drop two of the yy just for simplicities' sake. I don't really see too much of a worry for Tremulous being played in the 22nd century. Shortens the file name too.

[Ingar]

Would be nice to have the map name in there too, but maybe it's not worth making the file name even longer.

Might mess up chronological ordering of the files, unless the mapname comes after the timestamp.
Also, I have no idea where to find the mapname (code wise). It might be more difficult than it sounds,
but worth exploring.

Why the tremulous- at the start?  Surely its being in ~/.tremulous gives that away?

The best reason of all: lazyness. That way I can just upload screenshots
to my website without having to rename them.

I admit the number thingy does bother me somewhat, maybe I should limit it to two digits.

[David]

I seem to recall there being a mapname cvar, although that may be server only.

[Bissig]

Maybe put the map name into an exif field?

[kevlarman]

I seem to recall there being a mapname cvar, although that may be server only.

it is, but the client has easy access to the mapname anyway (how would it load it otherwise?), see the cl_autorecorddemo code.

[Norfenstein]

Would be nice to have the map name in there too, but maybe it's not worth making the file name even longer.

Might mess up chronological ordering of the files, unless the mapname comes after the timestamp.
Also, I have no idea where to find the mapname (code wise). It might be more difficult than it sounds,
but worth exploring.

After all the numbers was what I was thinking. And David's right, if you wanted tremulous- in front of all the file names you could easily mass rename them yourself. Agree with mooseberry too.

[UniqPhoeniX]

If Tremulous had a time cvar: bind f11 screenshotJPEG tremulous-\$time\-\$mapname\. At least in Tremfusion, the mapname part works already and I could get gametime with a script that starts counting time when I enter a game. The nnnn part can be made to work too. Why can't Tremulous have scripting?

[Ingar]

I did think about a cvar but it's just overkill. I don't feel like writing a parser for it.
I'll take a look at how tremfusion does it and maybe steal a good idea or two.

[Ingar]

The format in the new patch is:
yyyy-mm-dd-nnnn.jpg (or .tga)

nnnn is a number from 0000 to 9999, the client will continue numbering shots one the same day. If you happen to be playing at 0h 00m, it will not reset the numbering until you restart the client. If you make more than 10,000 screenshots on a single day you'll get an error message.

http://ingar.satgnu.net/tremulous/files/tremulous-gpp1-screenshot_timestamp2.patch

This way the funky number does something useful, I noticed it's quite confusing to find screenshots between a bunch of timestamps so I removed it and made the date a bit more readable.

I looked into adding the mapname but it seems slightly complicated, volunteers are always appreciated

@moosberry:
I don't like 2-digit year numbers. It's like a different kind of soda: It sounds good
but I like my usual brand better.

[gimhael]

The renderer stores the map name is in tr.world->baseName (this is the file name of the .bsp without extension), but be careful: tr.world may be NULL when no map is loaded !

[Demolution]

Is there something similar to this for demos?

If you make more than 10,000 screenshots on a single day you'll get an error message.

aww..

[kevlarman]

The format in the new patch is:
yyyy-mm-dd-nnnn.jpg (or .tga)

nnnn is a number from 0000 to 9999, the client will continue numbering shots one the same day. If you happen to be playing at 0h 00m, it will not reset the numbering until you restart the client. If you make more than 10,000 screenshots on a single day you'll get an error message.

http://ingar.satgnu.net/tremulous/files/tremulous-gpp1-screenshot_timestamp2.patch

This way the funky number does something useful, I noticed it's quite confusing to find screenshots between a bunch of timestamps so I removed it and made the date a bit more readable.

I looked into adding the mapname but it seems slightly complicated, volunteers are always appreciated

@moosberry:
I don't like 2-digit year numbers. It's like a different kind of soda: It sounds good
but I like my usual brand better.

cl_main.c:2928

Code:

                       Q_strncpyz( mapName, COM_SkipPath( cl.mapname ), sizeof( cl.mapname ) );
                        COM_StripExtension(mapName, mapName, sizeof(mapName));

[MitSugna]

That would be awesome if all I did was taking screenshots

[khalsa]

This patch should be for both demo's and sshots.

My vote is for yyyy-mm-dd-nnnn-mapname

[KillerWhale]

I'd prefer to see yyyy-mm-dd-mapname-nnnn for better sorting, in my opinion. Either that or, mapname-yyyy-mm-dd-nnnn.

Both of those ways will group the shots from a map together, where Khalsa's way would group all of the first shots from every map together, which doesn't sound too intuitive to me.

Having this on demos and on screenshots sounds very nice. I don't like "screenshot0001" and "demo0001".

[mooseberry]

I'd prefer to see yyyy-mm-dd-mapname-nnnn for better sorting, in my opinion. Either that or, mapname-yyyy-mm-dd-nnnn.

Both of those ways will group the shots from a map together, where Khalsa's way would group all of the first shots from every map together, which doesn't sound too intuitive to me.

Having this on demos and on screenshots sounds very nice. I don't like "screenshot0001" and "demo0001".

yyyy-mm-dd-nnnn-mapname seems the best way to me.

That would make the picture be 2009-12-17-0001-atcs.jpg. That doesn't make a ton of sense logically but I think it would be easiest to sort by. Knowing what map the picture was take on is nice, but I don't really see the need to ever sort by mapname (unless you're going back through old photos looking for pictures on a specific map.) It seems to me most of the time you will want it sorted by date.

And, you can name demos, but of course, this will make it a lot nicer if you don't bother to name them.

[kevlarman]

cl_autorecorddemo has already done this for ages...

[KillerWhale]

Well, I am confused as to the number. Is the number +1 for every shot taken on that day, or for on that map on that day?

[Ingar]

@KillerWhale
patch number 2 does +1 on a new day, it doesn't have mapname yet.

I did add the mapname, in fact it was rather easy thanks to the tips in this thread.
BUT it screws chronological order. bigtime. Think playing the same maps, in a different order,
in several games on a single day.

mapname and number don't mix, so it's either

- full timestamp (down to the millisecond)
- short timestamp (date and/or time) + number
- full timestamp + mapname

There is a perfectly sound technical reason but I won't bore you with it.

[UniqPhoeniX]

yyyy-mm-dd-nnnn-mapname shouldn't mess with cronological order tho.

[Paradox]

I like the idea of dumping mapname in EXIF data. Bissig said it, i believe

[mooseberry]

I like the idea of dumping mapname in EXIF data. Bissig said it, i believe

Only problem is for the average user they will not know what this is or how to view it.

[Ingar]

yyyy-mm-dd-nnnn-mapname shouldn't mess with cronological order tho.

The basic problem is I can't check if a filename yyyy-mm-dd-nnnn-* exists.
And after closer inspection, it will screw up in other situations as well.

I need to think this over.

[David]

Make it yyyy-mm-dd/nnnn-mapname, then all you have to do is count the number of nodes in the directory.

[A Spork]

Shouldn't mapname be before nnnn?
Otherwise you will get
0000atcs
0000niveus
0000nexus6
0001atcs
0002atcs

It should goup by map IMHO.

[David]

The numbers keep going up even if the map changes.

[A Spork]

Whatever, still makes more sense to me to have
mapnam before nnnn...

[mooseberry]

Whatever, still makes more sense to me to have
mapnam before nnnn...

Whatever, but read the thread you are posting in for it to make more sense.

[A Spork]

What?
how does it not make sense?

[mooseberry]

What?
how does it not make sense?

Hm... Again you should read what people say.

I said read the whole thread carefully to better understand why things are what.

So what are you asking me "how does it not make sense?" for.

(I'll save you time, that was a rhetorical question.)

[A Spork]

Your wording sucks.
And I did read the thread, and I didn't see any reason why mapname has to be last.

[mooseberry]

Your wording sucks.
And I did read the thread, and I didn't see any reason why mapname has to be last.

[UniqPhoeniX]

<date>-0000-atcs
<date>-0001-tremor
<date>-0002-atcs
is better than
<date>-atcs-0000
<date>-atcs-0002
<date>-tremor-0001

[David]

Give them all random junk names, and make a lots of text files all indexed different ways.  Or could make tons and tons of symlinks to make everyone happy.  Or a cvar to let you choose it.  Or do whatever you want safe in the knowledge no one will care enough to submit a rival patch.

[UniqPhoeniX]

Or wait until Tremfusion adds a cvar containing date and time (maybe game time too ).

[Paradox]

Why not just mapname/yyyy-mm-dd.jpg?

[David]

Because then I have to go through a stack of folders to find all of todays shots.

[Ingar]

mapname can't be done because I have to be able to check if a file with a certain number already exists.
I can't use wildcards.

In any case, I cleaned up the patch some more, format stays the same (yyyymmdd-nnnn) but the number resets to 0
on date changes. Demos and videos now use the same naming convention. (I did not change the autorecord demo names).

http://ingar.satgnu.net/tremulous/files/tremulous-gpp1-screenshot_timestamp3.patch

[Thorn]

How many Ingar's does it take to change a screenshot?

[David]

Six.  One to write the patch and 5 to fight off the ravaging hordes.

[gimhael]

mapname can't be done because I have to be able to check if a file with a certain number already exists.
I can't use wildcards.

Wouldn't it make things alot simpler if you just add an archived cvar that holds the date and number of the last screenshot/avi ? Then you don't need to check for existing files at the start, you just continue where you last stopped.

[Ingar]

mapname can't be done because I have to be able to check if a file with a certain number already exists.
I can't use wildcards.

Wouldn't it make things alot simpler if you just add an archived cvar that holds the date and number of the last screenshot/avi ? Then you don't need to check for existing files at the start, you just continue where you last stopped.

The last used number is stored in a static int but it still has to scan the first time. It seems a bit overkill
to make it more complicated 

How many Ingar's does it take to change a screenshot?

Six.  One to write the patch and 5 to fight off the ravaging hordes.

I have an infinite number of scary monkeys.

[Lakitu7]

So is this now done, tested, and ready to go in, with people generally happy about the results?

[Liskey]

Silence means consent - so it must be all good :-)

But since I'm snowed in and bored, I'll ask why would wildcards even be mentioned as an issue.  Don't you need to read all the filenames anyway in order to find the latest?  Just parse out the date and sequence number and ignore the rest -- it makes no difference how filenames are formatted or what else they contain.

Code:

nextn = 0
today = current_date()
while (fname = readdir(dir)) {
  if (parse_date(fname) == today) {
     if (n=parse_nnnn(fname) >= nextn) nextn = n
  }
}
nextn += 1

 

[Winnie the Pooh]

Ingar has become a developer?

[mooseberry]

What are you talking about?

[Winnie the Pooh]

What are you talking about?

I'm talking about Ingar's work going straight into the official Final.

So is this now done, tested, and ready to go in, with people generally happy about the results?

[mooseberry]

What are you talking about?

I'm talking about Ingar's work going straight into the official Final.

So is this now done, tested, and ready to go in, with people generally happy about the results?

I don't think/didn't know he is official dev, (although I could be wrong for sure) but this is open source, so anyone can create something useful, and "anything" could "potentially" end up being included in 1.2.

[gimhael]

Silence means consent - so it must be all good :-)

But since I'm snowed in and bored, I'll ask why would wildcards even be mentioned as an issue.  Don't you need to read all the filenames anyway in order to find the latest?  Just parse out the date and sequence number and ignore the rest -- it makes no difference how filenames are formatted or what else they contain.

Code:

nextn = 0
today = current_date()
while (fname = readdir(dir)) {
  if (parse_date(fname) == today) {
     if (n=parse_nnnn(fname) >= nextn) nextn = n
  }
}
nextn += 1

 

Ingar keeps the current file number in a variable, but the variable is lost when you quit and restart tremulous, so it has to scan the existing files to find the highest existing number. After the first screenshot it's just a matter of incrementing a counter.

An other possibility to fix this is to keep the counter value over restarts by storing it in the autogen.cfg.

[Liskey]

Yes of course, he explained all that.

mapname can't be done because I have to be able to check if a file with a certain number already exists. I can't use wildcards.

That was the question - mapname can certainly be included in filenames, there is no reason to use wildcards, and you can check if a file already exists using readdir.

[Ingar]

What are you talking about?

I'm talking about Ingar's work going straight into the official Final.

So is this now done, tested, and ready to go in, with people generally happy about the results?

I don't think/didn't know he is official dev, (although I could be wrong for sure) but this is open source, so anyone can create something useful, and "anything" could "potentially" end up being included in 1.2.

Sorry for the somewhate late response, but I still wanted to clear this up:

I am not an official developer, but I knew how to write code before I could make maps.
When there's something about a program that bothers me, I sometimes take the time to
correct it, make a patch and offer it to the developers. I already did this for a lot
of programs, not just tremulous.

In general, developers tend to pay more attention to patches than to random suggestions.