Reorganize scripts logic (Warps&Duplicates)

[Zopokx]

Mainly, I want to propose a change in the internal script structure. There are 2 kind of scripts that I think would be better if reorganize in another way:

- Warps

- Duplicates

I think with an example is easier to understand:

Actually:

- If you have an NPC duplicated, you usually try to put it in the city/map where it belongs (ex: /npc/re/cities/alberta.txt)

- Every warp from a map/zone are in the same file.

Proposal:

- When you have a duplicate, it should stay in the original script file, with every other duplicate of the same NPC.

- In every warp file should be only every warp that teleport you to that zone/region/map, not the warps that actually are in that map. (ex: The warp that teleports you from mjolnir to yuno fields should be in the warps/fields/yuno_fild.txt instead the mjolnir_fild.txt one. The warp that teleports you from yuno field to mjolnir should be with mjolnir warps)

Pros:

- By this way, you can easyly deactivate or activate zones/maps/region, letting them totally independent.

- You will never have problems like a map that is reachable, but from where you cannot come back. (!)

- NPCs would be easy to find, searching in the original scripts, instead of looking in the cities files.

Cons:

- Maybe individual warps would be more hard to find.

If you think that is a good idea, I can start helping with this.

[Brian]

Actually:

1. If you have an NPC duplicated, you usually try to put it in the city/map where it belongs (ex: /npc/re/cities/alberta.txt)

2. Every warp from a map/zone are in the same file.

#2: I believe it's organized like this because the actual warp npc is located in mjolnir, thus it goes in the mjolnir file.

Pros:

- By this way, you can easyly deactivate or activate zones/maps/region, letting them totally independent.

- You will never have problems like a map that is reachable, but from where you cannot come back. (!)

Not 100% easy, because say you wanted to remove a Yuno map completely (remove from /db/map_index.txt and /conf/maps_athena.conf). Yes you could easily disable the yuno warps file (to disable all warps TO yuno), but all the warps on the yuno map that warp FROM yuno to somewhere else ... you would have to edit the file of each destination!

#1: one Pro of the current organization (duplicates in the city file, not in the original file) is when you want to edit several NPCs in 1 city. Say you want to move the Alberta npcs to make room for a save point or your own npcs. You just open the Alberta city file.

However, one Con of the current organization is when you disable the source NPC, all duplicates break. This could be solved by making the source npc a floating one (not on a map) like was done for the custom Healer and Warper. But this raises the question of efficiency: Should an original NPC be made a floating npc if it only has 1 duplicate? 2? 3? What would be the cutoff? (The Healer and Warper have 34 and 48 duplicates, respectively.)

[Euphy]

- When you have a duplicate, it should stay in the original script file, with every other duplicate of the same NPC.

This is impossible with our pre-re/re split unless we duplicate entire scripts, which we've already decided not to do (it's hellishly annoying to edit files this way).

In general, for duplicates in pre-re/re split files, we keep a floating NPC in the root folder and duplicates in the pre-re/re paths. All duplicates in mixed folders (merchants, other, etc.) should be self-contained. Do you have any specific examples?

[Zopokx]

In general, for duplicates in pre-re/re split files, we keep a floating NPC in the root folder and duplicates in the pre-re/re paths. All duplicates in mixed folders (merchants, other, etc.) should be self-contained. Do you have any specific examples?

I know that (although I think that rAthena shouldn't support pre-re anymore, but it is just my opinion) In fact, I don't have more examples; it was just an example about NPCs and the existance of grouped vs distributed duplicates.

BTW, the main goal of this proposal is about warps.

[Euphy]

Upon rereading this (and looking at the votes), I'm going to reject this proposal. I think the costs outweigh the benefits, and doing a large-scale reorganization makes updating official scripts far more difficult.

An easy way to enable/disable NPCs on maps would be to write a script command which returns the names of all NPCs on a map (similar to @mapinfo 2) and then looping through with 'enablenpc'/'disablenpc'.