More DK point spending options (Spoilers?)

[Tora]

(sorry if this was already brought up--but I couldn't find it in Feature Request with searching)

Here's an off-the-wall idea that might go down in flames, but let's see:

First up would be the ability to 'store-up' DK points to spend at a later time.

With that option intact, you could start having things that cost more than 1 DKP.

For example:
Permanent +1 Mystical Arts Use (3DKP). (et Dark Arts & Theiving)
+1PvP per day. (5DKP)
+1Use in Specialty areas per day (3DKP) (Listening, Feeding, Kitchen, etc)
Custom Title (5DKP)
Name Creature (4DKP)
+1Torment per day (2DKP)
+10% HP Overheal each new day(2DKP) (like the opposite of Petra's Sideffect)
+1% Interest in the Bank each new day(9DKP)
+5 Attack (4DKP) - get a discount for sitting and waiting to spend point (et Defense)


and the list can get plain ridiculous if I keep going. The Custom Title and Name Creature will probably be no-go's because they steal from LoTGD's pocket books. And others because of coding issues. But this should at least get the wheels spinning.

[Furion]

Sounds interesting.

I agree a lot with what you wrote at the bottom (especially with the comment about the Donator ones :wink: )

Another idea is extra mount rounds, which has been brought up before. Someone coded it but it was rejected for the core.

[TheOttomancer]

I think it could be a good idea, to be able to have more choices with the DKs... obviously I'm referring to the non-donators options :D

If this go live some time, I can see lots of higk DKs taking orange candles :P

[Buttercup]

I like the idea of getting a discount for saving up DK points. Since saving (money, gems) can be a big part of a player's strategy, this is a great way to continue that method of playing.

[JCP]

A lot of those ideas just won't work.

For example, you may think of them as 'specialty areas', but they are all different numbers tracked by the game and a universal +1 won't work.

You need to keep in mind that the majority of the game are different modules which must exist independently of each other.

Plus, we already have plans. We just don't have the time to put them in motion.

[Sneakabout]

Aye, also the game just isn't set up so that it is possible to expand the list without altering the core - there would need to be a couple more hooks put in for modules to be able to extend the list, and that isn't an area which they want modules to be able to hook into casually.

Even with those put in, there would be problem such as: What happens when that module gets uninstalled (saving up DP qould affect this in particular)? How do these affect game balance?

[Waugh]

Personally I feel the ideas are good, but many of them can be purchased via the Lodge. It needs to stay this way, the game needs to generate cash flow to support itself.

Some of the other ideas are fascinating, and so is JCP's response regarding future plans. :)

[Tora]

Sneakabout made a good point, that anything related to spent DK, would have to avoid special modules. For example, if you made a DKP option for increasing creature rounds, and then for some reason Familiars and Mounts gets split up so you can one of each--what happens to the DKP you spent on just plain 'creatures' - lost? - special code has to be written to allow respend? Doubtful. One thing for sure is that spent DKP MUST be permanent--just as is now. I guess that throws +1Torment out the window too, because whose to say the Graveyard is permanent?

The +1 to specialty areas idea I got from GemDust RED, which has a setting in the Game Setup Info named: "Extra daily uses in specialty area" I figured that was the setting that lets me Listen to seth and eat at the Kitchen Twice each day

I'm very eager to see what Central's "already had plans" are. I bet they're a lock more rock solid than my original ideas. :wink:

[Furion]

The +1 to specialty areas idea I got from GemDust RED, which has a setting in the Game Setup Info named: "Extra daily uses in specialty area" I figured that was the setting that lets me Listen to seth and eat at the Kitchen Twice each day

Actually, it's use points for Thieving, Dark Arts, and Mysticality Skills.

[Sichae-Saracen]

Although Sneak does raise a good point about Module uninstalling, he is wrong about needing extra modulehooks. There are already enough hooks in there, to get what you need done. :)

To sooth any woes about module uninstallation, you would need to either need to have a central module, to store the values of DPs, and then to be able to track them at all times (perhaps an everyhit hook, counting the DP array), so that you could adjust when a module is uninstalled.

Quite honestly, I believe that the core 4, are good enough. :)

[Sneakabout]

Bah, I've tried implementing this on me home test server, and I found that hooks are the way to go. You need to store the information in the same place as the existing spends to be neat!

Plus, hooking everyhit is to be avoided wherever possible :P

[Sichae-Saracen]

Pfft, no one needs neatness! :P

You could always use a low priority hook. ;)
module_addhook_priority("everyhit", 10);

[Milkboy31]

::blinks twice::

I hang my coat on a hook. Does that help?

[Sneakabout]

Why Sichae, I had quite forgotten that making it a low priority reduced the hideousness of calling it every page hit. Truly you are a coding god.

:D

[Sichae-Saracen]

Calling it as a priority hook reduces server load. Besides, I only suggested an everyhit hook, to nip things in the butt as quickly as possible. Note the "perhaps"

Your sarcasm has been noted...

By the way, the correct solution (since you didn't even know that new DP options could be added in the first place, without modification of core :D), would be just a simple hook at dragonkill, check if the module is still installed (from the central module, seeing as how active/deactivated modules still retain module_prefs) then adjust and count all open DPs, so that when a person gets to the DP re-apportionment, they would have the correct amount.

[Darcia]

Why Sichae, I had quite forgotten that making it a low priority reduced the hideousness of calling it every page hit. Truly you are a coding god.

:DClearly a sign of too much mathematics.

[Moonchilde]

Calling it as a priority hook reduces server load.

Umm. no, it doesn't. Calling it as a priority hook has no affect whatsoever on server load.

Also, in general, priority hooks should be used only in the most extreme circumstances. Generally you should use the basic hook ordering. There are specific reasons for needing your hook called earlier, but those are very very few.

[Sichae-Saracen]

Having done my own tests, I have found that it in fact reduces server load, when used in the correct circumstances. :)

[Moonchilde]

Having done my own tests, I have found that it in fact reduces server load, when used in the correct circumstances. :)

Sichae,
then your test is flawed.

Using the 'non' prioritized form actually calls the prioritized form with a fixed priority value (ie, it provides a default). The code doesn't *care* :)

Whether you supply one or not, your hook has a priority and using it or not will have no effect on server load, page load time, latency, or anything else.

[Sichae-Saracen]

Kendaer, you should know by now that I do a lot of things just to yank your chain. :P

[Pwyll]

Ever run into a situation where changing the order of cases in a select statement so that the most likely one is first can significantly reduce the runtime of a script? I've seen it take a 2-hour runtime down to 13 minutes. :wink:

[SaucyWench]

I'd imagine it would. From my personal experience, it's often necessary to code not for that scenario, but because the final else catches "all other possibilities" thus has to be last.

[Moonchilde]

Ever run into a situation where changing the order of cases in a select statement so that the most likely one is first can significantly reduce the runtime of a script? I've seen it take a 2-hour runtime down to 13 minutes. :wink:
Not really a valid comparison here Pwyll.

Unless a module on a hook *explicitly* short-circuis execution (mainly be calling page_footer itself -- which is a bad idea unless you know *exactly* what you are doing and why) then *every* module on a hook will be executed on every call to that hook. The whole point of priority is that *if* needed, you can enforce that one module run before another one. However, it should only be used if there is actually a conflict and it actually matters. There are very very few cases where that is the case however. It still doesn't change the 'load' on the server one iota :)