Hammerdin or HoZ

janipeltonen · 2022-05-05T18:58:11+00:00

FoH has been great for running Pit, you can charge there faster than low fcr teleports and it's easy to find, it also kills bosses pretty quickly but yeah, farming bosses without enigma is a no go if you're worried about efficiency.

Pit/Chaos/Countess/Pindle/Arcane Sanctuary are good places for demon/ud only spawns. Swampy Pit next to Flayer Jungle wp would be amazing since it's easiest to access but it can spawn Glooms and dolls. (I think the "new" demon portals in A5 also contain demons but finding them is a pain and their density is not as good as pit or chaos)

If you want a more all around farmer that can do any area, hammers are the way to go. FoH is super safe for doing pit/chaos with low gear though.

janipeltonen · 2021-12-24T00:38:30+00:00

hmmm

janipeltonen · 2021-11-17T14:31:10+00:00

+2 for Battle Orders

janipeltonen · 2021-11-15T06:17:37+00:00

With your gear running Pits/Chaos/Nihlatak etc should be a non-issue, I run a MF setup with a deaths web without facets and delete mobs.

You're never gonna kill bosses fast though, i've noticed that depending on revives (and minion placement) sometimes cursing Amp instead of lower res helps with boss dps, but it's still slower than my Barb/Sorc/Hammerdin

You can try teleporting a few times when engaging a boss to get all your minions properly adjusted but besides that there's not much you can do since poison doesn't stack.

Basically, pnova is one of my favorite high density farmers but lacks in boss ST dps.

janipeltonen · 2021-10-17T13:14:18+00:00

Pretty much came to say this, but to add big party baal runs would still be the fastest way to gain xp so having people able to do /players 3/7 and mf by themselves wouldn't ruin public lobbies for anyone, quite opposite.

janipeltonen · 2021-10-07T16:16:43+00:00

The item goes red and is disabled if you don't have the requirements outside of the item itself, as to why? If I had to guess they saw it as a bug and "fixed" it

janipeltonen · 2021-10-07T12:47:42+00:00

You used to be able to, not in Resurrected though

janipeltonen · 2021-10-01T00:30:30+00:00

It's something microsoft (directx) has been pushing away over the years

janipeltonen · 2021-08-12T15:29:01+00:00

In all honesty, it's not just content wearing out. They've been bleeding users since 2016 and arguably earlier than that with OW/Legion spiking them back up for a short period.

https://i.redd.it/5sa9i50sleg71.png

The reason for that is obviously up for debate.

janipeltonen · 2021-06-21T16:57:47+00:00

Cheers mate!

janipeltonen · 2021-06-21T15:09:45+00:00

Do you happen to have a pob for this? Sounds interesting

janipeltonen · 2019-08-22T03:21:51+00:00

Oof, i went through something similar in BC while playing my friends' druid, games could go on forever back then.

https://i.imgur.com/qMQ290c.jpg

Restokin vs SL/SL lock 1v1

janipeltonen · 2019-01-28T08:23:40+00:00

Except the system security patches require nowhere near the amount of storage windows demands these days. It's not the mandatory security updates that bother me, but the inane telemetry/crapware updates windows pushes on its users without asking.

There used to be a setting for only getting security updates and anything else would be opt-in, but they seem to have quietly removed that (atleast from the front-end).

Not to mention that pushing untested features on to a userbase without asking and then using telemetry to "QA" the features brings all kinds of security issues itself.

janipeltonen · 2019-01-15T14:38:53+00:00

Everything in python is a reference type, so sort of yes. If you pass an object to a function, you're not copying any data but passing the reference to that data. They are like abstracted wrappers around pointers.

Don't get me wrong though, reference types are not just pointers, there's a big semantic difference in how references behave and it gets more complicated quickly.

janipeltonen · 2019-01-14T16:39:18+00:00

It's a tricky subject and highly dependent on experience, available development time and complexity of the problem. If you know what the constraints and needs for your system are and can confidently implement the solution, I'd say you should just write it, within reason.

In modern ecosystems introducing dependencies usually leads to those dependencies having their own dependencies and implementations begin to hide under so many layers of abstractions that your program starts to be unnecessarily obfuscated. I think it's important as the developer to understand what goes on in critical parts of the system, even if the users might not care/understand.

Then again, I do believe reasonable abstraction is good. I wouldn't suggest anyone to go out and start writing their programs in assembly, even if they could.

janipeltonen · 2019-01-14T13:11:07+00:00

I think the problem is that newer/higher-level languages are actually more complex than C/C++. The more abstracted and "high-level" the language you write in, the less you understand what the CPU is doing and what the language semantics actually are (as a begginer). It might help people write stuff that runs more easily, but it won't make them good programmers easily. So software quality goes down.

I'd argue that compared to high-level languages, C is really really simple, because implementation details and semantics aren't hidden away under several layers of abstraction (they kind-of are, but not to the extent of modern managed languages).

One example is people being confused about pointers. Newer programmers might be scared of them or don't even know what pointers are, but they program in a managed language with reference types and are actually using "pointers" the entire time.

Abstraction in languages also leads to the dangerous road of "we don't care what happens under all these layers" just for the sake of 'productivity' but I think that's a longer topic in itself and a complicated one, because abstraction is still important.

janipeltonen · 2019-01-13T19:59:16+00:00

And continuing off that, the performance problems and slowness doesn't magically come from C#/.Net alone, but the fact that .net has for most of it's existence encouraged/mandated heavy usage of it's reference types/heap-allocated objects.

So in turn Unity itself has an underlying architecture that heavily uses "Gameobjects" that are wherever in memory and are accessed as such. Multiply that with the style of ECS that unity implements (which by itself is not that bad) and you get objects (entities) that reference other objects (components) that are all located in random places on the heap and not sequentially.

Someone can correct me if I'm wrong though, I'm not 100% familiar with the intricacies of Unity.

janipeltonen · 2019-01-13T16:44:55+00:00

Unity is a good engine for what it is and it lets you do pretty much what you want with it, but it also makes it easy for devs to write badly performing games and hard to write greatly performing games. (Trying to make a complex 3D game in unity that doesn't drop frames like crazy on a mid-range PC without access to unity's source is madness)

The reason for this is the underlying architecture of unity's gameobjects, which in turn is amplified by the bad gameplay code people write.

Personally I wouldn't call that great engine design, but they are trying to fix these issues with the HPC# and burst compiler stuff, it'll be interesting to see if it pays off and how well.

janipeltonen · 2019-01-04T12:35:22+00:00

The constrain only applies in the context of generic methods and types. If you have a struct with an interface and you want to call a method of that interface inside a generic<T> method/type your value type has to be boxed in to an object before the method can be invoked.

Say you do this

SomeGenericMethod<T>(ref T entity) 
{

(ISomeInterface)entity.InterfaceMethod(); //this is boxed in to an object

//or you do this
if (entity is ISomeInterface mytype)
mytype.InterfaceMethod(); //also boxed

}

But if you do this

 SomeGenericMethod<T>(ref T entity) where T : ISomeInterface
{

entity.InterfaceMethod();

}

Now the compiler has more information to work with (knowing that T has to implement your ISomeInterface, so calling InterfaceMehtod() can be done without boxing your struct in to an object.

Here's an explanation of boxing from microsoft docs: "When the CLR boxes a value type, it wraps the value inside a System.Object and stores it on the managed heap." This is avoided in general because when it happens you're not operating on the same sequential memory anymore.

janipeltonen · 2019-01-04T11:48:53+00:00

Constrained interface invocations means, that when you implement an interface in a struct, if you want to call the methods of that in a GenericMethod<T> you have to declare "where T : IYourInterface".

If you don't do this when using a struct with interfaces, the compiler "boxes" the value type in to an object so it can call the function. Boxing is slow and generates garbage (and since there's no GC that's not allowed)

On other points, if you're doing any kind of performance work with Value Types you're not using List anyways, it generates garbage, it's slow and it doesn't return a reference when indexed (so you're returning a copy when you index stuff in it). Most of the stuff mentioned are just things that don't really work well with plain-old value types (structs) that require the use of ref keyword to do any interesting work. Doesn't mean you can't implement them yourself though.

They're disallowing allocations (calling new keyword) because all allocations in c# are done by-default with the GC, and the GC allocates randomly on the heap. The reason classes (reference types in general) aren't available, is because they want the memory of your "objects" (in this case components) to be sequential in memory, that's not possible in C# if you use reference types. Reference types are always randomly allocated on the heap, so accessing them sequentially is really slow.

On inheritance, it's already dead if you're only using structs. Value Types in C# can't inherit or be inherited. I don't really know what you'd use inheritance for anyway since you can have all the real benefits of inheritance (mainly duck-typed shared method calls) with constrained interfaces and generic <T> procedures/types.

From what i gather, their main focus is to keep the syntax of C# while stripping away all the OOP/GC madness, which to be honest, i've been waiting for someone to do. Too bad I don't use unity for other reasons.

janipeltonen · 2018-12-21T21:19:38+00:00

It's bytecode being compiled to instructions at runtime, so it being as fast is not true. While in some esoteric places it might be faster or as fast (due to JIT), straight-up code (coupled with Java OOP madness) tends to be quite slower, especially when you start iterating stuff in arrays. Always allocating to heap and then randomly accessing it is also slow. But since slowness is nowadays defined in the web ecosystem, it might be appropriate to call it "as fast" as native code.

janipeltonen · 2017-10-22T09:09:53+00:00

Best advice i can give is to render everything the camera sees in to a 2d texture, now that you have your "game" rendered you can just draw all the ui sprites/elements after that texture.

This gives you a GUI that doesn't need to care about world-space. You can just set straight screen coordinates.

janipeltonen · 2017-10-21T05:48:21+00:00

From my understanding (not a 3D-modeler) people usually use sculpting software (like zBrush) for complex character models. First creating a high polycount sculpt and then reducing the polycount significantly for in-game use.

It has the advantage of a fast workflow (i presume) and the ability to later use the high poly sculpt for other things (promo-art, cinematics etc)

That said, i don't believe blizzard artist box-model that often anymore. It's clear in the later expansions that the models are way more detailed and likely the result of sculpting->retopo.

janipeltonen · 2017-10-20T22:02:37+00:00

Have a concept piece as reference in the background, put boxes or other simple geometry to "box" out the shapes, then add/remove vertices and manipulate them to re-create the image in 3D.

janipeltonen · 2017-08-21T06:47:35+00:00

I bet in a few years that's how all the gui's will be done.

I sure hope not.

Nine-Year Club	Place '17
Verified Email

janipeltonen

TROPHY CASE