Prefix in Chat

[kevATin]

I think a prefix (chat-only, so it's simple text and doesn't mess with the server or client) would be quite useful. There could be an option for a prefix that's applied to every message sent from a player. Which in the case of my MMORPG server would be the player level variable (server specific, not Altitude experience/ace related). This is actually also the reason why I came up with the chat prefix idea, because I couldn't find any other place to put the player levels, Alti doesn't exactly offer a lot of GUI real estate. Another option could be prefixes for specific players, either identified by VaporID or simply admin, moderator, etc status. Admins could have [A], Moderators could have [M] and the server itself could have [S]. The admins and moderators would also include the player level variable, but I suppose having inheritance for multiple prefixes would be overkill, especially since most altitude servers don't have all that many admins.

[biell]

I don't have any control over what a player's chat looks like. Their client communicates with the server and the server sends it out to everyone, then logs something so I know what they said. But, after the fact and I can't change it. That being said, there a couple ways I can think of for people to know about other people.

1. Join notifications When a player joins, you could tell them the stats on all the players who are on-line right now. Additionally, if a player is on-line and a new person joins, you could send them the information about that player. Players would then always be made aware of the information about their fellow players.

2. Override my "/who " command This command prints out information about a user. You could add a hook for when that command is run, and add all your own information about the person. People would have to know to run the command, but then you could output whatever you wanted.

3. Add a command If we added a command like "/playerInfo" then it could be a stub. You could create an alti+ script which responded to it (similar to the "/game" command which is a stub for the same purpose). It could be "/players" or something else, the name is up for debate. In this case, players would have to know to run the command, but when run, you could output all the information you want about all the players currently on-line.

[kevATin]

the server sends it out to everyone

I was kinda hoping the server could modify the message before it forwards it to the clients. Like inject a piece of text "[A]" into it~ Or is that more something that would require a patched server?

Join notifications

Hm nice, but not really what I was looking for. It'd spam the chat quite a bit if the player activity goes. Even if it'd be limited to handle relogging by say only write it once every five minutes, it could still get a lot quickly with 20-30 players. Also you'd have trouble figuring out a persons level if your and their login lays back a long time, alti's chat isn't exactly good for re-finding information.

Override my "/who " command

Now that one's better, I hadn't paid that /who command any thought at all when i read through the readme. Giving that information to players shouldn't be much of a problem, I plan to have a "tutorial" area where players have to pick up "?"-powerups that use "/add note"; and even throughout the world map I'll probably place random bits of information so players don't forget it.

Is any of the information that /who gives out fixed, or can it all be changed relatively easily?

Add a command

"stub" in this context refers to a list or collection of stuff that can be expanded, right? Or do you have a different definition in mind when you use it like that?

I don't see much need for creating a separate command for that when /who should work fine. Being able to give information about more than one player at a time and most importantly players other than the one that the user is inputting, is quite an advantage- but currently I don't have much use for it. If the MMORPG idea takes off then I guess we could add /bestList and /bestOnline commands or similar, but for the time being I don't see the need.

Do you think you could add information about whether the player is an admin or moderator into /who? I think that could be useful on all kinds of servers.

[biell]

the server sends it out to everyone

I was kinda hoping the server could modify the message before it forwards it to the clients. Like inject a piece of text "[A]" into it~ Or is that more something that would require a patched server?

Join notifications

It would take a server patch to do this.

Hm nice, but not really what I was looking for. It'd spam the chat quite a bit if the player activity goes. Even if it'd be limited to handle relogging by say only write it once every five minutes, it could still get a lot quickly with 20-30 players.

Remember that there is chat::all and chat::team, and chat::whisper, and the last one only sends a message to a single player. So, on join, only the new player gets the message about the existing players. But, yes, everyone would get the message about the new player.

Also you'd have trouble figuring out a persons level if your and their login lays back a long time, alti's chat isn't exactly good for re-finding information.

Override my "/who " command Now that one's better, I hadn't paid that /who command any thought at all when i read through the readme. Giving that information to players shouldn't be much of a problem, I plan to have a "tutorial" area where players have to pick up "?"-powerups that use "/add note"; and even throughout the world map I'll probably place random bits of information so players don't forget it.

Is any of the information that /who gives out fixed, or can it all be changed relatively easily?

You can login and run /who against yourself. That output would still be sent to the user. But, you could also respond to a /who event and send your own stuff. You can choose to extend who:pre and respond first or extend who which will respond after the base Alti+ code.

Add a command

"stub" in this context refers to a list or collection of stuff that can be expanded, right? Or do you have a different definition in mind when you use it like that?

So, the Altitude server needs to know about all commands, so it can send them to the client. We would need either a stub (empty command which exists only to be overriden by alti+scripts scripts) or a new mechanism in Alti+ for you to register your own commands.

I don't see much need for creating a separate command for that when /who should work fine. Being able to give information about more than one player at a time and most importantly players other than the one that the user is inputting, is quite an advantage- but currently I don't have much use for it. If the MMORPG idea takes off then I guess we could add /bestList and /bestOnline commands or similar, but for the time being I don't see the need.

This makes me think that adding a mechanism for you to add your own commands would be better than stubs.

Do you think you could add information about whether the player is an admin or moderator into /who? I think that could be useful on all kinds of servers.

You have access to this information via player::admins, so you could report this with your extension.

[kevATin]

So, on join, only the new player gets the message about the existing players. But, yes, everyone would get the message about the new player.

Yeah I was referring to the second one. I think that'd fill the chat too much.

/who

I'll play around with it later, if it's showing me too much of what I don't like I'll just comment out who-code in alti+server until it starts complaining xd

So, the Altitude server needs to know about all commands, so it can send them to the client. We would need either a stub (empty command which exists only to be overriden by alti+scripts scripts) or a new mechanism in Alti+ for you to register your own commands.

After I wrote the reply I went googling and found this quite informative https://en.wikipedia.org/wiki/Method_stub too. "temporary substitute for yet-to-be-developed code", so like a dummy or stand-in that's expanded later on based on your needs..

I think now I'm starting to get it. So what you meant is that if I want actual new commands in alti they need to be defined before, simply scripting ~if player msg /xyz then do xyz ~ won't work because /xyz was never defined as a command, right? Does Altitude treat all /commands as failures if they weren't in the list of commands? Like does it even send /testtest to the server if I enter that in my client or does my client simply assume that there won't be a result because the server never defined that command? Or does it send the command to the server, so technically the server is made aware of it and could act on it but the client would display a "command not found" in the chat before I can act on the results, so it just wont look nice in chat?

This makes me think that adding a mechanism for you to add your own commands would be better than stubs.

Yeah if extending command functionality is currently that complicated, maybe I guess it'd be nicer to have actual support for adding them on your own. Maybe a new alti+commands folder next to the alti+scripts folder, where every file(name) is registered as a command at server start or something like that. Don't know how much work that'd be to get working on your part~ Well in any case I'll have to work on the map and generally figuring out some of the gameplay mechanics first, so there's no hurry to get that feature.

You have access to this information via player::admins, so you could report this with your extension.

Ah yeah I figured that much, just thought that'd be one of the features that'd be useful for all kinds of servers so maybe it'd be good to include in /who by default.

[biell]

So, the Altitude server needs to know about all commands, so it can send them to the client. We would need either a stub (empty command which exists only to be overriden by alti+scripts scripts) or a new mechanism in Alti+ for you to register your own commands.

After I wrote the reply I went googling and found this quite informative https://en.wikipedia.org/wiki/Method_stub too. "temporary substitute for yet-to-be-developed code", so like a dummy or stand-in that's expanded later on based on your needs..

You got it, that is what I was referring to.

I think now I'm starting to get it. So what you meant is that if I want actual new commands in alti they need to be defined before, simply scripting ~if player msg /xyz then do xyz ~ won't work because /xyz was never defined as a command, right? Does Altitude treat all /commands as failures if they weren't in the list of commands? Like does it even send /testtest to the server if I enter that in my client or does my client simply assume that there won't be a result because the server never defined that command? Or does it send the command to the server, so technically the server is made aware of it and could act on it but the client would display a "command not found" in the chat before I can act on the results, so it just wont look nice in chat?

Your instincts are correct, the Altitude server sends a list of command to the client and says: "I support /who, and /assignTeam, ..." You can look in your custom_json_commands.txt file in your servers directory to see what is being sent.

This makes me think that adding a mechanism for you to add your own commands would be better than stubs.

I agree, but it will be a bit of work. The custom_json_commands.txt file is only read on server start. I set this file up for you before reading your scripts. And I also allow you to add new scripts or update your scripts on the fly with /script reload on the console. Under this case, you would need to restart the altitude server after loading the script. So, it is totally possible, but we would need to define a workflow that makes sense.

Yeah if extending command functionality is currently that complicated, maybe I guess it'd be nicer to have actual support for adding them on your own. Maybe a new alti+commands folder next to the alti+scripts folder, where every file(name) is registered as a command at server start or something like that. Don't know how much work that'd be to get working on your part~

I have worked pretty hard to keep you from having to manage files, I really couldn't get around it for the alti+scripts folder, but I would like to keep configuration files out of this. As it stands now, I manage the following files for you: launcher_config.xml, json_stash.txt, custom_json_commands.txt, mods_json_commands.txt, mods.hjson, and permissions.hjson.

I would have to figure out how to registers new commands for starts of the altitude server. I may need to re-order things to make that happen right. Let's see if you really need it, and then I can work out the logistics. It would probably look something like adding a statement to your script as such: REGISTER "cmd" ["arg1", "arg2", "..."];. I would then want you to implement HOOKS to answer to cmd and possibly help cmd. I would then have to look at the impact of running script::install before config::launcher in my code. There probably is none.

Well in any case I'll have to work on the map and generally figuring out some of the gameplay mechanics first, so there's no hurry to get that feature.

You have access to this information via player::admins, so you could report this with your extension.

Ah yeah I figured that much, just thought that'd be one of the features that'd be useful for all kinds of servers so maybe it'd be good to include in /who by default.

Maybe, I will consider that.