[Question] Multithreaded Orion access

[JHuenerberg]

I get always NPE. I thought C# is thread safe for public static classes like Orion.

E.g. the "AimBot" Thread needs access to Orion.Me while the main thread does Orion.Update.

[aevitas]

For most of the BCL, that's true, but public static types aren't thread safe by default (C# doesn't guarantee thread safety on anything, implementation does, if present). If the update method is in the middle of updating the local player, and another thread accesses the local player, you could get a faulty read - I never implemented synchronisation because I don't think you should be multi-threading this personally.

If you really want to, you could start off with implementing a simple lock around the update. If lock contention turns out to be too high, you could implement a reader/writer lock.

Curious though, where are you seeing symptoms of your code racing? I'm fairly sure all members that read from the game should be thread safe.

[JHuenerberg]

Ups you are right. I did a mistake... The NPE came because Orion didnt updated the first time. But now I get alot of faulty reads all over the place. For example aim thread does Orion.Objects.Players.Take(10) but Orion.update() just has ~60 players.

What do you mean by I should not implement multi threading? I need a thread for AimBot, TriggerBot, BunnyHop and ESP is running in a Form thread.

I love your code base and im sorry that im messing around with it. I am completely new to game hacking and im just playing around with it. Actually I can do big steps with this base.

[aevitas]

Don't get me wrong, I appreciate that you're messing around with it and finding it useful. Personally I would run the ESP, aimbot and what other features you have all on the same thread unless you find that the reads are taking too long (if it's a problem with BlueRain, then feel free to report it in that repo), and then multi thread it.

I personally have never found running all that stuff on a single thread being a bottleneck in any way though.

As for the Orion.Objects thing, just call ToArray() on it and iterate over it instead of using Take().

[JHuenerberg]

You are completly right. Didnt even check the performance because every source I looked up (shame on me) does multi threading. The Aimbot routine costs ~2000 Ticks. Not worth for a thread.

And why sould I do ToArray() instead of Skip(1).Take(9) ? I would iterate over all entities (sure just bool check continue alot) and not just the players.

I did a bit of customization to the Framework to get all the stuff working. For ViewMatrix and ViewAngle. It is surely not coded like you wanted to be. Didnt knew how to solve it better. Maybe you can fix that quickly. I dont even get all the different Read methods. As I mentioned before im new to game Hacking so is memory reading and writing too. But isnt it always Adress + Offset? Why 3 differnt Read functions?

`protected T ReadField(BaseOffsets offset) where T : struct { //return ReadField((int) offset);

if (offset == BaseOffsets.ViewAngle) return Orion.Memory.Read(Orion.Client.BaseAddress + (int) offset);

return Orion.Memory.Read(Orion.ClientBase + (int) offset); }`

[aevitas]

Because you can't guarantee the first N entries will be the players - it may be in local games, and it could even be the case in matchmaking games, but those can get re-ordered as the game engine sees fit. If you want to obtain all players, you could consider using Where(e => e.Something); to grab those entities.

Those overloads are just for convenience, so you don't have to cast StaticOffsets or BaseOffsets to int every time you make a call.

You could say it's "address + offset", but it's definitely not always ClientBase + offset, so what you're doing there might work for view angles specifically, but you won't be able to get a good health/armor/other player-specific fields read with that.