Jump to content

Number Six

Homecoming Team
  • Content Count

  • Joined

  • Last visited

Community Reputation

233 Excellent

About Number Six

  • Birthday 01/01/1004
  1. An argument can be made about magnitude, but in general ATs with powersets dedicated to personal defense don't get force multiplier capability "out of the box" -- without having to dip into things like the leadership pool. IMO that's a good thing -- no one AT should get to do all of the things. Speaking mostly about 1-49 here since Incarnate powers seriously homogenize things. Sentinels are in the same boat with Opportunity, but IIRC PH wants to redesign their inherent anyway so I wouldn't count on it staying like it is.
  2. When the AI for the crate you're supposed to be retrieving from the bad guys forgets that it's supposed to be an inanimate object and starts turning to face you whenever you're nearby.
  3. Actually not possible. The total concurrent numbers, even on weeknights, is higher than the maximum number of players allowed on a single shard, even for when the game was in retail. If everyone played on a single shard, there would be constant queues during prime time. Raising that maximum any higher than it currently is can be done, but when we experimented with it early on, found that the limit is there for a good reason. dbserver (the piece that manages a 'shard' like Excelsior) has a ceiling of about 2,200 - 2,500 players before it starts having issues. Beyond those numbers any kind of database latency at all can very quickly escalate into cascade failure and cause instability. Splitting up the player base solves the design issue, even if the shards share the same hardware resources, mapserver pool, and database backend.
  4. I guess at 20% (same as Achilles Heel procs) it is higher than I remembered it being. I don't really have a dog in that fight and in general like the extra flavor, though I'm not sure I'd call something added in Issue 18 a "signature power". Mostly I'm making sure people aren't still under the misconception that it bypasses the purple patch. It used to be ridiculously good against +4 AVs because of implementation details, but not for many years.
  5. Errr, if you're running +4, Bruising is barely doing anything. It gets hit hard by the purple patch.
  6. Even that is unlikely, because as I've pointed out more than once when these conversations come up, our servers don't work that way. Shards are cheap. The map cluster that accounts for the majority of the cost serves all of them (except Reunion) and can be scaled up and down independently to fit the overall number of players across all shards. That's how the game was designed to be run and why Paragon never seriously entertained the idea, because it would not have been necessary to do that to reduce expenses.
  7. They were never locked to 2 processors. There were only 2 threads that did any significant work (since physx and the main thread were so tightly bound), so they could only effectively use two. In practice, the render thread and physx thread could never do any work at the same time. Even now fully using all 3 only happens under certain circumstances. At some point in the future it would be nice to identify things that can be parallelized, but there's a lot of work still to get there and be able to to do it safely.
  8. There are 3 threads that can use significant amount of CPU. 1. Main thread - all game logic, input, processing, etc. 2. Render thread - all draw calls and anything that touches the OpenGL driver, driven by thread #1 3. PhysX thread - simulation of visual effects that interact with the environment (sparks, etc), debris, etc 1 and 2 are relatively unchanged from retail. 3 used to be frame-locked to 1 -- it would do some background processing but ultimately if PhysX took too long to run a simulation timestep, the main thread would wait for it to finish, delaying the drawing of the frame (meaning thread #2 would also be idle). In the modern 32-bit and 64-bit clients (not the safe mode client), #3 is now fully decoupled and runs independently. If PhsyX starts to lag, it just won't be updated that frame and will make up the difference on the next one. If it gets too far behind, it will start removing PhysX objects in order to catch up. Under very effects-heavy situations with lots of particles flying around, that can lead to more efficient utilization of those first two cores. There are a few other minor threads, such as the background texture loading thread, geo loading thread, and some created by OS libraries for things like asynchronous networking, but those are relatively low-load and only serve to reduce latency.
  9. Specifically on the topic of porting AE missions: Honestly even if it were easy I'm not sure I would want to. With lots of respect for some of the talented AE writers out there, the AE toolbox is just so... limited... compared with what you can do with the full range of what's possible in standard missions. Consider the high bar that was set by the arcs added later in the game. Almost every single arc added in the last 2 or 3 years of the game includes things like customized mission maps, scripted NPC interactions, caption text, challenge badges, customized enemy powers, cutscenes, etc. While not every mission needs all of those at once or they start to feel gimmicky, by comparison AE missions feel like glorified radio missions. AE is a decent enough place to cut your teeth writing, but a good mission is produced by a team involving not only the writer but also mission designers, map editors, powers developers, artists, etc. We prototyped that process with the new vigilante & rogue arcs, putting a team recruited from within the community together to produce it, and everyone learned a lot from the experience. Those lessons will be applied to the arcs currently in development, and as we continue to get more people familiar with the processes involved we hope to get the pipeline more streamlined, and also to be on the lookout for additional talent within the community to add to it.
  10. Two things: Can @Garbleor anyone else who is having a similar problem try to locate islandrum.sh somewhere in the coh folder and post the contents? Once again the backtrace points at something wrong with the launch parameters, which seems to indicate an Island Rum issue rather than a game issue, but I haven't had any luck finding out what it's actually launching the game with. Also, an experiment: Launch Island Rum, let it validate/update, but do not run the game yet Go into applications/coh or wherever the game is installed Delete homecoming.exe Go into the hc-bin32 subfolder and rename cityofheroes.exe to homecoming.exe Move homecoming.exe out of hc-bin32 and into the top-level COH folder Try to launch "Homecoming (Safe Mode) the from Island Rum that's still open This doesn't actually launch safe mode, but launches the new 32-bit client with Island Rum thinking that it's safe mode. Surprisingly, this has actually worked for one person and would confirm that it's a problem with the way Island Rum is launching the new clients. It's not a permanent fix since Island Rum will redownload the original files the next time you run it, but if it works for more people it will help narrow down the problem and what needs to be fixed.
  11. One possible reason is that increasing the aggro cap for tanks makes it less desirable to have more than one tank on the team, not more, since a single tanker can pick up everything.
  12. Bit of a tangent, but the spawn behavior is correct, while the not-leveling-while-on-a-TF behavior is the bug. The reason for that is that you used to level up during a TF -- either natively or along with whoever you were sidekicked to. That broke when they introduced super sidekicking in Issue 16. Ever since then, upon starting a TF, the entire team gets locked to the level that the leader was when they started the TF. That means starting a TF at the minimum level, formerly a staple of static teams and SG runs, instead makes the entire TF a painful slog. It's a known bug that will be addressed at some point, just a matter of time and priority.
  13. I'm working on a standalone diagnostic tool to help get the info we need from these oddball devices, so keep an eye on this thread for it. At the end of the day, both the old client and the new one ultimately use the same method of getting joystick/gamepad input, but the old one had an extra middleware layer that Microsoft has since deprecated -- the newer one just gets the raw HID events directly. In theory anything that works with the old client should work with the new one, but in practice there may be some not-quite-compliant hardware we need to do special workarounds for (that presumably DirectInput was doing before).
  • Create New...