If you do, try turning it off. It's been known to cause some issues with GMCP in the past (essentially, everything is stored and compressed Lusternia-side until you get a prompt, or something else triggers it to send a chunk).
That, and I ran into the issue that if I changed targets, it didn't update until I changed rooms, vitals changed, etc.
Just send an empty command (I just use SendNoEcho("") in MUSHclient) to get a prompt, it should send the information. If I do that, it's either sent with a bunch of other commands or I gag the prompt, both of which should be easy enough to do in Mudlet I think. It's not an MCCP issue, but one with how Lusternia handles subnegotiation.
EDIT: And I just realised I misread Ssaliss's last post saying the same thing I did. Ignore me, no caffeine in the bloodstream yet.
So I've been playing around with IRE.Time a bit, and managed to extract a couple of things.
First of all, IRE.Time.Update isn't actually sent when daynight changes, but rather a second or two before it changes. This means that when you get a daynight time of 122, it'll very soon change to 125.
Second, each daynight value directly corresponds with a time. So 122, for instance, is always 21:00, 125 is always 21:30. Some are duplicated, though; for instance, 129 is also 21:30. (do note that this was thoroughly tested during one hour and a little bit; there might be some errors, although it seems to match up as far as I've seen since that test.)
With that out of the way, here's a list of daynight times and what time it precedes (for instance, a few seconds after you get daynight time 45 through IRE.Time.Update, it'll turn into 11:30). Technically, the internal time is 11:00 for daynight 45, but once you get the update message, there's just a couple of seconds left for that daynight anyway. [spoiler] 0: 05:30 3: 05:30 6: 06:00 9: 06:30 12: 07:00 15: 07:30 18: 07:30 21: 08:00 24: 08:30 27: 09:00 30: 09:30 33: 09:30 36: 10:00 39: 10:30 42: 11:00 45: 11:30 48: 11:30 51: 12:00 54: 12:30 57: 13:00 60: 13:30 63: 13:30 66: 14:00 69: 14:30 72: 15:00 75: 15:30 78: 15:30 81: 16:00 84: 16:30 87: 17:00 90: 17:30 93: 17:30 96: 18:00 100: 18:30 103: 19:00 107: 19:30 111: 19:30 114: 20:00 118: 20:30 122: 21:00 125: 21:30 129: 21:30 133: 22:00 137: 22:30 140: 23:00 144: 23:30 148: 23:30 151: 00:00 155: 00:30 159: 01:00 162: 01:30 166: 01:30 170: 02:00 174: 02:30 177: 03:00 181: 03:30 185: 03:30 188: 04:00 192: 04:30 196: 05:00 [/spoiler] It would be awesome if we could get the IRE.Time.Update message when the time actually changes and not a couple of seconds early, as well as a IRE.Time.List when the day changes, but for now this'll have to do.
That doesn't quite seem to match all the way. Try 159/162/164, for instance, or 140/144/148 (unless I mischecked something somewhere).
Okay, figured it was fairly right from the few random values I tested, but yeah, it's a bit off. Close, but not quite there. I'm having trouble matching your values exactly admittedly, and I'm not sure whether it's the dataset there or just something weird on the game's side. I'll play around with it a bit more, though anything else I've tried already with the current dataset fails a lot earlier my testing methodology is terrible.
I was considering making a formula for it as well, but then I noticed that the first hundred daynight values cover 12.5 hours, and the second 11.5 hours, so I'm not sure it's even possible to make a single all-encompassing formula.
Just a heads up for anybody who's trying to make any sort of script refraining entities (denizens mostly):
gmcp.Char.Items.Add = called when something enters the room gmcp.Char.Items.Remove = called when something leaves the room gmcp.Char.Items.Update = called when something dies in the room, but -with the creature's corpse-. That baffled me for a while till I figured out. The ID seems to be the same then the ID of the creature while it was alive.
Yep. Mobs are handled identically to items. Additionally, you can see if an object is a mob or an item by checking for the presence (or absence) of the "m" attrib.
After a little fiddling, I discovered that you can send "Char.Items.Room" to the server to get Char.Items.List be filled with the contents of the room.
Yup, using Mudlet. Working on my own system and trying to set up an event for removing overhaul afflictions via gmcp. Just not sure how I do it without testing every possible affliction to see if that was the one sent to be removed.
Also, for generally you should always be able to inspect the gmcp stuff using display(gmcp.Char.Afflictions.Remove) from within your event code.
Also can call that using the 'lua' command from your command prompt in mudlet, provided you had a appropriate event. That data of the last event of that kind stays around.
gmcp.char.vitals.<whatever balance you need> - check char.vitals for the full list
Two questions:
1. Is there a lag for people staying in comm.channel. players? This is what I'm currently getting:
<div>Sylari|Rivius|Andral|Ayre|Bandeon|Avalni|Olwen|Eleniel
(and me)
Currently, there is 1 Commune Member on this Plane and 9 on other Planes.
</div>
The top list is me scraping gmcp. As you can see, the numbers don't add up I'm pretty sure Sylari isn't online, but it's showing her.
1a. Does this only show people I share channels with? Is there a way to grab the entire online list?
2. Is there an event I have to send to have IRE send back the updated affliction list? The list it's returning is from 2 days ago:
<div></div>
<pre class="CodeBlock"><code><div>You are:
deaf.
(deafness - cured by eat earwort and eat myrtle)
You have 1 affliction.</div><div><br></div><div>"name=haemophilia|cure=eat puritydust|desc=Haemophilia will prevent your blood from clotting."|"name=manabarbs|cure=smoke soothingsteam|desc=Manabarbs will cause bodily damage whenever mana is used."|"name=egovice|cure=smoke soothingsteam|desc=Egovice will cause bodily damage whenever ego is used."|"name=achromaticaura|cure=smoke soothingsteam|desc=Achromaticaura will increase all damage to you that is linked to the attacker's charisma."</div>
I'm trying sending gmcp.afflictions, but it's not making the list update.
3. Is there a way to have these affs and defs return akin to vitals (eg x=y, ie paralysis=1)?
Regarding the player list, it's updated on request by the client. I'm not aware of any lag (and if there is, it should be less than 10 minutes; that's how often I update it, IIRC).
As for afflictions, I've never really looked into it much, since I don't fight. Seems odd though; possibly a client issue?
Sweet, thanks. The players was a client issue (forgot CMUD wants a variable when sending GMCP request). The afflictions is not a client issue, really, it seems - it's just displaying the last info it received and I can't figure out what request to send to get the game to send me the updated list.
0.0020 | [1] lustynolink Comline : start :
0.0014 | l lustynol | Alias "affget" compiled (Normal) : $affs=%gmcp.char.afflictions.list
0.0012 | n lustynol | Exec Alias "affget"
0.0024 | d lustynol | [1] lustynolink Comline : stopped
No data is coming through, so my client is displaying the most recent data it has from that list. (Ignore my weird session name, I named it that when I hadn't setup mudbot)
Looks like it may be a Lusternia problem? I opened a raw session in Achaea, made myself blind and got a nice list output from gmcp. Raw session on Lusternia shows this:
0.0039 | d rawlusty | [1] rawlusty Comline : stopped
0.1833 | i rawlusty *You are:<CR><LF>
0.0000 | blind.<CR><LF>
0.0000 | deaf.<CR><LF>
0.0000 | You have 2 afflictions.<CR><LF>
0.0000 | <IAC><SB><201>Char.Afflictions.List [ ]
Sending empty list. (Also, lol at my decade-old-dormant-for-about-as-long naked character being targetted by a pickpocket within 30 seconds of logging in to test in Achaea) EDIT: Figured it out. Looks like not everything is viewed as an aff by Lusty. Blind, deaf, bleeding don't show up. Paralysis does. Maybe only overhaul affs?
@Ssaliss thanks for the thread and the reply. This is very helpful
@Breandryn only overhaul afflictions will show up, I think they said. For the record, blind and deaf have their own gmcp values, I believe in gmcp.Char.Vitals.blind and gmcp.Char.Vitals.deaf respectively, supposedly ( guessing ) because of truedeaf / secondsight.
The only way to get a full list of your affs is to use the in game command diag, since it is equilibrium based skill you can't get the info from just a GMCP call.
Right. No free gmcp diag. As new afflictions are added they are sent under the add table, and not added to the gmcp list. This behavior can be confusing, but you can't just copy the list for your affs, you have to track them one by one as gmcp tells you to add/remove them.
I figured. The generic affliction lines are great, it's just a shame the overhaul isn't fully finished and so there are outliers that I'm still learning of. I had been hoping to use GMCP for those, but it doesn't work on non-overhaul affs.
I figured. The generic affliction lines are great, it's just a shame the overhaul isn't fully finished and so there are outliers that I'm still learning of. I had been hoping to use GMCP for those, but it doesn't work on non-overhaul affs.
As other have said, only overhaul affs show up in the GMCP. Blind and Deaf have gmcp values under Char.Vitals (blind and deaf, 0 is you don't have the aff, 1 is you do.).
Outside a few affs (freezing, ablaze, and non-standard curing affs like fear or disrupted), the affs not in the overhaul yet are monk affs. Turning on aff messages is a big help unless the aff is masked. Then it might be a good idea to use the afflict lines (and diag lines) for the affs that haven't been overhauled yet and deal with it that way.
Comments
First of all, IRE.Time.Update isn't actually sent when daynight changes, but rather a second or two before it changes. This means that when you get a daynight time of 122, it'll very soon change to 125.
Second, each daynight value directly corresponds with a time. So 122, for instance, is always 21:00, 125 is always 21:30. Some are duplicated, though; for instance, 129 is also 21:30. (do note that this was thoroughly tested during one hour and a little bit; there might be some errors, although it seems to match up as far as I've seen since that test.)
With that out of the way, here's a list of daynight times and what time it precedes (for instance, a few seconds after you get daynight time 45 through IRE.Time.Update, it'll turn into 11:30). Technically, the internal time is 11:00 for daynight 45, but once you get the update message, there's just a couple of seconds left for that daynight anyway.
[spoiler]
0: 05:30
3: 05:30
6: 06:00
9: 06:30
12: 07:00
15: 07:30
18: 07:30
21: 08:00
24: 08:30
27: 09:00
30: 09:30
33: 09:30
36: 10:00
39: 10:30
42: 11:00
45: 11:30
48: 11:30
51: 12:00
54: 12:30
57: 13:00
60: 13:30
63: 13:30
66: 14:00
69: 14:30
72: 15:00
75: 15:30
78: 15:30
81: 16:00
84: 16:30
87: 17:00
90: 17:30
93: 17:30
96: 18:00
100: 18:30
103: 19:00
107: 19:30
111: 19:30
114: 20:00
118: 20:30
122: 21:00
125: 21:30
129: 21:30
133: 22:00
137: 22:30
140: 23:00
144: 23:30
148: 23:30
151: 00:00
155: 00:30
159: 01:00
162: 01:30
166: 01:30
170: 02:00
174: 02:30
177: 03:00
181: 03:30
185: 03:30
188: 04:00
192: 04:30
196: 05:00
[/spoiler]
It would be awesome if we could get the IRE.Time.Update message when the time actually changes and not a couple of seconds early, as well as a IRE.Time.List when the day changes, but for now this'll have to do.
EDIT: Lucidity is "slush"
gmcp.Char.Items.Add = called when something enters the room
gmcp.Char.Items.Remove = called when something leaves the room
gmcp.Char.Items.Update = called when something dies in the room, but -with the creature's corpse-. That baffled me for a while till I figured out. The ID seems to be the same then the ID of the creature while it was alive.
edit: fixed assumption about ID of corpse.
enjoy
Also can call that using the 'lua' command from your command prompt in mudlet, provided you had a appropriate event. That data of the last event of that kind stays around.
http://nexus.ironrealms.com/GMCP
== Professional Girl Gamer ==
Yes I play games
Yes I'm a girl
get over it
Two questions:
1. Is there a lag for people staying in comm.channel. players? This is what I'm currently getting:
The top list is me scraping gmcp. As you can see, the numbers don't add up
1a. Does this only show people I share channels with? Is there a way to grab the entire online list?
2. Is there an event I have to send to have IRE send back the updated affliction list? The list it's returning is from 2 days ago:
I'm trying sending gmcp.afflictions, but it's not making the list update.
3. Is there a way to have these affs and defs return akin to vitals (eg x=y, ie paralysis=1)?
Edit: code tags failing me bad
As for afflictions, I've never really looked into it much, since I don't fight. Seems odd though; possibly a client issue?
No data is coming through, so my client is displaying the most recent data it has from that list. (Ignore my weird session name, I named it that when I hadn't setup mudbot)
Sending empty list.
(Also, lol at my decade-old-dormant-for-about-as-long naked character being targetted by a pickpocket within 30 seconds of logging in to test in Achaea)
EDIT: Figured it out. Looks like not everything is viewed as an aff by Lusty. Blind, deaf, bleeding don't show up. Paralysis does. Maybe only overhaul affs?
@Ssaliss thanks for the thread and the reply. This is very helpful
As other have said, only overhaul affs show up in the GMCP. Blind and Deaf have gmcp values under Char.Vitals (blind and deaf, 0 is you don't have the aff, 1 is you do.).
Outside a few affs (freezing, ablaze, and non-standard curing affs like fear or disrupted), the affs not in the overhaul yet are monk affs. Turning on aff messages is a big help unless the aff is masked. Then it might be a good idea to use the afflict lines (and diag lines) for the affs that haven't been overhauled yet and deal with it that way.