Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve: allow isActive(...) and exists(...) to use an ID number #6401

Merged

Conversation

SlySven
Copy link
Member

@SlySven SlySven commented Oct 29, 2022

Brief overview of PR changes/additions

With this PR passing an actual number as the first argument will use it as an ID number (provided it rounds to a zero or greater integer) and return a 1 or 0 if the corresponding Mudlet item is "active" or not / exists or not (though like the unmodified one that returns a count of items of the selected type that are active it does not consider whether all the item's "ancestors" are active as well before including an item in the count).

This can be used to identify the active status of temporary items (which are only identified by an ID number) - provided of course that they are around long enough to be checked. If the item does NOT exist then a nil and an error message will be returned instead.

N. B. isActive(...) will return 0 if the item (when given an ID number) or items (when given a name) does NOT exist - this might not be what is expected but is how the previous "name-only" form worked. OTOH ID numbers less than zero are never (:crossed_fingers:) going to occur and those will provoke a nil + error message if used.

Motivation for adding to Mudlet

This came about as a result of a comment in the Discord #help channel:

Kalrykh — 2022/10/29 at 15:15 UTC:

I've spent the past few(maybe more than a few) hours setting up some things with tempTriggers and tempTimers with regular triggers. Is there a way to show all active temp stuff? i can clear everything out by cycling mudlet, but I'd like to see if I've been running around generating tempTriggers/Timers without realizing it due to sloppy code on my part. if i don't know, they'll just keep getting generated by the regular triggers i'm using even after cycling mudlet.

SlySven — 2022/10/29 at 1526 UTC:
Humm, it seems that isActive(itemName, itemType) only works with a name (string) and not an ID number - so there is no way to find out the state of a temporary item.

Other info (issues closed, discussion etc)

This ought to help with the sort of issue that the OP raised (#6397) though a script using this revised function would, I think, be needed to do what is wanted there.

Signed-off-by: Stephen Lyons slysven@virginmedia.com

With this PR passing an actual number as the first argument will use it as
an ID number (provided it rounds to a zero or greater integer) and return
a `1` or `0` if the corresponding Mudlet item is "active" or not (though
like the unmodified one that returns a count of items of the selected type
that are active it does not consider whether all the item's "ancestors" are
active as well before including an item in the count).

This can be used to identify the active status of temporary items (which
are only identified by an ID number) - provided of course that they are
around long enough to be checked. If the item does NOT exist then a `nil`
and an error message will be returned instead.

This ought to help with the sort of issue that Mudlet#6397 raises though a script
using this revised function would, I think, be needed to do what is wanted
there.

Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
@SlySven SlySven requested review from a team as code owners October 29, 2022 02:06
@mudlet-machine-account mudlet-machine-account added this to the 4.17.0 milestone Oct 29, 2022
@add-deployment-links
Copy link

add-deployment-links bot commented Oct 29, 2022

Hey there! Thanks for helping Mudlet improve. 🌟

Test versions

You can directly test the changes here:

No need to install anything - just unzip and run.
Let us know if it works well, and if it doesn't, please give details.

@Kebap
Copy link
Contributor

Kebap commented Oct 29, 2022

Not sure if this addition is worthwhile really.
Usually players put their temp items in tables to know how many there are.
Maybe I am missing something.

Then again, would rather see a new function than overload existing API.
It is more newbie friendly and easier to code and easier to document.
I see hardly any advantage of using the same function name again.

@SlySven
Copy link
Member Author

SlySven commented Oct 29, 2022

OTOH It is impossible to determine the state of an existing temporary item. This is independent of whether the end-user generated it themselves and remembered/recorded the ID or not. Also, reusing/overloading the function name reduces the number of different functions that we have to document but extends the functionality in an, I think, logical/useful manner.

@Kebap
Copy link
Contributor

Kebap commented Oct 30, 2022

It is impossible to determine the state of an existing temporary item

Fair enough.

reusing/overloading the function name reduces the number of different functions that we have

My point exactly. I would prefer to have many small concise functions which will do one thing exactly and well, rather than very few very complex functions which can do a dozen different things, if you know how to wield them for that case.

While overloading is possible in c++ (but not c itself) it is rather uncommon in Lua, and I have pointed out some problems it may cause down the line already.

SlySven added a commit to SlySven/Mudlet that referenced this pull request Nov 2, 2022
This PR is an alternative/replacement for Mudlet#6401 that provides the
functionality with a *new* function rather than overloading the existing
`isActive(name as string, type as string)`. This is at the request of
@Kebap who expressed a strong desire for this alternative approach to
establishing the status of a Mudlet item by ID number rather than by name.
As temporary items do not *have* names but they do possess a unique ID this
will also work for them whereas the unmodified `isActive(...)` function can
not. Unlike the `isActive(...)` function there can only be a single item
that matches the ID so the return value is a boolean value rather than an
integer count (of matching items that are active).

Whilst developing the `isActiveID(...)` function I spotted that there was
potentially a need for the related `existsID(...)` in the same way that there
is an `exists(name, type)` alongside the `active(name, type)` function.
Like the `isActiveID(...)`function compared to the `isActive(...)` the
`existsID(...)` too only relates to a single item so also returns a boolean
result.

Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
SlySven added a commit to SlySven/Mudlet that referenced this pull request Nov 2, 2022
This PR is an alternative/replacement for Mudlet#6401 that provides the
functionality with a *new* function rather than overloading the existing
`isActive(name as string, type as string)`. This is at the request of
@Kebap who expressed a strong desire for this alternative approach to
establishing the status of a Mudlet item by ID number rather than by name.
As temporary items do not *have* names but they do possess a unique ID this
will also work for them whereas the unmodified `isActive(...)` function can
not. Unlike the `isActive(...)` function there can only be a single item
that matches the ID so the return value is a boolean value rather than an
integer count (of matching items that are active).

Whilst developing the `isActiveID(...)` function I spotted that there was
potentially a need for the related `existsID(...)` in the same way that there
is an `exists(name, type)` alongside the `active(name, type)` function.
Like the `isActiveID(...)`function compared to the `isActive(...)` the
`existsID(...)` too only relates to a single item so also returns a boolean
result.

Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
@SlySven
Copy link
Member Author

SlySven commented Nov 2, 2022

Closing in favour of #6403...

@SlySven SlySven closed this Nov 2, 2022
@SlySven
Copy link
Member Author

SlySven commented Nov 7, 2022

Reopened as this approach was deemed more acceptable in this case than #6403...

@SlySven SlySven reopened this Nov 7, 2022
@SlySven SlySven marked this pull request as draft November 7, 2022 16:47
@SlySven
Copy link
Member Author

SlySven commented Nov 7, 2022

Need to revise the exists(...) function to also take a numeric first argument as well.

@Kebap Kebap added the needs documentation This pull request changes things the players would use/see and thus needs an update in the manual label Nov 8, 2022
@Kebap
Copy link
Contributor

Kebap commented Nov 8, 2022

Can't review this code is above my level but some of my comments from the other proposal may hold true still.

This has been selected to be the more desirable way of doing things
compared to the alternative of Mudlet#6403.

Signed-off-by: Stephen Lyons <slysven@virginmedia.com>
@SlySven SlySven marked this pull request as ready for review November 11, 2022 03:11
@SlySven SlySven changed the title Improve: allow isActive(...) to use an ID number Improve: allow isActive(...) and exists(...) to use an ID number Nov 11, 2022
@vadi2 vadi2 self-assigned this Nov 17, 2022
@SlySven
Copy link
Member Author

SlySven commented Nov 26, 2022

📚 Documentation in Main wiki updated to (correctly) refer to handling ID numbers - the prior text incorrectly suggested that ID numbers already worked. See exists(...) and isActive(...).

Will require a further edit to replace Mudlet tbc with Mudlet 4.17.0 as I am not assuming anything at this time...! - Done.

Comment on lines +222 to +226
// The "isOptional" parameter is optional but modifies the error message to say
// that an argument is optional and it will default to not-optional parameters!
// HOWEVER it does not actually handle the absence of an argument that is
// supposed to BE optional - that has to be done by the caller before it
// makes the call... 8-P
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a bit of a bummer but I think the logic here might confuse others, especially not native English speakers

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are internal use functions though - only seen by us developers - who will need to remember this detail! 👿

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have non-native English speaking developers (and would love more), can you reword this to be simpler?

Copy link
Member Author

@SlySven SlySven Nov 27, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@vadi2

-// The "isOptional" parameter is optional but modifies the error message to say
-// that an argument is optional and it will default to not-optional parameters!
-// HOWEVER it does not actually handle the absence of an argument that is
-// supposed to BE optional - that has to be done by the caller before it
-// makes the call... 8-P
+// The (optional here) "isOptional" parameter only modifies the error message
+// given to the user to say that the parameter need not be provided. It does not
+// (until someone works out how to!) allow this function to deal with the argument
+// at the given pos not being present - so it is up to the function that calls this to
+// check for that BEFORE trying to call this function. This applies to all the
+// "getVerifiedXxxx" functions.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good!

if (lua_type(L, pos) == LUA_TNUMBER) {
// use lua_tonumber(...) and round because lua_tointeger(...) can return
// oversized values (long long int?) on Windows which do not always fit
// into an int:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@SlySven SlySven merged commit cdb35e2 into Mudlet:development Nov 27, 2022
@SlySven SlySven removed the needs documentation This pull request changes things the players would use/see and thus needs an update in the manual label Nov 27, 2022
@SlySven SlySven deleted the Improve_allow_isActive_toUseIdNumber branch November 27, 2022 18:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants