I'll see if i can reproduce it, sounds really strange though, I dont really know how the sendAll works, it almost sounds like it gets placed onto the execution thread as an event, and for some reason it is then handled after the #BID event.Ī workaround may be to use a tempTimer to force delay of the #BID command, though if handleCommand solves it, i would rather recommend using that.
nfigmudletprofilesAchaeaAdjustableContainer. I am not sure if the last message means that it is not an issue when using cpc:handleCommand or if the issue occurs with both modes. Is that a mudlet feature, or something in the GUI Im missing Worst case scenario I can just leave the frames up and docked where I want them, that part of the UI works fine, but that takes up space and I cant lock them.
(profile A put "water (which is none) in bag first then profile B get water from bag and pass it to profile A)
#Mudlet profiles code
(profile A get water from bag and pass it to profile B then profile B put water in bag)īut when fire from profile B, somehow the #bid code is executed first in profile A then sendAll code is executed in profile B. When fire from profile A, the code work perfectly.
#Mudlet profiles password
an (optional) character name to use - again, only really useful for creating a Desktop shortcut to a favourite profile (handling a password on the command line is awkward though, as it will likely be readable via system overview processes - e.g.an (optional) profile name - which is of limited use in resolving telnet:// scheme URLS but would help in, perhaps creating Desktop shortcuts on several OSes.a port number (default to 23 if omitted).We do need to revamp the command line argument handling to provide a mechanism to accept the following arguments to make this work I think - so, in addition to the current limited arguments (the QT ones and -h/ -help, -v/ -version and -q/ -quiet) I think we need to handle additional arguments: There'll an issue with peoples already made profile using the server name vs IP address directly as webmasters might, but that's not something that could be easily avoided. If not profiles match.Ĭreate a new profile with the given server and port data, and the profiles name will be the servers name as well. If multiple profiles do, auto-load the latest profile used. When Mudlet is spawned via the telnet link, check to see if any profile(s) server matches server field of the link. The logic for this could be the following: Telnet links seem to work in the format of: telnet://, see for the actual spec. I think Mudlet should support those types of links - it'd be a lot more convenient for players to try out new MUDs if they only have to click on a link, instead of copying the server and port, going to Mudlet, making a new profile and so on.Īs for the naming of the link, we could either go with a custom one: mudlet:// or - use an already standard one (telnet://), which would be much better as some websites use it already ( ) and it would be compatible with other MUDs clients. Similar to apt://, steam:// and so forth links. Idea: MUDs should be able to provide an easy to use link with their connection info to spawn Mudlet and get it to connect to their game.
0 kommentar(er)
