Jump to content

RubyRed

Members
  • Posts

    134
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by RubyRed

  1. Yeah if I was going to start completely from scratch and actually care about reusability I'd do that. Maybe a v2 some day. For now it works, which was my primary goal lol.
  2. So I originally had a thought about building a tool that needed some of the powers data, and that led me down the rabbit hole of how exactly to get the specific numbers from the client data. There are certainly sources floating around out there, but most of them are out-of-date, so I created a tool which can extract directly from the bin files of the latest builds and then spit it back out as JSON. Then I host those files online, et voila! >>> https://coh.tips/powers/ <<< Last update: February 12, 2021 -- Issue 27 page 1 (v2) It's not really an API, but it can be used like one. Additionally, you can just download the JSON files if you'd rather use them without an internet connection. I'm not trying to replicate the raw data exactly, rather it is in fact a massaged version that tries to make sense of the complex structures. v2 API is online, deprecating the v1 API. The v1 data is still available at the same URL as before (I have no current plans to remove it even though it's deprecated). It is safe to use the online v2 API as the structure is set. New data may be added but there will be no breaking changes to field names or structure. If you're looking for some tips on how to read bin files yourself, I put together a blog post about it: https://rubidium.dev/2020/03/07/code-archaeology-reading-city-of-heroes-bin-files.html Also this is completely open source. I tried to write it in such a way that anyone can follow along at home and incorporate learnings into their own projects: https://gitlab.com/rubidium-dev/powers Here's hoping that more community devs can build some awesome tools and web sites for us to enjoy. 😎
  3. Agree, SD shouldn't be buffed IMO. It's already really good, and making it trivial to get 100% uptime on it would feel a bit OP.
  4. I finally got some time to test DM on Brainstorm this morning in a PI radio team (with 4 elec defenders! felt pretty good 🤣). Shadow Maul feels great now, I had basically just been using it as a single target attack before, but now I can actually consistently hit multiple targets. Great change. Dark Equilibrium I'm not sure how I feel about. My level 50 scrapper didn't have endurance problems anymore so I very rarely use it on live, mostly only when I'm actively getting endurance drained. I tried just using it as part of my attack chain to see if the added aoe damage was good, but as @ScarySaipoints out above, it just doesn't feel that impactful. The damage didn't feel like it was really moving the needle in any fight, especially with how long the recharge is. I also don't like having attacks that can't crit, that's the whole reason I play a scrapper.
  5. I've kind of struggled myself with the 'do it right' mentality when approaching this. The problem in the instance of the .bin files though is that they're not self-describing... even if you figure out that the structures of data are a series of 32-bit floating point numbers and booleans (which accounts for most of it), there's so many of them that it's nearly impossible to know what you're looking at. And if someone goes in and adds a new bit of data, it's not immediately obvious where it is or what it is, and you have to decipher that. Even though I'm referencing the i25 code from early last year, I ran into several parts that have changed since then and that slowed me down quite a bit. I'm glad I have the code to reference because this effort would have taken ten times longer if I was reverse-engineering from scratch, and I don't really have the time for that. I'll live with the fact that my code is a bit messy (but probably easier to figure out what's going on) rather than the perfect, generic solution. That said, now that I know a lot more, I think when I'm done I'll share some tips that could save other people time if they want to go down the same route and not have to look at the CoH code base (which is an adventure all on its own). Nah, not really. At least not to me, I understand the mindset as I tend to approach things the same way (at first... I change my mind a lot).
  6. Actually I find that interesting, I work in Rust as well.
  7. Oh my! My dark/dark scrapper is already my favorite toon... these changes sound so good, can't wait to try them out!
  8. Yeah that's something that personally bothered me when I was looking back through the history of tools created by the CoH community. It seems everyone wanted to keep their sauce secret. 🙄 As I alluded to in other threads, I'm working through bin parsing myself. It will all be open source and permissively licensed. I even *gasp* comment my code so others can figure it out. The only way the tools get better is if people share instead of keeping their toys to themselves.
  9. Just taking a quick jaunt through the rendering pipeline, it appears that all of the FSAA done in the game is MSAA, regardless of the number of samples. At least that's what it's asking OpenGL to do, what it actually does is entirely up to the hardware driver. The 16x difference could be a quirk of the Nvidia drivers' implementation, but I'm not that experienced on the particulars of different drivers so I couldn't say for certain.
  10. So the game is capable of reading two formats - .def and .bin. The .def files are plain text and can be edited by hand (I'm guessing Paragon probably had tools for doing this but we don't have those). So you can go in and adjust stats there, and if the server/client are running in development mode, it can read those directly so that a developer can make on-the-fly changes and test them. For release builds, the .def files are read into memory and then dumped out as .bin -- these aren't really compressed per se, but they are a pain to use directly as they're basically a memory dump of the structures as the game sees them. There's also two possible formats -- i24 uses Parse6 which looked a bit more like the original .def files in structure, but i25+ uses Parse7 which is arranged in a way that's quicker to load into memory and cuts down on repetition. You could probably reverse engineer Parse6 pretty easy but for Parse7 I've had to refer to the code a lot.
  11. It's not in the code itself but a bunch of external .def files that are compiled into .bin files for release bundles. Check Common/entity/powers_load.c for the starting point of where that happens... or if you just want the data itself check the dumps as @Sifpointed out.
  12. Sure, you can reduce anything down to "it can be done." It probably isn't hard, in fact. It's definitely time-consuming and tedious though. And for what benefit? Like I said, what you've proposed is different, but I don't see how it makes things better. Dev time is scarce. Personal preference, but I would prefer they prioritize things that actually make ATs and power sets fun to play and close the gap between great powers and "okay" powers. This just doesn't seem like it. Being able to move the needle on a secondary effect from 60% to 100% or whatever just seems incredibly nitpicky.
  13. It's an interesting proposition, but it basically changes the entire characteristic of the powers you're referring to. Those added effects have a flat-rng chance to proc specifically because they are a secondary effect of the power, a bonus if you will, and not the main thing that is being checked for accuracy. This isn't that uncommon a thing to do, even in modern games. It's certainly possible to change them to be more accuracy-like rather than a completely random-chance, but as @Wavicle points out, that would probably require a balance pass on every effected power... I don't know that the benefits (if it is a benefit, I think it's just different) are enough to justify such a sweeping change. Outside of the secondary effects, are there any powers that use a flat % chance to hit? I can't think of any off the top of my head. If they exist, then maybe powers where the primary effect is completely random could be looked at.
  14. Oof. The name generation part of this was the most complex part, and I spent way too much time on it. (And frankly I'm still not 100% happy with it, I had to force myself to stop messing with it...) It's a good idea, though. I've got some other things I'm working on right now, but maybe later I'll revisit this and add SG naming. Thanks!
  15. "interesting option" ... I could only imagine the outcry when players encounter monsters that eat inf 🤣 (I assume that's what's meant by "strip away unspent influence points" ? though it's not real clear)
  16. You may find this reply on Primalist from NumberSix useful:
  17. I don't have a lot of time to collaborate on a project right now, but you're more than welcome to use the interface CSS I wrote (if your project is web-based). I put it under a MIT license which should hopefully be permissive enough to not be a problem for anyone wanting to use it. https://gitlab.com/rubidium-dev/city-suggests
  18. Oh no, that would be an absolute cluster----. The whole basis of this thread is the fact that people on different servers want different things. Not having a shared code base is what allows people like WHC to do whatever they want without impacting others.
  19. Unfortunately, like most game codebases, CoH is a bit messy but more importantly it's a bunch of interlocking systems that interact in ways that are hard to comprehend if you didn't spend years becoming familiar with it. I wouldn't dream of touching anything without a good deal of testing afterwards. This is evidenced even in Homecoming's latest patches.. try to fix some things for tankers and a whole bunch of other things get swept up in the changes. I appreciate that there are those out there that want to be on the bleeding edge of content, and for those that can stomach the bugs that come along with it, I'm glad they have a place to play. For me personally, stability and playability will always be more important.
  20. This thread has gone completely OT, but what the heck. I'll bite. I went back and looked for where it took a nosedive. It was originally a fairly neutral conversation about getting some things that another server has, and the philosophies behind why we may or may not get them. It wasn't until jubakumbi's first post that anything resembling animosity towards other servers was discussed or implied. Then once he got the conversation steered in that direction he just comes back to the pot to stir every few posts. In other words, classic trolling. The only animosity being displayed here is by those who feel they have something to prove about non-HC servers for whatever reason. It's a self fulfilling prophecy because once the conversation moves in that direction, everyone instinctively gets defensive. Don't feed the trolls. HC and the other servers can and do co-exist peacefully. It isn't worth arguing over suppositions.
  21. I don't think anyone needs to "get over it," new things like ATs and power sets and whatever else are certainly exciting and can only help the longevity of the game. I get excited about the possibilities myself! But I would hope that everyone could also realize that the other part of ensuring the game's longevity is not just throwing new things in the mix just because we can, since that could easily disrupt the stability and balance that players want out of a live service game that we hope will run for many more years.
  22. I actually prefer the slower pace of homecoming. I'd rather get changes that are incremental, balanced, and thoroughly tested rather than whatever toy looks flashy this week.
  23. IMO, the problem with threads like this is that they always start with the premise "The game isn't hard enough" and then end with a suggestion of basically universally altering the game for everyone, without regard for those who enjoy the current state. Suggesting things like nerfing IO sets and attunement like OP just starts an unwinnable argument between the sides that like the idea and those that don't. Personally, I like that the game can appeal to a wide range of players, from those who like to sit in their base and RP to those that challenge themselves to solo TFs at +4/x8. The game is for all of those players. However, if you're at the upper range of mastery of the games mechanics, you're probably never going to be satisfied. Adding things like a +8 difficulty option just creates a delaying factor until you discover a build that can easily solo that content. Difficulty inflation isn't an ultimate solution to dissatisfaction with the upper end of the difficulty curve, because that goal post will always move. You could of course increase the difficulty but then not give rewards/power that match that difficulty, such that it becomes a hard ceiling, but then that also becomes unsatisfactory because you basically create an upper bound with no hope of overcoming it, and the mastery-driven players will still leave. Getting back to my original point, though, I would like to see more constructive discussions about the state of the elder game in CoH. The game has a lot of flexibility in builds and mechanics that's quite different from the rest of the genre, and there's probably space there to discuss what those could be. But if the hardcore players just keep suggesting what things to take away from the rest of the players, we'll probably never actually reach those more productive discussions.
  24. Something is definitely up with the volume. I also run at like 5% on my volume sliders and it still sounds really loud at times. On top of that, it seems when the same sound is fired at the same time, it amps the volume I guess because it's playing them all overlapped? Good example is when a MM zones in with buffed pets -- the reapplication of the buffs to all the pets is ear-shattering.
  25. I'll illustrate it with your own words from the other thread where you're borderline harassing the devs. "High design and philosophy" isn't a spectrum of game design. That's not a thing, as there is no discipline of game design (on any successful game) that isn't fully involved in getting one's hands dirty and actually implementing things and trying them out. What you're describing is the speculation and the "uniformed rebuttals" I was talking about earlier. When the devs share info, it tends to go quickly into this area that isn't useful or enjoyable for them to engage with, and I don't fault them for not sharing details about what they're working on specifically to avoid "helpful feedback" that falls into this category. But, the first sentence, "I can't let the sleeping dog lie" is more illustrative of what the problem is with someone mistaking plans as promise. Highly engaged players in a community space simply cannot let something go. They will keep reposting and reposting the same positions and try to browbeat devs into getting what they want out of the conversation: either to relent on implementing the thing that was "promised", or to admit that they "lied", and either route devolves into a toxic cesspool, especially as it happens again and again over years of development. In short, I'm not surprised a volunteer group of devs isn't any more willing than "publisher-dictated" (🙄) devs to engage with players in this manner. Bringing it back to the current environment, I think that the Homecoming team has done an amazing job of balancing the players' feedback while trying not to rush in and implement things that would make it unrecognizable to those who played on live. And until they show some signs of actual incompetence in this area, I'm personally willing to give them the benefit of the doubt.
×
×
  • Create New...