Have been running this version since release, but have not been playing much lately as i have been working a lot. Such an evil world it is
I have noticed some small bug though. When as a masteradmin putting a recent track in the jukebox gives a warning message that the track has been played recently, which is true but as the command is beeing issued as a masteradmin i guess it should not be displayed, and the track is added to the jukebox correctly
That's not a bug but an intentional warning, so that the masteradmin can decide to drop it again when there was no intention to (ab)use his/her powers by queuing a recently played track already again.
soehest wrote:/list newest is a very nice addition but does not seem to be working on recent tracks added via /admin add xxx. Doing a /list newest after the add command does not reveal the new tracks(s) at once, first when the track changes which is a bit late, as i would like to use this command to put in new tracks in the jukebox without having to browse all tracks with the /list command
works by checking the database for the highest challenge IDs, but a track is only added there when it's first loaded by the server and an onNewChallenge event is sent to the database plugin. So that requires a /list
(search by track name saves browsing through many pages though) and /jukebox
The only other approach, which is the one /add
takes, is to add the track immediately to the jukebox after downloading it via /admin add
. I'm actually not sure why the latter doesn't do that the same way as the user /add
, but can make that a new option.
soehest wrote:Another thing completely off topic is the ban and blacklist commands. As far as i can tell the blacklist command has a file (blacklist.xml) which enables one to save blacklisted players where as the ban command does not have this and thus all bans will disappear when doing a server restart. Are there any other differences in theese?
The banlist also stores the IP and client (computer name) of the banned players, and blocks players by IP. The blacklist stores only logins and thus blocks players by those logins. As to why no calls
exist in the TMN server to read and write the banlist just like the blacklist and guestlist... I don't know.
Would it be possible to adapt the blacklist behaviour to the ban list as people to tend to use the ban command (which imho is the correct term for a user not being able to log in to the server) so there is a banlist.xml as well, and that this files gets autoupdated when doing a new ban or unban. And reloaded at server startup. I do forget to write those files and can't see the point of not keeping those files up2date as changes happen so theese files would always reflect the current ban list. I apologise if this has been asked ealier
A couple of things are mixed up here. First, it's important to understand the blacklist and banlist are maintained inside the TMN server, but it provides read/write calls to a file only for the blacklist (and guestlist). So I can't adapt one to the other inside
Aseco because their meaning and use is defined and controlled outside
Second, the blacklist.txt file (and guestlist.txt) is already read automatically when the TMN server starts up and finds it in the GameData/ directory (this is the reason why my renaming the file to blacklist.xml in v0.89 had to be reverted in v0.90).
Third, while it's possible to grab the banlist from the server and write it to a file in XML, there's no point in doing that because such a file cannot be read back and restored in the TMN server's banlist. That's because the Ban server call (to add a player to the banlist) works only on players (logins) that are online, as only then can the server obtain that IP and clientname to include in the list. The BlackList server call does
work on offline logins because all it has to do is store those logins.
The only thing that isn't done yet, is to write out the current blacklist and guestlist whenever a player is added or removed, so that the files on disk are at least always current with the TMN server. I'll add that to the next release.
Btw, you said "people to tend to use the ban command" but if by people you mean users, that's because with the CallVotes system there is no blacklist vote, only a ban vote; and with the chat-based voting system there is no /ban command at all, so I'm not sure how they could "tend to use" it. Perhaps you meant admins instead of users, and they have a choice whether to use ban or blacklist, while keeping in mind the above information about their respective purposes.
Oh yes i also do have a small request
A shuffle command which can shuffle the current tracks based on length so it will shuffle the tracklist between long and short tracks. So a server can have a tracklist with one long, one short one long etc... Or if this cannot be made just a shuffle command so i don't have to restart the server to shuffle the tracks
The former isn't really feasible: you'd have to read the track list, remove all the tracks from the track list, sort it by alternating
long and short author times (for which no PHP sort call exists so that would have to be programmed manually), and add them all back to the server. Thanks... but no thanks.
The latter will be possible in the imminent v0.91 by using /admin writetracklist
and /admin readtracklist
, see page 3
of this thread.
What happened to the dedimania record system, were plans dropped?
No, but as mentioned before that's a complex and time-consuming subproject, and I first wanted to get all the 'simpler' requests and subprojects cleared off my plate.
Not to mention lengthy forum posts like this.
But now that you mention it, I did write a simple "hello world"-type script this weekend to learn more about how it works. So there's your progress report on that.