Vigilante Supergroup ???????? Beacons?

Triumph: White Succubus: 50 Ill/Emp/PF Snow Globe: 50 Ice/FF/Ice Strobe: 50 PB Shi Otomi: 50 Ninja/Ninjistu/GW Stalker My other characters

It may not be possible to do that. They can limit when they list the bases you have available to enter, but it may not be possible to set a limit for the exit menu that takes you back to a Zone. So it may not be possible to do this without allowing Heroes to exit into Villain Zones.

From Pocket D it appears they can cut off a particular portal from either a Hero or a Villain, but that would mean that the whole teleporter would have to be cut off, not just an individual exit. So at best that might mean you won't be able to put a Hero exit and a Villain exit on the same teleporter. And Pocket D is a co-op Zone, and you might not want to bother with the complications of co-op Zones in a base. (For instance, you would be kicked out of a Task Force if you entered your base)

One solution that has been suggested, though, is to allow Rogues and Vigilantes to "borrow" the teleporters of a base on the other side. An SG can set permissions to let teammates of the team leader in their base, just allow "tourists" in there as well. (Currently they are not allowed in)

I've also suggested allowing Coalitions, or even allowing an SG to have two bases, each with their own teleporters, so Vigilantes can have access to a second base with the exits they need.

Another thing to note is that although you can't place the beacon, that is a badge you can earn for your SG. So that's something, even if it has no gameplay function.

Are you... seriously... wanting a response to that question? I mean, I can give one.

The Database Does Not Work Like That.

For starters, Supergroup and Villain-group bases are not exposed to the player in the same way that other maps are exposed. Bases are a hybrid of an instanced map, a zone map, and have other odd attributes, such as the exposure of controls to modify and manipulate the map.

In Zone maps, the map is always on. Even if nobody is in the zone, the map itself is still loaded, and events still occur inside the zone. Which is why events like Zombie attacks or Giant Monster assaults can occur in zones that don't have any players logged in.

In the base map, the map is not always on. The base-map is loaded and given an instance identification whenever somebody access's it. Now, this may have changed, but I'm pretty sure it hasn't.

Exposing base maps as instances allow the developers to save on real-time processing needs. If there is nobody in a base, there's no reason for the base to be loaded onto a server.

The hybrid nature of the SuperGroup / Villaingroup base is just one of the many obstacles that stand in the way of spawning them as a Tourist capable zone. There's many other legacy code issues, such as the status of destructible objects which are flagged to be friendly to Hero's / Vigilantes in SG bases, but would be valid targets for Villains and Rogues.

No, these are not insurmountable problems to address. They are, however, time consuming problems, and it's only now with Going Rogue actually having launched that Paragon Studios might have the development resources to tackle the legacy database issues. Even then, updating Bases and everything that can be done with bases to recognize Faction differences is probably a good 12month to 16month project.

A: wrong terminology.

B: This is actually related to the original problem: The database doesn't work like that, or more preciously, limitation based on how the database currently works.

The system largely works on an automated trigger, where certain actions automatically result in a certain event. This comes down to a code-simplification problem. As I understand how the system works; and if I'm wrong Tele will likely chew me out later; the system basically does a table look-up. The database system checks to see how many badges you have earned, then when you meet certain requirements in the table, an automated script is run that performs the on screen unlocks.

Determining whether or not you are eligible for those benefits to begin with would require an additional lookup. Your information and status has to be sent to the server for every action that you do, and a response has to be generated in relatively real-time. One additional look-up operation isn't a big deal. Now ask yourself this question: how many people play the game? How many different characters will be capable of generating the circumstances you created.

One single operation suddenly just became thousands of operations. Now we are talking not just one or two kilobytes of data to and from the network, we are looking at gigabytes of information to be taken in, stored, analyzed, and manipulated... for each player.

This additional character look-up would have to be added to every situation where a Tourist faction could gain a reward that they are not eligible for. Now the solution has gone from one or two lines of code to several lines of code for every single situation.

Rather, the developers current solution, which basically consists of a read / write permissions check after the action has been accomplished, saves, time, data, and prevents against code bloat. The scripts and codes don't have to be changed or modified, and the developers can bury the denial of reward on the back-end of the processing, which means that your direct gameplay does not suffer from the increased processing load.

The thing is, you use the wrong terminology. There's nothing for the developers to fix. The code itself is not broken. Your expectation of how the code should work is what is broken.

The developers don't need to fix anything with the code. What would be nice is if the developers were able to either update the code, or rewrite the code, and the resulting database infrastructure.