Jump to content


  • Content count

  • Joined

  • Last visited

Everything posted by twostars


    Y'all are getting off-topic. On the topic of warrior damage, we've reverted a couple of nerfs:
  2. Patch notes (20/04/2018)

    Changelog [Hotfix] Warrior's Cry Echo is now correctly dealing 300% damage + 200 bonus damage again. [Hotfix] Warrior's Berserk Echo is now correctly dealing 300% damage again. [Hotfix] Changed scaling on the Plwitoon stuck in lava to account for the fact only ranged can deal damage to it Fixed a bug causing skill bars (Chaos Dungeon & regular) to not correctly save sometimes. [Hotfix] Cleaned up daily/weekly/monthly quests some more. This should fix them not correctly resetting data. These previously worked such that the quest data shown to the client was different to that reset/tracked by the server. It behaved like this for 2 reasons: 1. So that we were able to easily identify these types of quests (and reset them on access, because unfortunately there was no better way). 2. So players could still see the quest in the NPC's menu after it was completed. In this case it would error saying something like "You have already completed this for the week". This behaviour was very error-prone (particularly with things like week identification on completion; this doesn't play nicely with being able to turn in the previous week's quest and take it again for the following week), and in general just a mess, so now weekly/monthly quests behave like all other quests: when a quest is completed, the NPC does not show it anymore until it's reset. NOTE: As this caused weekly quests from last week to not reset correctly (causing players to not be able to take them this week), we've hotfixed these to reset as of today. That means these have all reset a couple of days later than they should (potentially causing loss of progress to those who did still have it). This was unavoidable, sorry. Certain quests (for now, only applicable daily/weekly/monthly quests) will now be transferred when you Nation Transfer. Previously, transferring meant you'd have both copies of certain quests (one per nation), which were tracked independently. Now, for the quests we've allowed for, you will only ever have the 1 quest -- and your progress will transfer over to the other nation's variant of that quest when you transfer. This makes quests like [Monthly] A small challenge more attainable as players will retain existing quest progress after transferring. Existing quest progress will not be merged; only the credit for your current nation will count. This only applies to quest progress going forward from the patch. Fix a bug with quest progress not being reset correctly on login. In other news, this week we've been getting back into our client source project. Since it's been a while we're still getting reacquainted with the sourcebase so progress is a little slow, but we've: Implemented name change support. Updated resistance logic and implemented the newer stun rate algorithm. Implemented skillbar saving/loading, with future support for Chaos Dungeon skillbars (when that's eventually implemented). Updated warp list logic & implemented all various warp list (and some other) errors as of current 2.1xx clients. Updated quest support & implemented existing quest UIs [quest tab+quest info popup & level guide]. Mostly implemented stealth/lupine skill behaviour (still a work-in-progress). Client now correctly supports even newer effect files. Implemented support for unpacking/using newer client files. Still a lot of work to go before it's in a usable state, but it's getting there. With larger things like transformations (soon!) out of the way we can probably start working on a newer client version and the systems involved with that (e.g. 1.534, letter system, new event & quest systems, etc).

    We're not restoring the +15 STR. Sorry, but that was always a bug. It's really not even worth suggesting at this point, unless USKO happens to do so (which I doubt), it's not coming back. It existed primarily because we assumed their data was wrong. But it wasn't; it intentionally didn't give that STR, so we removed it. Complaining about it is silly. As Aesteris said, it makes very little difference in damage output, the only reason it's so overblown is because it was a 'nerf' (if you can even call it that) to warriors, and "OMG WTF GM WARRIOR NERF WTF". Considering OP is in general complaining about a larger damage disparity, this 15 STR doesn't help solve the OP's alleged problem... so again: complaining about it is silly. It's not being changed back, so you can stop trying to blow that small change completely out of proportion and just deal with it.
  4. The party system in the client source code doesn't yet support drop-down menus, let alone party leader promotions so this behaviour doesn't exist yet. We'll have to be careful to avoid repeating mgame's mistakes when we implement it.
  5. Party interface commands bug

    The party system in the client source code doesn't yet support drop-down menus, so this behaviour doesn't exist yet. We'll have to be careful to avoid repeating mgame's mistakes when we implement it.
  6. "Tab" doesn't work in the letter menu

    Letters (and ROFD+ behaviour) aren't implemented in the source yet, so we'll have to bear this in mind when we implement this and ensure we don't repeat mgame's mistakes.
  7. This Tag boss Active thing is broken

    Going to assume the problem is resolved.
  8. Chaos Dungeon skill bar is not saving

    This will be fixed after the next restart.
  9. As reported here:
  10. Skill bar not saving on my main character

    This will be fixed after the next restart.
  11. Power over player at war

    So we could go a few ways with this. 1. We could outright disable it, because it's a useless feature primarily being used for trolling. 2. We could further limit it at a target level (at the moment the cooldown exists for the commander that used it, so multiple war commanders can use it at the same time). 3. We could exclude players currently casting from being affected by it (I'd ideally like to push it further to only those that aren't in combat, but that's something we're still looking into in and of itself). Thoughts on these?
  12. ItzTOOLATENOW cry after he get npt :D

    These threads are never productive. Stop trying to cause drama.
  13. Power over player at war

    Yes, and that response was me saying it should be addressed by limiting it with a CD etc. i.e. We didn't know there was still a problem here because nobody mentioned it. I really don't appreciate this attitude, so consider this a warning. Next time I won't be so generous. Even now nobody's mentioned what's actually going on to make it an issue. The CD exists to limit it so it cannot be spammed. "Now I think you can see the issue when these kids start spamming the commands" shouldn't happen, unless it's possibly MULTIPLE people using it. I'm probably more inclined to just remove it altogether, but still - what is even the problem here. One person, for sure, cannot spam it. Unless by "spamming" you're meaning once every minute.
  14. Changelog Implemented support for hypothetical event outcomes As most of you are no doubt aware, events have been a troubling topic for some time, rife with abuse and sabotage. Fortunately, with razor's help, we've finally come up with a solution to this problem: hypothetical event outcomes. With this feature, you no longer have to worry about whether or not your event is going to be sabotaged. The outcome will be hypothetically decided for you, giving equal fairness to all parties and improving event participation tenfold. Note that this feature is a work in progress and doesn't yet apply to all events. But don't worry; as we see how this plays out, we can adapt it to the remaining events as well. Fixed another bug involving HP scaling. With the HP amounts bumping around because of scaling, the HP bar was bouncing around, giving the appearance it was regenerating a lot of HP (when in reality, it was not). As the client doesn't care about actual amounts, this all uses its base health, so the HP bar should move consistently and no longer give off the wrong impression. Events will no longer automatically shutdown in 1 minute when one party leaves. With the new hypothetical event outcomes system in place, there's no longer a need for this.
  15. server of ? 离线 NIEAKTYWNY

    Server's usually online, so hypothetically it's online right now.
  16. server of ? 离线 NIEAKTYWNY

    Looks fine to me.
  17. NP Scroll mysteriously disappeared again?

    No, and I refunded you earlier.
  18. Orcs left bdw, we lost.

    Are you suggesting they left to let you win while they themselves received nothing (being offline and all)? As noble as that sentiment may be, it doesn't really change any of what I said. Really, you didn't win. Neither did they. The server essentially treated it as such. Conclusion: No bug. If you're saying that nobody intentionally was trying to abuse anything, then evidently it hasn't been abused either. So: No abuse still (yet?). So I guess we're in agreement that it's probably best to just leave everything as it is then.
  19. Orcs left bdw, we lost.

    So basically the only real proposal is to just remove it entirely so people can sit around in the event until it expires so that the losing (but still 'active') side has a chance at winning. Increasing the instance shutdown timer would probably help, but at the cost of making people wait around and I don't think there's ever going to be a perfect time for that. Forcing the remaining side to win makes the event far more sabotageable than it already is, and as-is situations like this can be abused to deny the party that probably would have won the chance at it. As for "not being stupid", I don't see how you can say that -- they got literally nothing out of the event. Nothing. You guys at least got rewarded for losing. I'm not saying they would have won, but they completely wasted their own time just to prevent you from winning... and got nothing out of it in the process. That sounds stupid to me.
  20. Be careful fake char

    FYI, Hizliresim doesn't seem too happy with people not in Turkey. Since this is an English forum, most of us aren't going to be able to see anything posted there, so I suggest not using it.
  21. Orcs left bdw, we lost.

    I suspected this scenario may occur when I implemented this, however since it's not in their best interests to leave (forfeiting any rewards) we figured it probably wouldn't matter too much. This may just be my sleep-deprived self talking here, but are people really that stupid as to forfeit their reward and waste their time like that? Maybe it's better not to answer that... I mean, if they were still rewarded, obviously it would be abusable in that they could guarantee a win and then just dip. But if they're not there to be rewarded, they get nothing. And since you guys didn't leave, but you also didn't win, you don't get rewarded for winning (obviously). So winner prize goes to nobody. I just don't understand the motivation there. If we were to do what was proposed (and what you're suggesting) and consider the team that stayed as the winner, players would be incentivised to game the system by sabotaging events with characters on the other nation & leaving, making it an easy win for the other (their) nation, which is obviously not ideal. As far as I can tell, doing it like this isn't really abusable in any similar regard... but people are stupid and this happens? Eh.
  22. NP Scroll mysteriously disappeared again?

    At any point during that (full) video do you check how long's left on it? Or is it perhaps used during that? (maybe you applied it at the same time as the other buffs, but either way I'd be curious if the duration ever desynced with them) Anyway, about the video all I can really say is this: 1. The buffs themselves are removed on death. The icons for the persistent buffs are not removed visually though, so we still see those. At this point, your NP scroll is still visible (but technically it's removed, as with the others). 2. When you respawn all buffs & their icons are actually removed in the client. This is surprising and dumb behaviour, because I wanted to optimise behaviour slightly so that when you die, the persistent buffs aren't even removed at all, removing the need to be selectively saying "hey, since it's a persistent buff on death I actually don't want you to remove the icon, but y'know, everything else is fine"... which would then mean we also wouldn't need to recast these immediately afterwards on respawn... Alas, we can't do this because the client is stupid. Not without removing that from the client, and I have no idea if that would cause any unintended side-effects. For now this is not overly relevant, I'm only stating this just to break down how these are actually working (despite what it appears to do). Regarding your NP scroll, this is why this gets removed here (as does every other icon, which we don't see because of 3-). 3. Immediately after we confirm the respawn (where the client forcefully removed all icons), we recast all persistent buffs. As it's quick, from your perspective you don't even notice any change other than the NP scroll being removed. But this happened previously, because of the reset. For some reason that's yet to be established, your NP scroll didn't get recast. And more than this, it no longer persists because it either failed to apply and removed it... or it didn't bother attempting to reapply because it's no longer in the list of persistent buffs to recast. -- It's interesting, because the buff does seem to be active prior to your death, so it's not exactly silently removed server-side while still showing as existing. So it should still exist at that point. Yet on the other hand, when they fail to apply, they usually say so in the info box. It is possible there are cases where they do not, but it's a stab in the dark to figure out why that would be. Particularly considering there's nothing special about the buff in the first place, and clearly your other similar buffs were recast just fine. We'll probably just have to wait for this to reoccur, because it still doesn't really help too much with regards to actually identifying why it's not being recast. If it's failing, it'll be logged. And if it's not, all modifications to them are logged, so we should be able to see what it's doing.
  23. Lag Problems !

    Then the traceroute you made for now isn't all that useful other than as a baseline. If you give your ISP a traceroute, it should be when the problem's occurring.
  24. Lag Problems !

    It's lagging for you right now?
  25. Lag Problems !

    Sorry habit, Windows calls it tracert / *nix traceroute, oops. Either way, the screenshots I already gave should be enough for them. The behaviour is consistent during the period in which it lags.