0.5.5 Questions
 

- Tradeskills dont seem to work (0.5.5 and MW DB), it is normal or i have a problem with my DB ? Actually, tradeskill window dont show up.
- I dont see where is the AC column for NPC (Using msSQL Front), and would it be possible to get the formula you used ? When AC is entered, that would be way too long to enter in game, hit mob and verify for how much i hit it.

Thanks :)

You are getting way ahead of me :-)

I don't have AC in for mobs yet. It actually is in the code about 90% - I've been slipping it in a little at a time - but isn't implemented yet. As is the case in any change like this, we will test it on our server first before putting it in the code.

There will be an AC column in npc_types, but it isn't there yet. It will go through the same code as it does for players. Currently, for players (and therefore eventually for mobs) hits are reduced by a random value between 5% and 10% of the total AC. This will be changed as we try it and adjust it.

So a hit of 350 on a target with AC of 1500 would be reduced to a hit of 200-275.

The big controversy among developers regarding AC is this: should a hit for the max amount ever be achieved? As an old AD&D player I satnd on the side of "no". Armor should, in my opinion, always provide some protection, just as it would in real life. Others believe that there should be a random possibility that it should. I understand it does on eqlive. Since this is an emulator, if that is true, it should here too. (Although it won't on our server <grin> )

Your AC thread remember me my OLD EQ Time when we were raiding NToV and arguing about AC/HP, lol :lol:

As for EQLive AC, you will have a chance to get hit at max, emperor SSSSTFU is an example. Not very "roleplay" but well, who said EQ was RPG game ?!

EDIT : And for tradeskills !? Reading forum, they were working on 5.3, so or its broken in 5.5 or my DB is ...bip... ...bip... ...bip... !

How hard would it be to add another column for customizing a server? Such as ac_max_hit = 1 and it would allow for max hits that ignore ac (ie armor defeating hits in the palladium game). I prefer the version where ac always affords some protection. As EQEMu servers tend to be smaller scale than EQ Live, you need a little more protection for groups in my opinion. Just a thought. I'm all for the Scorpious2k version of it though. :) But there will be those who liek the "real" EQ version as well. Easy to make both?

You know whats a much better idea that a value in the Db just turning max hit on and off is putting in the db a value ACMAXREDUC and ACMINREDUC or something like that. And the code reduces it by and random percentage between those two values. So scorp can set those at ACMAXREDUC=10 and ACMINREDUC=5 while peole wanting it close to live can set ACMINREDUC=0 and people who want it to be much more uber can set ACMAXREDUC=500 and ACMINREDUC=100.

I agree. That is a much better idea. :) Me likey...

/bonk EQEmu devs
... go work now ... :P

i got a question

how do i update my current server

im not sure which im running

i created my server (minilogin) about a month ago useing 5.5DR1VSNETBinaries aswell as the EQEmu-0.5.3-DR3-Source&win32 and EQEmu-0.5.2-Win32

gee i bet i sound like a newb lol

Just download 0.5.5 bin, paste in your EQEmu folder, and you're ready.

If developoping it is so esy, why dont you guys just make an sql file that has it and become famous or something! :lol:

I dont see you contributing :P

It is NOT a matter of simply developing it. It has to be tested to make sure that it is compatible with everything else. This is a VERY tricky thing to do, because you may think you have ONE thing fixed but have actually broken something that was already working..

Borrowing from all the good ideas here, this is what I came up with:

First, I thought putting it in the DB would be a problem. It would mean the world builders would have to modify and come up with values for each npc in npc_types. Second, it seems to me this needs to be in the hands of the ServerOp and not world builders.

So, I propose instead the creation of 3 variables in the variables table.

ACfail - the percentage of time AC fails to protect. 0 would mean there was always some level of protection, 100 would mean AC has no affect. When AC fails, it will be possible to get a max dmg hit.

ACreduction - the percentage of AC that is ALWAYS reduced from a hit (except when AC fails with ACfail)

ACrandom - the maximum amount of additional protection AC provides. 0 would mean no additional protection is provided, otherwise an additional amount of reduction is calculated using a random percentage of 1 to this value (except when AC fails with ACfail)

So on our server ACfail=0, ACreduction=5, ACrandom=5. AC always provides protection of 5-10 percent.

Someone else might use ACfail=10, ACreduction=2, ACrandom=3 meaning that AC would fail 10% of the time and when it works you get 2-5% reduction.

Setting ACreduction to a value and ACrandom to 0 would give a constant reduction of a fixed percentage of the AC.

Setting ACrandom to a value and ACreduction to 0 would give a random reduction percentage of the AC from 1 to ACrandom.

I think this would give the ServerOps a lot of flexability.

That works for me as well. As long as it's customizable it has my vote. So in that event, how would mobs AC be factored if it's not in the database? Or are you saying that the mobs AC is still in the db, but not the probabilities?

I like the idea.

The actual AC amounts for each mob will be in the DB, only the variables controlling how AC impacts the calculations on hits would in the variables table.

AC for mobs will be treated in the exact same way, following the same rules set up by the ServerOp, as the players.