GET FREE INSTANT DATA TRANSFER SPEED ENLARGEMENT

[Setras]

Hi guys, and there i am again.

Sorry for such topic name, but the idea was mindblowing onve i've thought about it.

What i suggest is a "morse method" modification.

By using emote morse you can transmit one of 76 emotes each 1/3 second.

But we can't do it faster. We need either more emotes or less delay between them.

What i suggest is using target selection method instead.

Imagine if there are 2 people. Let's say that 0 is man A and 1 is man B. You can transmit lots of data per second in binary by selecting either A (0) B(1) or Deselecting (let's say D, means same symbol as previous).

So for coding 10101011 you need to send BABABABD and ingame it looks like rapid selection of both people and then deselecting them.

Or 11100111 could be encoded as BDBADBDB, that means select B, deselect, select again (so we send 1 1 1 ) then select a (0) and deselect it (again 0). then same 111 sequence.

But then... Imagine a whole raid of 24 people. Now you can use 24-al system. And data transfer speed increases in progression.

Furthermore, you are not only limited by people in your raid, but you can use everyone around, the problem is that if they move out you can't select them, so it's a problem.

So we can use and encode any amount of any transferable data, and send it at very large speeds.

This is just an idea and it has no realization yet, but this system can transfer data faster than emote icons one.

Also, once we have such fast data transfer system we can add our own rules like "each word(byte) is made of 8 bits" or "if i send 11111111 this means end of line" or by simply transferring any ancoding system to AO...

Also we can add rules like system is binary (a player that uses it, any other target, deselect) and by sending special data like a player's objectId following an "add person" command will add a person to encoding system (like adding a var to an array) or something like that so we could increase from binary to trinary and further on-the-fly.

[SLA]

I just got an e-mail alert about a new topic, which title looked like "GET FREE INSTANT ..... ENLARGEMENT", and came to delete it, but it turned out, that it isn't a spam )

[Ciuine]

I thought the same thing SLA, hilarious.

The issue I see with this is attention span or requirements of the users. The emote morse code in MasterLoot is meant to send an itemId that other players would have no knowledge of its existence otherwise. So in order for another player to see this data using this targeting binary; they'd have to enable the code manually (so as to not be running all the time), target the Master Looter, and then the Master Looter would have to send the ID and hope all people in the group were targeting the Master Looter and that they don't drop target or they themselves don't accidentally target something else.

A chat log saver true and true, but systematically the same or worse/better requirements on the users themselves.

These are obviously just opinion based flaws, it's a great concept and very usable beyond what you mentioned even, by changing the base as you said from binary to others just by the number of possible targets. But it does require some extra thought on implementation as it does require the user to do something to get this data from another player.

[Setras]

True, this requires users not to switch targets by an error or misclick.

BTW i lol'ed here:

EVENT_AVATAR_TARGET_TARGET_CHANGED

Событие посылается при изменении основной цели основной цели (это не опечатка) аватара.

Whis looks like "This event is sent when main target of main target of (this is not a type-o) avatar is changed".

Users could have this turned on always, they don't require to turn it on and off each time. This could just filter all the target of target changes and turn on and send ID's only after a certain sequence. Like ADBDABAD or something like that (depends on system we use) and end on ending sequence (should not be same as starting), also sender could send info all the time looped untill roll is made, and he can send item ID's or roll ID's or anything else that could differ one roll from other, so if there are 3 items he can send theiir sequences all the time looped untill one is rolled and he stops putting it in the loop.

Imagine 1 as a starting word, 2 as a finishing word, and 3 4 5 as three different item sequencdes containing all the needed data.

So once a masterlooter picks up an item he starts to send 1 - 3 - 2 - 1 - 3 - 2 (start transfer - transfer item 2 data - stop transfer), and once he picks up another two items he starts to send 1 3 2 1 4 2 1 5 2 1 3 2 1 4 2 1 5 2.

And each player who targets the master looter will see the item's ID eventually.

Maaaan, if the data transfer method will be fast enough we will be able to insert something like integrity check - if a player selects some wrong target he won't corrupt the data...

[Guest Carnifex]

Yes, it's a very nice concept, but has some problem, which must be solved before particle use.

The first is the problem mentioned by Ciuine: We only can get the target of another player, if he target us or we have target him. If we havn't tarhet him and he targets another person to send the msg, we will not receive any data from that targeting. So we need to send a startcode, which say, that someone will share data by this method and we must target him (this must be done to each player, which should recieve the date seperate e.g. as short code of self targeting, detargeting and targeting of the other player). The next problem with this is, that we can only listen to one player with this method at the same time. If to players start sending data at the same time we will get in trouble... (will be continued, when I have new thoughts to it^^)

BTW: "emotes each 1/3 second" -> 1/3sec??? -> I've tested it and it looks like that emotes have a cooldown of 1 sec.

BTW²: Any idea, how fast you method will work?

Edit: you was faster than me^^

[Ciuine]

I had a thought while I was driving to lab. Merge the two codes.

Initialize, specific emote sent by Master Looter, add-on receives emote, checks if target is Loot Master, forces player to target Loot Master, depending on speed afterwards, runs hopefully very quick target of target binary recognition pattern, translates into ID while targeting the last known target of the user.

Edit: This would remove the issue of it being invasive, or requiring of user input, and also would fix the issue involving the current emote morse code problems in the RU client.

[Setras]

Well IMO message recognition mechanisms could be runned always, i don't think that it's a problem to add info to an array if target switches it's target, remove 1-st (0-th?) entry if there is more than 8 and chech if the pattern equals to "start transmit".

And about player-actions - player should just select the lootmaster. Everyone knows who lotmaster is, and once you target him you automatically receive all his messages.

This mechanism is less player-action-requiring than turning emote-mechanisms on and off each time.

[Ciuine]

I really think a combination of the two techniques is the most user friendly. Zero user input for all party members aside from the Loot Master clicking a button which sends a single defined emote. The single emote is recognized by the add-on and then forces targeting of the Loot Master, runs the target pattern in a single cycle, translates, displays the item, targets old target and stops.

One emote in the chat box, no excess user input. No need for emote mechanism switches, just define an emote or even a Say based chat command to initialize.

I don't like the transmission concept, as it disables the Loot Master's ability to play the game as long as there is an item to be delivered.