I’ve noticed that a variety of plugins transmit data from player to player. NavComp, for example, can coordinate navigation routes via the station bar chat, granted that multiple users are docked in the same station. Other plugins appear to use more elaborate methods such as the TCPsocket(), etc.

I believe that the standard chat interface is more than sufficient to accomplish similar tasks. The only problem, however, is that transmitting data over chat channels is rather disruptive to the normal flow of chat. So this is what I propose:

Allow us to add a simple text based prefix to the beginning of outgoing chat messages, it could be something as simple as #silent#. Chat messages that are sent with this prefix would still trigger events such as CHAT_MSG_GIULD within plugins, but would not actually be visibly displayed in the primary chat interface.

As a1k0n wrote when explaining the TCPsocket...
http://vendetta-online.com/x/msgboard/16/17247

“Now, this is somewhat confusing stuff. You can't just write regular straight-line send-this-recv-that socket code and expect it to work.”

So I guess what I am proposing is an extremely simple method to accomplish “send-this-recv-that” from within the client, piggybacking easily off of what already exists.

I suggest this be limited to Guild and Group chats.

Edit: I should probably mention that, yes, I am aware that you can hook the chat receiver and effectively mute messages of your choice. This is geared more towards creating a native system, for those who would not be using the associated plugin, or phone/tablet users who might struggle to install such a plugin.

-1

As you indicated, this sort of thing can be accomplished with a plugin.

What you're proposing is a kludge. And while something like this might be acceptable for a plugin, if the devs are going to take the time to implement something in the client, it might as well be done right and not be a half-baked bandaid.

Why not create an entirely new set of events to handle the proposed functionality? There is no reason to piggyback off the chat system to implement this.

Obviously, I would prefer an entirely new set of events and a more complete implementation. The point is to keep it simple and save time, low hanging fruit, and so on. I honestly would really like to see something like this implemented so that I can get busy using it, and soon. The more complex the idea gets, the less likely it is to become a reality. Perhaps I should mention that I am not so dead set on the specific mechanics, not at all. I am simply interested in the end result, however it may be achieved

I've done a lot of research on this particular issue. It is actually possible to send silent transmissions to your guild members using the guild bank description. Also, when you send a PM via the API its a silent PM and you can easily write a function that checks if it has some text in it to tell it not to display on the receiving end.

So there are two methods of 'piggybacking' (to borrow meridians term). But I have looked extensively into decentralising communication systems using just the in-game protocols and the reason you MUST use a third party server is simply this: rate limiting.

Every single method of text transfer currently existing in VO has some form of rate limiting for obvious reasons. And better than just being rate limited, it's also character limted. So you can only ever send a certain number of characters through any given time. Plenty to have a fluid conversation, but probably not enough to fully realise the potential of any sort of guild transfer based information system; even if you encrypt or cypher the text.

The end result is that you buy a virtual server and you use lua tcpsocket and json messages like that because VO was specifically designed so you couldn't lag the servers by sending a veritable crap-ton of automated data sends.

Sorry mate but it's not an original question, lots and lots of people have thought of it before and they all end up at the same conclusion when they're presented with the realities of what they can pass through the game: it's better just to use a damn 3rd party server.

hook chatreceiver if you want to hide chat messages.

This thread should be moved to community projects.

Ok, thanks TRS, I will do some research on virtual servers. However, I still feel that this is a bit excessive. In my opinion, the fact that people are resorting to third party solutions only further confirms that there truly is a demand for such functionality, at least in some form, within the api.

I understand and agree with the need for rate limiting. It is a concession that I am more than willing to make. The negative impact of rate limiting, however, is dependent on the application. Not every possible application would transmit enough data for it to be a problem.

The current chat rate limiting would serve just fine, even if it were more strict. The true goal is simply a method to move it into the background... Hooking the chat receiver is only relevant to users, anyone else receives no benefit.

"The negative impact of rate limiting, however, is dependent on the application. Not every possible application would transmit enough data for it to be a problem."

No no no no no no. You're not getting it.

Unless your goal is to send a basic message from one person to another (you know, something that you can do with a private message script or guild chat script like the target info thingy) then it's still too limited to do anything because its not limited by the application it's limited by the number of peers you want to send data to.

Even if you want to send rudimentary 5 character messages to your guild, you are going to have to mess with complicated buffer systems which will impact your normal ability to send messages or perform other normal game functions.

What you're asking for i.e. headless messages is possible but I defy you to try and make even the most basic plugin without running into so many problems with the way the game is setup. It will have 0 scalability and your inner programmer will die.

Virtual server relay is the only way to go.

"Unless your goal is to send a basic message from one person to another (you know, something that you can do with a private message script or guild chat script like the target info thingy)"

LOL Yes! Basic messages, this is exactly what I am talking about :) The point is simply to silence them, but still have them trigger API events, to avoid spamming and disrupting the normal flow of chat - without also requiring absolutely everyone to install a plugin that hooks the chat receiver, especially phone and tablet users... I'm not talking about a live data stream, just an occasional chirp.

Read the rest of my post, its limited by peers, what you're describing is basically just a chat message. But VO will not let you send that chat message to 3+ people at a time. What use is that?

You can also use group chat or a randomly selected numbered channel for one-to-many messages. it's not hard to make this sort of thing scale as long as you aren't *sending* a lot at once.

Yep. And if you go with a high-numbered channel, you don't have to worry about disrupting people who aren't using the plugin, since they wouldn't be listening on that channel anyway.

you will still need a plugin to tell the receivers not to display the messages

But the receivers need a plugin anyway in order to actually use the data, so who cares? The goal here is to avoid disturbing the people who don't have the plugin, and if they aren't listening on the data channel, they won't be disturbed.

yeah I didn't get that part either about not requiring 'absolutely everyone' to install a plugin, if you're doing anything with this, its with a plugin, so only the people who had the plugin would get use out of the data.

So yes, you can do it already with simple messages using a numbered channel but if that answer satisfies you're really not doing anything especially fantastic with the plugin; at least nothing like what's available out there already i.e. TCFT2/Anyx/Voce/Navcomp which all use virtual servers and tcpsocket to send data.

And besides, these systems work because they are (relatively) secure, so not just anybody can access the data. If you're doing it on a channel it would not be nearly as secure so I guess my question to you is what the hell are you actually planning on doing.

It's not like you're making a plugin to take credit card payments or anything; this is a video game. A randomly selected oddball channel would probably suffice, and if that's not good enough, encrypt the messages.

Its harder for somebody to find your specific channel than it is for somebody to be motivated to pass the plugin code onto a dodgy character. That is not a solution to the issue of security.

Whoa. So you're saying, like, people could betray you? Trippy idea, dude!

There's a difference between one person betraying you and you having to boot them out of the system and one person betraying you forcing you to change or replace the entire system.

We would prefer if people did not push third-party data through the game chat. Virtual servers are a much better way of going about this. We've had a lot of bad experiences with poor user-written plugin architecture (just on the client-side), and the last thing we need are super-spammy plugins that saturate our network and server with chat messages that only a few people care about.

If you really want to move data around, use an out-of-band TCP connection, that's what it's there for.