Stop the hatred!

You either didn’t watch the video or you misunderstood the issue.
That video tells you how to change the default cursor for the whole app. Which LE already did. LE’s cursor isn’t the default cursor. It also tells you how to have different cursors for different actions. Which LE already does as well.

What it doesn’t tell you (because it can’t be done natively) is different players having different cursors in the same app.
Meaning that they can change the cursor but both you and me will always have that same changed cursor. What we won’t have is you having a cursor for one action and me having a different cursor for the same action.

Exact same issue.

No one says that Unity doesn’t let you change your cursor. What Unity doesn’t allow is changing the cursor at runtime. Which is what you need to have custom cursors as they’re being discussed here.

That is just doing what Yolomouse already does. So why would EHG spend months creating something that already exists (for free, even) and that only works for windows anyway?

You can’t. That requires changing the cursors at runtime, which Unity doesn’t allow.
I know you already saw these discussions before and you saw these exact same arguments before, so why are you arguing about this? Is it to vent your frustration on the paid class issue? Because that’s a totally different one.

Currently the only way to use native Unity and have a sort of custom cursor (in the way that’s being asked, not in the way those videos explain, because that was already done by EHG), is to create extra layers in the game. have a different cursor per layer and then switch to the appropriate layer according to what you select. But I expect that has quite an impact on performance, so it’s not a feasible solution.

You can’t. You seem to either misunderstand the issue or to not understand programming. It gets locked in when the solution is built.
The OnMouseEnter and Exit will run the exact same code for you and for me and will set the exact same cursor for both of us.

Do you honestly think that you know more than Unity support? You won’t find a single post on their forum saying that you can do this, but you will find many that say you can’t.

As said before (even by Mike), there are “dirty” ways of doing that, but those will usually have negative impacts as well.

Which, again, is what Yolomouse already does and it only works for windows. So, again, why should they waste months of development on this issue when there’s already a free tool for it and there are much more important things to do in the game?

1 Like

Cause it’s improving their product, that’s why.

The object solution itself works.
And Yolomouse is not using the object solution but simply enforces windows to change the cursor. It just has extra functions available on top… which are irrelevant for LE.

You know… don’t start making a phone… people already have phones, so why would we make another one? Right? Same argumentation line.

Yolomouse detects where the cursor is and it will render the custom cursor over it. It doesn’t change the windows cursor.

And, like mentioned, it only works in Windows. So EHG would spend months on a solution that already exists for free for it to only work in windows as well. And then have to deal with customers that have linux and bought a cursor and now it won’t work.

Is it the same argumentation line, though?
I guess that EHG should work on a game distribution platform to distribute their game, rather than using the existing steam solution then.
Or they should an option to replace all spiders with something else (since arachnophobia is a common mod in most games).
Or they should add an autoclicker to the game, since players can also use one.
Or they should add a macro creator, since players will use AHK.

Same argumentation line.

Fair.

But the object solution also doesn’t directly asks for the position unlike Yolomouse which does that and then removes the base cursor to overlay it with another texture instead. It uses the Unity-internal method of switching the texture based on position.

It’s a bit different but the result is the same for the end-user.

Also as said, this is Unity-internal, not windows-based. Which you would’ve been able to read out of it as I stated it’s a object-based internal Unity function.
Transparent object over whole window, while mouse is inside the texture is exchanged.
Which is different from the base premise of permanently changing the cursor texture over to the unity-enforced one, which is singular.

For example:

You can have a chest and a enemy, both count as objects. Your base cursor is your cursor. When you move over the chest it’s a cursor with a chest-icon in the lower right edge of it, which is… another cursor… so now you got… 2 cursors! If you hover over a enemy you can instead color the cursor red, which is… another cursor again! So now you got… 3 cursors total!

It’s situational changing of the cursor.

So now you instead mis-use the functionality of that. Instead of making it a chest… or a mob… you overlay it over the whole window and hence get the respective result as a cursor. Those can be made in as many forms as you want.

You can open the options and say ‘I want this cursor’ and now the enine simply removes the object you used… and instead places another one over the whole window which has another texture attached to it while hovering over it.

This is a built in function of Unity actually. And allows a workaround of the singular cursor texture issue.

Sure, but that’s not improving their product and we have proof of that as well with streaming services and game-launchers.

So why do it? It’s not a positive now, is it?

For example of Yolomouse had a setup to allow integrating that for developers into their game directly for a small fee… that would be a viable solution. But it doesn’t have that, so they cannot do that.

So they gotta make their own shit instead.

The arachnophobia one is a given… yeah… that’s a common thing which should absolutely be done ages ago and was missed out upon.

As for the other 2, those are idiotic, and you know perfectly well why.

At the very least, they haven’t even gotten the hang of releasing beautiful MTXs. Compare any MTX in LE to POE – they’ll be prettier and there are more of them, everyone will find something they like and want to buy.

Regarding balance, I’m more than sure the new paid class will be meta, otherwise there’s no point in releasing it. And in the future, there’s a possibility of adding 2-3-5-10 paid classes, each one will be meta upon release, and the previous class will be nerfed to make the new one better.

Also, I have more personal complaints. In my opinion, the game currently has a couple of gaps in mob content, and against that backdrop, some paid content is planned. That’s not serious. I also think it’s important that the developers at least make money from the game’s sales on PS5, which will definitely provide money and support for online play, and against that backdrop, paid DLC is planned.

That already happens. You get different cursors based on where you’re pointing. But, again, EVERYONE gets the same cursor for the same action.

The only way I know of to actually achieve this with Unity’s limitations is to add 20 extra layers to the game renders, each with a different custom cursor, and depending on your setting it will hide 19 of them and show the other.

As you can expect, this has a performance impact, so it’s not desirable. It would be preferably to use an external tool that doesn’t impact the game, like Yolomouse.

(As I read the rest I realized that’s what you were talking about. Still, the point stands that it’s an extra render that impacts performance, not to mention all the other layers that are toggled but that still exist).

Are they? I grant you that the autoclicker one was just there as bait, but AHK is a perfectly reasonable tool that most players use.
Many PoE players use it to set their auras (or did when the auras were turned off on death), since you tend to have more auras than free space on the skill bar.,
Many also use it (or a mouse button macro, which does the same thing) to piano flask.

In LE, lots of players use the num lock trick to autocast, so why not provide an internal autocast tool?
Why not allow the assignment of a macro to a key so it can send out a sequence of buttons you’ll be doing always together? Like casting 3 skills in a row?
Players already use AHK if they want to do so, so why not create that internally rather than letting them use a 3rd party tool? It would also improve the game.

Welcome to conditions!
‘You got base cursor ‘x’ and hover over something? Now it’s ‘xa’. Hover over something else? ‘xb’.’ And then you switch it to ‘y’ which demands ‘hovering over something? ‘ya’. Something else? ‘yb’.’

What’s the diversion from the damn norm?

And you only need 1 layer for the base cursor decision and then check which cursor is the base one to adjust it to the alternative options.

Not what you describe.

And obviously it has a performance impact, which is so laughable when done properly that it’s not even to be talked about… if we wanna talk about performance we can optimize the game to run on a damn potato… but Unity is a shitty modern engine which is a overbloated mess taking far too many resources for a bazillion options you’re not even using or not providing any reasonable visual acuity.

Forbidden by the rules?
So yes?

Why the fuck would they implement something they intentionally want to keep away? That’s idiotic by design.

Because it’s ‘tolerated’ and not more. A workaround scraping at the edge of being a exploit.

The new character is bound to be OP, every single class they added was OP at first. Since it’s going to be a paid character, it’s going to be P2W because you have to pay to get the new OP class. If it’s not OP then “nobody” will buy it, so it kinda has to be OP.

1 Like

And in the future, there will be nerfs to the old paid class to accommodate the release of a new meta paid class :slight_smile:
We’ve all seen this and know all about it, but well, games like these have their fans)

I think it’s not that much in the big picture but a steady stream of money. Even the most poor people I know who don’t spend a dime on games threw kind of 50 quid on stash space at some point. Sure that’s little to the ammount who is buying 400+ support packs every league but it’s a steady stream where even ppl with less money participate.

there is no MTX in the LE store I would spend a cent on and most of it I wouldn’t even take as a gift or ever use if I can’t give it back. That’s the level of bad those are to me.

Intresting I guess I do the reading on this, not to hate on EHG or something but because to me this looks like an issue I talked about with someone in the past who hated unity with all his heart because he said it’s a trash engine and noone who makes bigger projects should ever use it :smiley: .

And… they would be absolutely right! But that’s what we’re stuck with here :stuck_out_tongue:

i’ve been stewing on this concern since yesterday. Going forward, since we know there is still a lot of ‘endgame’ stuff missing, the only thing I see an OP build being an issue is when they start implementing firm ranking stuff, like ladders and leaderboards.

The easy fix for that would be to have separate boards for these Paradox classes.

Another potential problem would be to be certain to maintain a very, VERY wide healthy ratio of Paradox to Traveller classes.

Other than that, if us casuals want to drop $1.99, $3.99, $9.99 or whatever the price will be for the class I don’t know why this would be such a problem as it’s given the ‘I don’t have 20 hours a day to spend playing’ crowd a means to maximize the use of their time, but with separate boards the content creators who want to cater to the more hardcore gamers can still do that?

I realize there are subtleties that I’m probably missing, but I think it’s a bigger deal that they’re giving us the Expansion for free.

1 Like

If they can make class balance tighter before then, I’ll take a look at it. The current state though is not good enough to warrant throwing more classes into the mix. The dev response if why paid classes over dlc I think makes sense in a roundabout way and I don’t hate it but the game just needs more polish all around which hopefully happens in the seasons in-between.

Also as a side note again the expansion isn’t free, but current players don’t have to pay for it. As to why that distinction is important, it may make it less appealing for new players, but more importantly I doubt expansions going forward will be free to current players.

2 Likes

This is frustrating.
THAT ALREADY HAPPENS. When you have your cursor over the general field you get one cursor. When you hover the chest you get another.

What you can’t do is “PlayerA hovers X so they get Cursor1, PlayerB hovers X so they get Cursor2”. That is what Unity doesn’t allow at runtime. Those conditions are created during the build and are fixed for everyone.

The only solution that Unity allows at runtime is showing/hiding layers.

AHK is not only not forbidden by the rules, it’s also undetectable to enforce them if it was.
Which is why streamers will also use it with impunity.

And yet, having autocast for some skills would “improve their product”. So they could implement it themselves.
Except that it would take a long time, it would be prone to bugs and the functionality already exists.

As long as there is a trade market (which is inherently competitive, since you want to sell earlier than everyone else and for more profit than everyone else), it will be an issue.

You see this clearly in PoE. There are plenty of items which are worth a few chaos in the first day that become absolutely worthless in the second day. The first person to get there is the one profitting from it.
So class balance does matter even outside the leaderboards (not even counting the social competitiveness aspect, since that’s harder to quantify).

2 Likes

And also there… you damn well can!

As stated. conditional texture changing.

You create a construct which reads up on which specific texture is applied currently and then you apply the respective fitting one accordingly as a follow-up.

So if Player 1 got Cursor 1 then Cursor with chest 1 applies.
If Player 2 with Cursor 2 does the same then for their client it is Cursor with chest 2 that’s applied.

Cursors are client-side, and unless EHG is so absolutely inept to have your damn cursor lag - which not even they do - it still is client-side based. So when the fucking base cursor is there you get the damn follow-up cursors based on the damn base cursor. Why? Cause that’s the darn condition for applying the respective texture.

I mean… come on… that’s basic shit.
A hassle that it’s not directly implemented but not stopped either.

Yeah, and what has that topic to do with shit here?

You know exactly what the term ‘improved’ in this case meant from my side. So maybe use that instead of the literal application?

You can’t. Again I ask you: do you know more than Unity support which have repeatedly said in their forums that it can’t be done?
Cursor textures and their respective trigger uses are assigned at build time and they can’t be changed at runtime.
When Unity hovers ObjectA it will always show CursorA which is what was defined at build time. It will never change to show CursorB at runtime, which is what you need to have custom cursors per player.

Cursors being client-side is actually the problem. Because cursors get bundled with the build and can’t be changed after that. If it were server-side (wouldn’t help offline, but it would at least fix online) then the server could just send different cursors.

There is no way to implement this that doesn’t involve either creating multiple layers (which impacts performance) or using an external tool (which takes a long time to develop).

Having an autocast is as much an improvement for the game as having a different cursor.
And for both, there are already tools that do that without EHG needing to waste time recreating the same thing.
Especially when you consider that even without Yolomouse you can simply increase cursor size in windows and already have a bigger cursor in LE.

1 Like

If you hover over a object it is changed during runtime.

You’re 100% right that the default cursor chosen cannot be changed. But what can be done is changing the cursor through object during runtime. which does allow workaround to use objects as a cursor-changing methodology.

Also said objects can trigger different cursor texture changes however you choose to setup your code so a chest which has 2 textures for itself (closed/open state for example) can theoretically also apply separate textures according to their state… hence for example a cursor with a lockpick symbol and when opened a cursor which showcases you can open it as a container.

So to circumvent the default runtime cursor you can enforce a see-through object spanning the whole screen* to exist, which for example can simply be controlled through the settings on which texture it applies while hovered over (which already is a cursor changing during fucking runtime after all, isn’t it?).

So following that you then can apply respective code to the actually interacted objects to change the cursor respective to the already pre-changed cursor condition.

Which should be possible, unless something else fucks it up for some odd reason… which shouldn’t be the case though as multi-selecting is a option available, hence the ability to highlight 2 objects at once when hovered over so you don’t stop any interaction with objects since a invisible one is always at the topmost layer at all times.

That is exactly what I said before, which is adding layers to the game, which impact performance. You’d need one per custom cursor.

Umh… barely? You only need one layer, the one which decides on the base cursor. The only performance impact will be the check for which cursors is to be applied should a custom one hence be applied.

As stated, absolutely and entirely neglicible. Any miniscule graphical optimization will cause more upsides then this takes up performance.

“Man proposes, but God disposes.”