Mudlet-2.0 release candidates [latest: Mudlet 2.0 final]
Re: 2.0 snapshots
Yes, these files are missing, I don't have them either Babelfish probably forgot to commit them.
Re: 2.0 snapshots
They'll be added in later. It's fine that they aren't there right now.
Re: 2.0 snapshots
i'm playing around with roomuserdata, but things don't go well.
seems like if the room doesn't have any userdata stored on it, it doesn't return anything..
seems like if the room doesn't have any userdata stored on it, it doesn't return anything..
would be nice if it returned false or nil or anything. but at the moment echo("test1") is not even executed.
Re: 2.0 snapshots
I have also noticed....
getRoomUserData NEEDS to return nil or false if it does not exist.....
last time I checked.... this was NOT being saved with the map either.( so completely useless after you restart the client)
getRoomUserData NEEDS to return nil or false if it does not exist.....
last time I checked.... this was NOT being saved with the map either.( so completely useless after you restart the client)
Re: 2.0 snapshots
User data is being saved with the map. I'll return false if the key doesn't exist in the future. Right now I'll raise a Lua error which is pretty idiotic.
Re: 2.0 snapshots
Your bug report (detail: On updates to the gmcp.Char.Status section, instead of updating
the value, a new table with only the updated value is sent, clearning out all other information
within it. As of right now, this is fixable by doing SCORE to receive a full table.) - has been
removed because it is not a bug (usually meaning that this is the way things are intended to be).
Please accept our apologies for any inconvenience or misunderstanding that may be involved. The
following notes were included: GMCP is functioning correctly in that only the tabular value being
changed is sent in the GMCP packet. It would seem that there is a problem in the client-side script
that is expecting the entire table to be present every time anything changes rather than just the
value to be updated. The fact that the gmcp.Char.Status table is being cleared would be the result
of the same client-side script expecting a full table of values and not getting them, ergo clearing
them locally. Fix the bug in the client script to not expect the entire table and it should work
fine..
BUG: When any update to the Char.Status table is recieved, (IE, they update just the xp variable of the table), it clears the entire table. This is Achaea's response to the bug.
the value, a new table with only the updated value is sent, clearning out all other information
within it. As of right now, this is fixable by doing SCORE to receive a full table.) - has been
removed because it is not a bug (usually meaning that this is the way things are intended to be).
Please accept our apologies for any inconvenience or misunderstanding that may be involved. The
following notes were included: GMCP is functioning correctly in that only the tabular value being
changed is sent in the GMCP packet. It would seem that there is a problem in the client-side script
that is expecting the entire table to be present every time anything changes rather than just the
value to be updated. The fact that the gmcp.Char.Status table is being cleared would be the result
of the same client-side script expecting a full table of values and not getting them, ergo clearing
them locally. Fix the bug in the client script to not expect the entire table and it should work
fine..
BUG: When any update to the Char.Status table is recieved, (IE, they update just the xp variable of the table), it clears the entire table. This is Achaea's response to the bug.
Re: 2.0 snapshots
Gotta admit that their approach to it makes sense, though (in not sending an entire table for one changed value).
Re: 2.0 snapshots
Is there any chance the split-screen console could be fixed? Maybe it's just me on linux with funny font sizes or something, but take the following screenshots for example:
No split:
Split:
Note that in the split screen, I can no longer see the newest line, even in the bottom section, and part of the bottom section is also in the top. In fact, it looks like no matter how high you drag the split-line up, the top section shows all but the last three lines. Eg:
No split:
Split:
Note that in the split screen, I can no longer see the newest line, even in the bottom section, and part of the bottom section is also in the top. In fact, it looks like no matter how high you drag the split-line up, the top section shows all but the last three lines. Eg:
Re: 2.0 snapshots
Make the main window a tiny bit bigger until you see the last line. It's prolly an unfortunate screen resolution/font size thingy in your case.
Re: 2.0 snapshots
I can confirm this issue in my version of Mudlet on Linux as well.Widjet wrote: (Images removed)
Is there any chance the split-screen console could be fixed? Maybe it's just me on linux with funny font sizes or something, but take the following screenshots for example:
Note that in the split screen, I can no longer see the newest line, even in the bottom section, and part of the bottom section is also in the top. In fact, it looks like no matter how high you drag the split-line up, the top section shows all but the last three lines. Eg: