Get a wand that does cone of cold. nt,
Nivek1,
13-Jan-07 04:06 PM, #14
RE: Necromancer PK,
Elerosse,
12-Jan-07 02:21 PM, #11
Tips!,
GinGa,
12-Jan-07 01:57 PM, #10
RE: Necromancer PK,
_Magus_,
12-Jan-07 12:44 AM, #4
Here are some tips,
Mayaletha,
12-Jan-07 12:40 AM, #2
Addendum,
Mayaletha,
12-Jan-07 12:52 AM, #5
RE: Here are some tips,
Plushka,
12-Jan-07 01:00 AM, #6
You'll learn new things every day.,
DurNominator,
12-Jan-07 03:22 AM, #8
Santa's little quantum mechanic agrees. nt,
Marcus_,
12-Jan-07 07:33 AM, #9
Har!,
Sandello,
12-Jan-07 04:06 PM, #12
RE: Here are some tips,
Isildur,
12-Jan-07 04:28 PM, #13
RE: Here are some tips,
Mayaletha,
13-Jan-07 06:15 PM, #15
RE: Here are some tips,
Isildur,
14-Jan-07 11:37 AM, #16
RE: Here are some tips,
Eskelian,
15-Jan-07 11:29 AM, #17
RE: Here are some tips,
Plushka,
16-Jan-07 10:54 AM, #18
RE: Necromancer PK,
Isildur,
12-Jan-07 12:39 AM, #1
RE: Necromancer PK,
Plushka,
12-Jan-07 12:41 AM, #3
RE: Necromancer PK,
Daevryn,
12-Jan-07 01:08 AM, #7
| |
|
Nivek1 | Sat 13-Jan-07 04:06 PM |
Member since 04th Mar 2003
655 posts
| |
|
#15981, "Get a wand that does cone of cold. nt"
In response to Reply #0
|
|
|
|
Elerosse | Fri 12-Jan-07 02:21 PM |
Member since 01st Nov 2006
423 posts
| |
|
#15956, "RE: Necromancer PK"
In response to Reply #0
|
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.
|
|
|
|
|
Mayaletha | Fri 12-Jan-07 12:40 AM |
Member since 10th Jun 2003
47 posts
| |
|
#15936, "Here are some tips"
In response to Reply #0
|
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. "Once you can accept the universe as matter expanding into nothing that is something, wearing stripes with plaid comes easy." - Albert Einstein
|
|
|
|
  |
Mayaletha | Fri 12-Jan-07 12:52 AM |
Member since 10th Jun 2003
47 posts
| |
|
#15939, "Addendum"
In response to Reply #2
|
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. "Once you can accept the universe as matter expanding into nothing that is something, wearing stripes with plaid comes easy." - Albert Einstein
|
|
|
|
  |
Plushka | Fri 12-Jan-07 01:00 AM |
Member since 16th Feb 2005
150 posts
| |
|
#15940, "RE: Here are some tips"
In response to Reply #2
|
|
|
  |
DurNominator | Fri 12-Jan-07 03:22 AM |
Member since 08th Nov 2004
2018 posts
| |
|
#15943, "You'll learn new things every day."
In response to Reply #2
|
Now I know that boredom is an integer.
|
|
|
|
    |
Marcus_ | Fri 12-Jan-07 07:33 AM |
Member since 04th Mar 2003
681 posts
| |
|
#15946, "Santa's little quantum mechanic agrees. nt"
In response to Reply #8
|
|
|
  |
Sandello | Fri 12-Jan-07 04:06 PM |
Member since 04th Mar 2003
175 posts
| |
|
#15957, "Har!"
In response to Reply #2
|
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.
|
|
|
|
    |
Mayaletha | Sat 13-Jan-07 06:15 PM |
Member since 10th Jun 2003
47 posts
| |
|
#15984, "RE: Here are some tips"
In response to Reply #13
|
> 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. "Once you can accept the universe as matter expanding into nothing that is something, wearing stripes with plaid comes easy." - Albert Einstein
|
|
|
|
      |
Isildur | Sun 14-Jan-07 11:37 AM |
Member since 04th Mar 2003
5969 posts
| |
|
#15989, "RE: Here are some tips"
In response to Reply #15
|
>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.
|
|
|
|
      |
Eskelian | Mon 15-Jan-07 11:29 AM |
Member since 04th Mar 2003
2023 posts
| |
|
#15994, "RE: Here are some tips"
In response to Reply #15
|
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.
|
|
|
|
|