GMCP

Jacen

I don't see the problem with updating the table on QL/L/WHO HERE/visible entrances. Your character sees that person enter, so they should have access to that information whether in retard or aeon. If they're in blackout, they yeah, don't update it, but if you receive the line "Jacen enters from the west", I don't see a legitimate argument against adding that to the table. But that's just my opinion that spam shouldn't be used to hide things. 

Eld

Nizaris said:

Veldrin said:

It would assumably just be like the gmcp event for removing/adding items on your inventory, except it'd be on people leaving or entering the room in a way you can visible discern, if you can't see the person entering the event for it won't fire and doing QL/WHO HERE/LOOK would simply send the entire table

@Eld: @Veldrin's statement was my assumption of the functionality.

Right, but since it would only fire on visible entrances and exits, which you can already parse to keep track of things, it's not allowing you to do anything you can't already.

Nizaris

Eld said:

Nizaris said:

Veldrin said:

It would assumably just be like the gmcp event for removing/adding items on your inventory, except it'd be on people leaving or entering the room in a way you can visible discern, if you can't see the person entering the event for it won't fire and doing QL/WHO HERE/LOOK would simply send the entire table

@Eld: @Veldrin's statement was my assumption of the functionality.

Right, but since it would only fire on visible entrances and exits, which you can already parse to keep track of things, it's not allowing you to do anything you can't already.

Fair enough.

Cardan

Weapon wield hand is now represented by 'l' for wielded left and 'L' for wielded right.

Race change events should now fire properly for things like dragonforming and lesserforming (amongst others)

Gwawr

The left/right hand thing is very nice, but there's one fly in the ointment: weapons that need both hands to wield (bows, bastard swords, etc) show up as indistinguishable from left-hand items when wielded.

Also I just found a bug: SWAP HANDS doesn't send Char.Items.Update with the new state.

Cardan

Two-handed items should now show as "lL" to signify both hands being involved.

SWAP HANDS should also now send a Char.Items.Update for the two items involved.

Veldrin

something for when you lose a follower or you stop following someone? (Not when someone sneaky follows you though, unless you checked group)

Xith

Not terribly familiar with what's possible through GMCP, but how about team coloring through arena events? So it'd be possible to overwrite your personal highlights with team colors correctly.

Nim

I'm not sure that's something feasible with GMCP (there could be a prefix message that says "the next line you get includes thisperson on thisteam"), but I personally would like a way to turn that on/off. For whatever reason, how I currently have my highlights set up, the team color stuff interferes with that and prevents them from working properly.

That said, as a completely random thought, don't team colors potentially restrict illusions?

Personally, I wish all balancing issues around illusions were put on hold, the game were improved as if they didn't exist, and illusions were just allowed to send fake GMCP messages too. I would love if there was a GMCP message attached to each affliction message listing what affliction (or what potential afflictions, if there're multiple) it could have caused, and the only problem I see with it are serpent illusions... so, why not let serpents be able to fake those too?

ETA: Obviously, only GMCP messages that it'd make sense a serpent could illusion would count. Not anything like, your skills list.

Eld

I doubt illusioning GMCP events would be feasible, since the server doesn't really pay attention to the contents of the illusion, beyond checking the character and newline limits. If I "CONJURE NIM ILLUSION You eat a bloodroot leaf." the server has no way of knowing that that message is the one that's usually associated with a particular Char.Items.Remove event. Also, since the Char.Items.Remove event refers to a specific item id, it would probably be rather confuse the software on the server side if you didn't have a bloodroot leaf in inventory. Maybe there are ways to get around complications like that, but I suspect they'd be hideously complicated.

Nim

Although something as simple as that would be pretty cool, I was imagining a more defined method, like...

CONJURE NIM ILLUSION AFFLICTION CURE PARALYSIS You eat a bloodroot leaf.

It would be complicated, yes, and ideally there'd be a way to keep it elegant and simple, but I personally would like it!

Vadimuses

Can anyone post what Aetolias illusions were changed to? It was something mechanical that they put in.

Yue

@Nim: No. 

Personally, I really dislike the idea of prefabricating illusions for players. This takes all of the fun (work) out of being a good illusionist.

Iocun

Nim said:

Although something as simple as that would be pretty cool, I was imagining a more defined method, like...

CONJURE NIM ILLUSION AFFLICTION CURE PARALYSIS You eat a bloodroot leaf.

It would be complicated, yes, and ideally there'd be a way to keep it elegant and simple, but I personally would like it!

This would mean creating new keywords whenever something new is added to the GMCP functionality and weeding out all bugs and problems associated with it. I also dislike the general direction of having Achaea communicate more and more "privately" with clients and leaving the people behind the screens unaffected. This also leads to fighting/illusioning in ever more "mechanical" ways that only try to target scripts and not players.

The beauty about abilities like illusion or force is their openness. They do not work around a predefined whitelist of illusions/commands, but are mostly just restricted by a few blacklisted items, as well as the imagination of the user. This is what makes using such abilities so challenging and fun, and this is what we'd lose if we went anywhere in the direction of the Aetolian system.

Yes, GMCP offers us nice convenience, but personally I value upholding the versatility of Achaea's skill/combat system higher than making everything as convenient as anyhow possible, so when it comes to conflicts between adding some GMCP message for convenience or keeping something combat-relevant illusionable, I'll always vote for the latter, particularly seeing that in its current state, most things in Achaea really aren't that inconvenient already.

Tvistor

Vadimuses said:

Can anyone post what Aetolias illusions were changed to? It was something mechanical that they put in.

I don't know the specifics, but I think serpent illusions were deleted for faster doublestabs and (I'm really terribly uninformed) they had afflictions that did nothing but provide 100% chance to be cured over other afflictions of the same cure type.

And I think their doublestab is based off dirk speed, and some classes do actually have regular illusions.

I am basing this off my 6 hours of playing it.

Nim

On a slightly different discussion (I'm sure someone can argue that this is still related to illusions vs GMCP, but the module already exists!), could the Comm.Channel module be improved a bit?

Right now, it sort of sandwiches the channel message between two GMCP messages, which seems really kind of weird, since the only discrete information you get from it is the channel name (and, if it's a tell, the other player, but not even whether they sent it or you sent it). Given the abundance of GMCP messages that essentially provide discrete information without the need to gather it via triggers, it seems odd how you still basically need triggers to get anything out of the message itself.

(Also, it doesn't really work on tintin++, since tintin++ seems to parse all telnet (and thus GMCP) messages before even looking at the text. This isn't so bad if you only receive a single game message in any given packet, because you'd know that the next line after the Comm.Channel.Start and End messages is attached to those GMCP messages... but it becomes messier when you receive multiple channel messages in a single packet.)

A quickly drafted suggestion could be as followed, although this is more just to show what I mean than a suggested final version.

Comm.Channel.Msg
* Informs the client that something's been said over a communication channel
* Message body is an object containing the keys "name", "char", and "msg"
* In the case of tells, the name value is either "tellout" (when the tell was sent by the client) or "tellin" (when the tell was sent by the other player). Otherwise, the name value is the same as would be reported by Comm.Channel.List
* Example: Comm.Channel.Msg { "name":"ct", "char":"player1", "msg":"Hey, player2. Let's take this to tells." }
* Example: Comm.Channel.Msg { "name":"tellin", "char":"player2", "msg":"Sure thing!" }

If the placement of the Start and End messages are for some reason important for IRE clients, you could keep the End message as is, and sandwich the in-band message between the above and an End message, or something like that.

Alternatively, it could be argued that it should be removed because it might let you avoid channel illusions (but that argument is silly, because you can already use channel colors for that purpose!)

Vadimuses

I agree Comm.Channel's implementation is currently poor - GMCP is an out of band protocol, and it's hitched on in-band data right now.

Veldrin

Would be neat if there'd be sent a 'honours x' just before the actual honours goes through.. Or there'd be a static line opening it up that we could trigger off

Eld

Just occured to me, in light of the recent addition of the "m" and "t" attribute tags in GMCP.Char.Items events, could we also get an "r" or something for riftables?

Dodder

Assuming it's not already the case, I'd like to see if I'm graced or not via GMCP.

That'd be very helpful!

Eld

Eld said:

Just occured to me, in light of the recent addition of the "m" and "t" attribute tags in GMCP.Char.Items events, could we also get an "r" or something for riftables?

Just realised this already exists. Don't mind me, move along, nothing to see here.

Iocun

It existed, but then suddenly it stopped working and we got weird other attributes on some riftables while still sometimes having "r". Not sure what's up with that and whether it has been fixed yet.

Eld

Iocun said:

It existed, but then suddenly it stopped working and we got weird other attributes on some riftables while still sometimes having "r". Not sure what's up with that and whether it has been fixed yet.

Ah, interesting. I only checked a few herbs and minerals, which all had attribute 'gr'.

Trevize

Groupable/Riftable?

Eld

Trevize said:

Groupable/Riftable?

Yes. Sigils, for example, just have "g".

Cardan

For items in your inventory:

Wearable: W

Worn: w

Wielded Both: lL

Wielded Left: l

Wielded Right: L

Groupable: g

Riftable: r

Is Container: c

For denizens in the room:

Is Dead: d

Can Be Taken: t

Is a denizen: m

Yes - the gmcp-doc file needs updating. Msg has already been passed up to get it done

ETA: As Eld pointed out - missed the is a denizen line. Sorry!

Eld

Cardan said:

For items in your inventory:

Wearable: W

Worn: w

Wielded Both: lL

Wielded Left: l

Wielded Right: L

Groupable: g

Riftable: r

Is Container: c

For denizens in the room:

Is Dead: d

Can Be Taken: t

Yes - the gmcp-doc file needs updating. Msg has already been passed up to get it done

Seems to be missing "m" for "mobile".

Lynara

Cardan said:

Just as an upfront definition, we will not be adding any GMCP metrics that have combat balance implications. This means no to combat-related balances, defences, afflictions, etc.

ETA - wilderness coordinates and date/time are already under consideration

I understand the 'combat related balances' that are not displayed in the prompt however CEXKDB defences would be nice for GMCP, at least while not in blackout... They show anyhow in the prompt, so should have no new combat implications.

Lynara

Jacen said:

Just don't have that table update on evade events. Have it update on visible people entering/leaving, and look/quick look/who here events.

Expanding here, Char.Items-esque is the way to go with a gmcp tracking of people in the room - Char.Items handles secreted items quite well... does not show when they enter your inventory, as there is no Char.Items.Add message sent on it. So, in the same respect, have a 'Char.People', with 'Char.People.Add' and "Char.People.Remove", as well as a "Char.People.List" - list would -only- be sent on l/ql/entering a room, and only when those things aren't hindered, say by unholy darkness and no nightsight, being trueblind, or some such.

This would completely mitigate the 'evade' issue, as well as provide a good way to track people in the room.

On another note, could track the 'qw' list as well with this same list of people; just have a 'location' sent with the add/remove/list, so you know if it applies to 'room' or 'plane'... although, I'd say that the list of people in-realms should be able to  be requested, 'Char.People.Request' therefore would be nice, but only for the list of people in realm (and not gemmed/off plane), not for the list of people in the room.

ETA: Oh, darn. Teach me to read the whole page before replying - what Veldrin said...

Cardan

Just as an update given the recent GMCP updates, the items I currently have listed as pending improvements to GMCP are:

Current players elevation

List of players in room

Ship prompt

Org memberships including aideship/position