The ENTIRE Skill tree system needs to be completely redone. Over 40% of interactions don't work/broken, 70% Useless. (Rant warning, I quit, this game will be at ~100 players in 8 months))

General
86

C’mon! DOES do. Bethesda does do this. So much so, that I can’t actually say that it’s not the player’s fault at this point. And I personally think the players should almost never be blamed. Star Citizen players, er, marks. Yeah, they should be blamed.

So Bethesda crowd-sources it’s QA. So if you buy Bethesda software, you know what you are getting into, now reporting bugs is your duty. My question is, how does Bethesda treat it’s QA Tea, er, Players? Does Bethesda say thank you when QA_Bob_Spaceman submits a defect?

:smiley: this is so true, lol. They have definitely taken the, “we need the players, er, customers to test this for us”.

And, on top of that, the whole conversation of ‘safe’ AI… like, how? How do you make safe AI when 1) you can’t definitively say why it comes up with any specific answer and 2) all AI developers are competing with nation states that only care about speed to market? It’s a very good thing it’s not self-directed and seems to regularly veer into hallucinations.

1 Like
87

True xD
Users are looking for the most direct shortest, quickest way of achieving things that will spiral out of control. But this should be taken into consideration from developers.

There’s this park at a campus in Netherlands if I’m not mistaken where people made paths onto the grass by walking on it, so they just decided to pave on top of that. It looks ridiculous, but the rest of the grass is beautiful and untouched.

88

I guess the developers of that park couldn’t predict that people would walk over the grass :smiley:

89

Even with that context, the further context of my quote entirely being about scaling overrides talking about how many people you need. Since the sentenced “don’t talk to me about scale” when I said nothing about the amount of people needed makes no sense while it does make sense in regard to “the scaling area” conversation.

This is my fault. I’m on my phone so I’m being succinct and it left out context. There were absolutely changes between 1.0 and 1.1, but AFAIK (correct me if I’m wrong) no changes between 1.1 and this cycle reset. I saw someone ask about it post reset and F0lk confirmed it was working before, and Llama reconfirmed that he had noticed it wasn’t working and had reported it too. I’m not sure if that was sometime during 1.1 before the reset or post reset.

90

I definitely wasn’t being fair to Bethesda. Funny enough, my best friend was a massive Bethesda fan boy, to the point that he even argued with me about it. I had told him “if Bethesda spent less time making sure modding was available on release and more time on making sure their game worked, the players wouldn’t be forced to fix their game for them with mods.” and he argued up and down about how modding is good (which I never said it wasn’t) and that my favorite games also have bugs (which wasn’t the point). Then he played Fallout 76 on release and has been just… done with Bethesda. I don’t even think he bought Star Citizen

1 Like
91

Mmm okay the QA testing debate is a bit over my head by now. But I stumbled on this bug today (I haven’t used blessing respec tooo much) Ability to spec 2 blessings from the same timeline

I don’t mean to be mean to the LE team, but this is wack. Blessing respec was introduced with 1.1 and this kinda bug should be like one of the first basic tests QA should have done no? and I don’t think this would’ve been a low priority bug that made it through…

92

Yes, you did talk about “scaling” (of a skill’s area), but that doesn’t necessarily mean the word “scale” in the reply to your post talks about the same thing :slight_smile:

You opened with

so, if I join your post + the previous Llama8 post which ends with this:

…then the word “scale” refers to testing scale, not to skill scaling.
Hope it helps :slight_smile:

But the bug about Explosive Trap and Jelkhor was reported prior to 1.1 and was never fixed since, so patches between 1.1 and this cycle don’t matter?

Here’s OP’s original bugreport: Detonating Arrow melee attack (jhakarts blast knife) + Hold This node from explosive trap doesn’t attach trap on hit

On a more positive note, 1.1.7.5 Hotfix is out and the Warpath issue I referenced apparently got fixed, yey :tada:

93

I assume that is what EHG did as well.

94

Except Llama also didn’t use the word “scale”. So between Llama and Myself, only I used the word “scale” or “scaling” that she was replying to. You can try to extrapolate meaning from nuance and implications. But occam’s razor, mate, “the simplest explanation is usually the best one.”

Admittedly, I was going off of what F0lk and Llama said at the start of this thread (which is wild, as this thread feels way more than almost 2 days old lol). So you’re right, it should have been tested and fixed. Though I found another thread where someone mentioned it didn’t work with Shift as a melee attack either, so it’s likely a bug with what “hold this” recognizes as a melee skill. Sure would be great if EHG responded to bug reports to let us know they were aware of the issues…

95

The discussion already moved on, and nobody mentions skill scaling except you, so …

Here’s an idea. If you need to be 100% sure, ask Kiwitus what it meant :+1:

Yep.
Here’s another idea. Community can set up its own bugtracker. There are free solutions like Bugzilla or Mantis. Slap it on a freehosting service and done :wink:

96

I assume they don’t do it because there are hundreds (if not thousands) of bugs on the list. And I expect, especially at early days of a major patch, that they get many thousands of bug reports. So they’re have to hire a team just to keep replying to all of them.

As a general rule, and this is from EHG’s history so far, you can expect that if you suggested something on this forum, or if you reported a bug on this forum or via the game report tool, they’re aware of it.
You won’t know the priority they’ve set for the fix or when it will be fixed, but you can safely assume they’re aware of it.

Regarding the specific bug you’re discussing Jelkhor, you can safely assume they’re aware of it as well, and that it’s on the list of things to fix. Which, again, is likely numbered on the hundreds or thousands of things to fix.

And before someone says it, no, it’s not because they’re sloppy. It’s because any software will have hundreds or thousands of bugs as long as it’s big enough. And the more interconnecting parts it has, the more bugs it will have.
So you give different priorities for the bugs, while at the same time you also have to keep working on new features. Because no software these days can focus on just fixing bugs and staying otherwise stale while they do that.

This leads to a lot of people complaining about not fixing bug X even though it should be a relatively simple fix. Which is true (although many times things that seem like simple fixes really aren’t that simple). But usually there are also dozens or more of similar bugs that should be a relatively simple fix.

As an example, Microsoft (which has thousands of developers working on their products) has had a bug on SQL Server Management Studio where sometimes it “forgets” the saved passwords for some connections. And you try to force it to remember them again and sometimes it doesn’t. And sometimes it does for a few times and then forgets it again.
This has been around for many years and in several different versions of SSMS.

So what’s my point with all this? Simply that if EHG wasn’t fixing bugs at all you could legitimately complain about existing bugs. But they do a decent job of tackling a bunch of them each with each patch and they even do a bigger push and extra patches for the real important ones (like the stash tabs freezing).
So yes, while it’s annoying to know that a bug has been around for years, it’s not because of incompetence or unwillingness to fix them. It’s just because there are lots of them to fix and you have to assign priorities based on their severity, how easy it is to fix and how prone that fix is to break something else.

1 Like
97

That wasn’t the bug I reported. If you have Jhelkor’s equipped then Explosive Trap doesn’t appear to proc Detonating Arrow at all, even if the trap is within melee range of a valid target (since DA is now a melee skill, I wondered if ET would use DA on a melee range mob, it doesn’t).

98

I don’t think that’s a bug, since it’s converted to melee and that node says “shoots a Detonating Arrow”. But I’ve seen weirder interactions, so what do I know lol

99

Which is why I wondered if it would apply a DA in melee range, rather than “throwing” (or something) a DA like a satchel charge.

100

How would something like this break? Generally something can’t come from nothing no? I would assume some thing else touched a code bit? Genuine curious

1 Like
101

Welcome to software, shit just breaks sometimes.

I think 1.1 (I think, maybe 1.0 or 0.9) re-introduced old bugs that had been fixed some time ago.

1 Like
102

I guess software defies the laws of physics and Newton’s first law. Explains also why bad devs don’t get fired like rest of world who do a bad job lmao.

We found a rip in the universe

103

I can give a non-game dev answer.

I was taking a class on Java Python and over the 5-week course we built upon each previous week to develop a functional employee management system.

In week 4 or 5, we added some functionalities and in the process, I added a line of code that would loop the menu until the user returned to the main menu. On the surface this worked flawlessly. Except… Once you got back to the main menu, the software stopped accepting any inputs. I didn’t touch the main menu code, and it took me over an hour of scouring the code to find out that while my functionality for returning to the main menu worked. It didn’t close the loop, causing everything else to display properly, but stop accepting inputs.

Basically, it’s very possible that something somewhere could affect something somewhere else either by reference or, as I call them, code goblins. They’re related to the dryer goblins that steal socks. You know when you put a pair of socks into the wash and only one of them comes back out of the dryer.

Edit: I could have probably added more detail and say that it took me an hour and the code was only ~300-400 lines, not something with potentially hundreds of thousands of lines (no idea how much code makes up a game like LE) and much of that code likely spread across multiple files that cross reference each other in order to work. and I need to correct that this was Python, not Java.

3 Likes
104

Sometimes, yes. I remember a few years ago where I was getting an error for no explicit reason I could think of, but when I restarted the computer (not just Visual Studio) it started working properly.

I’ve also had a situation where a game was crashing randomly and eventually I figured out that it was a USB multiport adapter that was causing it to crash when it was plugged in one of the USB ports but it stopped crashing when I connected it to another. Why? Who knows. There probably was a reason for it, but for all intents and purposes it was unknowable.

As for how a thing like this could happen, it’s not that hard to figure out. You just have to change something that influences, for example, the way things proc. Or changing how melee works. Or how charges work. All peripheral stuff that for some reason breaks this specific interaction.

EDIT: I’ll add another way you could completely break this without touching either one, but I’ll add the disclaimer that almost certainly this isn’t the reason in this case:
Let’s say we have a list of uniques and a list of skills. When you have both Unique[5] and Skill[9], it does the thing. Now you add a new unique in position 1. Unique[5] is now Unique[6], so the code that checks for the interaction doesn’t work. You didn’t change anything in either the unique or the skill, but it doesn’t proc anymore.
Like I said, this is almost certainly NOT how it works, but it’s a simple example of breaking things with changing them.

3 Likes
105

No, it’s because they’re sloppy.

You’re assuming LE is “big enough.” It’s 22 GB, DotA 2 is double that which doesn’t even have many interactions. If any, and usually it’s the art and models which occupy those parts, not the actual codding of skill interactivity.

To some extent yes. The more interconnection it has will result in more probable bugs.

There are many examples of games with complex interactions having little to no bugs. They weren’t sloppy.

I wouldn’t call Harbingers a “new feature.” or “content.” Truly. Not for a new cycle. It’s just dozen more bosses slapped behind the same mono grind.

And this is the most important part. What I’ll say next.
Why on earth would you release a cycle game with plethora of bugs with things that could’ve been found out by a proper testing QA team and taken care of before you start adding new content that will multiply the number of bugs exponentially? Even better, why not have the majority of your team on fixing the bugs and only a handful making concept art on the new content, writing the scripts, flashing out the details so once the main team takes over their work will flow naturally and quickly when everything is laid out and they know exactly what to do?

If they don’t break the cycle, this will remain LE’s future. Bugs, constantly. Fix 10% of old bugs, ignore another 10% because the bugged thing will be reworked anyway, and be plagued by phantom leftover code forever, and then when the outrage gets so high, go completely silent while you have every single person on your team scrambling to appease the players. Once the new content is added, now you have 80% more bugs.

Again, and again, and again.
Especially now at a time where players lose their temper with gaming studios over a color of the character, it won’t be long before they turn on EHG and say enough is enough, and then, then the game will truly die.