So are there any suggestions from you all for how to do PK as a necromancer, or a place where I could look at tips etc.? :) I've been trying but so far I've died 8 times and haven't killed anyone at level 18 :P Oh well though, I'll get it sooner or later lol

.

Never played a necro out of the 20's but at level 18 I would do the following:

1) Gear for HP above all else, buy a merc that can rescue
2) sleep target
3) maldict with blind, weaken, poison, curse
4) wake with chill touch
5) have merc rescue and then chill touch them till they are dead.

This is reasonably succesful at low levels more so if you are a human and can take a level advantage into the fights. Gear for HP and at level 12 you can pk a lot of people with a simple tactic like this without the merc and poison.

A key thing to remember is that many people panic when they get slept, they do not respond always in the best way, use this to your advantage.

Necro's are very much a finesse class, and require a great deal of game knowledge to pk effectively with.

Summon is an amazing tool to the knowledgable player. Knowing where you can/can't summon, where you can summon blind players to lose them easily and where the locked doors (inescapable rooms without pass door) are can bring you critical success.

Sleep is going to be your main pk tool. I wouldn't consider trying to out-melee anything but a low-damage mage like a low-level shifter or possibly conjurer. That means you'll NEED to land either sleep (to spell them up and then initiate 'the pain') or get them blind (not a good opener, as you get free hits against someone opening with a non-damage spell). Your golem is good for taking the hits, learn how to ORDER it about and get it to RESCUE you. Manipulate autoassist for times you want to help it fight, and times when joining direct combat will just mean someone redirects to you (while unblinded) and does something nasty.

I highly suggest read our logs board to get an idea of what a necro does and does not fear. Fear will keep you alive when intelligence fails. If you aren't scared of trying to sleep a mace spec that can bash you or an axe spec with pincer, then you're either very secure or really dumb.

Enjoy!

Yhorian.

Yeah, don't attack people who could be potential allies. You want people who are more knowledgeable and stronger than you as allies, if it's possible, as opposed to taking orders from a she-man and attacking random people.

for(int bored = 0;bored < 1;bored--)
{
if(!(user.equals("On Carrion Fields"))) user = "On Carrion Fields";
}

Alright here are some tips for starters:

1) If you want an infinite loop, use a while(true) instead of your weird for loop.
2) Define "On Carrion Fields" as a constant instead of creating two separate strings.
3) When comparing two strings, always use the constant on the left hand side incase user is null.
4) Fix the indentation.
5) Wrap if body in curly braces for readability.

Some tips on Necromancers:

You've probably learned by now that necromancers are not uber powerful in the teens. If you care about PK ratios, don't try and kill any melee classed before you hit level 24. Up until then though you should be alright up against other mage classes. As a necromancer, always make sure you give yourself the greatest possibility of escaping a planned attack. This means always keep fly up, modify your size depending on who you are attacking, put up added resistances (protection is easy to get and gives you 25% dam reduction that lasts for 24 hours). Necromancers are damn fragile and can easily die within the first two rounds if you allow yourself to get lagged.

Since you are new though, just focus on gaining ranks. Mid-thirty necromancers are supremely powerful (level 36 makes wraithform protect you from being bashed). I'd get to that rank before experimenting PK-wise, otherwise you'll con loss too quickly as they are not a newbie friendly class. Learning the hard way is the best way though.

:p i forgot i even had that as my sig, i wrote it at like 3 in the morning after 3 days without sleep :P thanks though ;) oh and thanks to the other guy for the tips about getting to 36 necro and what not, i guess ill hold out on trying to fight until then :P 2 cons already lost and working on a third, might be wiser to hold off ;)

Now I know that boredom is an integer.

nt

String constants are interned in Java, so (2) is irrelevant =P

>for(int bored = 0;bored < 1;bored--)
>{
>if(!(user.equals("On Carrion Fields"))) user = "On Carrion
>Fields";
>}
>
>Alright here are some tips for starters:
>
>1) If you want an infinite loop, use a while(true) instead of
>your weird for loop.
>2) Define "On Carrion Fields" as a constant instead of
>creating two separate strings.
>3) When comparing two strings, always use the constant on the
>left hand side incase user is null.
>4) Fix the indentation.
>5) Wrap if body in curly braces for readability.

>1) If you want an infinite loop, use a while(true) instead of
>your weird for loop.

That would get rid of the "bored" variable, which is integral to his joke, i.e. you're always bored.

>2) Define "On Carrion Fields" as a constant instead of
>creating two separate strings.

This looks like Java. In that case strings are immutable, so defining it as a constant instead of a literal doesn't buy you anything performance wise. If it's C++ then the compiler should treat it as static data, so there should still only ever be one copy.

>3) When comparing two strings, always use the constant on the
>left hand side incase user is null.

That's ugly. At any given point in your code you should know whether a variable can potentially be 'null'. If it ends up being null when you didn't think that was possible, then you want to know about that, rather than have your code continue to run and possibly do something stupid.

> This looks like Java. In that case strings are immutable, so defining it as a constant instead of a literal doesn't buy you anything performance wise. If it's C++ then the compiler should treat it as static data, so there should still only ever be one copy.

You are correct in that it wouldn't buy you anything, but it's still good programming practice, thus a "tip".

> That's ugly. At any given point in your code you should know whether a variable can potentially be 'null'. If it ends up being null when you didn't think that was possible, then you want to know about that, rather than have your code continue to run and possibly do something stupid.

No offense, but I'd never hire you as a Java programmer if you truly disagree with point 3.

>No offense, but I'd never hire you as a Java programmer if you
>truly disagree with point 3.

I acknowledge that most people consider this good practice.
It's supposed to help you avoid "accidental" null pointer exceptions, which is what would happen if you call equals() on the variable. By calling equals() on the literal you just get "false" returned instead when the variable contains null.

My point is that "avoiding" exceptions when someone "accidentally" passes you a value you didn't expect is often worse than not avoiding them. When you create a method you create a contract along with it. Often that contract extends beyond the basic types of the parameters your method accepts. Maybe you take a String (pointer), but in addition you expect that pointer to be non-null. If you stipulate that passing null values to your method results in undefined behavior, then doing it your way is fine. Who cares if the comparison returns "false" for null, since we've already covered our ass by stating the behavior is undefined?

Other times you might want to actually acknowledge that the contract was violated, primarily for the caller's benefit. So maybe you test the variable at the top of the method, then throw an exception (or return a special "error" value) if it's null. Once past that statement, your method can assume the variable isn't null and act accordingly.

This isn't java, but consider the example of free() in C. It takes a pointer. Any pointer. But part free()'s contract is that this pointer must have previously been returned by a call to an allocator, and must not already have been free'd, or else behavior is undefined. If you violate that contract then the behavior could very well be a crash. Actually, if you're lucky it will be a crash, since that at least let's you know there's a problem with your code.

Basically if you write some code that expects never to be passed a null value, and some other part of your code is passing it a null value, you wan't to know about that instead of having it continue to run as if nothing were amiss.

I agree with Isildur regarding point 3.

The first scenario somevar.equals("somestring") will return a nice easy to catch exception if somevar is null.

The second will just continue along, possibly creating odd behavior over the life of the program which may be extremely hard to track down.

Then again, I tend to qualify my function inputs as being non-null prior to doing any logic.

...Right, time to change my sig :P

I've only played a necromancer into the 30s, but until you get a zombie army (or wands) it's mostly about putting someone to sleep, then making it so they can't get away (usually via summon). It gets easier when you learn crimson scourge, and easier still once wraithform stops bash. Teleport potions are your enemy.

Put someone to sleep, maledict them all to hell, summon them into an enclosed room (preferably locked), kill them. If there is no enclosed room, and they're blind, just summon them somewhere else in the area. They won't get far. The trick is avoiding dying while you're trying to put all these people to sleep.

alright so basically wait until i have something stronger than poison...and avoid the damned cities and inn :P thanks <3 sleep is a fun skill too, 95% in it already

Note, you *can* kill with a necromancer even at level 11, though it requires a certain mindset due to your extreme fragility.

As you level, you'll get more and more tools to fight PvP with. Unfortunately, so will all of your enemies. :)

Don't forget you also have wands, staves, and scrolls. Some of the most surprising low level necromancer PKs I've seen involved an offensive one of these.