Improvement: Custom MXP elements now support default values for arguments (#6853)
<!-- Keep the title short & concise so anyone non-technical can
understand it,
the title appears in PTB changelogs -->
#### Brief overview of PR changes/additions
Custom Element Definition and Handler are changed to handle default
values by ATT="EntityName=DefaultValue" as specified in the MXP protocol
definition.
#### Motivation for adding to Mudlet
Improve MXP compliance.
#### Other info (issues closed, discussion etc)
To see this issue (in addition to reviewing the test code coming with
this PR):
connect to aldebaran-mud.de port 2000
login as guest
y (confirm you want to login as a guest)
Now do:
who
Notice the mouse-over hint on your (or another players) name in the who
output.
Right click and try some commands. Admittedly guest has no finger info,
and the game does not allow you to tell to yourself (and you have to
wait for a few minutes for your mana to build up for tell), so you can't
really do much.
Alternatively, you can just login with another guest character (but
mudlet needs a second game profile for this) and "look". The issue is
the same with the short description of the other guest character. But
here you can also select "whisper" from the menu, which will work
nicely.
BTW, all commands are just copied in the input line, even for "finger
guest" you have to hit enter. This is by design / limitation of the MXP
SEND command (you cannot choose 'PROMPT' per menu entry, only globally).
With the current mudlet version this does not work. This is due to the
definition:
<!EL PL '<SEND "tell &NAME; |finger &NAME; " HINT="tell
&NAME;|finger &NAME;" PROMPT>' ATT='NAME=someone'>
Mudlet misinterpretes 'NAME=someone' as the whole name of the entity,
not just NAME.
The effect of the default value 'someone' is not easy to demonstrate,
except when you can find an invisible wizard and convince him to to
interact with you. However, you can do:
say ^<PL player_id>Test1</PL>
and
say ^<PL>Test2</PL>
and see/use the menus created by/in Mudlet for the echo of Test1 and
Test2. You'll see how it refers to player_id or someone.
Note that Mudlet should actually not evaluate the PL tag in the say
command, as it is a secure MXP tag and the session is in open mode at
this time. However, Mudlet does not honor this security measure as of
now, which is another, unrelated, issue.
2023-05-30 19:16:10 +02:00
|
|
|
/***************************************************************************
|
|
|
|
|
* Copyright (C) 2020 by Gustavo Sousa - gustavocms@gmail.com *
|
|
|
|
|
* Copyright (C) 2020 by Stephen Lyons - slysven@virginmedia.com *
|
|
|
|
|
* Copyright (C) 2023 by Michael Weller - michael.weller@t-online.de *
|
|
|
|
|
* *
|
|
|
|
|
* This program is free software; you can redistribute it and/or modify *
|
|
|
|
|
* it under the terms of the GNU General Public License as published by *
|
|
|
|
|
* the Free Software Foundation; either version 2 of the License, or *
|
|
|
|
|
* (at your option) any later version. *
|
|
|
|
|
* *
|
|
|
|
|
* This program is distributed in the hope that it will be useful, *
|
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of *
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the *
|
|
|
|
|
* GNU General Public License for more details. *
|
|
|
|
|
* *
|
|
|
|
|
* You should have received a copy of the GNU General Public License *
|
|
|
|
|
* along with this program; if not, write to the *
|
|
|
|
|
* Free Software Foundation, Inc., *
|
|
|
|
|
* 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. *
|
|
|
|
|
***************************************************************************/
|
|
|
|
|
|
|
|
|
|
#include <QTest>
|
|
|
|
|
#include <TMxpSendTagHandler.h>
|
|
|
|
|
#include <TMxpElementDefinitionHandler.h>
|
|
|
|
|
#include <TMxpCustomElementTagHandler.h>
|
|
|
|
|
#include <TMxpFormattingTagsHandler.h>
|
|
|
|
|
#include <TMxpColorTagHandler.h>
|
|
|
|
|
#include <TMxpTagParser.h>
|
|
|
|
|
#include <TMxpTagProcessor.h>
|
|
|
|
|
|
|
|
|
|
#include "TMxpStubClient.h"
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* One can certainly argue if this should be in a separate module, but
|
|
|
|
|
* I want to include only the handlers needed by this file into the module
|
|
|
|
|
* for a sensible link time and executable size
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
class TMxpStubHandlerContext : public TMxpStubContext {
|
|
|
|
|
TMxpSendTagHandler sendTagHandler;
|
|
|
|
|
TMxpFormattingTagsHandler formattingTagsHandler;
|
|
|
|
|
TMxpColorTagHandler colorTagHandler;
|
|
|
|
|
|
|
|
|
|
public:
|
|
|
|
|
virtual TMxpTagHandlerResult handleTag(TMxpContext& ctx, TMxpClient& client, MxpTag* tag)
|
|
|
|
|
{
|
|
|
|
|
TMxpTagHandler *tagHandler;
|
|
|
|
|
|
|
|
|
|
if (sendTagHandler.supports(ctx, client, tag)) {
|
|
|
|
|
tagHandler = &sendTagHandler;
|
|
|
|
|
} else if (formattingTagsHandler.supports(ctx, client, tag)) {
|
|
|
|
|
tagHandler = &formattingTagsHandler;
|
|
|
|
|
} else if (colorTagHandler.supports(ctx, client, tag)) {
|
|
|
|
|
tagHandler = &colorTagHandler;
|
|
|
|
|
} else {
|
|
|
|
|
qDebug() << QString("unhandled Tag: [%1%2]").arg(tag->isEndTag() ? "/" : "").arg(tag->getName());
|
|
|
|
|
return MXP_TAG_HANDLED;
|
|
|
|
|
}
|
|
|
|
|
qDebug() << QString("handleTag([%1%2])").arg(tag->isEndTag() ? "/" : "").arg(tag->getName());
|
|
|
|
|
return tag->isStartTag() ? tagHandler->handleStartTag(ctx, client, tag->asStartTag()) : tagHandler->handleEndTag(ctx, client, tag->asEndTag());
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
class TMxpCustomElementTagHandlerTest : public QObject {
|
|
|
|
|
Q_OBJECT
|
|
|
|
|
|
|
|
|
|
private:
|
|
|
|
|
|
|
|
|
|
private slots:
|
|
|
|
|
QSharedPointer<MxpNode> parseNode(const QString& tagText) const
|
|
|
|
|
{
|
|
|
|
|
auto nodes = TMxpTagParser::parseToMxpNodeList(tagText);
|
|
|
|
|
return nodes.size() > 0 ? nodes.first() : nullptr;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void testCustomItemCmd() {
|
|
|
|
|
// Complex Example: Aldebaran defines a profile with definitions like this:
|
|
|
|
|
// <!EL ITI '<SEND "examine &ID;|drop &ID;" HINT="&CMDH;examine|drop">' ATT='ID'>
|
|
|
|
|
// Then uses <ITI inv##N>a rock</ITI> for brevity all over the mud (here plain ITem in Inventory)
|
|
|
|
|
// Note the use of positional parameter ID (first arg)
|
|
|
|
|
// Mudlet, up to version 4.10, made the hints ALL UPPER in this context
|
|
|
|
|
|
|
|
|
|
TMxpStubHandlerContext ctx;
|
|
|
|
|
TMxpStubClient stub;
|
|
|
|
|
TMxpTagParser parser;
|
|
|
|
|
|
|
|
|
|
ctx.getEntityResolver().registerEntity("&CMDH;", "");
|
|
|
|
|
|
|
|
|
|
auto defTag = parseNode("<!EL ITI '<SEND \"examine &ID;|drop &ID;\" HINT=\"&CMDH;examine|drop\">' ATT='ID'>)");
|
|
|
|
|
auto startTag = parseNode("<ITI inv##10>");
|
|
|
|
|
auto endTag = parseNode("</ITI>");
|
|
|
|
|
|
|
|
|
|
TMxpElementDefinitionHandler definitionHandler;
|
|
|
|
|
definitionHandler.handleTag(ctx, stub, defTag->asStartTag());
|
|
|
|
|
|
|
|
|
|
TMxpCustomElementTagHandler customElementTagHandler;
|
|
|
|
|
TMxpTagHandler& tagHandler = customElementTagHandler;
|
|
|
|
|
|
|
|
|
|
tagHandler.handleTag(ctx, stub, startTag->asStartTag());
|
|
|
|
|
tagHandler.handleContent("a rock");
|
|
|
|
|
tagHandler.handleTag(ctx, stub, endTag->asEndTag());
|
|
|
|
|
|
|
|
|
|
QCOMPARE(stub.mHrefs.size(), 2);
|
|
|
|
|
QCOMPARE(stub.mHrefs[0], "send([[examine inv##10]])");
|
|
|
|
|
QCOMPARE(stub.mHrefs[1], "send([[drop inv##10]])");
|
|
|
|
|
|
|
|
|
|
QCOMPARE(stub.mHints.size(), 2);
|
Fix: Tooltip hints for MXP hints no longer forced to uppercase (#6878)
<!-- Keep the title short & concise so anyone non-technical can
understand it,
the title appears in PTB changelogs -->
#### Brief overview of PR changes/additions
In some, but not all, occasions the tooltip hints of MXP hints were
forced to all upper case by Mudlet
#### Motivation for adding to Mudlet
Improvement of MXP compatibility, more uniform menu appearance.
#### Other info (issues closed, discussion etc)
Mudlet forced HINT attributes used in custom elements to upper case, but
only there. Note that entities were interpolated afterwards, hence not
forced to uppercase. I think the behaviour is inconsistent and not
'logically' comprehensible for a user.
Afaik, if the mud specifies a HINT text it should be display as such. If
the game wants it to show up in UPPERCASE the game should just say so.
**However,** in difference to my other MXP patches, it will change the
look of the GUI for games that somehow depend on it.
So.. it can be argued.
It does change the non uniform display of hints like those two from the
unfixed version:
and
to
Also, it used to deal with HINTs only prior to entity resolution, so
without the fix it looked like
rather than
And the only difference between these two menus (both from the unfixed
version)
is that the first uses a plain `<send>` while the second uses a custom
element.
Again, you can see this in action by connecting to aldebaran-mud.de 2000
, login as guest (y to confirm) and with 'set mxp test 4'.
2023-06-11 16:45:58 +02:00
|
|
|
QCOMPARE(stub.mHints[0], "examine");
|
|
|
|
|
QCOMPARE(stub.mHints[1], "drop");
|
Improvement: Custom MXP elements now support default values for arguments (#6853)
<!-- Keep the title short & concise so anyone non-technical can
understand it,
the title appears in PTB changelogs -->
#### Brief overview of PR changes/additions
Custom Element Definition and Handler are changed to handle default
values by ATT="EntityName=DefaultValue" as specified in the MXP protocol
definition.
#### Motivation for adding to Mudlet
Improve MXP compliance.
#### Other info (issues closed, discussion etc)
To see this issue (in addition to reviewing the test code coming with
this PR):
connect to aldebaran-mud.de port 2000
login as guest
y (confirm you want to login as a guest)
Now do:
who
Notice the mouse-over hint on your (or another players) name in the who
output.
Right click and try some commands. Admittedly guest has no finger info,
and the game does not allow you to tell to yourself (and you have to
wait for a few minutes for your mana to build up for tell), so you can't
really do much.
Alternatively, you can just login with another guest character (but
mudlet needs a second game profile for this) and "look". The issue is
the same with the short description of the other guest character. But
here you can also select "whisper" from the menu, which will work
nicely.
BTW, all commands are just copied in the input line, even for "finger
guest" you have to hit enter. This is by design / limitation of the MXP
SEND command (you cannot choose 'PROMPT' per menu entry, only globally).
With the current mudlet version this does not work. This is due to the
definition:
<!EL PL '<SEND "tell &NAME; |finger &NAME; " HINT="tell
&NAME;|finger &NAME;" PROMPT>' ATT='NAME=someone'>
Mudlet misinterpretes 'NAME=someone' as the whole name of the entity,
not just NAME.
The effect of the default value 'someone' is not easy to demonstrate,
except when you can find an invisible wizard and convince him to to
interact with you. However, you can do:
say ^<PL player_id>Test1</PL>
and
say ^<PL>Test2</PL>
and see/use the menus created by/in Mudlet for the echo of Test1 and
Test2. You'll see how it refers to player_id or someone.
Note that Mudlet should actually not evaluate the PL tag in the say
command, as it is a secure MXP tag and the session is in open mode at
this time. However, Mudlet does not honor this security measure as of
now, which is another, unrelated, issue.
2023-05-30 19:16:10 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void testCustomElementDynamicEntity() {
|
|
|
|
|
// Complex Example: Aldebaran has a global custom element MAP used in maps printed for
|
|
|
|
|
// the player to click onto it and then follow the map.
|
|
|
|
|
// However, it uses the id of the map currently looked at in an entity redefined for
|
|
|
|
|
// each map you look at.
|
|
|
|
|
// <!EL ITI '<SEND "examine &ID;|drop &ID;" HINT="&CMDH;examine|drop">' ATT='ID'>
|
|
|
|
|
// Then uses <ITI inv##N>a rock</ITI> for brevity all over the mud (here plain ITem in Inventory)
|
|
|
|
|
// Note the use of positional parameter ID (first arg)
|
|
|
|
|
// Mudlet, up to version 4.10, made the hints ALL UPPER in this context
|
|
|
|
|
|
|
|
|
|
TMxpStubHandlerContext ctx;
|
|
|
|
|
TMxpStubClient stub;
|
|
|
|
|
TMxpTagParser parser;
|
|
|
|
|
|
|
|
|
|
ctx.getEntityResolver().registerEntity("&MID;", "map of the newbie jungle");
|
|
|
|
|
|
|
|
|
|
auto defTag = parseNode("<!EL MAP '<SEND \"follow &MID; to &ID;\" HINT=\"go here\">' ATT='ID'>");
|
|
|
|
|
|
|
|
|
|
TMxpElementDefinitionHandler definitionHandler;
|
|
|
|
|
definitionHandler.handleTag(ctx, stub, defTag->asStartTag());
|
|
|
|
|
|
|
|
|
|
auto startTag = parseNode("<MAP P8x7>");
|
|
|
|
|
auto endTag = parseNode("</MAP>");
|
|
|
|
|
|
|
|
|
|
TMxpCustomElementTagHandler customElementTagHandler;
|
|
|
|
|
TMxpTagHandler& tagHandler = customElementTagHandler;
|
|
|
|
|
|
|
|
|
|
tagHandler.handleTag(ctx, stub, startTag->asStartTag());
|
|
|
|
|
tagHandler.handleContent("*");
|
|
|
|
|
tagHandler.handleTag(ctx, stub, endTag->asEndTag());
|
|
|
|
|
|
|
|
|
|
QCOMPARE(stub.mHrefs.size(), 1);
|
|
|
|
|
QCOMPARE(stub.mHrefs[0], "send([[follow map of the newbie jungle to P8x7]])");
|
|
|
|
|
|
|
|
|
|
QCOMPARE(stub.mHints.size(), 1);
|
Fix: Tooltip hints for MXP hints no longer forced to uppercase (#6878)
<!-- Keep the title short & concise so anyone non-technical can
understand it,
the title appears in PTB changelogs -->
#### Brief overview of PR changes/additions
In some, but not all, occasions the tooltip hints of MXP hints were
forced to all upper case by Mudlet
#### Motivation for adding to Mudlet
Improvement of MXP compatibility, more uniform menu appearance.
#### Other info (issues closed, discussion etc)
Mudlet forced HINT attributes used in custom elements to upper case, but
only there. Note that entities were interpolated afterwards, hence not
forced to uppercase. I think the behaviour is inconsistent and not
'logically' comprehensible for a user.
Afaik, if the mud specifies a HINT text it should be display as such. If
the game wants it to show up in UPPERCASE the game should just say so.
**However,** in difference to my other MXP patches, it will change the
look of the GUI for games that somehow depend on it.
So.. it can be argued.
It does change the non uniform display of hints like those two from the
unfixed version:
and
to
Also, it used to deal with HINTs only prior to entity resolution, so
without the fix it looked like
rather than
And the only difference between these two menus (both from the unfixed
version)
is that the first uses a plain `<send>` while the second uses a custom
element.
Again, you can see this in action by connecting to aldebaran-mud.de 2000
, login as guest (y to confirm) and with 'set mxp test 4'.
2023-06-11 16:45:58 +02:00
|
|
|
QCOMPARE(stub.mHints[0], "go here");
|
Improvement: Custom MXP elements now support default values for arguments (#6853)
<!-- Keep the title short & concise so anyone non-technical can
understand it,
the title appears in PTB changelogs -->
#### Brief overview of PR changes/additions
Custom Element Definition and Handler are changed to handle default
values by ATT="EntityName=DefaultValue" as specified in the MXP protocol
definition.
#### Motivation for adding to Mudlet
Improve MXP compliance.
#### Other info (issues closed, discussion etc)
To see this issue (in addition to reviewing the test code coming with
this PR):
connect to aldebaran-mud.de port 2000
login as guest
y (confirm you want to login as a guest)
Now do:
who
Notice the mouse-over hint on your (or another players) name in the who
output.
Right click and try some commands. Admittedly guest has no finger info,
and the game does not allow you to tell to yourself (and you have to
wait for a few minutes for your mana to build up for tell), so you can't
really do much.
Alternatively, you can just login with another guest character (but
mudlet needs a second game profile for this) and "look". The issue is
the same with the short description of the other guest character. But
here you can also select "whisper" from the menu, which will work
nicely.
BTW, all commands are just copied in the input line, even for "finger
guest" you have to hit enter. This is by design / limitation of the MXP
SEND command (you cannot choose 'PROMPT' per menu entry, only globally).
With the current mudlet version this does not work. This is due to the
definition:
<!EL PL '<SEND "tell &NAME; |finger &NAME; " HINT="tell
&NAME;|finger &NAME;" PROMPT>' ATT='NAME=someone'>
Mudlet misinterpretes 'NAME=someone' as the whole name of the entity,
not just NAME.
The effect of the default value 'someone' is not easy to demonstrate,
except when you can find an invisible wizard and convince him to to
interact with you. However, you can do:
say ^<PL player_id>Test1</PL>
and
say ^<PL>Test2</PL>
and see/use the menus created by/in Mudlet for the echo of Test1 and
Test2. You'll see how it refers to player_id or someone.
Note that Mudlet should actually not evaluate the PL tag in the say
command, as it is a secure MXP tag and the session is in open mode at
this time. However, Mudlet does not honor this security measure as of
now, which is another, unrelated, issue.
2023-05-30 19:16:10 +02:00
|
|
|
|
|
|
|
|
// Now player looks at another map and gets an MXP button to go to another place.
|
|
|
|
|
// Note the MAP element is NOT redefined, only the entity.
|
|
|
|
|
ctx.getEntityResolver().registerEntity("&MID;", "map of the south forest");
|
|
|
|
|
startTag = parseNode("<MAP P42>");
|
|
|
|
|
endTag = parseNode("</MAP>");
|
|
|
|
|
|
|
|
|
|
tagHandler.handleTag(ctx, stub, startTag->asStartTag());
|
|
|
|
|
tagHandler.handleContent("*");
|
|
|
|
|
tagHandler.handleTag(ctx, stub, endTag->asEndTag());
|
|
|
|
|
|
|
|
|
|
QCOMPARE(stub.mHrefs.size(), 1);
|
|
|
|
|
QCOMPARE(stub.mHrefs[0], "send([[follow map of the south forest to P42]])");
|
|
|
|
|
|
|
|
|
|
QCOMPARE(stub.mHints.size(), 1);
|
Fix: Tooltip hints for MXP hints no longer forced to uppercase (#6878)
<!-- Keep the title short & concise so anyone non-technical can
understand it,
the title appears in PTB changelogs -->
#### Brief overview of PR changes/additions
In some, but not all, occasions the tooltip hints of MXP hints were
forced to all upper case by Mudlet
#### Motivation for adding to Mudlet
Improvement of MXP compatibility, more uniform menu appearance.
#### Other info (issues closed, discussion etc)
Mudlet forced HINT attributes used in custom elements to upper case, but
only there. Note that entities were interpolated afterwards, hence not
forced to uppercase. I think the behaviour is inconsistent and not
'logically' comprehensible for a user.
Afaik, if the mud specifies a HINT text it should be display as such. If
the game wants it to show up in UPPERCASE the game should just say so.
**However,** in difference to my other MXP patches, it will change the
look of the GUI for games that somehow depend on it.
So.. it can be argued.
It does change the non uniform display of hints like those two from the
unfixed version:
and
to
Also, it used to deal with HINTs only prior to entity resolution, so
without the fix it looked like
rather than
And the only difference between these two menus (both from the unfixed
version)
is that the first uses a plain `<send>` while the second uses a custom
element.
Again, you can see this in action by connecting to aldebaran-mud.de 2000
, login as guest (y to confirm) and with 'set mxp test 4'.
2023-06-11 16:45:58 +02:00
|
|
|
QCOMPARE(stub.mHints[0], "go here");
|
Improvement: Custom MXP elements now support default values for arguments (#6853)
<!-- Keep the title short & concise so anyone non-technical can
understand it,
the title appears in PTB changelogs -->
#### Brief overview of PR changes/additions
Custom Element Definition and Handler are changed to handle default
values by ATT="EntityName=DefaultValue" as specified in the MXP protocol
definition.
#### Motivation for adding to Mudlet
Improve MXP compliance.
#### Other info (issues closed, discussion etc)
To see this issue (in addition to reviewing the test code coming with
this PR):
connect to aldebaran-mud.de port 2000
login as guest
y (confirm you want to login as a guest)
Now do:
who
Notice the mouse-over hint on your (or another players) name in the who
output.
Right click and try some commands. Admittedly guest has no finger info,
and the game does not allow you to tell to yourself (and you have to
wait for a few minutes for your mana to build up for tell), so you can't
really do much.
Alternatively, you can just login with another guest character (but
mudlet needs a second game profile for this) and "look". The issue is
the same with the short description of the other guest character. But
here you can also select "whisper" from the menu, which will work
nicely.
BTW, all commands are just copied in the input line, even for "finger
guest" you have to hit enter. This is by design / limitation of the MXP
SEND command (you cannot choose 'PROMPT' per menu entry, only globally).
With the current mudlet version this does not work. This is due to the
definition:
<!EL PL '<SEND "tell &NAME; |finger &NAME; " HINT="tell
&NAME;|finger &NAME;" PROMPT>' ATT='NAME=someone'>
Mudlet misinterpretes 'NAME=someone' as the whole name of the entity,
not just NAME.
The effect of the default value 'someone' is not easy to demonstrate,
except when you can find an invisible wizard and convince him to to
interact with you. However, you can do:
say ^<PL player_id>Test1</PL>
and
say ^<PL>Test2</PL>
and see/use the menus created by/in Mudlet for the echo of Test1 and
Test2. You'll see how it refers to player_id or someone.
Note that Mudlet should actually not evaluate the PL tag in the say
command, as it is a secure MXP tag and the session is in open mode at
this time. However, Mudlet does not honor this security measure as of
now, which is another, unrelated, issue.
2023-05-30 19:16:10 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void testCustomElementDefaultAttributes() {
|
|
|
|
|
// This example literally taken from the MXP definition at https://www.zuggsoft.com/zmud/mxp.htm#ELEMENT
|
|
|
|
|
//
|
|
|
|
|
// <!ELEMENT boldtext '<COLOR &col;><B>' ATT='col=red'>
|
|
|
|
|
//
|
|
|
|
|
// Then you could use it on the MUD like this:
|
|
|
|
|
//
|
|
|
|
|
// <boldtext>This is bold red</boldtext>
|
|
|
|
|
// <boldtext col=blue>This is bold blue text</boldtext>
|
|
|
|
|
// <boldtext blue>This is also bold blue text</boldtext>
|
|
|
|
|
|
|
|
|
|
TMxpStubHandlerContext ctx;
|
|
|
|
|
TMxpStubClient stub;
|
|
|
|
|
TMxpTagParser parser;
|
|
|
|
|
|
|
|
|
|
auto defTag = parseNode("<!ELEMENT boldtext '<COLOR &col;><B>' ATT='col=red'>");
|
|
|
|
|
|
|
|
|
|
TMxpElementDefinitionHandler definitionHandler;
|
|
|
|
|
definitionHandler.handleTag(ctx, stub, defTag->asStartTag());
|
|
|
|
|
|
|
|
|
|
auto startTag = parseNode("<boldtext>");
|
|
|
|
|
auto endTag = parseNode("</boldtext>");
|
|
|
|
|
|
|
|
|
|
TMxpCustomElementTagHandler customElementTagHandler;
|
|
|
|
|
TMxpTagHandler& tagHandler = customElementTagHandler;
|
|
|
|
|
|
|
|
|
|
tagHandler.handleTag(ctx, stub, startTag->asStartTag());
|
|
|
|
|
tagHandler.handleContent("This is bold red");
|
|
|
|
|
// is it?
|
2023-05-31 19:44:48 +02:00
|
|
|
QCOMPARE(stub.bold(), true);
|
Improvement: Custom MXP elements now support default values for arguments (#6853)
<!-- Keep the title short & concise so anyone non-technical can
understand it,
the title appears in PTB changelogs -->
#### Brief overview of PR changes/additions
Custom Element Definition and Handler are changed to handle default
values by ATT="EntityName=DefaultValue" as specified in the MXP protocol
definition.
#### Motivation for adding to Mudlet
Improve MXP compliance.
#### Other info (issues closed, discussion etc)
To see this issue (in addition to reviewing the test code coming with
this PR):
connect to aldebaran-mud.de port 2000
login as guest
y (confirm you want to login as a guest)
Now do:
who
Notice the mouse-over hint on your (or another players) name in the who
output.
Right click and try some commands. Admittedly guest has no finger info,
and the game does not allow you to tell to yourself (and you have to
wait for a few minutes for your mana to build up for tell), so you can't
really do much.
Alternatively, you can just login with another guest character (but
mudlet needs a second game profile for this) and "look". The issue is
the same with the short description of the other guest character. But
here you can also select "whisper" from the menu, which will work
nicely.
BTW, all commands are just copied in the input line, even for "finger
guest" you have to hit enter. This is by design / limitation of the MXP
SEND command (you cannot choose 'PROMPT' per menu entry, only globally).
With the current mudlet version this does not work. This is due to the
definition:
<!EL PL '<SEND "tell &NAME; |finger &NAME; " HINT="tell
&NAME;|finger &NAME;" PROMPT>' ATT='NAME=someone'>
Mudlet misinterpretes 'NAME=someone' as the whole name of the entity,
not just NAME.
The effect of the default value 'someone' is not easy to demonstrate,
except when you can find an invisible wizard and convince him to to
interact with you. However, you can do:
say ^<PL player_id>Test1</PL>
and
say ^<PL>Test2</PL>
and see/use the menus created by/in Mudlet for the echo of Test1 and
Test2. You'll see how it refers to player_id or someone.
Note that Mudlet should actually not evaluate the PL tag in the say
command, as it is a secure MXP tag and the session is in open mode at
this time. However, Mudlet does not honor this security measure as of
now, which is another, unrelated, issue.
2023-05-30 19:16:10 +02:00
|
|
|
QCOMPARE(stub.fgColor, "red");
|
|
|
|
|
tagHandler.handleTag(ctx, stub, endTag->asEndTag());
|
|
|
|
|
|
|
|
|
|
// back to defaults:
|
2023-05-31 19:44:48 +02:00
|
|
|
QCOMPARE(stub.bold(), false);
|
Improvement: Custom MXP elements now support default values for arguments (#6853)
<!-- Keep the title short & concise so anyone non-technical can
understand it,
the title appears in PTB changelogs -->
#### Brief overview of PR changes/additions
Custom Element Definition and Handler are changed to handle default
values by ATT="EntityName=DefaultValue" as specified in the MXP protocol
definition.
#### Motivation for adding to Mudlet
Improve MXP compliance.
#### Other info (issues closed, discussion etc)
To see this issue (in addition to reviewing the test code coming with
this PR):
connect to aldebaran-mud.de port 2000
login as guest
y (confirm you want to login as a guest)
Now do:
who
Notice the mouse-over hint on your (or another players) name in the who
output.
Right click and try some commands. Admittedly guest has no finger info,
and the game does not allow you to tell to yourself (and you have to
wait for a few minutes for your mana to build up for tell), so you can't
really do much.
Alternatively, you can just login with another guest character (but
mudlet needs a second game profile for this) and "look". The issue is
the same with the short description of the other guest character. But
here you can also select "whisper" from the menu, which will work
nicely.
BTW, all commands are just copied in the input line, even for "finger
guest" you have to hit enter. This is by design / limitation of the MXP
SEND command (you cannot choose 'PROMPT' per menu entry, only globally).
With the current mudlet version this does not work. This is due to the
definition:
<!EL PL '<SEND "tell &NAME; |finger &NAME; " HINT="tell
&NAME;|finger &NAME;" PROMPT>' ATT='NAME=someone'>
Mudlet misinterpretes 'NAME=someone' as the whole name of the entity,
not just NAME.
The effect of the default value 'someone' is not easy to demonstrate,
except when you can find an invisible wizard and convince him to to
interact with you. However, you can do:
say ^<PL player_id>Test1</PL>
and
say ^<PL>Test2</PL>
and see/use the menus created by/in Mudlet for the echo of Test1 and
Test2. You'll see how it refers to player_id or someone.
Note that Mudlet should actually not evaluate the PL tag in the say
command, as it is a secure MXP tag and the session is in open mode at
this time. However, Mudlet does not honor this security measure as of
now, which is another, unrelated, issue.
2023-05-30 19:16:10 +02:00
|
|
|
QCOMPARE(stub.fgColor, "");
|
|
|
|
|
|
|
|
|
|
startTag = parseNode("<boldtext COL=blue>)");
|
|
|
|
|
tagHandler.handleTag(ctx, stub, startTag->asStartTag());
|
|
|
|
|
tagHandler.handleContent("This is bold blue text");
|
|
|
|
|
// is it?
|
2023-05-31 19:44:48 +02:00
|
|
|
QCOMPARE(stub.bold(), true);
|
Improvement: Custom MXP elements now support default values for arguments (#6853)
<!-- Keep the title short & concise so anyone non-technical can
understand it,
the title appears in PTB changelogs -->
#### Brief overview of PR changes/additions
Custom Element Definition and Handler are changed to handle default
values by ATT="EntityName=DefaultValue" as specified in the MXP protocol
definition.
#### Motivation for adding to Mudlet
Improve MXP compliance.
#### Other info (issues closed, discussion etc)
To see this issue (in addition to reviewing the test code coming with
this PR):
connect to aldebaran-mud.de port 2000
login as guest
y (confirm you want to login as a guest)
Now do:
who
Notice the mouse-over hint on your (or another players) name in the who
output.
Right click and try some commands. Admittedly guest has no finger info,
and the game does not allow you to tell to yourself (and you have to
wait for a few minutes for your mana to build up for tell), so you can't
really do much.
Alternatively, you can just login with another guest character (but
mudlet needs a second game profile for this) and "look". The issue is
the same with the short description of the other guest character. But
here you can also select "whisper" from the menu, which will work
nicely.
BTW, all commands are just copied in the input line, even for "finger
guest" you have to hit enter. This is by design / limitation of the MXP
SEND command (you cannot choose 'PROMPT' per menu entry, only globally).
With the current mudlet version this does not work. This is due to the
definition:
<!EL PL '<SEND "tell &NAME; |finger &NAME; " HINT="tell
&NAME;|finger &NAME;" PROMPT>' ATT='NAME=someone'>
Mudlet misinterpretes 'NAME=someone' as the whole name of the entity,
not just NAME.
The effect of the default value 'someone' is not easy to demonstrate,
except when you can find an invisible wizard and convince him to to
interact with you. However, you can do:
say ^<PL player_id>Test1</PL>
and
say ^<PL>Test2</PL>
and see/use the menus created by/in Mudlet for the echo of Test1 and
Test2. You'll see how it refers to player_id or someone.
Note that Mudlet should actually not evaluate the PL tag in the say
command, as it is a secure MXP tag and the session is in open mode at
this time. However, Mudlet does not honor this security measure as of
now, which is another, unrelated, issue.
2023-05-30 19:16:10 +02:00
|
|
|
QCOMPARE(stub.fgColor, "blue");
|
|
|
|
|
tagHandler.handleTag(ctx, stub, endTag->asEndTag());
|
|
|
|
|
|
|
|
|
|
// back to defaults:
|
2023-05-31 19:44:48 +02:00
|
|
|
QCOMPARE(stub.bold(), false);
|
Improvement: Custom MXP elements now support default values for arguments (#6853)
<!-- Keep the title short & concise so anyone non-technical can
understand it,
the title appears in PTB changelogs -->
#### Brief overview of PR changes/additions
Custom Element Definition and Handler are changed to handle default
values by ATT="EntityName=DefaultValue" as specified in the MXP protocol
definition.
#### Motivation for adding to Mudlet
Improve MXP compliance.
#### Other info (issues closed, discussion etc)
To see this issue (in addition to reviewing the test code coming with
this PR):
connect to aldebaran-mud.de port 2000
login as guest
y (confirm you want to login as a guest)
Now do:
who
Notice the mouse-over hint on your (or another players) name in the who
output.
Right click and try some commands. Admittedly guest has no finger info,
and the game does not allow you to tell to yourself (and you have to
wait for a few minutes for your mana to build up for tell), so you can't
really do much.
Alternatively, you can just login with another guest character (but
mudlet needs a second game profile for this) and "look". The issue is
the same with the short description of the other guest character. But
here you can also select "whisper" from the menu, which will work
nicely.
BTW, all commands are just copied in the input line, even for "finger
guest" you have to hit enter. This is by design / limitation of the MXP
SEND command (you cannot choose 'PROMPT' per menu entry, only globally).
With the current mudlet version this does not work. This is due to the
definition:
<!EL PL '<SEND "tell &NAME; |finger &NAME; " HINT="tell
&NAME;|finger &NAME;" PROMPT>' ATT='NAME=someone'>
Mudlet misinterpretes 'NAME=someone' as the whole name of the entity,
not just NAME.
The effect of the default value 'someone' is not easy to demonstrate,
except when you can find an invisible wizard and convince him to to
interact with you. However, you can do:
say ^<PL player_id>Test1</PL>
and
say ^<PL>Test2</PL>
and see/use the menus created by/in Mudlet for the echo of Test1 and
Test2. You'll see how it refers to player_id or someone.
Note that Mudlet should actually not evaluate the PL tag in the say
command, as it is a secure MXP tag and the session is in open mode at
this time. However, Mudlet does not honor this security measure as of
now, which is another, unrelated, issue.
2023-05-30 19:16:10 +02:00
|
|
|
QCOMPARE(stub.fgColor, "");
|
|
|
|
|
|
|
|
|
|
startTag = parseNode("<boldtext blue>)");
|
|
|
|
|
tagHandler.handleTag(ctx, stub, startTag->asStartTag());
|
|
|
|
|
tagHandler.handleContent("This is also bold blue text");
|
|
|
|
|
// is it?
|
2023-05-31 19:44:48 +02:00
|
|
|
QCOMPARE(stub.bold(), true);
|
|
|
|
|
QCOMPARE(stub.fgColor, "blue");
|
Improvement: Custom MXP elements now support default values for arguments (#6853)
<!-- Keep the title short & concise so anyone non-technical can
understand it,
the title appears in PTB changelogs -->
#### Brief overview of PR changes/additions
Custom Element Definition and Handler are changed to handle default
values by ATT="EntityName=DefaultValue" as specified in the MXP protocol
definition.
#### Motivation for adding to Mudlet
Improve MXP compliance.
#### Other info (issues closed, discussion etc)
To see this issue (in addition to reviewing the test code coming with
this PR):
connect to aldebaran-mud.de port 2000
login as guest
y (confirm you want to login as a guest)
Now do:
who
Notice the mouse-over hint on your (or another players) name in the who
output.
Right click and try some commands. Admittedly guest has no finger info,
and the game does not allow you to tell to yourself (and you have to
wait for a few minutes for your mana to build up for tell), so you can't
really do much.
Alternatively, you can just login with another guest character (but
mudlet needs a second game profile for this) and "look". The issue is
the same with the short description of the other guest character. But
here you can also select "whisper" from the menu, which will work
nicely.
BTW, all commands are just copied in the input line, even for "finger
guest" you have to hit enter. This is by design / limitation of the MXP
SEND command (you cannot choose 'PROMPT' per menu entry, only globally).
With the current mudlet version this does not work. This is due to the
definition:
<!EL PL '<SEND "tell &NAME; |finger &NAME; " HINT="tell
&NAME;|finger &NAME;" PROMPT>' ATT='NAME=someone'>
Mudlet misinterpretes 'NAME=someone' as the whole name of the entity,
not just NAME.
The effect of the default value 'someone' is not easy to demonstrate,
except when you can find an invisible wizard and convince him to to
interact with you. However, you can do:
say ^<PL player_id>Test1</PL>
and
say ^<PL>Test2</PL>
and see/use the menus created by/in Mudlet for the echo of Test1 and
Test2. You'll see how it refers to player_id or someone.
Note that Mudlet should actually not evaluate the PL tag in the say
command, as it is a secure MXP tag and the session is in open mode at
this time. However, Mudlet does not honor this security measure as of
now, which is another, unrelated, issue.
2023-05-30 19:16:10 +02:00
|
|
|
tagHandler.handleTag(ctx, stub, endTag->asEndTag());
|
|
|
|
|
|
|
|
|
|
// back to defaults:
|
2023-05-31 19:44:48 +02:00
|
|
|
QCOMPARE(stub.bold(), false);
|
Improvement: Custom MXP elements now support default values for arguments (#6853)
<!-- Keep the title short & concise so anyone non-technical can
understand it,
the title appears in PTB changelogs -->
#### Brief overview of PR changes/additions
Custom Element Definition and Handler are changed to handle default
values by ATT="EntityName=DefaultValue" as specified in the MXP protocol
definition.
#### Motivation for adding to Mudlet
Improve MXP compliance.
#### Other info (issues closed, discussion etc)
To see this issue (in addition to reviewing the test code coming with
this PR):
connect to aldebaran-mud.de port 2000
login as guest
y (confirm you want to login as a guest)
Now do:
who
Notice the mouse-over hint on your (or another players) name in the who
output.
Right click and try some commands. Admittedly guest has no finger info,
and the game does not allow you to tell to yourself (and you have to
wait for a few minutes for your mana to build up for tell), so you can't
really do much.
Alternatively, you can just login with another guest character (but
mudlet needs a second game profile for this) and "look". The issue is
the same with the short description of the other guest character. But
here you can also select "whisper" from the menu, which will work
nicely.
BTW, all commands are just copied in the input line, even for "finger
guest" you have to hit enter. This is by design / limitation of the MXP
SEND command (you cannot choose 'PROMPT' per menu entry, only globally).
With the current mudlet version this does not work. This is due to the
definition:
<!EL PL '<SEND "tell &NAME; |finger &NAME; " HINT="tell
&NAME;|finger &NAME;" PROMPT>' ATT='NAME=someone'>
Mudlet misinterpretes 'NAME=someone' as the whole name of the entity,
not just NAME.
The effect of the default value 'someone' is not easy to demonstrate,
except when you can find an invisible wizard and convince him to to
interact with you. However, you can do:
say ^<PL player_id>Test1</PL>
and
say ^<PL>Test2</PL>
and see/use the menus created by/in Mudlet for the echo of Test1 and
Test2. You'll see how it refers to player_id or someone.
Note that Mudlet should actually not evaluate the PL tag in the say
command, as it is a secure MXP tag and the session is in open mode at
this time. However, Mudlet does not honor this security measure as of
now, which is another, unrelated, issue.
2023-05-30 19:16:10 +02:00
|
|
|
QCOMPARE(stub.fgColor, "");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void testCustomElementPlayer() {
|
|
|
|
|
// Real life example from Aldebaran: (there are more sensible ones with EXPIRE which Mudlet does not yet support)
|
|
|
|
|
//
|
|
|
|
|
// <!EL WH '<SEND "whisper &NAME; |finger &NAME; |tell &NAME; " HINT="whisper &NAME;|finger &NAME;|tell &NAME;" PROMPT>' ATT='NAME=someone'>
|
2025-07-13 14:29:14 +01:00
|
|
|
//
|
Improvement: Custom MXP elements now support default values for arguments (#6853)
<!-- Keep the title short & concise so anyone non-technical can
understand it,
the title appears in PTB changelogs -->
#### Brief overview of PR changes/additions
Custom Element Definition and Handler are changed to handle default
values by ATT="EntityName=DefaultValue" as specified in the MXP protocol
definition.
#### Motivation for adding to Mudlet
Improve MXP compliance.
#### Other info (issues closed, discussion etc)
To see this issue (in addition to reviewing the test code coming with
this PR):
connect to aldebaran-mud.de port 2000
login as guest
y (confirm you want to login as a guest)
Now do:
who
Notice the mouse-over hint on your (or another players) name in the who
output.
Right click and try some commands. Admittedly guest has no finger info,
and the game does not allow you to tell to yourself (and you have to
wait for a few minutes for your mana to build up for tell), so you can't
really do much.
Alternatively, you can just login with another guest character (but
mudlet needs a second game profile for this) and "look". The issue is
the same with the short description of the other guest character. But
here you can also select "whisper" from the menu, which will work
nicely.
BTW, all commands are just copied in the input line, even for "finger
guest" you have to hit enter. This is by design / limitation of the MXP
SEND command (you cannot choose 'PROMPT' per menu entry, only globally).
With the current mudlet version this does not work. This is due to the
definition:
<!EL PL '<SEND "tell &NAME; |finger &NAME; " HINT="tell
&NAME;|finger &NAME;" PROMPT>' ATT='NAME=someone'>
Mudlet misinterpretes 'NAME=someone' as the whole name of the entity,
not just NAME.
The effect of the default value 'someone' is not easy to demonstrate,
except when you can find an invisible wizard and convince him to to
interact with you. However, you can do:
say ^<PL player_id>Test1</PL>
and
say ^<PL>Test2</PL>
and see/use the menus created by/in Mudlet for the echo of Test1 and
Test2. You'll see how it refers to player_id or someone.
Note that Mudlet should actually not evaluate the PL tag in the say
command, as it is a secure MXP tag and the session is in open mode at
this time. However, Mudlet does not honor this security measure as of
now, which is another, unrelated, issue.
2023-05-30 19:16:10 +02:00
|
|
|
// Used like <WH playerid>Player</WH> says: Hello!
|
|
|
|
|
// However, if player is invisible, playerid is empty, like <WH >Someone</WH> says: Hello!
|
|
|
|
|
//
|
|
|
|
|
// Upper and lower case are mixed in the entity name to make this a more severe test case
|
|
|
|
|
|
|
|
|
|
TMxpStubHandlerContext ctx;
|
|
|
|
|
TMxpStubClient stub;
|
|
|
|
|
TMxpTagParser parser;
|
|
|
|
|
|
|
|
|
|
auto defTag = parseNode("<!EL WH '<SEND \"whisper &Name; |finger &NAme; |tell &namE; \" HINT=\"whisper &name;|finger &NAME;|tell &NAME;\" PROMPT>' ATT='NAme=someone'>");
|
|
|
|
|
|
|
|
|
|
TMxpElementDefinitionHandler definitionHandler;
|
|
|
|
|
definitionHandler.handleTag(ctx, stub, defTag->asStartTag());
|
|
|
|
|
|
|
|
|
|
auto startTag = parseNode("<WH playerid>");
|
|
|
|
|
auto endTag = parseNode("</WH>");
|
|
|
|
|
|
|
|
|
|
TMxpCustomElementTagHandler customElementTagHandler;
|
|
|
|
|
TMxpTagHandler& tagHandler = customElementTagHandler;
|
|
|
|
|
|
|
|
|
|
tagHandler.handleTag(ctx, stub, startTag->asStartTag());
|
|
|
|
|
tagHandler.handleContent("Player");
|
|
|
|
|
tagHandler.handleTag(ctx, stub, endTag->asEndTag());
|
|
|
|
|
|
|
|
|
|
QCOMPARE(stub.mHrefs.size(), 3);
|
|
|
|
|
QCOMPARE(stub.mHrefs[0], "printCmdLine([[whisper playerid ]])");
|
|
|
|
|
QCOMPARE(stub.mHrefs[1], "printCmdLine([[finger playerid ]])");
|
|
|
|
|
QCOMPARE(stub.mHrefs[2], "printCmdLine([[tell playerid ]])");
|
|
|
|
|
|
|
|
|
|
QCOMPARE(stub.mHints.size(), 3);
|
Fix: Tooltip hints for MXP hints no longer forced to uppercase (#6878)
<!-- Keep the title short & concise so anyone non-technical can
understand it,
the title appears in PTB changelogs -->
#### Brief overview of PR changes/additions
In some, but not all, occasions the tooltip hints of MXP hints were
forced to all upper case by Mudlet
#### Motivation for adding to Mudlet
Improvement of MXP compatibility, more uniform menu appearance.
#### Other info (issues closed, discussion etc)
Mudlet forced HINT attributes used in custom elements to upper case, but
only there. Note that entities were interpolated afterwards, hence not
forced to uppercase. I think the behaviour is inconsistent and not
'logically' comprehensible for a user.
Afaik, if the mud specifies a HINT text it should be display as such. If
the game wants it to show up in UPPERCASE the game should just say so.
**However,** in difference to my other MXP patches, it will change the
look of the GUI for games that somehow depend on it.
So.. it can be argued.
It does change the non uniform display of hints like those two from the
unfixed version:
and
to
Also, it used to deal with HINTs only prior to entity resolution, so
without the fix it looked like
rather than
And the only difference between these two menus (both from the unfixed
version)
is that the first uses a plain `<send>` while the second uses a custom
element.
Again, you can see this in action by connecting to aldebaran-mud.de 2000
, login as guest (y to confirm) and with 'set mxp test 4'.
2023-06-11 16:45:58 +02:00
|
|
|
QCOMPARE(stub.mHints[0], "whisper playerid");
|
|
|
|
|
QCOMPARE(stub.mHints[1], "finger playerid");
|
|
|
|
|
QCOMPARE(stub.mHints[2], "tell playerid");
|
Improvement: Custom MXP elements now support default values for arguments (#6853)
<!-- Keep the title short & concise so anyone non-technical can
understand it,
the title appears in PTB changelogs -->
#### Brief overview of PR changes/additions
Custom Element Definition and Handler are changed to handle default
values by ATT="EntityName=DefaultValue" as specified in the MXP protocol
definition.
#### Motivation for adding to Mudlet
Improve MXP compliance.
#### Other info (issues closed, discussion etc)
To see this issue (in addition to reviewing the test code coming with
this PR):
connect to aldebaran-mud.de port 2000
login as guest
y (confirm you want to login as a guest)
Now do:
who
Notice the mouse-over hint on your (or another players) name in the who
output.
Right click and try some commands. Admittedly guest has no finger info,
and the game does not allow you to tell to yourself (and you have to
wait for a few minutes for your mana to build up for tell), so you can't
really do much.
Alternatively, you can just login with another guest character (but
mudlet needs a second game profile for this) and "look". The issue is
the same with the short description of the other guest character. But
here you can also select "whisper" from the menu, which will work
nicely.
BTW, all commands are just copied in the input line, even for "finger
guest" you have to hit enter. This is by design / limitation of the MXP
SEND command (you cannot choose 'PROMPT' per menu entry, only globally).
With the current mudlet version this does not work. This is due to the
definition:
<!EL PL '<SEND "tell &NAME; |finger &NAME; " HINT="tell
&NAME;|finger &NAME;" PROMPT>' ATT='NAME=someone'>
Mudlet misinterpretes 'NAME=someone' as the whole name of the entity,
not just NAME.
The effect of the default value 'someone' is not easy to demonstrate,
except when you can find an invisible wizard and convince him to to
interact with you. However, you can do:
say ^<PL player_id>Test1</PL>
and
say ^<PL>Test2</PL>
and see/use the menus created by/in Mudlet for the echo of Test1 and
Test2. You'll see how it refers to player_id or someone.
Note that Mudlet should actually not evaluate the PL tag in the say
command, as it is a secure MXP tag and the session is in open mode at
this time. However, Mudlet does not honor this security measure as of
now, which is another, unrelated, issue.
2023-05-30 19:16:10 +02:00
|
|
|
|
|
|
|
|
// Now w/o a NAME parameter given:
|
|
|
|
|
startTag = parseNode("<WH>");
|
|
|
|
|
tagHandler.handleTag(ctx, stub, startTag->asStartTag());
|
|
|
|
|
tagHandler.handleContent("Invisible SuperAdmin");
|
|
|
|
|
tagHandler.handleTag(ctx, stub, endTag->asEndTag());
|
|
|
|
|
|
|
|
|
|
QCOMPARE(stub.mHrefs.size(), 3);
|
|
|
|
|
QCOMPARE(stub.mHrefs[0], "printCmdLine([[whisper someone ]])");
|
|
|
|
|
QCOMPARE(stub.mHrefs[1], "printCmdLine([[finger someone ]])");
|
|
|
|
|
QCOMPARE(stub.mHrefs[2], "printCmdLine([[tell someone ]])");
|
|
|
|
|
|
|
|
|
|
QCOMPARE(stub.mHints.size(), 3);
|
Fix: Tooltip hints for MXP hints no longer forced to uppercase (#6878)
<!-- Keep the title short & concise so anyone non-technical can
understand it,
the title appears in PTB changelogs -->
#### Brief overview of PR changes/additions
In some, but not all, occasions the tooltip hints of MXP hints were
forced to all upper case by Mudlet
#### Motivation for adding to Mudlet
Improvement of MXP compatibility, more uniform menu appearance.
#### Other info (issues closed, discussion etc)
Mudlet forced HINT attributes used in custom elements to upper case, but
only there. Note that entities were interpolated afterwards, hence not
forced to uppercase. I think the behaviour is inconsistent and not
'logically' comprehensible for a user.
Afaik, if the mud specifies a HINT text it should be display as such. If
the game wants it to show up in UPPERCASE the game should just say so.
**However,** in difference to my other MXP patches, it will change the
look of the GUI for games that somehow depend on it.
So.. it can be argued.
It does change the non uniform display of hints like those two from the
unfixed version:
and
to
Also, it used to deal with HINTs only prior to entity resolution, so
without the fix it looked like
rather than
And the only difference between these two menus (both from the unfixed
version)
is that the first uses a plain `<send>` while the second uses a custom
element.
Again, you can see this in action by connecting to aldebaran-mud.de 2000
, login as guest (y to confirm) and with 'set mxp test 4'.
2023-06-11 16:45:58 +02:00
|
|
|
QCOMPARE(stub.mHints[0], "whisper someone");
|
|
|
|
|
QCOMPARE(stub.mHints[1], "finger someone");
|
|
|
|
|
QCOMPARE(stub.mHints[2], "tell someone");
|
Improvement: Custom MXP elements now support default values for arguments (#6853)
<!-- Keep the title short & concise so anyone non-technical can
understand it,
the title appears in PTB changelogs -->
#### Brief overview of PR changes/additions
Custom Element Definition and Handler are changed to handle default
values by ATT="EntityName=DefaultValue" as specified in the MXP protocol
definition.
#### Motivation for adding to Mudlet
Improve MXP compliance.
#### Other info (issues closed, discussion etc)
To see this issue (in addition to reviewing the test code coming with
this PR):
connect to aldebaran-mud.de port 2000
login as guest
y (confirm you want to login as a guest)
Now do:
who
Notice the mouse-over hint on your (or another players) name in the who
output.
Right click and try some commands. Admittedly guest has no finger info,
and the game does not allow you to tell to yourself (and you have to
wait for a few minutes for your mana to build up for tell), so you can't
really do much.
Alternatively, you can just login with another guest character (but
mudlet needs a second game profile for this) and "look". The issue is
the same with the short description of the other guest character. But
here you can also select "whisper" from the menu, which will work
nicely.
BTW, all commands are just copied in the input line, even for "finger
guest" you have to hit enter. This is by design / limitation of the MXP
SEND command (you cannot choose 'PROMPT' per menu entry, only globally).
With the current mudlet version this does not work. This is due to the
definition:
<!EL PL '<SEND "tell &NAME; |finger &NAME; " HINT="tell
&NAME;|finger &NAME;" PROMPT>' ATT='NAME=someone'>
Mudlet misinterpretes 'NAME=someone' as the whole name of the entity,
not just NAME.
The effect of the default value 'someone' is not easy to demonstrate,
except when you can find an invisible wizard and convince him to to
interact with you. However, you can do:
say ^<PL player_id>Test1</PL>
and
say ^<PL>Test2</PL>
and see/use the menus created by/in Mudlet for the echo of Test1 and
Test2. You'll see how it refers to player_id or someone.
Note that Mudlet should actually not evaluate the PL tag in the say
command, as it is a secure MXP tag and the session is in open mode at
this time. However, Mudlet does not honor this security measure as of
now, which is another, unrelated, issue.
2023-05-30 19:16:10 +02:00
|
|
|
}
|
Fix: MXP EXPIRE tag support and custom element attribute handling (#8431)
#### Brief overview of PR changes/additions
* **Add MXP EXPIRE tag support**: Implements the EXPIRE attribute for
MXP SEND tags, allowing servers to expire groups of links by name
* **Tooltip fix**: Fixed MXP link tooltips displaying "HREF" instead of
the actual link command when the EXPIRE attribute appears before the
HREF attribute in SEND tags
* **Custom element fix**: Fixed custom MXP elements to properly pass
through ALL attributes (EXPIRE, HREF, HINT, etc.) to their expanded tag
definitions
#### Motivation for adding to Mudlet
**EXPIRE tag support**: The MXP specification defines an EXPIRE
attribute that allows servers to tag groups of links and expire them all
at once (e.g., `<EXPIRE Exits>` expires all links tagged with
`EXPIRE="Exits"`). This is essential for dynamic content like room exits
that change as players move around.
**Tooltip fix**: Addresses reviewer feedback in PR #8383. When games
send MXP links like `<SEND EXPIRE="Exits" HREF="east">East</SEND>`, the
tooltip was incorrectly showing the literal text "HREF" instead of
"east" (the command that would be executed), making links confusing for
users.
**Custom element fix**: When servers define custom elements like
`<!ELEMENT Ex '<SEND>'>` and use them with attributes like `<Ex
EXPIRE="Exits" HREF="north">North</Ex>`, those attributes weren't being
passed through to the expanded SEND tag. This made custom elements less
functional than regular tags. Now all attributes are properly inherited.
#### Other info (issues closed, discussion etc)
- Related to PR #8383 (initial EXPIRE tag implementation discussion)
- Addresses @mfontani's comment about custom elements not passing
through EXPIRE attributes
- Added comprehensive unit tests:
- Tooltip attribute ordering tests in `TMxpSendTagHandlerTest`
- Custom element attribute pass-through test in
`TMxpCustomElementTagHandlerTest`
- All existing MXP tests continue to pass (100% success rate)
- Changes summary: 5 files changed, 101 insertions(+), 2 deletions(-)
2025-10-26 15:48:42 -04:00
|
|
|
|
|
|
|
|
void testCustomElementAttributePassThrough() {
|
|
|
|
|
// Test that attributes from custom element tags are passed through to the definition
|
|
|
|
|
// <!ELEMENT Ex '<SEND>'>
|
|
|
|
|
// <Ex EXPIRE='Exits' HREF='north'>North</Ex>
|
|
|
|
|
// Should result in: <SEND EXPIRE='Exits' HREF='north'>North</SEND>
|
|
|
|
|
|
|
|
|
|
TMxpStubHandlerContext ctx;
|
|
|
|
|
TMxpStubClient stub;
|
|
|
|
|
|
|
|
|
|
// Define custom element that expands to <SEND>
|
|
|
|
|
auto defTag = parseNode("<!ELEMENT Ex '<SEND>'>");
|
|
|
|
|
TMxpElementDefinitionHandler definitionHandler;
|
|
|
|
|
definitionHandler.handleTag(ctx, stub, defTag->asStartTag());
|
|
|
|
|
|
|
|
|
|
// Use custom element with EXPIRE and HREF attributes
|
|
|
|
|
auto startTag = parseNode("<Ex EXPIRE='Exits' HREF='north'>");
|
|
|
|
|
auto endTag = parseNode("</Ex>");
|
|
|
|
|
|
|
|
|
|
TMxpCustomElementTagHandler customElementTagHandler;
|
|
|
|
|
TMxpTagHandler& tagHandler = customElementTagHandler;
|
|
|
|
|
|
|
|
|
|
tagHandler.handleTag(ctx, stub, startTag->asStartTag());
|
|
|
|
|
tagHandler.handleContent("North");
|
|
|
|
|
tagHandler.handleTag(ctx, stub, endTag->asEndTag());
|
|
|
|
|
|
|
|
|
|
// Verify the attributes were passed through correctly
|
|
|
|
|
QCOMPARE(stub.mHrefs.size(), 1);
|
|
|
|
|
QCOMPARE(stub.mHrefs[0], "send([[north]])");
|
|
|
|
|
QCOMPARE(stub.mHints.size(), 1);
|
|
|
|
|
QCOMPARE(stub.mHints[0], "north");
|
|
|
|
|
QCOMPARE(stub.mExpireName, "Exits");
|
|
|
|
|
}
|
Improvement: Custom MXP elements now support default values for arguments (#6853)
<!-- Keep the title short & concise so anyone non-technical can
understand it,
the title appears in PTB changelogs -->
#### Brief overview of PR changes/additions
Custom Element Definition and Handler are changed to handle default
values by ATT="EntityName=DefaultValue" as specified in the MXP protocol
definition.
#### Motivation for adding to Mudlet
Improve MXP compliance.
#### Other info (issues closed, discussion etc)
To see this issue (in addition to reviewing the test code coming with
this PR):
connect to aldebaran-mud.de port 2000
login as guest
y (confirm you want to login as a guest)
Now do:
who
Notice the mouse-over hint on your (or another players) name in the who
output.
Right click and try some commands. Admittedly guest has no finger info,
and the game does not allow you to tell to yourself (and you have to
wait for a few minutes for your mana to build up for tell), so you can't
really do much.
Alternatively, you can just login with another guest character (but
mudlet needs a second game profile for this) and "look". The issue is
the same with the short description of the other guest character. But
here you can also select "whisper" from the menu, which will work
nicely.
BTW, all commands are just copied in the input line, even for "finger
guest" you have to hit enter. This is by design / limitation of the MXP
SEND command (you cannot choose 'PROMPT' per menu entry, only globally).
With the current mudlet version this does not work. This is due to the
definition:
<!EL PL '<SEND "tell &NAME; |finger &NAME; " HINT="tell
&NAME;|finger &NAME;" PROMPT>' ATT='NAME=someone'>
Mudlet misinterpretes 'NAME=someone' as the whole name of the entity,
not just NAME.
The effect of the default value 'someone' is not easy to demonstrate,
except when you can find an invisible wizard and convince him to to
interact with you. However, you can do:
say ^<PL player_id>Test1</PL>
and
say ^<PL>Test2</PL>
and see/use the menus created by/in Mudlet for the echo of Test1 and
Test2. You'll see how it refers to player_id or someone.
Note that Mudlet should actually not evaluate the PL tag in the say
command, as it is a secure MXP tag and the session is in open mode at
this time. However, Mudlet does not honor this security measure as of
now, which is another, unrelated, issue.
2023-05-30 19:16:10 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
#include "TMxpCustomElementTagHandlerTest.moc"
|
|
|
|
|
QTEST_MAIN(TMxpCustomElementTagHandlerTest)
|
|
|
|
|
|