Best Of
Emote Syntax Feedback
I love that custom emotes are so versatile, but it feels a little complex on the users end and I wonder if there isn't a way it could be simplified. Currently it works like this:
Input: emote (Smiling,) says to @Lertsek, "Hello!"
Output: Smiling, Kestrel says to Lertsek, "Hello!"
I would like for it instead to work the way humans intuitively type. Like this:
Input: emote Smiling, Kestrel says to Lertsek, "Hello!"
Output: Smiling, Kestrel says to Lertsek, "Hello!"
So here's what I propose. Have the code detect:
1a. If the word that comes directly after the 'emote' syntax begins with a CAPITAL LETTER.
1b. If the emote contains the CHARACTER'S NAME outside of quotation marks.
i. If yes to both, do not add the character's name at the beginning.
ii. If no to both, add the character's name at the beginning.
iii. If yes to the first but not to the second, return an error message.
Result:
Input: emote Smiling, Kestrel says to Lertsek, "Hello!"
Output: Smiling, Kestrel says to Lertsek, "Hello!"
Input: emote Smiling says to Lertsek, "Hello!"
Output: Did you mean to include your name in that emote? (Do not send the emote.)
There's no scenario where you'd want a capital letter directly after a person's name in the start of an emote. 'Kestrel Smiling' would be weird. There's no workaround that I can think of for this next potential foible, but it seems like it would be an uncommon mistake.
Input: emote smiling, Kestrel says to Lertsek, "Hello!"
Output: Kestrel smiling, Kestrel says to Lertsek, "Hello!"
For targeted emotes, check:
2a. If a person receives an emote that CONTAINS THEIR OWN NAME outside of quotations, automatically change it to 'you'. Change nothing for the sender.
2b. If the emote contains their name MORE THAN ONCE, followed by an underscore.
i. If yes to the first, automatically change the first, unmodified instance of the target's name to 'you'.
ii. If yes to the first but no to the second, change nothing for the sender.
iii. If no to the first but yes to the second, return an error message.
iv. If yes to both, change secondary, modified instances of the target's name to second person on the target's end, but third person on the sender's end.
Result:
Kestrel's Input: emote Smiling, Kestrel says to Lertsek, "Hello!"
Kestrel's Output: Smiling, Kestrel says to Lertsek, "Hello!"
Lerstek's Output: Smiling, Kestrel says to you, "Hello!"
No need for Kestrel to fiddle around with code in this case. It'll handle things automatically on Lerstek's end. For more complex targeted emotes, however:
Kestrel's Input: emote Looking Lerstek up and down, Kestrel raises her eyebrows dramatically as she admires Lerstek_his feet. "Nice shoes!" she notes.
-Or-
Kestrel's Input: emote Looking Lerstek up and down, Kestrel raises her eyebrows dramatically as she admires Lerstek_your feet. "Nice shoes!" she notes.
-Or-
Kestrel's Input: emote Looking Lerstek up and down, Kestrel raises her eyebrows dramatically as she admires Lerstek_their feet. "Nice shoes!" she notes.
Kestrel's Output: Looking Lerstek up and down, Kestrel raises her eyebrows dramatically as she admires his feet. "Nice shoes!" she notes.
Lerstek's Output: Looking you up and down, Kestrel raises her eyebrows dramatically as she admires your feet. "Nice shoes!" she notes.
All of the input options should work on Kestrel's end, making things a lot more intuitive for longer emotes where you're referring to the target multiple times, and saving me the embarrassment of accidentally misgendering someone if I forgot to check their honours/score. Currently, I sometimes have to write my emotes in second person to avoid any targeting foibles with an RP partner, but this only works for one-on-one, and goes out the window in a larger social setting where I generally just revert to third person - so no one gets targeted, but no one has to read an emote that alternately refers to them as both 'you' and 'him'. And even in those easier one-on-one settings, it only reads easier for the recipient, not the sender. I'm over here getting tripped up on having written something like 'Kestrel smiles at you' even though I am Kestrel!
Also as a note, the reason why we can't just default to Lerstek_his all the time is that sometimes 'his' is supposed to be 'yours' instead of 'you'. E.g., 'Kestrel eyes up that sword of his' -> 'Kestrel eyes up that sword of yours', 'Kestrel eyes his sword' -> 'Kestrel eyes your sword'. Otherwise I would generally always write in third person.
Kestrel's Input: emote smiles at Lerstek_him.
Kestrel's Output: Who are you emoting at?
Otherwise, someone would walk into the room and see: 'Kestrel smiles at him', but not know which 'him' is being referred to.
Input: emote (Smiling,) says to @Lertsek, "Hello!"
Output: Smiling, Kestrel says to Lertsek, "Hello!"
I would like for it instead to work the way humans intuitively type. Like this:
Input: emote Smiling, Kestrel says to Lertsek, "Hello!"
Output: Smiling, Kestrel says to Lertsek, "Hello!"
So here's what I propose. Have the code detect:
1a. If the word that comes directly after the 'emote' syntax begins with a CAPITAL LETTER.
1b. If the emote contains the CHARACTER'S NAME outside of quotation marks.
i. If yes to both, do not add the character's name at the beginning.
ii. If no to both, add the character's name at the beginning.
iii. If yes to the first but not to the second, return an error message.
Result:
Input: emote Smiling, Kestrel says to Lertsek, "Hello!"
Output: Smiling, Kestrel says to Lertsek, "Hello!"
Input: emote Smiling says to Lertsek, "Hello!"
Output: Did you mean to include your name in that emote? (Do not send the emote.)
There's no scenario where you'd want a capital letter directly after a person's name in the start of an emote. 'Kestrel Smiling' would be weird. There's no workaround that I can think of for this next potential foible, but it seems like it would be an uncommon mistake.
Input: emote smiling, Kestrel says to Lertsek, "Hello!"
Output: Kestrel smiling, Kestrel says to Lertsek, "Hello!"
For targeted emotes, check:
2a. If a person receives an emote that CONTAINS THEIR OWN NAME outside of quotations, automatically change it to 'you'. Change nothing for the sender.
2b. If the emote contains their name MORE THAN ONCE, followed by an underscore.
i. If yes to the first, automatically change the first, unmodified instance of the target's name to 'you'.
ii. If yes to the first but no to the second, change nothing for the sender.
iii. If no to the first but yes to the second, return an error message.
iv. If yes to both, change secondary, modified instances of the target's name to second person on the target's end, but third person on the sender's end.
Result:
Kestrel's Input: emote Smiling, Kestrel says to Lertsek, "Hello!"
Kestrel's Output: Smiling, Kestrel says to Lertsek, "Hello!"
Lerstek's Output: Smiling, Kestrel says to you, "Hello!"
No need for Kestrel to fiddle around with code in this case. It'll handle things automatically on Lerstek's end. For more complex targeted emotes, however:
Kestrel's Input: emote Looking Lerstek up and down, Kestrel raises her eyebrows dramatically as she admires Lerstek_his feet. "Nice shoes!" she notes.
-Or-
Kestrel's Input: emote Looking Lerstek up and down, Kestrel raises her eyebrows dramatically as she admires Lerstek_your feet. "Nice shoes!" she notes.
-Or-
Kestrel's Input: emote Looking Lerstek up and down, Kestrel raises her eyebrows dramatically as she admires Lerstek_their feet. "Nice shoes!" she notes.
Kestrel's Output: Looking Lerstek up and down, Kestrel raises her eyebrows dramatically as she admires his feet. "Nice shoes!" she notes.
Lerstek's Output: Looking you up and down, Kestrel raises her eyebrows dramatically as she admires your feet. "Nice shoes!" she notes.
All of the input options should work on Kestrel's end, making things a lot more intuitive for longer emotes where you're referring to the target multiple times, and saving me the embarrassment of accidentally misgendering someone if I forgot to check their honours/score. Currently, I sometimes have to write my emotes in second person to avoid any targeting foibles with an RP partner, but this only works for one-on-one, and goes out the window in a larger social setting where I generally just revert to third person - so no one gets targeted, but no one has to read an emote that alternately refers to them as both 'you' and 'him'. And even in those easier one-on-one settings, it only reads easier for the recipient, not the sender. I'm over here getting tripped up on having written something like 'Kestrel smiles at you' even though I am Kestrel!
Also as a note, the reason why we can't just default to Lerstek_his all the time is that sometimes 'his' is supposed to be 'yours' instead of 'you'. E.g., 'Kestrel eyes up that sword of his' -> 'Kestrel eyes up that sword of yours', 'Kestrel eyes his sword' -> 'Kestrel eyes your sword'. Otherwise I would generally always write in third person.
Kestrel's Input: emote smiles at Lerstek_him.
Kestrel's Output: Who are you emoting at?
Otherwise, someone would walk into the room and see: 'Kestrel smiles at him', but not know which 'him' is being referred to.

1
Junk Consolidation
Would it be possible to consolidate the value of junk at higher levels and have less of it drop? I find that Mudlet/Nexus both hang for several seconds when someone dies in the room and is carrying a lot of junk (i.e., 500-700 pieces of junk). It seems like if higher level junk were worth more, then fewer pieces could drop and accomplish the same thing, but without creating undue noise in my inventory, the room when I die, or causing the game to hang if someone else dies during group combat.
Thanks!
Thanks!
Re: Artifact Questions
Arti tuning is probably a bit too conservative at the moment, to be 100% honest, but easier to let the cat out of the bag than to stuff it back in.
12
Prone, Stand, and the queue system
(Edit: Upon checking logs, some of this information is not accurate. Queueing is still an issue with prone though!)
I wanted to provide some feedback on prone as an affliction and the issues I'm having with the queue system. I play with a high ping, and I cannot send my attacks right as I regain balance because the delay turns a 2.5 second balance attack into what's effectively 4-5 seconds of waiting for the attack to go off. So I use queueing, and it works well. On occasion I'll have 3+second lag spikes, but that's fine and nothing other than a queue stack would help alleviate that one.
The problem is prone. If I'm prone, I need to manually stand. That takes a command, and I cannot attack while I'm prone. So I need to stand right after I regain balance. But then my queue has to be used for stand, bringing me back to my original problem. I have tried sending joint commands to queue them (stand|wristblade Tecton) but only the last command gets put on the queue. (Edit: I see the issue now. The queued attack won't go through. WW will make me stand immediately after the "you must be standing" error message, and then I can send my command again. But this is where we run into the ping problem, as basically prone disables the use of any queueing for me since I must manually resend after getting balance.)
Somebody suggested that using an attack just automatically stand you if you are not otherwise hindered and unable to stand. I think, unless we're able to get queue stacking, this would be a simple enough solution. The prone condition is trivial if your ping is low, since you can just put "stand" at the top of every attack alias. It's significantly more debilitating if that method of attacking (sending several commands on balance, as opposed to queueing one command before balance) is not feasible due to high ping.
High ping is already very punishing, and this change would help us not fall even further behind due to a single condition that's otherwise easy to fix.
Thoughts? I often miss something obvious with these suggestions, so maybe what I'm proposing is stupid for some reason I haven't considered.
I wanted to provide some feedback on prone as an affliction and the issues I'm having with the queue system. I play with a high ping, and I cannot send my attacks right as I regain balance because the delay turns a 2.5 second balance attack into what's effectively 4-5 seconds of waiting for the attack to go off. So I use queueing, and it works well. On occasion I'll have 3+second lag spikes, but that's fine and nothing other than a queue stack would help alleviate that one.
The problem is prone. If I'm prone, I need to manually stand. That takes a command, and I cannot attack while I'm prone. So I need to stand right after I regain balance. But then my queue has to be used for stand, bringing me back to my original problem. I have tried sending joint commands to queue them (stand|wristblade Tecton) but only the last command gets put on the queue. (Edit: I see the issue now. The queued attack won't go through. WW will make me stand immediately after the "you must be standing" error message, and then I can send my command again. But this is where we run into the ping problem, as basically prone disables the use of any queueing for me since I must manually resend after getting balance.)
Somebody suggested that using an attack just automatically stand you if you are not otherwise hindered and unable to stand. I think, unless we're able to get queue stacking, this would be a simple enough solution. The prone condition is trivial if your ping is low, since you can just put "stand" at the top of every attack alias. It's significantly more debilitating if that method of attacking (sending several commands on balance, as opposed to queueing one command before balance) is not feasible due to high ping.
High ping is already very punishing, and this change would help us not fall even further behind due to a single condition that's otherwise easy to fix.
Thoughts? I often miss something obvious with these suggestions, so maybe what I'm proposing is stupid for some reason I haven't considered.
Re: MKO reunion thread
Will you tell Rae-Rae that everyone I’ve spoken to misses him and loves him dearly?Ludwig said:Rossin and Lehoi, sounding off! Hey everyone!
*SQUISH*
And ask him if he’s eating enough. I still remember when he was like 15, and it brings out my maternal instincts.

2
Re: mod market
The first person to master a particular mod seems like they’d probably end up with a monopoly on it until they sold enough for others to reverse engineer, and could charge and arm and leg to make back that investment.
1
Re: Grinding to max level
Going back on my bowing out because you have a tendency to twist people's words. Not sure where you got the idea that I care about criticism. I stated or implied multuple times you have the right to do so.Maruna said:Not gonna lie I lost it at the attempt to compare a text game to something like overwatch or wow. When you're comparing something you should make sure they're actually similar games.
"It's my opinion." Isn't a very good retort. Opinions are there to be criticised. If you don't like criticism then don't give your opinion to a public forum.
Again, I am fine with being in the minority. I will continue to break games down to a series of button pushes to accomplish a goal because that is, in essence, what it is.
My opinion is that I don't think it is right to turn the game into an idle tapper. Is it within the rules? Sure. Do I think it helps the game in the long run? Nope. Do I care if people question my intelligence because my opinion is different than theirs? Well, they look like the asshole, not me.
For reals though, I am done.
1
Re: Looking for Dynasty
For me the question would be... why make a dynasty for that? It seems like something some might want to be a part of even if they already have a dynasty. At the same time, an OOC focus puts many of the dynasty facilities to waste, while blocking those that already are or want to be a part of a more RP focused one...
Re: Lets talk about Nanoseers abilities. Nanoseer General
NOTHING respects the allies list. This has been another one of many out of our biggest complaints. It also hits every single bot, so if you cast that in a room with two engineers you’re getting spammed to death.
1
Re: Lets talk about Nanoseers abilities. Nanoseer General
It'd be nice if we could see when wetwiring procs, even if we can't see what it cures. Maybe add that as an effect to rattle, even. Currently, rattle seems like a lesser version of wireblock so that could add a unique element to it.
2