Jump to content

Map zone


Lighta

Recommended Posts


  • Group:  Members
  • Topic Count:  16
  • Topics Per Day:  0.00
  • Content Count:  737
  • Reputation:   216
  • Joined:  11/29/11
  • Last Seen:  

Here the current mapzone merge from Hercules :

http://pastebin.com/cUJL5PqC

 

I didn't test it all and will probably take a long time to do all, so this are the current issues :

- @gvgon/off @pvpon/off won't change the zone

- @mapflag can't set zone atm like he use to with restricted

 

But if we do that those refresh it is there really a difference between mapflag and zone ? I mean that look pretty much the same except one is on one file and could benefit heritage and could easier presentation. (yes could figure out restricted&2 = pvp not that obvious) but beside inherit it's pretty much the same.

So idk, imo I think all mapflag should disapear to become zone and only deal with them but not have both simultaniously since it's bring useless complexion, please tell me what you think I'll talk to it on hercules too I think.

Well I suppose we could say a zone regroup multiple map while mapflag is more for one but idk, like mapflag Town and zone Town as well kinda disturb me.

 

add an acmd to test it:

http://upaste.me/479f5591f180fd1a

  • Upvote 2
Link to comment
Share on other sites


  • Group:  Members
  • Topic Count:  72
  • Topics Per Day:  0.02
  • Content Count:  2997
  • Reputation:   1130
  • Joined:  05/27/12
  • Last Seen:  

Thank you so much for doing this!

The main problem with getting rid of mapflags is killing backwards compatibility. Also, it's simpler adding a mapflag than being forced to use zones. Is there much difference in the amount of code/processing?

PM me your final patch before/if you commit this; I'll want to edit the database files first.

Link to comment
Share on other sites


  • Group:  Members
  • Topic Count:  16
  • Topics Per Day:  0.00
  • Content Count:  737
  • Reputation:   216
  • Joined:  11/29/11
  • Last Seen:  

hmm applying zone is higher in cpu since the other one it's just a attribute assignement difficult to do less then that.

But zone give the advantage to have all info in a same db like I said, right now info are kinda in all place and you don't really know that much what flag are on each map unless @mapinfo (wich imo should be updated to display all mapflag)

Also you can inherit a zone wich is like copy those mapflag assign and add this.. that could be sweet.

 

But what I really dislike it's that atm it bring confusion since you have mapflag and zone wich bring almost the same functionnality, so you dunno wich is what.

In other hand that zone for final user is't a good way to define easily mapflag. I mean right now with our current system you could do this with restricted adding a new zone and then have item and skill blocked by default; but if you want for say that zone3 also block mail you'll need to do src edit. if(restricted&3) blabla; or add a new mapflag.

With that zone thing you could simple add a new zone in the group and assign blocked functionnality. Dunno if you follow ?

In short will have less src edit to add new "mapflag"; since they're just new zone.

Link to comment
Share on other sites

  • 4 months later...

  • Group:  Members
  • Topic Count:  32
  • Topics Per Day:  0.01
  • Content Count:  247
  • Reputation:   207
  • Joined:  10/23/12
  • Last Seen:  

Do to the new set of developers we have, I feel this should be brought up again.  Currently, Cydh is working on simply bringing Lillith's mod into the source.  Before this is done, we should actually finish this discussion as a map zone database may be the way to go.

 

Pros:

  • Everything is in one place, rather than scattered throughout different files
  • More versatility with the same DB (Lillith's mod for example)

Cons:

  • More processing time
  • Breaks backwards compatibility
  • Support for transition will need to be provided

 

I am on the fence with this change, but I feel that with the work already completed (at least updating the diff shouldn't be that hard), changing over to this system is much less of a task than starting from scratch.  Can we have some other developer input on this?

Link to comment
Share on other sites


  • Group:  Development Manager
  • Topic Count:  56
  • Topics Per Day:  0.01
  • Content Count:  732
  • Reputation:   525
  • Joined:  12/13/11
  • Last Seen:  

I feel like it is the way forward. It also helps with new functionality for WoE:TE stuff and blocking classes much more easily. You could add a new category restriction like "disable_class" and define a few jobs in there that can't enter the zone.

Link to comment
Share on other sites


  • Group:  Members
  • Topic Count:  16
  • Topics Per Day:  0.00
  • Content Count:  737
  • Reputation:   216
  • Joined:  11/29/11
  • Last Seen:  

Just a note Herc did some update in their system after that diff so it would need to be updated with new herc stuff before being ported.

The more versatile thing is kinda same actually, I said it would require src edit in my previous post for our current thing but mapzone thing as well would required. once it's done you playing with the zone as you wich but you need to do the handler 1st.

I'd go for a systeme or another.

A pro is that you can do inheritage.

A cons is taht adding remove in runtime is more difficult.

Link to comment
Share on other sites

  • 2 months later...

  • Group:  Members
  • Topic Count:  32
  • Topics Per Day:  0.01
  • Content Count:  247
  • Reputation:   207
  • Joined:  10/23/12
  • Last Seen:  

This was a closed topic in the Developer Forum as a rejected change based on the responses of developers.  In general, you will never see this, but due to some recent suggestions, I've brought this topic out for extra discussion.

 

http://rathena.org/board/topic/88512-merger-map-zone-database/

http://rathena.org/board/topic/88598-feature-of-hercules/

Link to comment
Share on other sites


  • Group:  Developer
  • Topic Count:  153
  • Topics Per Day:  0.04
  • Content Count:  2285
  • Reputation:   745
  • Joined:  06/16/12
  • Last Seen:  

how if just make new mapflag for template, so we don't need to change everything (item_noequip, skill_nocast, etc).

we keep current working system and make "zone template" for map and use it as mapflag.

 

like, define the zone mapflags:

zone1 mapflag town
zone1 mapflag nightenabled

use map to use zone's mapflag(s)

prontera mapflag zone1
Link to comment
Share on other sites


  • Group:  Members
  • Topic Count:  31
  • Topics Per Day:  0.01
  • Content Count:  666
  • Reputation:   93
  • Joined:  04/27/12
  • Last Seen:  

I agree with Cydh's take on this. While it may be longer in the end, at least this way we can have a bit more freedom in how it's handled, for instance, giving prontera different restrictions than other towns, but while making it a town.

 

However, I can see why you don't want to implement this, from my stand point it seems the main reason is backwards compatibility with previous revisions that use a normal mapflag system. My solution to this would be a 2-3month merger time limit.

Meaning we implement the system, but keep both operational for 2-3months, allowing server owners to make the switch, then just cut the old wire.

Or if that isn't a possibility than, perhaps a conf file switch, 0 new zone system, 1 old mapflag system.

 

At any rate, these are my thoughts on the subject. If I'm missing something crucial into why it was rejected please let me know, because resource issue seems a bit minor in terms of processing the new information. Mainly because the same issue has been said about sql but there have yet to be any major reports regarding performance issues due to sql.

Link to comment
Share on other sites

  • 8 months later...

  • Group:  Members
  • Topic Count:  35
  • Topics Per Day:  0.01
  • Content Count:  114
  • Reputation:   0
  • Joined:  05/10/12
  • Last Seen:  

Is this compatible with 3CeAm?

Link to comment
Share on other sites


  • Group:  Members
  • Topic Count:  16
  • Topics Per Day:  0.00
  • Content Count:  737
  • Reputation:   216
  • Joined:  11/29/11
  • Last Seen:  

@vijay30393 well we do not maintain 3ceam so we don't kno; better ask them but basically with few change it's probably possible to make it work there.

@GmOcean, @Cydh: for what I understand of Cydh idea, he proposing an aggregation as mapflag as zone.

Like in this exemple zone1 = town + nightenabled

And the main idea was to propose some template.

So let review this : Basically this aggregation idea doesn't bring a new functionnality since you could already do that by adding all mapflag into the map needed, which would bring the exact same result.

What this bring is something to help configuration, exemple of usage of mapflag, a way to encourage it.

Which is all fine but like I said if you already know well how mapflag work it won't change much for you.

 

 @GmOcean: My main issue ain't really backward compability, those are an issue but could be changed overtime and we shouldn't be stuck on something for that reason.

No the issue is about functionnality, as I believe it's quite bad to have 2 ways of doing the same thing. In case of a change we have to update 2 place, people will be mix about how do the stuff etc.. => bringing less good support and so on.

Now let summerize mapflag and "zone" functionnality, (altough I may need to take a look at their current zone system as he might add new stuff that are neat)

Mapflag = A way to add a propriety to a map

Zone = A way to add proprieties to a map 

(Both for group of map you need to list the map you want and set the mapflag/zone into it)

So what the differences ? only the multiplicity of propriety, for reusability purpose your attribute you want to seton mapflag is better to be atomic so like that when you associate it with another mapflag you could build the group of final propriety you want on that map.

But really that just a way of doing it and no one is forcing you to do it atomic. (most of time is not even the case).

And anyway both way on code would necessite something like
if(map.mapflag&x) { map.add_propriety(...); }
(Once you enter a new propriety ofc, in case it's already here you'll try to reuse a flag/zone so you don't have to edit the src.

For the databases thing. Well really on our current implementation you could see that really as a limitation. Sure having it all of them in 1 place is better to review and see who got what, but in other hand you can't ship your new instance in 1 file containing all he need. (mapflag on the script). So that really depend on what kind of organisation you prefer.

Now if we do want to do that bd stuff is really easy and for instance we could say ok we only read the "mapflag" keyword on npc/mapflag/ folder, everywhere else we raise an error/warning. Bam all mapflag instruction are moved on that folder and you have your db.

Or you could just do a mapflag.txt db file ye why not, in anycase I don't judge this too relevant on our decision.

 

I could try to draw a flowchart for idea on decision but basically :

If there a way to already do the thing you try to add and that your change doesn't the execution process (performance), or help much users to do it (convenience), doesn't help dev understanding (maintenance)..., then it's kinda useless.

Now the Cydh idea bring convenience so it's nice but bah may not worth it...

 

Now what I suggest on zone is to delimit on a map a "zone" by xmin,xmax,ymin,ymap, where you would add some mapflag in it.

If you follow me, the current systeme is adding propriety on the whole map, but you may very well be interested on adding a propriety only on a portion of it. Like for example a tvt/pvp map. On the center you will allow pvp mapflag whereas on the cliff you will put noskill. (This way you could have an arena with nice spectator not doing shit on the map). (Just an exemple)
 

Link to comment
Share on other sites


  • Group:  Developer
  • Topic Count:  153
  • Topics Per Day:  0.04
  • Content Count:  2285
  • Reputation:   745
  • Joined:  06/16/12
  • Last Seen:  

@Lighta, my idea also make a template but with our current system, so doesn't need many changes than we're talking about template in libconfig.

but well, libconfig is easier to read, more human friendly.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...