srmalloy

I've participated in a number of Hami raids where people in the league are running around with Hamidon Bud pets out; this results in confusion during the bud phase, where you can't tell whether tab targeting is just picking a target way off in the distance rather than the bud right in front of you, and you can't tell for sure without mousing/clicking on it to tell whether it's a 'real' bud or a pet. I'd originally thought of asking that Hami Bud pets be counted as "live buds" for the purpose of preventing Hami from respawning, but it was pointed out that this opens the door to griefing, by people who leave their bud pets out specifically to keep Hami from spawning for the next run. As an alternative, if the Hami Bud pets could be configured to not be summonable in the Hive or the Abyss, that would solve the problem as well. A similar problem I've seen happen is when someone summons an MDC into the bowl during an MSR. Eventually, the MDC will capture the target, both for players and pets, and while lore pets, MM henchmen, and players can change target to a real one, once a (say) Fire Imp targets the MDC, its player has no way to tell it to ignore the MDC and target something else except by dismissing and resummoning it. This will result, depending on where the pets are when they change target when their current one is defeated, in all of the non-controllable pets eventually winding up targeting the MDC again. Unfortunately, I can't think of an easy solution to this issue, as there are some missions where nothing happens for some time, and an MDC would provide a distraction.

Would we have to sit through a thirty-minute animation sequence for his powerup, though?

An event message for the new Labyrinth of Fog shows up in chat as Visage of a giant monster has emerged within the Labyrinth of Fog. To be more grammatically correct, it should be "The visage of a giant monster...

And if it is done before your character reaches a level at which you've replaced all of their enhancements with IOs, you suddenly have a character slotted with enhancements they can't use. Pass.

It's annoying to be falling back to the style of the old "pets die in elevators" time, and having to reselect my chosen anchor to fire the power off again. I'll have to see about setting up a custom bind for it to make it faster. And while I expected it to happen this way, each of the Incandescence usages in the Hami raid I just participated in knocked off Shifting Tides -- being ported up to the monsters, being ported back to the collection area, and being ported to Hami. I don't know if this is just due to the time it takes me to click on 'accept' for the teleport prompt, but I've been particularly leery about auto-accepting teleports since early on Live, when some people got their jollies by teleporting lowbies to a point just off the roof of a tall building to watch them fall; unfortunately, all your henchmen automatically 'accept' every teleport request, even if you have 'prompt for teleport' turned on.

I don't know whether it will stack with another Tide Pool from a different character, but I've verified experimentally that when you drop a new Tide Pool, the old one vanishes. This means that we're not leaving warehouses and office buildings a meter deep in water, but it limits the utility of being able to put a Tide Pool behind you to slow ambushes while using it offensively.

Targeted toggles have long had a feature where, if the anchor moved too far away from the caster, the toggle would shut off. As I recall, this was done to reduce the magnitude of the swarm of mobs that could come rushing in if a player dropped a targeted AoE on a hostile mob who panicked and ran off, aggroing everything in sight back to the caster. I've found a case where this causes an annoying condition due to map design. With my Necro/Marine MM, I've been dropping Shifting Tides on my Lich, keeping the buff in range (I had been using Barrier Reef as an anchor, but it despawns periodically, requiring a resummon and reapplication). However, as I'm sure people are aware by now, multi-floor map instances -- labs and offices -- have each floor as a disjoint section, and your character teleports from one elevator to the one on the next floor when you click on the elevator. Well, the floors are separated by a sufficiently large distance that Shifting Tides detoggles every time I enter an elevator, forcing me to stop and reapply the toggle, akin to the way Controllers used to have to resummon their pet(s) every time they went up or down an elevator. This also occurs when entering or leaving an instanced mission, although it causes a much smaller degree of disruption, because I often dismiss my zombies while I travel to another mission, just to avoid having a string of zombies trailing behind me. Do people consider detoggling on elevator use within a mission a sufficiently unwanted behavior that it should be reported as a bug?

This bug has been posted as an issue on the Github page here. When importing the "build.txt" file exported from the Homecoming client using '/build_save', a character with Marine Affinity can have a power vanish from the build as imported. My Necro/Marine MM had taken "Power of the Depths" at level 30, and the 'build.txt' file showed it as Level 30: Mastermind_Buff Marine_Affinity Call_Depths When the file was loaded into MidsReborn, this power was missing completely, with the powers taken at level 32 and later moved up one selection, leaving the level 41 power selection blank (character is 43). After starting to open the issue on Github, I wondered if the problem was simply that MidsReborn wasn't looking for the right power name. I tried changing "Call_Depths" to "Power_Depths", after the same style of abbreviation used for other powers. This also failed to import. However, changing "Call_Depths" to "Power_of_the_Depths" (the full power name) imported properly. This means that it is not a completely broken functionality, and there is a workaround.

You just need to do some digging into images; there are plenty of wide-blade seaweeds, in various colors from green to reddish to brown, so you can just handwave it as generic 'seaweed' instead of getting finicky about the genus and species.

Use the plant chest detail, you can color it brown, a pale green to dark green, a pale red, and even some purples, and call it seaweed -- you can find all those colors if you look online.

I exported all my characters from Guardian using Titan Icon before the shutdown, so I can open the saved character file and copy out the character bio if I recreate the character. Unfortunately, when a character bio involves a lot of Unicode, I usually have to do a lot of transliteration and editing. For example, the first part of БРИГАДИР's origin story (up to the flashback) before abridgement to make it fit: … Калибрование… Один… Два… Три… Базовые системы онлайн. Чек памяти… Переданный. Кодовые модули… Нагруженный. Просмотр окружающей среды… Угрозы: Ноль. Эксплуатационный БРИГАДИР. A crate buried in the depths of a dusty, forgotten warehouse is a lonely thing to wake up in. Even when you're a robot. БРИГАДИР ('Taskmaster') was the prototype for a robotic officer, the director for a squad — or a platoon or company — of robotic infantrymen. But the Soviet researchers had built better than they knew. The Ministry of Defense wanted a soulless combat manager that would direct equally-soulless shock troops into frontal assaults with no consideration for casualties; what they got was a cybernetic Napoleon critiquing the tactical failings of the officers who tried to order him into action. When he decided the orders he'd gotten were practical, he could carry them out flawlessly. When given orders he decided were ill-conceived, he would as often as not completely disregard those orders and undertake a different objective, or at best disregard the battle plan he was given and implement his own. Finally, it was decided the problem was fundamental to БРИГАДИР's design, and he was deactivated, crated up, stuck in a warehouse, and forgotten... where he was lost for more than a decade, until, during an earthquake, an automatic threat sensor restarted his systems.

I have an ongoing issue doing MSRs with my Necro/Marine MM; despite having all my henchmen on Defensive/Follow, I'll regularly see one of them drop to half HP, and when I click on them in the pet window, I'll see them halfway up the bowl chasing some random Rikti while I'm down in the middle of the healspam passing out buffs, and they're just outside the range of my heal. Doing missions, even though the zombie horde rushes forward into melee while the Grave Knights and Lich hang back, I can usually position myself where the buffs hit everyone, though.

I have a fair number of characters with Russian or ex-Soviet backgrounds -- Ядерный Огонь, БРИГАДИР, Черная Молния, Удар Молнии, Совня, Стальная Дева, and others, eventually building up a headcanon of various heroes, villains, and hero and villain groups (Народная Армия, Красный Угроза), the state-sponsored hero groups being largely disbanded with the breakup of the Soviet Union, causing a diaspora of heroes to other countries. I also did some digging when writing up backgrounds, using real Russian research institutions where I could, like Институт эволюционной физиологии и биохимии имени И.М. Сеченова (the I.M. Sechenov Institute of Evolutionary Physiology and Biochemistry); this let me build loose connections between the backgrounds of different characters to show them as coming from a common culture, rather than springing out full-blown with no connection to anything else. Unfortunately, because Unicode characters are two bytes wide, they chew up a disproportionate amount of space in the 1023-character limit for a character background, which limits what can be inserted for flavor. One of the characters, БРИГАДИР, wound up with a background that spilled way over the 1023-byte limit, and I wound up continuing his background as a text file that currently sits at six and a half pages, stuck on my not being able to write a combat scene I'm satisfied with. He was my first MM back on Live, a Bots/Dark -- an experimental director for combat robots that became sentient and was shut down and packed away in a storage bunker after he started ignoring the direction of the officers defining his mission plan when he could see more efficient ways to accomplish the mission goals; the Ministry of Defense wanted a soulless combat manager that would direct equally-soulless shock troops into frontal assaults with no consideration for casualties, and what they got was a cybernetic Napoleon critiquing the tactical failings of the officers who tried to order him into action.

In Anton Sampson's "Defeat all soldiers in office" mission, part of the Mass Duplicity arc, after rescuing Lisa, I'm supposed to take her to where she hid the ledgers. The target arrow displayed on screen for this, however, is on the first floor, pointing at nothing, rather than the nav bar's indicator of it being someplace else (it looks as if it's simply a case of not being in the correct position for the elevators): Update: The red circle with white border marker was in the correct position on the second floor for the location I had to take Lisa to, although there is a secondary (albeit beneficial) bug that has been around since Live -- when a "take NPC to mission goal" target is on an upper level of a room, it is only necessary to draw the NPC under the goal location; only the horizontal position of the NPC is compared against the goal location, and they can be several 'floors' above or below the goal and still count.

At the end of Anton Sampson's first mission, you get the following message in your chat window: After calling your contact, you receive instructions to talk to Phillipa Meraux, the counter-terrorism specialist. This is impossible at this stage of your relationship with Anton Sampson, because you do not have his cell phone number at that point. If the mission text had some reference to a way to message Sampson with what you discovered, it would address the issue, but as it is you're told that you do something you can't have done. This has been a standing problem all the way back to the early days of Live, and the original devs apparently thought it was a sufficiently minor issue not to be worth fixing.

The character names are force-limited to ASCII 32-127, while the game proper supports a subset of Unicode (limited more by the game font than the client itself; it has Cyrillic, Greek, hiragana, katakana, and Devanagari characters, but not, for example, Ugaritic. I have characters with foreign backgrounds, and I've set up popmenus with common speech items in the appropriate language (although I used Romaji for the Japanese popmenu, since I figured no one would be able to read it in kanji/hiragana).

What I've done for most of the Location AoE powers (and I do new ones as I have characters acquire powers I haven't used before) is to make a .mnu file in the game folder (\data\texts\English\menus) with popmenu definitions giving options for using the power: //------------------------------------------ // Rain of Arrows Menu "ArrowRain" { Title Rain of Arrows Option "Rain of Arrows &1" "powexecname Rain of Arrows" Option "Here &2" "powexeclocation down:max Rain of Arrows" Option "Target &3" "powexeclocation target Rain of Arrows" } I then create a macro that calls the popmenu -- i.e., "/macro Rain popmenu ArrowRain" -- and drag the actual power icon off onto an auxiliary tray so I can see the recharge. When I click the macro, I get three options, that I can click on or type 1/2/3 to select: Execute the power normally, with the ground reticle to target Execute the power straight down at maximum distance. This toe-bombs the power if I'm on the ground, or if I'm flying over a group of mobs (i.e., the Hami raid monster phase), drops it on the ground directly under me. Executes the power at the location of my current target. This allows me to take my time selecting a target and then use it to center the power effect. Note that, because this is a location power, you can have a friendly or neutral mob targeted, or even a defeated mob, and the power will go off normally, because it's the position on the ground, not the target status, that is important. Some powers have more options -- Wormhole has five: normal, drop target(s) right in front of me, put target(s) straight up as far as possible (they don't take damage from the fall, which is disappointing, but it's fun to watch), drop target(s) in the camera direction at max distance, and drop target(s) behind me at max distance. The last two are useful for moving spawns around when you have limited stealth, as Wormhole by itself does not cause aggro.

Or the implants would have fallen off when the skin decayed, given the increasing prevalence of mammoplasty... again making them gender neutral.

With most of the MM henchmen, the upgrade powers do a model replacement along with granting the upgraded abilities, so yes; there's no place in the henchman definition structure for the fields that would be needed to make them colorable -- much less the UI functionality in the costume editor to define the colors.

The MM version of the power has the same issue; you can bring up the rename window and rename it, but upon zoning (i.e., leaving a mission), it gets resummoned on exit as "Barrier Reef".

I have a level 50 Grav/Traps Controller, and she plays completely different on teams than she does solo. Solo, she'll move up moderately near a spawn, lay down a number of trip mines determined by their relative level and a Poison Gas Trap or two, then Wormhole the spawn into the middle of the mines, letting my Singularity clean up any not-quite-dead survivors. Not particularly speedy, but walking through a mission with none of the mobs ever getting an attack off has its own appeal. On teams, that all goes out the window. At most, she'll put down a trip mine or two if there's a known route where an ambush will roll in from, but Lift, Propel, and the Singularity make up the vast majority of her activity; no one is interested in waiting for the time necessary to set up a room-clearing mine field.

The issue seems to be that you are rezzed, and then the Untouchable effect is applied, because it has no effect on a downed character -- so you have to be alive before it can be applied. And it has a non-zero (albeit small) activation time, so if you draw the attention of mobs by rezzing, a mob that does not otherwise have its attacks on cooldown can -- and if you're the only one standing at that point, will -- draw fire before the Untouchable activates. The fix would be to make Untouchable usable on a defeated target, and apply it first, before the rez, so that you rez as untouchable.

For the time being, I've got the other four -- two Mark of Supremacy, the Call to Arms aura, and the Cloud Senses proc -- slotted, and I'm still in the 'not enough slots for everywhere' levels, so I shouldn't have a problem waiting.

In your updated build, Lich is showing the Touch of the Nictus proc in slot 5; this is an Accurate Healing set, and the power doesn't take that set when I try to slot it in game. Is Mids allowing invalid slotting now? If so, it should be reported as a bug.

I've had a number of occasions where the informational popup for an IO -- the one showing the IO characteristics, the set bonuses, et al. -- will pop up over the entry in the AH window, blocking the bid field while I'm trying to type in a bid. The coverage is purely cosmetic -- if I'm counting the characters I'm typing, they are entered normally -- but I can't see what I'm typing, so if I've made a typo, I won't see it until I stop and drag the mouse cursor off to the side to make the floating tooltip disappear. As a minor QoL improvement, can the AH interface be tweaked so that when you put the focus in the bid field for an item, it automatically makes the floating tooltip disappear? Having the tooltip is useful most of the time, so just turning it off wholesale isn't what I want, but not having it cover the bid I'm entering would be useful.