2016 Necromancer Revamp

[dargon]

That makes complete sense Leo. I guess I was looking too deeply into the issues

[tegstewart]

Could we create a new class from scratch based on the necromancer?

[Leodagan]

That should be possible, but I don't think we have an easy way to make them selectable in the character creation screen (which rely on Hardcoded Class ID)

[Sand]

I can't say I am a fan with the messed up shit they did with all the classes when I tried out live last year. One of my major annoyances was pet changes like making them slow ass. One of my most played characters is a cabalist so headed off to df with her and as typical cast up on entry buff and then head down. Don't make it very far before pet is waay behind me. I can see why they might of slowed down pets now that they are in many ways more powerful but out of combat running somewhere, your pet should be able to keep up with you, especially if your not using any sort of run speed.

I digress. Even if I LOVED the changes, I am leary of implementing the necro revamp, at this point. Mainly because of the massive amount of changes they have made to not just the necro but other classes too. That is a lot of work and we are already significantly behind on other changes or fixes needed and prefer effort would go to fixing those rather than chasing flavor of the day changes by Broadsword.

That being said, I don't want to discourage work on support for changes, just looking for a way for that work to start and be added to code without messing things up in meantime by having a hodgepodge mess of different patch versions for different aspects of the game.

Coding wise, not 100% sure how to do this but could we possibly add in a new game object for new necro pets called NecromancerPet122.cs (actually put the patch version in there) and then work changes in there. Possibly even do the same the other classes for their pet changes, though most of those aren't as fundamental changes so may only need minor changes to code.

If one wants to test those changes or use the new necro instead of old. They take out the version number from name, compile and way you go.

OTOH the necro vamp almost made 3 new classes out of the one in that each spec has a different behavior , mainly tied to the "form" that replaces the old shade form behaviour so revamp may warrant having a different necropet object for each of these.

I am sure there be some complications due to certain elements requiring changes in other parts of game but I expect most of that will be potentially adding some spells, spell types, and/or styles that can be addded without causing issue for existing elements.

Once do have the changes tested out and other changes ready as well, then I would also like to keep the old necro pet object so the support is there for old style necro.

I tested out Necro briefly, mainly deathsight /servant combination so know little on the painworking one which I think be the toughest line to implement. I believe that is the one where you become your pet so in a way is almost closer to the old necro while the other 2 lines make necro more like a regular pet class as no longer have shade form and do more of the casting directly instead of through the pet.

[Sand]

Leodagan,

I am unsure where you are coming from on this.

We don't support every variation of live updates in db and that is where all the spells/skills/style specifics reside.

Server property switches are for allowing customization of the CODE for things that change play on a fundamental level.
ETC. RVR versus PVE server type.
Archery based on spells or old system where it was essentially ranged mele.
Turn off /on availability of old frontiers.

The fundamental change to the Necro is sort of change that would potentially warrant a server property to switch between different codes.

Any changes that are minor tweaks to code and/or db changes we do not as DOL is about providing a server framework that allows customization.

Can you give an example of what you mean by "The DOL Server game logic is already hard to understand because a lot of variable/hardcoded values can change the behavior of the game regardless of the content of your database".

The only experience I have with the C coding languages or mysql is DOL and have assisted on storm with fixes (primarily db but did a couple code tweaks as well) and don't recall code/db being hard to understand in this manner. I have made plenty of db updates without looking at the code.

[ontheDOL]

I can't say I am a fan with the messed up shit they did with all the classes when I tried out live last year. One of my major annoyances was pet changes like making them slow ass. One of my most played characters is a cabalist so headed off to df with her and as typical cast up on entry buff and then head down. Don't make it very far before pet is waay behind me. I can see why they might of slowed down pets now that they are in many ways more powerful but out of combat running somewhere, your pet should be able to keep up with you, especially if your not using any sort of run speed.

i actually think this is more to do with bad pathing , my cabby pet can keep up with me , then in certain places he starts doing some yoyo pathing and ends up way back

[Sand]

i actually think this is more to do with bad pathing , my cabby pet can keep up with me , then in certain places he starts doing some yoyo pathing and ends up way back

It is more than bad pathing. I never lost my pet like this before when I played live and unlikely they made the pathing that much worse.

My pet on storm keeps up with me no problem. This was on live where I would loose him and this was not a problem before. If read the patch notes they did do speed changes to the pets.

[Leodagan]

On DOL we have a lot of specific handling in Run Speed Calculator to raise Walking Speed of summoned pet to make sure they can follow or even catch up if they have been lagging behind... (there are hardcoded 25% speed boost when following out of combat, and 45% speed boost if following a player on horse, then any kind of player own speed buff is added on top of this)

As for versioned Specialization in DB it doesn't exists for now, but you should be able to build it on top of Data Career easily, right now there are some property that don't work anymore like the switch for Old Archery/New Archery, you have to manually change Archer Career to grant them the Old Melee-based Specialization instead of the newer Caster-based Specialization. (Specs are no longer awarded through OnLevelUp Events in CharacterClass Objects...)

I agree that Server Property switch are for customization, but I don't think they should apply to content and assets, most of them are plain overrides to default values used in game script or rules computation (damage modification, reward settings, mobs stats customization, enabling features X or Y, startup level/money...), and the few that change data records behavior are a pain in the ass (like New Keeps / Old Keeps Model switch that always result in duplicated Keeps and which doesn't work with New-New Frontiers Models anyways...)

Can you give an example of what you mean by "The DOL Server game logic is already hard to understand because a lot of variable/hardcoded values can change the behavior of the game regardless of the content of your database".

Charming Spell use AmnesiaChance Field in Spell Table to set the body type of mob that can be charmed, Bonedancer Pet must have the correct names in database to enable their scripted behavior in specific brains classes... (and I have tons of other examples...)

[Sand]

Charming Spell use AmnesiaChance Field in Spell Table to set the body type of mob that can be charmed, Bonedancer Pet must have the correct names in database to enable their scripted behavior in specific brains classes... (and I have tons of other examples...)

The charming is actually something I worked on as it was one of the few code changes that I made plus my most extensive db update to Storm db to fix the code. Here are the related topics:

http://www.dolserver.net/viewtopic.php? ... lit=+charm
http://www.dolserver.net/viewtopic.php? ... lit=+charm

I had forgotten about the less than obvious use of Amnesia chance for the property on the spell to determine what mob types can be charmed with it. I don't recall find it hard to determine what code was doing, the challenge was making code work properly to allow for proper defining of which mobs one should be able to charm. The reason I looked into this was class like menty wasn't able to charm anything with their perma charm. The problem was twofold, the code check was not correct and bodytypes were rarely set on mobs. I implemented a quick straightforward change to the code that would allow me to implement body types while not breaking ability to charm then go back and fix the code to do a proper check. Unfortunately, I didn't get back to it and come up with proper code.

For the most part fields are named in accordance to what they do, but to keep tables from getting overly big with many unneeded fields, it good to reuse fields for different spell types so you will have some exceptions like amnesia chance. In that case your example is highlighting code that is unfinished, not hard to understand code.

To be brutal, if your looking to customize a server, then you need to have the skills to understand the code and given what the project is trying to accomplish, with many decisions are forced on us by not having control over the client, I think the code is pretty well structured and understandable just very much unfinished. This is why I prefer see efforts into finishing the framework more than looking to chase the new live changes.

With regards to pets, I was commenting on my impression of playing on live recently compared to past experiences on live, NOT dol. My go to caby pet has always been the sapphire simi as it was the most durable pet (maybe not the highest hits and af but the lifetap made up for any differences there) for my pve playstyle and never had an issue with him keeping up with me. Before realizing that this wasn't case any more since they considered him a "caster" so beefed him up in those areas, I tested him out and found he wasn't keeping up and found the new best pve pet was potentially even slower. To rule out just bad pathing, I tested in an open area.

[PlanarChaosRvrtwo]

That should be possible, but I don't think we have an easy way to make them selectable in the character creation screen (which rely on Hardcoded Class ID)

Why not work on that above base class so if you pick necromancer it get disciple and disciple ether can get necro or necro (new one) and make it chooseable?
Well dint xplained well but i guess you get my idea.

[tegstewart]

That should be possible, but I don't think we have an easy way to make them selectable in the character creation screen (which rely on Hardcoded Class ID)

Why not work on that above base class so if you pick necromancer it get disciple and disciple ether can get necro or necro (new one) and make it chooseable?
Well dint xplained well but i guess you get my idea.

I was thinking about this myself this morning. Add a conversation option to trainers to let you swap back and forth between the new or old spec.

It's doable, but a huge amount of work.

[PlanarChaosRvrtwo]

Nono i dont mean this way i mean copy necro class pretty much and call it in core necro_new and necro_old and depending on patch in the properties necro trainer makes you new or old one. without menu.

[tegstewart]

I like the idea of having both the old and new class versions available on one server, but it's definitely a balancing nightmare.