Hotspots Module upgrade so it can access database.

I still have code to submit to hotspots if you are done with this (I read something about how you had completed this on tw.org forums).

If you don't commit within a couple of weeks, I'll have to consider it dropped, and probably commit my changes, which you'll need to then merge with yours later if it's just taking some time.

Demystify has been removed from the TW Bot Development team

Perfect! I'm modifying the hotspots module quite a bit and wanted to add in this functionality.

What I'm planning to add:

- More spot options. Spot creation will begin with choosing to either: warp players to another location (or within the radius of a location), or send them to another arena. Then additional options become available. For both: optional text message displayed when the spot is fired. For the standard warp, they can select one, none or all of the following options: sending a single specific prize; sending a string of prizes; sending a specific number of random prizes; turning on/off any number of LVZ objects for the player; turning on/off LVZ after a certain time. (However, the warp will be necessary so as not to trigger the spot over again.)

- Allowing creation of spots before adding them in. You modify the options, then you !addspot in order to add it in.

- Something like !loadspots for ER+, and !savespots for HighMod+. !savespots will first remove all spots from the DB under the arena's name, so !loadspots will need to be done first.

I've committed an update to hotspots in association with the new custom utility. This will give hotspots a lot more functionality. Creating hotspots will now only take three parameters: The spots X, Y, and radius. I've added in the ability to keep the four, five, and six parameter options just in case people are used to them or don't want to change their macros.

At first I couldn't quite tell why 3 parameters would be used for a hotspot, but I see now entirely where you're going with this, and it expands the range of use quite a bit. Looks good — this does a lot of what I was planning to do on this module, but in a much more modular and useful fashion.

A few comments:

1) It's critical that the isAllowed and replaceKeys methods be moved to a core file; otherwise they will need to be defined in several different classes, and code forking will inevitably occur when someone updates one instance of a method in one class and not the other. If you don't want to put it in Tools because that class is getting too cluttered, I'd recommend a new static class in the same package. (In my opinion just pasting into Tools would be fine, though.)

2) As the vast majority of hotspots uses will still probably be the 5-argument standard warping feature, the !help display should still include information on the 5 and 6 argument versions. Otherwise some users may think that it's now dependent on the loading of the custom util to be able to do warping and such.

3) While I know there never has been before, there should be a way to remove individual hotspots.

4) Only after looking at the code did I get what repeat time means. I'd recommend something in the !help like: Time after which a hotspot may refire on the same player.

5) Just realized that the repeat checker works by creating not only a new TimerTask for each player, but also a new Timer. This means a new program thread is created every time someone enters a hotspot, which is not an effective use of resources. (I did a similar thing when creating a game module a few years back.) Instead I would recommend creating only one TimerTask that is scheduled by BotAction's scheduling methods, so as to use just one program thread, and using a HashMap<String,Integer> mapping from player name to time the player entered, as found in System.currentTimeMillis(). The task could run once every 200ms (the minimum possible repeatTime), iterate using for( String pname : hashmap.values()) over the entries and add each entry that is over the repeatTime to a new List of some kind. Then iterate over the list and remove all of those entries from the HashMap. Or, something equivalent and maybe more efficient if you can think of it, but creating a new program thread for each player is definitely not an option.

All in all, great concept work. This should expand it out quite a bit. I'll try to think of a way to package it all nicely in a DB. Or, are you planning to allow custom to save to the DB?

Good ideas. I'll claim this ticket and implement them.

Ara had an idea to save custom setups, but I have no plans to implement it. It completely depends on how successful these new utility updates are. If the custom utility gets a lot of use and I get a lot of feedback on the necessity of saved custom setups the most I'll most likely do is create a few pre-defined setups within the code/cfg. If anyone is fond of the idea of the ability to save custom setups I have no qualms about them implementing it as long as it works.

All changes in dugwyler's post have been implemented by Changeset 2321.

The hotspots module seems to be working fine now without any complaints. Do we want to keep this ticket open in hopes of still implementing some kind of database/file storage of spots?

I guess it's about time I got around to this. The website's <ER> Tools page needs to have a form added to submit new hotspots for arenas, but the bot coding is complete. I manually inserted the Javs coordinates into tblSetupHotspots in RoboKing's database and set the code's database to "local". I'm not sure if those match up or not. Once MMaverick restarts the multibots and makes sure those databases match I'll update the ?go javs setup thread.

Changeset 2456