Jump to content

Kai Moon

Members
  • Posts

    196
  • Joined

  • Last visited

Everything posted by Kai Moon

  1. From a documentation point of view, I'm imagining a wiki table to lay out this cross-stacking split debuff scheme. I could cut out the archetype differences, but this much complexity would still need at least 3 to 5 columns. Might need its own separate sub-article to fit on mobile. Maybe a flowchart. Am I passive-aggressively pushing for plain debuff stacking or non-stacking? Yes. I'm a jerk before coffee. But I'm also serious, that table's gonna be big, and almost nobody's gonna understand it.
  2. Happy to help! It turned out "secseparators" was in a format only used by old versions of DPL. Updating that line fixed the duplicates. https://homecoming.wiki/wiki/Special:Diff/298400/300536
  3. Rune Burst is the power used by the fire traps in the Hellions part of Death From Below (DFB). It incorrectly deals energy, not fire damage. Apparently a copy paste error from Electric Bomb Blast, the power used by the electric bombs in the Lost part of DFB, which correctly deal energy damage. Tested on level 1 tankers. Steps to reproduce: 1. Create a level 1 elec armor/* tanker with Charged Armor. 2. Queue locked solo for DFB. 3. Untoggle Charged Armor. 4. Get hit by a fire trap, and record damage. 5. Toggle Charged Armor. 6. Get hit by a fire trap, and record damage. 7. Create a level 1 fiery aura/* tanker with Fire Shield. 8. Repeat steps 2-6 with Fire Shield instead of Charged Armor Expected results: Fire Shield reduces Rune Burst damage from 2.02 to 1.41 (30% reduction). Charged Armor has no effect. Actual results: Charged Armor reduces Rune Burst damage from 2.02 to 1.31 (35% reduction). Fire Shield has no effect.
  4. Having a pre-filled account name display as asterisks would be awesome, but getting off-topic. "Make the setting work right" isn't the way I'd put it. "Right or wrong" leaves space for personal opinions, judgement calls whether design is good or bad, clashing expectations based on being used to this old game's quirks vs expectations based on current design practices. Instead, what I want is "Make the setting do what it plainly says it does". The setting is "Remember Account Name". When unchecked, the game will sometimes Remember Account Name anyway. The cause, as seen in the source code, is because uiLogin.c never checks the setting (except to put a checkmark in the box or not). That omission makes the plain text of the setting not match the function of the setting. Fortunately, it's probably a one-line fix.
  5. These appear to be the relevant lines from uiLogin.c : smf_SetRawText(s_editAccount, g_achAccountName, false); smf_CreateAndParse(g_achAccountName, s_editAccount); // Required so smf_SelectAllText works. smf_SelectAllText(s_editAccount); This enters the account name into the text field, but doesn't look at g_iDontSaveName, so always executes. My understanding is that, for housekeeping reasons, g_achAccountName can't be wiped. But enclosing these lines in an if block should stop it from being displayed, which would be good enough. if( !g_iDontSaveName ) { smf_SetRawText(s_editAccount, g_achAccountName, false); smf_CreateAndParse(g_achAccountName, s_editAccount); // Required so smf_SelectAllText works. smf_SelectAllText(s_editAccount); }
  6. I think you're misunderstanding. When I start the game from desktop, the account name is properly blanked out. That part's working fine. The issue is that a LCTMS dumps me back to the login screen, and exposes my account name, whether or not Remember Account Name is unchecked. I can't expect or control that. And it's working contrary to what it says it does, which is a bug in my business.
  7. On the game login screen, unchecking "Remember Account Name" blanks the account name field, but only when starting up the game. So, for example, mapserver crashing or disconnection will expose the account name. This is a security risk for streamers. It should be blanked every time. Steps to reproduce: 1) On the login screen, uncheck "Remember Account Name" 2) Log in, select a server, select a character, enter the game normally 3) Quit to login screen, or simulate a mapserver disconnection Expected results: The account name field is blank, same as game startup Actual results: The account name field shows your account name
  8. There's a loading screen tip with the old url, any chance we can get that updated?
  9. Sir Lionel, Night Ward "Handle Drudges" mission acceptance / "Defeat the Drudges" nav text / "3 heads of Drudges to defeat" objective text There are three required enemies to defeat: one is "Head Taskmaster", but the other two have other names, such as "Remote Taskmaster" or "Powerful Spectre". Typo 1: "Powerful Spectre" should be used for Apparitions, not Drudges. Typo 2: The objective complete text is "You defeated Head Taskmaster!" for all three. That's only correct for one of the three.
  10. Retested and confirmed this bug is still occurring. These are the "Blue Ink Man" critters in the game: * Tsoo_CoV_Claws_Red_Men "Tiger Blue Ink Man" * Tsoo_CoV_Kama_Red_Men "Eagle Blue Ink Man" * Tsoo_CoV_Katana_Red_Ink_Men "Dragon Blue Ink Man" - does not count for Ink Man badge * Tsoo_CoV_Sai_Red_Men "Serpent Blue Ink Man" * TsooEndgame_BlueInkMan_Claws "Tiger Blue Ink Man" * TsooEndgame_BlueInkMan_Kama "Eagle Blue Ink Man" * TsooEndgame_BlueInkMan_Katana "Dragon Blue Ink Man" * TsooEndgame_BlueInkMan_Sai "Serpent Blue Ink Man" The only critter that breaks the naming convention (added "Ink") is the only one that doesn't count. So I'll bet there's a mismatch between the critter ID and the badge data.
  11. Did some testing. Ticks reliably apply the debuff when the sleet/rain pseudopet is still active. And debuffs reliably stay stuck to enemies outside the pseudopet's radius when it despawns. So it's only unpredictable when a tick of debuff hits enemies at the same time as the despawn. Possibly a timing issue or race condition. Maybe making the pseudopet persist for extra time, no longer attacking, might make a difference? For instance, instead of despawning after 15 seconds, make it last 15.2 seconds, but revoke its powers or make it only-affecting-self after 15. That way, no enemies are taking a tick of debuff at the same time as the despawn.
  12. Since i27p3, in Crey's Folly, some instances of the low level versions of Crey LTs incorrectly spawn the high level versions instead. These versions are forced to level 35 by their level range. Example, level 31 outdoor spawn. I'm level 34, the minions are correctly level 31 and gray to me. The Crey Juggernaut is the high level version with taunts, and level 35. This also occurs with level 35 Crey Crisis Units and Crey Eliminators in lower level spawns.
  13. I've gotten feedback from streamers that the sound effects of Kinetics Repel are too loud, and hurt the quality of their streams. I think Sonic Repulsion also has loud sound effects per target, similar to Repel. Suggestion 1: When the ReduceIfKD tag prevents Repel or Sonic Repulsion from knocking a target, don't play visual or sound effects on that target. Repel and Sonic Repulsion have no effect on a target when ReduceIfKD stops the knock. Playing no FX on a target is good UI feedback for nothing happening to that target. It'd also differentiate knock not happening due to ReduceIfKD, from knock happening but less than the target's knock protection. Suggestion 2: Play Repel and Sonic Repulsion's sound effect no more than once per tick, at the user's position. This would be similar to fixing the old Snow Storm bug, where the full visual FX were playing per target, blocking vision. Similarly, multiple Repel sound effects block hearing. Just one Snow Storm visual effect was enough, and same with Repel's sound effect. Suggestion 3: Both of the above! Just doing 1 reduces the volume in some cases, but leaves volume spikes in other cases, like if I use unslotted Repel on rooted enemies. Just doing 2 prevents volume spikes, but leaves confusing visual and sound effects when nothing happens due to ReduceIfKD. I think doing both would have the best result.
  14. I remember myself using Gale to blow things out of Freezing Rain before it ends, when soloing, to avoid this bug and make sure the debuffs stick, back in 2012. Long time ago, I may be misremembering. But it's such a weirdly specific memory, I think it probably happened. I haven't done that on HC, and I wasn't on the secret server, so I think I'm remembering 2012. I'm just puzzled why I didn't post this on the Defender Issues thread. Maybe I reported it after April 2012 (the last archive.org snapshot)?
  15. Not sure what Pzn means, but zoning has nothing to do with what I saw. Sometimes the debuff sticks, sometimes it doesn't. I'm just standing there with my power analyzer, not zoning. Also, it happens in SCoRE, so it's not HC specific.
  16. Stasis tube can be destroyed, but it permanently blocks the doorway whether destroyed or not, and prevents mission completion. Mission: "Stop Crey Arachnoid research" in the story arc "Building a Better Vermin" from Terrence Dobbs in Grandville Map: Tech_60_Layout_03_02 Approx coords: 2426 0 89 Edit: on my 5th mission reset, the tube spawned far enough from the door to complete
  17. Saw the same inconsistent debuff sticking myself. Checked score, and the debuff sticking is also inconsistent in score, so it's not HC specific. It seems familiar, so it might have been this way in 2012, though I don't see it mentioned in the Current Defender Issues thread as of June 2012.
  18. One exception: In a "Boss" detail, the critter selected as the "Boss" is not penalized for lacking minion+LT+boss enemy group diversity. The surrounding spawn, if any, may be penalized. This can be seen in "Bads" style farms. If the author creates only bosses/EBs/AVs, and constructs the mission so that "Boss" details spawn alone, then there is no penalty for lacking minions or LTs.
  19. Thanks all for the macro help! OK, maybe Combat Teleport isn't dead, though I still feel the powexec target macro for it might be. I had Teleport bound to cursor and Combat Teleport macro'd to target. I'll try reversing the two. Hope the longer range on Teleport avoids the screenful-of-cave-wall result so much.
  20. My teleport to target macro, before the last patch, had two possible results. Both results were completely fine. 1. Target is out of range, message displays, nothing happens. 2. I teleport directly next to my intended target. The same teleport to target macro, now, is frustrating to use, because the outcome is unpredictable, and often disorienting. 1. Target is out of range, message displays, nothing happens. 2. Target is kind of out of range, message displays, but then it goes off a moment later, and maybe I pressed the button twice, so I teleport twice and change directions, so I have no idea where I am. 3. Target is out of line of sight, false "out of range" message displays, and I teleport into a wall, and my screen is full of wall, so I have no idea where I am. 4. I teleport directly next to my intended target, because the target was already close to me anyway. For a couple months, I just stopped using the macro to avoid that frustration. Before I take the next step and start respec'ing alts out of Combat Teleport (and perhaps the whole teleport pool) entirely, is there any way to make teleport macros useful, other than just ensuring the target is already close to me?
  21. Hold up. "Working as intended" is misleading. It was a kludge, to patch over poor underlying design. Technical debt, some would call it. The door should remain open to someday making Power Boost actually do what the documentation and design says it does.
  22. Yeah, sorry about that, the City of Heroes devs did it on purpose. Questionable design decision, though (they could've made the piddly resist unenhanceable instead). And not documented anywhere in game.
  23. In Vincent Ross's mission "Learn the Source of True Power", there are 3 tablets (of the stone / mystic kind, not the computer kind) to activate. Clicking them gives confusing messages in the system log: "You access the computer." "You finish accessing the computer." "You found something"
  24. One thing that looks weird: the damage uses a proper AT scaler, the PvP mez duration uses a proper AT scaler, but the PvE mez duration uses Ones. That seems like either an oversight or a questionable design choice.
×
×
  • Create New...