Mudlet features and API requests

phasma
Posts: 191
Joined: Sat Aug 03, 2013 7:00 pm
Discord: phasma#4694

Re: Mudlet features and API requests

Post by phasma »

Yeah. Honestly, just sysLoadEvent would be plenty.

User avatar
demonnic
Posts: 883
Joined: Sat Dec 05, 2009 3:19 pm

Re: Mudlet features and API requests

Post by demonnic »

Ok... i'd lke to address stopwatches again. I know there was a previous thread about it, but I think it should be looked at again.

Consider an actual stopwatch. It tends to have two buttons, one to start and stop, and one to reset. It also has a display to set the time.

the start/stop button can be represented with the stopStopWatch() and startStopWatch() functions. The reset button with the resetStopWatch() button.

Only, it doesn't work this way in practice. When you push the start/stop button on a running stopwatch( stopStopWatch() ), it stops the time where it is, and leaves it at that time. Then if you hit the button again ( startStopWatch() ) it should start counting from exactly where it left off. The only way to put it back to 0:00:00 would be to hit the reset button ( resetStopWatch() ).

The way it works in mudlet is you run startStopWatch() and it starts the watch. You hit stopStopWatch() and it returns the time, but if you query it for the time it appears to still be running. Not only is this a waste of cycles, but it's not the expected behaviour. On a real stopwatch, I would be able to look at the screen ( getStopWatchTime() ) any number of times and see the same number as when I stopped it.

Then, you run startStopWatch() again, and it auto-resets back to 0. Making the resetStopWatch() function just about useless, except perhaps to reset a running stopwatch ( I have done no testing to see if it works like this in practice, it may stop the stopwatch in addition to resetting the time to 0 ).

In fact, I've seen instances where if you resetStopWatch() and the get the time from it, it'll suddenly be in the thousands of seconds.

Is there any way we could get these functions to behave like an actual stopwatch? If not, could we get functions which do work like a real stopwatch?

If needs must I could do this in lua, creating 'objects' which store the time built up/etc but I think the current implementations are more of a bug than anything and should be reworked. The only problem being it might potentially break peoples' scripts to change it. Though, if they were following the prescibed stop->reset->start formula put forward, they should behave in the way expected by the script still (as any start resets it to 0 anyway)

User avatar
Akaya
Posts: 414
Joined: Thu Apr 19, 2012 1:36 am

Re: Mudlet features and API requests

Post by Akaya »

I agree with what you're saying and propose that a new set of functions be implemented while keeping the old for backwards compatibility.

User avatar
demonnic
Posts: 883
Joined: Sat Dec 05, 2009 3:19 pm

Re: Mudlet features and API requests

Post by demonnic »

Is it even necessary? Is someone relying on their timers not stopping when they tell them to, or randomly jumping into the thousands when it's reset instead of staying at 0?

I mean, I suppose but I'm having a hard time coming up with a use case for that one. I know it would make me redo some of the animated timer stuff I just worked on (which prompted this post in many ways) and so for those things I can kind of understand wanting to preserve the old functionality.

A new set of functions would do just fine though I suppose, and still be better than me writing around it in lua myself.

ktiedt
Posts: 31
Joined: Wed Feb 20, 2013 1:08 am

Re: Mudlet features and API requests

Post by ktiedt »

Why not just provide an optional argument to get legacy method for 1 release... forcing a new name for a properly working method would be a bit asinine.... now you have a logical name that doesnt work... and odd names that... do... all to possibly save someone from not fixing admittedly broken code....

User avatar
demonnic
Posts: 883
Joined: Sat Dec 05, 2009 3:19 pm

Re: Mudlet features and API requests

Post by demonnic »

Mudlet has worked hard to try and prevent breaking its API from earlier versions whenever possible, so that peoples' scripts are less likely to suffer from bitrot.

I know the workaround I used in my animated timers framework would still actually work as intended, come to think of it, as I'm resetting the stopwatch before starting it anyway (because I wasn't sure if not doing so might introduce some random element to the stopwatch, not knowing what stop actually does as it doesn't seem to actually stop the stopwatch)

User avatar
SlySven
Posts: 1019
Joined: Mon Mar 04, 2013 3:40 pm
Location: Deepest Wiltshire, UK
Discord: SlySven#2703

Re: Mudlet features and API requests

Post by SlySven »

The "don't break existing API" can be a pain because even adding additional arguments to work with "improved" versions will fall over if you (or more likely some other user who is using your scripts) use scripts that require the "new" functionality with an "old" Mudlet instance that doesn't provide that same "new" stuff - the Lua or at least our standard is generally to disregard additional arguments (or so I believe). Hence the general direction of using new names for "built-in" functions so that scripts can check for that functionality by the presence of the new function name is the only really safe way to do it.

[aside]
For example, I coded some additions to the map user room data code so that the user could delete a single data item from a particular room by specifying the room number and the data key so the lua function became clearRoomUserData(roomID, key) whereas it was clearRoomUserData(roomID) previously - unfortunately whilst this was fine for both old scripts on both new and old instances of the Mudlet application, if a new script was used on an old instance of Mudlet, the latter would ignore the additional key data and proceed to delete ALL the room user data for that room instead of the just the specified item; now this was a particularly harmful instance but the reason for moving the new code to a new clearRoomUserDataItem(roomID, key) should seem a bit more understandable of why we have to do it this way!

To help, a little, with this sort of thing I have also recently coded in something that propagates the Mudlet version data all the way through the application, which, if adopted, means that you might look for a lua command: getMudletVersion({|"major"|"minor"|"revision"|"build"|"string"|"table"}) in the future which means a script might be able to modify it's behaviour to fix some known bug in a particular version. This is provided the correct values get set in the project file at compilation time, but I understand from other developers that it is not likely to be recommended or the approved way of doing so. :geek:
[/aside]

It seems to me that the stopStopWatch() has to remain (with the addition of a synonym getStopWatchTime) but we additionally need a haltStopWatch() to inhibit timing and a continueStopWatch() to undo that.

I am aware that there has been a change in the QTime and related Qt classes since Qt5.0, 1 or possibly 2(?) came out that means that a null time is not the same as a zero time (only the latter returns isValid() as true) and that adding a time value to a time variable that is invalid no longer results in a valid time whereas it did in Qt 4. This might be relevant for that resetStopWatch() producing odd results. :ugeek:

ktiedt
Posts: 31
Joined: Wed Feb 20, 2013 1:08 am

Re: Mudlet features and API requests

Post by ktiedt »

While I can appreciate not breaking backwards compatibility... there should be a level of common sense applied to it too... ie: 1) its clearly broken... it was never intended to work the way it does 2) not creating new functions for the sake of creating new functions (deep down, that is what this turns out to be -- it is a BUG fix (meant to replace broken functionality and fix it), not an enhancement (meant to supplement existing functionality (ie: new methods))

If you truly plan to never break any old script that may or may not even be used anymore... I feel sorry for the nightmare that will come of this....

User avatar
Akaya
Posts: 414
Joined: Thu Apr 19, 2012 1:36 am

Re: Mudlet features and API requests

Post by Akaya »

Its not broken. It just doesn't function how an actual stopwatch does. Numerous scripts utilize these functions (many of my own included) which is why it cannot break backwards compatibility. Mudlet has been exceptionally good with this 'rule'.

The only bug I really see is with resetStopWatch() and the thousandths of seconds. Which SlySven addressed as a result of a Qt update.

I still think a new set of functions that work as expected is the way to go.

ktiedt
Posts: 31
Joined: Wed Feb 20, 2013 1:08 am

Re: Mudlet features and API requests

Post by ktiedt »

I will just say that "a new set of functions that work as expected" pretty much cements the fact a methods named around the function of a "StopWatch" not functioning as a stopwatch is in fact broken.

And I'll leave it at that, clearly I am the minority here that feels code bloat for the sake of bug fixes is a bad idea. I just hope this "fix" is an exception and not the norm for Mudlet otherwise we'll soon be seeing M$ level of inflation in file sizes...

Post Reply