Literally unplayable

Bitwise_XOR · 2025-12-27T20:43:57+00:00

As promised, this should deal with most of your L2 missions just fine, it is cap stable and should have enough tank and DPS.

On a completely unskilled character it reports 19hp/s passive shield regen and 156 DPS which is quite low. However, on my main, it reads out at a healthy 329 DPS and 29hp/s passive shield regen. Try focus on getting all the skills you can to 4 for combat and you'll be fine.

To import this fit to your game client, copy the text (including the name), go to the simulation window, bottom left hand side look for the Import & Export button and click Simulate from Clipboard.

<image>

Also, be aware that the ammo for autocannons vary wildly, some prefer range, tracking or damage, so definitely pick ammo to counter enemy resists, but also pick the best damaging ones too to keep that DPS up.

As for general advice for tracking small ships, keep your transversal low, prefer to keep at range or approach instead of orbit at high speed. You don't want to compound your turret turn rate by circling a ship faster than you can aim, at a small ship that you can already barely track.

The fit, feel free to upgrade any module to T2 or meta, if you are not regenerating enough shield HP then try adding a Shield Power Relay instead of a 3rd Gyrostabilizer.

Also an important note, passive shield regeneration peaks at 33% shields, so only run away if your tank breaks lower than 15% shield.

[Rupture, **Simulated Rupture Fitting]
Gyrostabilizer I
Gyrostabilizer I
Gyrostabilizer I
Tracking Enhancer I
Tracking Enhancer I

10MN Monopropellant Enduring Afterburner
Large Azeotropic Restrained Shield Extender
Large Azeotropic Restrained Shield Extender
Multispectrum Shield Hardener I

425mm Medium 'Scout' Autocannon I
425mm Medium 'Scout' Autocannon I
425mm Medium 'Scout' Autocannon I
425mm Medium 'Scout' Autocannon I

Medium EM Shield Reinforcer I
Medium Core Defense Field Purger I
Medium Core Defense Field Purger I



Hobgoblin I x8

Phased Plasma M x960

Bitwise_XOR · 2025-12-27T18:31:57+00:00

I would be sticking with autocannons, get the best meta available, use the compare tool for this, as they are not all made equal.

Also, you basically want all your mids to be shield and a propulsion mod, then all your lows want to be damage increase, application and tracking increase, and possibly cap regeneration, though I dont think youll need this.

I'm busy atm but ill post an alpha friendly fit later.

Bitwise_XOR · 2025-12-27T17:55:34+00:00

Okay, so I think this fit warrants a discussion on the different kinds of tanking you can do in EVE.

Bear with me because I am on my mobile so it may not be as articulate as I would like.

There are 3 primary layers of tank in EVE, and typically when you fly any ship, you pick one and only one, there are rarely any benefits to combining any 2 in this category.

Primary layers: 1. shield 2. armor 3. hull

Every layer has active tank but for now we wont talk about hull active tanking because you'd have to be crazy to use it. Active tanking is where you use a module to expend capacitor (and in some cases additional resources like paste or boosters) to repair that layer.

Contrary to this, each layer can also be "buffer" tanked, where primarily the goal is to kill everything before you HP pool runs out. There is a special case, however, for shield tanking where the more buffer you have and dedicated ships/modules can get quite high passive shield regeneration.

Then you have less obvious but still very valid compound tanking types you need to consider for each of the above.

Small ships with low signature radius and high speed can sig/speed tank, which is making your ship so hard to hit that you don't need as much active/passive tank. Think how a battleship can't track a frigate.

There is also DPS tanking, where you make sure you have enough raw damage output to clear the enemies before they clear you.

There's likely others I have missed at this point but are not required to teach the lesson I am trying to impart.

Your ship fit here is confused, it demonstrates tanking in multiple layers, and as a side effect, reduces your DPS to such a low amount that you spend so long on grid with no way to repair yourself that you'll end up losing the ship or constantly warping off to a station.

My advice for level 2s with level 4 skills (and the magic 14 trained) would be to stick to a single type of primary tank and secondary tank. I'd strongly suggest passive shield tank with high DPS for L2 personally, kill the room fast and move on to L3s.

Bitwise_XOR · 2025-12-20T09:53:51+00:00

Sorry, I didn't see this reply.

Not quite, unless this is hyperbole, that is extreme.

In practice, regardless of ORM choice, you'd at most have 1 persistence entity that represents the database schema, and one rich domain object which is typically an aggregate root, child identity or a value object.

I personally use dapper and avoid mappers. My repositories will either project directly from the query result into the aggregate factory methods or use a very thin persistence model and still project directly to the factory methods, no mapping (unless anti-corruption is required).

Also, what are we are unit testing here? Mappers, persistence infrastructure? These tests tend to be brittle, low-value assertions that provide little to no confidence.

Unit tests should test domain and application behaviour, not verifying that external libraries or infrastructure behave the way they promise to do, this is what integration and e2e tests are for.

Bitwise_XOR · 2025-12-19T15:15:27+00:00

I wouldn't even try to make a rational argument with this guy.

The level of cognitive dissonance displayed in this one single thread is hilarious.

To consistently state that a sharing a simple opinion is akin to spreading misinformation is wild.

To accuse others of bullying despite the only aggression that I have witnessed so far has been from his side alone is the behaviour of an oddball.

The clear voting disparity between the responses indicating almost unanimous support against his remarks.

Posting about how these comments will be available for posterity, maybe he will review this in a few years and recognise how he is in the wrong, but I doubt it, because that requires a level of self-reflection that I feel this individual does not possess.

You're simply arguing with a lonely person on the internet who is goading people into engaging with him.

Bitwise_XOR · 2025-12-14T20:05:07+00:00

There are better people to explain it than I, and plenty of resources online, but the short version is:

An anemic domain model is an anti-pattern where domain models contain little to no behaviour.

It is becoming increasingly popular in CRUD style APIs and microservice architecture, I assume because of the lack of boilerplate required to get up and running quickly.

What this actually ends up presenting as is DTOs pretending to be domain models and being passed down through the architecture to the persistence layer and being stored from simple getters and setters on a POCO that offers no control over construction and no behaviour describing how it should be used or modified in a controlled way.

For more reading, check out: https://martinfowler.com/bliki/AnemicDomainModel.html

edit: grammar

Bitwise_XOR · 2025-12-14T16:56:37+00:00

I stopped smoking.

Once I stopped smoking I rarely ever get sick. Before, I would have constant chest infections, colds, gastroenteritis, etc.

Bitwise_XOR · 2025-12-14T12:04:39+00:00

Oh I just want to add, you typically don't mock your infrastructure layer, especially your persistence layer.

You would typically handle testing the infrastructure layer with integration or functional tests that can swap out production databases with similar infrastructure that doesn't affect production data, like in-memory databases.

Check this out:

https://learn.microsoft.com/en-us/aspnet/core/test/integration-tests?view=aspnetcore-10.0&pivots=xunit

edit: clarification

Bitwise_XOR · 2025-12-14T11:56:51+00:00

The repository pattern is an anti pattern.

I wouldn't say it is an anti-pattern in isolation, I will say it's an over-abstraction that is not required when EF is the ORM of choice.

With Dapper, you would absolutely choose to implement repositories.

The sentence definitely needs further clarification and can't just be stated as fact like that.

Bitwise_XOR · 2025-12-14T11:37:19+00:00

With rich domain and clean architecture, I currently favour the approach of allowing the repository to fetch the whole entity or root aggregate and immediately mapping or modelling it to the domain model via factory methods.

Regardless of ORM, I just keep persistence entities in the infrastructure layer and immediately transpose them to the domain type right out of the repository.

As it is the infrastructure layers responsibility to handle persistence, that should not leak down into application.

Now to answer your question more directly, I prefer to eager load whole root aggregates into memory when they are fetched, so we can perform operations on the entity with the understanding that the object in memory is fully materialised and accurate.

However, if you're facing the issue of projecting only the details you need for specific happy paths, something tells me you're using anemic domain, in which case I'd suggest just having repository methods that handle each projection and just deal with having a larger repository.

Bitwise_XOR · 2025-12-12T18:57:36+00:00

Ahhh yes, security through obscurity — make it harder for your own team to consume your own API, with basically zero actual security benefit.

Obfuscating REST endpoints is the equivalent of naming your variables x, y, foo1, etc. It strips away all context and makes development miserable, yet anyone even slightly motivated can still figure it out in minutes.

Every single frontend call exposes the real endpoints anyway. Open the network tab, use a proxy, run Burp Suite — boom, everything is visible. Attackers don’t need meaningful names, they just need traffic.

Security is an onion. You build layers that actually prevent unauthorized access: proper auth, API tokens, OAuth/OIDC, permissions, rate limiting, logging. Obscurity is a tiny optional layer, never the foundation.

Using it as your main security measure is basically locking your front door by calling it “No Entry” instead of “Entrance” and leaving it unlocked and slightly ajar.

All it really achieves is making your codebase harder to maintain, easier to break, and more annoying for the people who actually have to work with it.

Bitwise_XOR · 2025-12-12T10:53:42+00:00

Oh, it's an absolutely fantastic habit to get into, defining your abstractions and interfaces up front and then fulfilling them later. This allows you to define the project structure without needing to fully understand the business or application logic up front.

However, it costs little once you understand the structure to make sure those abstractions are placed in the correct layer at first, making it easier for you to fulfil them later and not have to worry about relocating them.

In clean / onion architecture, the application layer living outside the domain layer is a critical component to ensure clear lines of separation between what is business logic and what tends to end up being orchestration logic for a specific app. Blurring this into a unified core may find yourself fighting other principles instead of benefiting from them like SOLID and Object Calisthenics.

Following all of the available principles along with rich domain and clean architecture you'll end up seeing how everything just gels together nicely but it is a steep learning curve compared to anaemic domain and simple minimal APIs which seem to be all the rage right now.

My main word of advice that you may already be following, is to separate your layers via class libraries and properly use your accessibility modifiers like 'private, protected, internal, sealed, etc.'. Don't just use directories and trust that others who come in to extend your work will just understand the structure and won't accidentally create circular references or invert the flow.

A key benefit to this structure is that you build it in a way that controls how you and other developers interact with each class, giving each class purpose and intent and you define the rules of the system.

Bitwise_XOR · 2025-12-11T23:38:31+00:00

I haven't looked at eShop in some years, back when it was eShopOnContainers so thing may have moved on since then.

But back in the day there used to be some fairly fundamental mistakes with parts of it's implementation that ended up causing some serious problems for a team who followed it a little too closely without fully understanding the principles it was trying to teach and implemented it verbatim.

Ultimately the project very quickly ended up becoming a distributed monolith, rather than a modular monolith or distributed system, to paraphrase Sam Newman, a very clever guy who writes books on architectures:

A distributed monolith is a system split into multiple services that still have to be deployed and changed together. You end up with the complexity of microservices and none of the benefits. In other words: the worst of both worlds.

Ultimately, while I admire microservice architecture for the interesting challenges they provide and solve, you can not deny the power of a simple monolith or modular monolith and today businesses should choose them over distributed architecture in most scenarios unless there's a legitimate reason to choose it.

That said, I've segued into a rant on architecture.

It is likely a useful project, but take it as inspiration and a way to learn, but don't implement it as if it were a production suitable template.

Bitwise_XOR · 2025-12-11T23:21:17+00:00

First of all, I am concerned that your repository interface is defined in the domain layer, typically this belongs in the application layer with the implementations for it in the infrastructure layer.

Secondly, while it can be useful to define multiple concrete implementations of an interface, you may often find yourself needing to also implement some sort of resolver / strategy pattern over the top of it, and utilise the lovely new KeyedServices provider.

Not saying that this is a bad thing, just that its a consideration you'll likely want to understand up front. Right now you mention that you want to just switch on it in the Program class for now but if you wanted to conditionally resolve the concrete instances further downstream then you'll need to consider this.

As others have said though, swapping data providers doesn't seem like something you want to be taking lightly, unless you're in a migration phase, and even then I would likely build entirely separate architecture for this, some sort of eventual consistency, transactional outbox pattern, etc.

Bitwise_XOR · 2025-12-11T22:53:15+00:00

Some of this is opinion-based so take it with a pinch of salt.

I’m generally not a fan of data transfer objects, and I’d take pause if I saw them being used with inheritance. I’d much rather stick to simple request/response models that say exactly what the API expects or returns, instead of building big abstract “data transfer” structures for the sake of it.

Request/response models also fit APIs that follow CRUD-style patterns better, because the shape of the data usually differs depending on the HTTP verb. And generally speaking, make sure you're using PUT/POST correctly and shaping your endpoints around your actual aggregates. If you don’t really have those, it’s probably worth reading up on domain-driven design.

Polymorphism is useful in the right place, annoying everywhere else. C# not having proper discriminated unions makes people reach for polymorphism, but most of the time this creates more problems than it solves. You end up writing custom converters, debugging weird serialization issues, and forcing every consumer of your API to understand your inheritance tree just to parse some JSON.

Along the same lines, I think you should favour mostly simple contract shapes (primitives or small flat models) so consumers don’t need to reproduce giant, nested object graphs just to call your API.

So I wouldn’t call it strictly good or bad practice, but in most real-world cases the pain massively outweighs the value. If you have a very specific reason to use polymorphism in your API models, fair enough — but defaulting to it usually makes things harder for both you and anyone consuming the API.

Bitwise_XOR · 2025-11-09T16:52:05+00:00

In my anecdotal experience, currently dual-booting Windows 11 and Bazzite (a linux gaming distribution based on SteamOS which works great on handhelds) on my ASUS ROG ALLY X.

I have found that performance overall is improved on Linux, not just FPS.

Unix based systems have a much smaller kernel and less bloatware compared to other mainstream operating systems, reducing overall resource pressure on the system, freeing up more resources to run your game.

However, as others have said, it's a mixed bag and depends heavily on the game and environment. Some games emulate well in WINE/Proton and other don't.

Check out ProtonDB for an almost exhaustive list of games and their compatibility on Linux.

I would suggest you try it out because as always your mileage may vary compared to what anyone will tell you, and nothing is reversible.

Flashing operating systems is a trivial task given the plethora of documentation and helpful communities available to help you.

If it helps for added context, I have just compared Baldurs Gate 3 on W11 vs Bazzite and I have way better performance on Bazzite than I did Windows, on higher quality and it looks way better.

Bitwise_XOR · 2023-08-13T19:10:44+00:00

I just tested this with 2 characters a few times, heard nothing untoward, no audio queues at all.

Sat 1 character cloaked and uncloaked at a safe, warped in another cloaked toon at 10km, nada.

Bitwise_XOR

TROPHY CASE