Jump to content

  •  

Bug Tracker Migration

June 3rd
Good news everyone! The staff has decided that it is time to slowly kill off this Bug Tracker. We will begin the process of slowly migrating from this Bug Tracker over to our Github Issues which can be found here: https://github.com/HerculesWS/Hercules/issues

Over the next couple of days, I will be closing off any opportunity to create new reports. However, I still will keep the opportunity to reply to existing Bug Reports. Doing this will allow us to slowly fix any bug reports we have listed here so that we can easily migrate over to our Issue Tracker.

Update - June 7th 2015: Creating new bug posts has been disabled. Please use our https://github.com/HerculesWS/Hercules/issues tracker to post bugs. Users are still able to reply to existing bug posts.

- Administration

Issue Information

  • #003982

  • 1 - Low

  • Fixed

Issue Confirmations

  • Yes (0)No (0)
Photo

zone-based item/skill restriction system cleanup

Posted by Hercules Bot on 29 December 2009 - 02:28 PM

Originally posted by theultramage
http://www.eathena.w...er&showbug=3982

The skill_nocast_db was invented by Celest in r370. Its original purpose seemed to be to move the zone-specific skill behavior to a db file - normal maps, pvp maps, gvg maps, pk maps and woe time restrictions. The item_noequip file already existed by then, also only pvp and gvg support.

The restriction system was expanded by Komurka in r5115 by adding a restricted.txt db file. It expands on the bit stacking concept of the existing files, adding even more confusing notation as bit shifting has to be done to get the values to match.

Also note that there are various existing issues with the current restriction code:
bug #437 - apparently there's a numbering mismatch between the item and skill restriction files - same zone values have different meanings?
bug #2780 - restrictions not covering gvg_dungeon (undecided)
bug #2931 - multiple item restriction flags not stacking together
bug #3367 - bug/user confusion?

So, here are my thoughts and suggestions:

It is blatantly obvious that even though the original authors wrote the thing to be keyed by item/skill instead of zone number and used bit stacking, as time progressed, everybody, themselves included, started visually grouping the entries together by zone. Which of course makes much more sense. Forcing users to use values like 256 512 1024 is worse than using 4 5 6. And the whole "sum values up to assign to multiple zones at once" feature can be just discarded in favor of implicit stacking: you specify a skill 3 times in different zones, and it'll be restricted in those 3 zones.

Preliminary idea - something like packetdb.txt's packet version line tracking:
CODE
zone: 0      // normal maps
87           // no icewalling, it bugs the server
CG_HERMODE   // skilldb_name2id() magic at work, baby!

zone: 22     // some custom stuff
14

zone: 10     // we can list stuff out of order too!

zone: 12345  // parser will yell errors at us and will skip all skill entries until next zone

zone: 31     // max. supported zone number?

Perhaps something like the above.

This post has been edited by theultramage: Dec 29 2009, 06:30 AM

Ind 
changed status to: Fixed

fixed by hercules' map zone db