Robobot 4 - Freezetag module

That's odd. Are you doing anything with the bot while this happens? Perhaps it's just not set to receive all death packets reliably … will check on that.

Note that this is RoboBot4 - the old multibot from queen. Roboqueen's multibot needs a good update first to make sure this problem isn't solved already.

Also I believe freezetag wasn't on Roboking's multibot - RoboBot5 ?

The MultiBots on Queen are currently using a slightly newer version than the ones on King, which was somewhat accidental — looks like lnx updated a large part of the core, and perhaps all of it. Unfortunately, the new MultiBot code was still waiting confirmation of every module.

Interestingly, even though the changes between Queen Multi and King Multi could be said to be cosmetic (help file changes, basically), King's MultiBot runs fine, but Queen's have trouble registering deaths. Stargazer ran several tests where hunt was failing on Queen Multi but running great on King. Star even ran the "dangerous" module on King's MultiBot, which worked just as it had in the past without any problems; this is known to be a notoriously intensive module.

My question is, why are Queen Multis having such trouble when the code is essentially the same?

I think we have to get both bots updated with the most recent version first before real bug solving starts since we don't know what version both bots (mainly queen) are running now. (wow what a long sentence :p)

Also, I would recommend to only focus on Roboking since we can control the version of the code of that core and properly fix it. Queen will follow in the next months (* cough * …years * cough *).

Replying to dugwyler:

looks like lnx updated a large part of the core, and perhaps all of it.

I highly doubt it, Staffbot and Robohelp still show the same bugs that have already been fixed. I think he only updated twdbot and compiled it so he didn't had to turn off the whole core.

Well, Queen seems to have the very latest version of MultiBot. There are 3 versions to consider:

1) Newest, the one you made changes to (casing of commands, !load == !loaded fix) 2) One I made changes to (added !modhelp and cleaned up help files) 3) Update to "MultiBot 2.0" which combines the features of TWBot and MultiBot

King appears to have the 3rd from the help display; Queen appears to have either the 1st or 2nd.

A complete core recompile (though, not all bots) is required to update to any of these. After the last Queen update it appeared Queen was still running (thankfully) the old MultiBot version. After this recent update it appears to now run at least the 3rd — at least this is when all of the complaints have come in. I believe that changes incorporated into 1 and 2 have been committed after that first major Queen update, so it looks like at least MultiBot was updated… but this would again require a full core update, and it would seem odd for lnx to update the core, plus only MultiBot and TWDBot, but not other bots. It's certainly possible, but unlikely — are you sure StaffBot and RoboHelp fixes are working?

You're right that we need to update RoboKing to the latest SVN to make any real headway here, though.

He also updated the core to fix the Ships enum problems but Staffbot still shows the problem with the missing first letter of each warn:

(StaffBot)>18 Apr 2007  - runks_rage (strikeball) to SeRtIfI: *warn you aren't sexy at all!

Also, I fixed Robohelp's !mystats but RoboHelp of queen still shows the old bug(s).

Weird! He must've manually compiled a few specifics… maybe to try to keep it safe.

Was this fixed?

No idea, will ask the ERs about this.

No complaints received about freezetag, closing ticket.