ZH's not able to spawn MatchbotR's from Roboking

This is probably a case of Roboking's old code that did this got replaced.

Here's the present code inside HubBot:

    public void handleSpawnMessage( String messager, String message ){
        if( m_botAction.getOperatorList().isOutsider( messager ) == true ){
            spawn( messager, message );
        } else {
            m_botAction.sendChatMessage( 1, messager + " isn't an ER+, but (s)he tried !spawn " + message );
        }
    }

Should ZH+ be able to spawn any bot? Even outside coders can spawn bots, but not ZHs. I don't really see bot spawning being harmful, particularly since they can't generally control them. Also, people hired to ZH should generally be trustworthy "enough" — just as are non-staff coders.

Alternately, we could just allow ZHs to spawn MatchBot, doing a check against the text of the bot requesting to be spawned.

Which is preferred?

Well I need to check the old code of Roboking to see how it was done in there.

I think ZHs should be able to spawn matchbots since they can control those but not the other bots - that is a thing for ER+ and another thing a ZH can "earn".

P.S. I don't even see why outside coders can spawn bots - as far as I know, outsiders.cfg isn't even used.

We could make it just ER-only then, except for MatchBot. This would also be more in-sync with the message it gives, anyhow.

Any word on how the old version was doing it? It would be a quick job if you can't find it to force a check if they would like to spawn a MatchBot.

The code from the old roboking is the same as you posted above.

     /**
     * Spawns a bot of a given type.
     * @param messager Name of the player who sent the command
     * @param message Bot type to spawn
     */
    public void spawn( String messager, String message ){
        String className = message.trim();
        if( className.length() > 0 ){
            m_botQueue.spawnBot( className, messager );
        } else {
            m_botAction.sendSmartPrivateMessage( messager, "Usage: !spawn <bot type>" );
        }
    }

    /**
     * Spawns a bot of a given type.  User interface wrapper for spawn().
     * @param messager Name of the player who sent the command
     * @param message Bot type to spawn
     */
    public void handleSpawnMessage( String messager, String message ){
	if( m_botAction.getOperatorList().isOutsider( messager ) == true ){
            spawn( messager, message );
        } else {
            m_botAction.sendChatMessage( 1, messager + " isn't an ER+, but (s)he tried !spawn " + message );
        }
    }

I'm wondering, a ZH should be higher then an outsider or not? If they are, why can't they spawn bots then?

ZH is still lower than Outsider, with access to nothing but basically ZonerBot and the ZHBot. Outsider was created as a compromise with upper staff for developers that needed minor access such as bot spawning, and then often wrote themselves into operator lists. For example, Ikrit used this to test and even host racingbot before he became a member of staff. At the moment it isn't used anymore, especially because of the new developer classification… but who knows, somebody on a startup zone might use it. Not sure.

If we don't have old code to work from it looks like we should probably just have it check for which kind of bot ZHs are trying to spawn.

Yea but I'm not sure we should do this. You would be putting something bot specific in a generic core class. It was chosen at one point that ZHs can't spawn bots, but now we would be blurring this line.

I would say not to do this (unless one of the higher ups also require this). There are always some unused ones around that they can use and if not, they can ask an ER+ to spawn one. Not that much trouble. (Also, I can make more MatchBotRs be spawned at startup - autospawn - so they don't need to be spawned and maybe only once with high-peak times.)

I definitely see your point there, from the perspective of good coding practices. It would certainly be a hack. Granted, though, TWCore is not a permanent codebase, perhaps having another good 3-5 years in its running time before something else is done. TWCore itself is a hack, to be sure; it emulates an SS client (but not even sending security packets properly), rather than working on the end of the server. I certainly hope that by then, someone trustworthy can wriggle the Continuum code from PriitK's hands. Then perhaps a redesign could be in order, and with it, server-side bots.

Rather than having an excess of MatchBotR's sitting around, though, why not just allow ZHs to spawn bots? There's generally not much harm that can be done in just spawning them when they can't be controlled. In fact it was far more of a security hole allowing newer coders to spawn bots that they coded themselves, often writing their names into the code.

As a comprimise, we could at least make a static String array of ZH-spawnable bot names in HubBot which would be checked against one at a time rather than simply being written in directly to the code. Probably also better than a CFG addition as it's such a small feature. I dunno. Personally I'm more for hacky usability than cleanliness, but then this is why I'm also not in the software industry and can only stand to code as a hobby.

I don't really agree.
I think more people has said that TWCore isn't going to live that much longer but the opposite has happened, it has lived on ever since and it probably won't die out unless TW dies or, as you said, a new Continuum client/game. However I don't see that happening since Continuum is and always will be an old 2d space game (and there is no money to make out of it).
TWCore isn't setup that bad, it works quite well seeing that a whole zone's bot population is working on it. Not to mention all the leagues and other statistics there are running.

Anyhow, we would have to do with what we got (and probably for quite some while). Putting in hacks and making this even more complex without a very good reason will just be destroying the whole core for the zone and future developers.

I don't think it's such a good thing for ZHs to spawn bots. It's a trainee position, they shouldn't be given something that can potentially crash the entire core (just try spawning all of the bot types).
Also, it isn't a real day-to-day problem that ZHs can't spawn bots, they only need to do this when there aren't enough around which can be easily fixed by auto-spawning more. (MatchbotR's are only used in 4 arena's; base, javduel, wbduel and spidduel where javduel is rarely used and spidduel isn't used at all.) Furthermore, keep in mind that the MatchBotR's can't be removed (as in !die).

Fair enough. It is still a client-side bot system, though, which, while not being set up that badly for a client-side bot system, is still unfortunately a bit of a hack. (Take a look at the Arena class if you want to see to what extent, particularly the player position tracking. All of this would be unnecessary and far more reliable server-side.)

I don't think that putting an allowed-spawning array in would really "destroy the whole core" — that's a bit dramatic, you have to agree. :> Yeah, it might need to be edited by any who use it outside of TW, but that wouldn't be all that difficult.

Such an option could also be relegated to a CFG; not too big a deal except for the space it would take up. But, it would also open the door for adding other options that could be easily turned off and on in the main setup.cfg. One good thing to have there would be a default value for player position tracking. It's not very well-known, but by default a bot only changes which player it is spectating every 5 seconds. Anyone trying to use it to reliably track position data has to search in BotAction a bit (if they would even know to do so) just to figure out that they should set the value to 200ms when they need the info — otherwise it works very, very badly… There are many more such core-wide options that could be included in the main CFG for fast and easy customization of esoteric options that are hard-coded right now. The ability for ZHs to spawn MatchBots could just be one such option.

CFG system implemented for this one so as to keep the code clean but still allow the option. Not sure if it works yet.

Was doing == comparison of two Strings. Yikes.

This should now work.

== comparison… ewww .. how could you?! :p

Never claimed to be a particularly good or careful coder — only somewhat prolific. Both styles have benefits, both useful, and ideally when two such opposites work on the same project.

hahaha only joking there buddy