It is also possible that the we get the wrong fax because it changed before we got to it. Of course, we wouldn't expect the message to get lost so it typically is a failure in that case but it isn't that unusual of a case to not have chat open (I haven't opened it since 2018 and I can't really support telling scripters that they'd have to have chat open). That said, faxbot() seems to treat the lack of chat response as a complete failure and doesn't even check if the fax occurred and the message was lost. I don't think changing the faxbot() function is necessarily a good idea, although, I have no idea how many workflows would be broken by it and it doesn't have current run significance so it may be worthwhile to say: we need to redo this, sorry for the change. Generally, once the faxbot is online, it stays online until rollover (or until someone pollutes my DNS.) I agree with your asserton about online status. The faxbot() function is very unique compared to other functions because it has an interaction with open chat (very much an unexpected behavior for newer customers). I think the existing workarounds don't handle having to change a faxbot well at all (in fact, having private clans is yet another workaround for this to avoid relying on a missing faxbot). This is essentially my response to an unmade Feature Request to try all known bots before failing to get a fax.
#Resist faxbot code#
I am inclined towards the latter but it will make some code in some scripts unnecessary. Modify faxbot() so that it checks other bots in case of failure and uses the presence/absence of the photocopied monster to define success/failure.Īnd there are always things I have not thought about. This essentially moves the iterate over bots until success or end of list from mafia to the script.Ĭreate int robust_faxbot() that returns 1 if the requested monster was faxed, 0 if there is already a photocopied monster (possibly unknown) in inventory and -1 if it failed. (Tangentially, I did not see the expected prompt from a photocopied monster present so I don't know whether I don't quite understand the code or what so there is some work to be done).ĪFAIK there is no easy way for a script writer to detect that a bot did not return the desired fax and try a different bot.Īdd ash functions so that a scripter knows which bots are available and whether a monster is available from a specific bot. An attempt (temp code change) was made to check the next bot when the first one failed, but if chat was not running the result was getting a fax from one bot, not knowing the status, and then getting a fax from the next bot. The faxbot() command iterates over all bots and returns the result from the first one. The faxbot online status is based upon /whois and is not changed by the non-success of fax attempts. There is dead code that once aborted the command if chat was not running but that code is disabled, presumably in 2012. Since the faxbot command checks for a photocopied monster in inventory and offers the chance to dump the fax or abort, several scripts ignore the return from faxbot() and instead detect success or failure from the presence of the photocopied monster. Sometimes false means the attempt was made and definitely failed but sometimes it just means the attempt was made and the status is unknown. It returns true if a monster was successfully faxed but false does not mean the attempt was unsuccessful. My specific concern was the ash command faxbot() but some of these comments apply to fax support in general.Īt present faxbot() will only request a monster from the first faxbot that has it. In response to I started looking at the code.
0 kommentar(er)
