A good mud client for an Apple computer

[Lloth]

Tick timers are a bit tricky.

First, you need to pull the hour value from your prompt. This is used later to determine when to reset the timer.

Then you need a timer with 45 seconds. Yes, I know this is way too long, but trust me. The whole point is to make sure the timer never reaches zero. It's used later to allow for perpetual tick checks.

You need to add a line in the timer call that echoes a message to you about the incoming tick. I would say to set this at 25 seconds remaining. This gives you plenty of warning before the tick. 

Similar to adding the echo line for incoming ticks, you also need a line that compares the stored variable with your current hour in your prompt. If they are the same, it waits one second before checking again. It repeats this until they are different, at which point it spits out an echo, disables the timer, then immediately enables it again.

This creates a loop that guarantees complete and total accuracy, with no further need to adjust or guess.

Essentially, it's simple regex in a while loop to get everything you need. Ezpz.

[virr]

6 hours ago, Gifnab said:

Just throwing it out there, I actually started toying with my first ever aliases/variables and highlights in Mudlet this past weekend. Found what seems to be a fairly compact, easy-to-use system that also allows for things to be added on the fly, directly through the input window.

https://forums.mudlet.org/download/file.php?id=1885

Now all I need is a Mudlet friendly tick-timer and I'll be ready to move into the future with the rest of you.

Well it's not as easy to use as my very old Zmud. Or maybe it's just different. It sure seems to be very competent though.

[Lexi]

I am a huge cmud fan. So easy to learn and use.

[virr]

1 hour ago, Lexi said:

I am a huge cmud fan. So easy to learn and use.

But Cmud is not for Apple is it?

[Kassieti]

Not without the aforementioned virtual machine.

[myrek]

Here's the Mudlet Tick Timer I'm testing. Call the function when hour changes are detected.

function hourlyActions()
  cecho("<red>\nTick\n")
  
-- replace these with any scripts you'd like to run on the hour
  updateSpells()
  populateConsole()
  
-- kill timers

if tick_timer then killTimer(tick_timer) end
if warning_timer then killTimer(warning_timer) end

-- start new timers

  warning_timer = tempTimer(25, function()
    cecho("<red>Tick in 5 seconds.\n")
    end
  )
  tick_timer = tempTimer(30, function() hourlyActions() end)
end

 

[Lloth]

The problem with that timer is that it will desync over time, as tick duration is a range, not a constant.

[myrek]

3 minutes ago, Lloth said:

The problem with that timer is that it will desync over time, as tick duration is a range, not a constant.

I don't understand. Feel free to critique but the intent is to reset itself when a tick is detected from the game. That's why the timers are deleted when a tick is detected. 

It only "runs blind" when you're not getting input from the mud.

[Kassieti]

9 minutes ago, myrek said:

I don't understand. Feel free to critique but the intent is to reset itself when a tick is detected from the game. That's why the timers are deleted when a tick is detected. 

It only "runs blind" when you're not getting input from the mud.

It means that FL timer runs between 25-35 seconds.  If you just let it run, it's going to drift.
You've seen to that particular problem, though through what I assume is spells falling.  It's better to put the time on your prompt and have it reset based off that.

[myrek]

I understand the threat of timer drift. I don't understand why people think my script would drift. It resets whenever an hour change is detected.

Don't get me wrong. The script has issues - mainly doing double ticks - but it shouldn't drift.

[Lloth]

The issue that would cause drift is the detect method. It's not perfect. It's a great trigger, don't get me wrong. Just not quite perfect. That's why I suggested a method to check every second. Perhaps I'm reading it wrong, but it looks like it's detecting spell expiration. Which works, but requires a spell to expire. And it gets messed up by dispel magic, either way. That's why I suggested using a check every second below the threshold. You can also do it so that mudlet queries the mud directly, without displaying anything to you. That's way harder, though. 

[myrek]

I'm tying the function to the time in my prompt changing. So if I'm sitting there doing absolutely nothing, there can be problems with drift until something resets it. But if I'm active, it catches the ticks pretty closely.

5 minutes ago, Lloth said:

That's why I suggested using a check every second below the threshold. You can also do it so that mudlet queries the mud directly, without displaying anything to you. That's way harder, though. 

That's a nice magic wand if you have it. But, like magic wands, it's just fantasy as far as I can tell. I was told that FL did not support any of the data protocols. If you can show us how to query the time, that's a whole new ball game. Or can you point me in the right direction and I'll do some digging? Does FL support GMCP? MSDP? MSSP?

[Lloth]

I'm actually not sure if it does. I play without any form of automation, myself. But I know that mudlet has that functionality. I'd have to do some reading up on it to see if it works with FL. But I'm at least fairly certain you can hide text returns from the mud, and the automatic input mudlet gives. So you can at least mimic the functionality as a bare minimum.

[myrek]

So basically ping FL every second to update the prompt? I'd worry that would interfere or cause lag or something.

[Lloth]

Nah, you can poll it for information as normal, not using a ping.

But what I meant was, you can hide some or all of script output (even trim everything but the script echoes) from yourself, making it so the script can see the return text, but it doesn't flood your screen. Useful for all kinds of stuff, like getting updates on who becomes visible, who you lose track of (invis, hidden, camo'd), who in your PK range enters your area, etc. You can use deleteline() to remove everything between line breaks, which the mud appends to the end of every bit of output it sends. But the script still knows that text is there, so you can still manipulate it and call it for things like comparing who/where lists and printing colored notifications. Or you can use it to simply hide the trash from yourself as it parses output and prompts for a time change in order to reset it's timer and alert you when the hour changes. Done right, you can have all of your scripts run completely invisible to you, minus the parts you want to display. 

Oh, and it actually doesn't cause lag. Lua is fast. C++ is even faster for low level computations, so processor lag isn't an issue. And many people also type a lot of commands in the span of a few seconds manually. So I don't see network latency being noticeable either. That said, if you use deleteline() a TON, on a slow computer... Sure it can be something you'll notice impacting mudlets performance. But... It's just text. Super unlikely. And if it does happen, I'm sure there are more elegant solutions.

But I personally find that all a crappy way to play. 

[F-3000]

Tintin++, very robust but not easy at all. Before I submerged deeper into TT's syntax, I combined PHP with it. When I wrote the PHP out of the code, I used bash with things I couldn't figure out how to do with TT.

On 2/9/2021 at 9:02 PM, Lloth said:

You can also do it so that mudlet queries the mud directly, without displaying anything to you. That's way harder, though. 

Something like this may cause "invisible lag" that may, in worst case scenario, get you killed. As we know, in the realm of FL and PK, we play with milliseconds, and even sending an empty line (just pressing return) will cause you a delay with a length least of ping. In my case it would be (avg.) 116 ms by these days, while it was 150 ms years ago. Someone physically close to the server may be able to enter 5 commands in that time, assuming that the game engine's internal tick is 20 ms, which would be the minimum delay with anything. This, of course, could be circumvented least in some degree with careful function design.

I still clearly remember the frustration when I (beast ranger) got murder-trigger-killed (by minotaur [zerk?]) several times at one halloween party years ago, when I couldn't get hide-command in just because of the ping-difference. I used flee;hide, and the assaillant had time even to walk two rooms and one back and murder me before the hide entered, as my client sent the commands separately. I've cried about this before, yes, but now I'm merely using it as a strong example. In a wrong situation a mere background prompt update may cause deadly lag.

On 2/9/2021 at 9:02 PM, Lloth said:

Which works, but requires a spell to expire.

Or any other tick-timed event. Weather is very useful for that. Just avoid anything that can be triggered by a player, as they may happen off-tick. Call lightning may ring someone's bell.

On 2/9/2021 at 9:02 PM, Lloth said:

And it gets messed up by dispel magic, either way.

Unless your client code keeps track of ongoing time, which @myrek's code doesn't seem to do.

My code made sure that the hour had actually changed when a spell drops, which included a check that the saved hour had changed recently enough not to dismiss a tick due to 12 min pause in getting a fresh prompt. Like, note editor or something. It also made sure to check for dispel magic or anything else that dispels spells.

On 2/10/2021 at 4:09 AM, Lloth said:

But I personally find that all a crappy way to play. 

I actually agree with this. There certainly is benefits for knowing when the tick is about to change, but getting that extra info constantly creates extra load for your brain to process.

[Lloth]

Some of that isn't true.

A client query is not a query made from a character, this nothing in the code to change the state of the character. That's if FL responds to such queries, which it may not. 

The exact timing may indeed differ, and there certainly are ways to get around the roadblocks I mentioned. Neither way is more perfect than the other.

You can hide the output of the script commands. One of the biggest benefits of mudlet is how insanely fast it is compared to other clients. Some of the processing lag other clients may experience with data removal is something mudlet can effectively shrug off. You can try really, really hard to give mudlet process lag, and I'd be willing to bet you'd have to be doing a hell of a lot more than output squelching.

A periodic information checking subtimer is infinitely more valuable (given that you hide it outside specific intervals), and while it certainly poses risks, it's a risk I would gladly take, especially when you string that information into other routines built into the script, like getting who list updates without having to remember to check it yourself, and warnings when PK range people enter your zone (can even keep a record of alignments tied to variable character names, to squelch warnings from people who can't kill you, like a paladin when you're a goodie).

And that highlights the benefit of how I'd put one together: larger integration. If you JUST want a tick timer, and have no plans for expanding your automation or convenience scripts, then the simple methods already mentioned work very well, and you don't need to concern yourself with being this fancy. If you do expect to want a wide range script platform, however, being able to seemlessly integrate functions heavily outweighs simplicity in the long run.