To avoid cluttering peoples pickmap tabs unnecessarily, I propose creating a pickmap library, separate from the arch/dev/editor/pickmaps folder. People can then pick and choose which pickmaps they want to see in their Editor, on top of the existing basic ones.

This was prompted by someone committing a sand floor pickmap (and calling it 'dirt'), when I already have loads of different plain floor pickmaps, including sand (called 'sand' ), which I created myself when the need arose.

"Themed" (or style-enforcing) pickmaps, such as Twisty Little Passages, should also be removed to the new library, and if anyone creates a useful pickmap, this can be committed to the library for others to use if they want to.

The question is where to put it, and in which SVN library. My preference is to create a new folder arch/dev/editor/pickmap_library, i.e on the same level as the existing pickmaps folder so it can easily be found. This should be added to the public SVN trunk, IMO.

I just replied to Grommit's PM about the first two paragraphs, so I'll post the reply:

So to reply to the other two paragraphs as well. The TLP pickmap and others I have so far made for Sh Province are on daiserv so only available to map masters, which is right. The only issue is that MMs not working on Sh Province probably aren't too interested in these pickmaps so don't want the clutter. This shouldn't be a problem when Ragnor sorts out Gridarta's pickmap folder navigation.

Then, for example, we can arrange pickmap folders like map folders, so we have planes/human_plane/stonehaven/ with the existing areas as subdirs (yes, I know ).

So only dirs at your current level (plus a special .. to go up a dir) are visible in tabs, with any files (the actual pickmaps) visible in the dropdown menu. This means all pickmaps (for which you have permissions) are accessible, but no constant clutter.

In view of the quoted reply, I question the need for a pickmap library, but if this is done it can fit in perfectly well with the current/planned pickmap folder system.

(I don't think the current precompiled Gridarta has any of this, so you probably did not know about it.)

Might also consider a /editor in the trunk with all the resources for the editor there. At present you have to get /editor from the obsolete mapmaker package.

The problem with pickmaps in /arch is that to be able to make a collection for test server or main server you have to export multiple svn /arch to a clean directory, erasing any locally made pickmaps that haven't been backed up.

I don't think a huge Smacky directory structure to pickmaps is really necessary. Keep it simple       .

Well, this suggestion mystifies me. Where, for example, does a grit1 or desert floor pickmap fit into this scheme of things?

Yes, players can create these pickmaps if they need them, but it takes time (certainly took me time to build up my set). The idea of the pickmap library is to avoid re-inventing the wheel over and over again - someone needs a pickmap, looks in the library, finds it already there and copies it into the main pickmap folder. Job done.

Ya, nice and simple Grommit.

I'm a bit confused by this series of comments. How is this 'keeping it simple'? Rather than the pickmaps all being available from the editor, you need to specifically copy the ones you want to use from whichever SVN they happen to be in to the resource read by the editor, then run the editor.

If you want a pickmap library, just commit the library of pickmaps to SF in the arch/dev/editor/pickmaps/ dir (as now). Throw away the useless onces (eg, the lights/directors thing) and add whatever is considered useful (eg, sand, grit, etc).

These pickmaps will then appear in the dropdown menu (actually currently they appear as tabs).

People who also have access to daiserv would get, for example, arch/dev/editor/pickmaps/human_plane/nyrrwood/, .../cloud-mts/, etc. so would have these new subdirs as tabs (currently in the pickmaps>folders submenu).

So you get what you have permissions for, and get it automatically, but needn't be bothered by the clutter of stuff you aren't using at that time.

As for erasing your local pickmaps and losing everything because you forgot to back it up, well the same 'problem' exists with maps. So the same solution should help -- be more careful. (I do agree though that it is a bit easier to miss pickmaps as they are buried deep in the arches, and perhaps extracting them to their own dir on the same level as arch, maps, etc would help).

Oh well, I guess I'll just crawl back into my shell and keep my own pickmaps to myself and let everyone else make their own.


The whole point of the library was to reduce the amount of clutter in the tabs, but have additional pickmaps instantly available if required.

Deleting extra stuff you don't want is not an option, since the next time you update arches they will come back. I don't understand why you can't see that.

 

Why? Of the three people who have contributed to this thread two think a pickmap library is a good idea and one (me) thinks it is, not a bad idea, but not especially useful. So unless you're saying that my arguments have convinced you, which I don't think you are, I'm outvoted.

In any case, my previous post was supposed to modify my previous outline to accomodate both POVs: we have a billion pickmap files in arch/dev/editor/pickmaps/ on SF which is the library. Currently yes these will cause lots of clutter because they appear as tabs, but this is because the pickmap feature in Gridarta isn't finished ATM. When finished it would be like the archetype display is ATM, with the addition that you can navigate subdirs. So subdiirs appear as tabs and files appear in the dropdown menu.

(Personally I think you'd be better off having the library in a subdir called 'library' which could then contain whatever further subdivisiions people feel are necessary, but as that is exactly my original idea except 'library' was 'misc' I guess for some reason that won't do.)

Another way to look at it is my pickmaps on daiserv are a library of pickmaps, but a specialist library. You want a general library. I don't see much point in that as it takes about 1 minute to make your own basic general pickmap anyway and if people roll their own rather there will (not in all cases) be some variation in arches used and/or frequency of arches used which leads to mapmakers developing their own style. But whatever. The point is, their is no technical reason why such a library should not be possible. This (in terms of specialist libraries) was why I asked Ragnor to change Gridarta's handling of pickmaps and make it dir-based in the first place.

Hmm...

At first i was leaning more towards grommit, but then i realized... while a library would be useful, i think it would just be better for each mapper to keep his own pickmaps, because each uses their own technique and knows exactly what is in their picmap (imagine if you used some wall that was blocks_view 0 for some reason on a whole mapset because you didn't know). Now, a library could be useful in some cases... (communication between developers) and i think it's fine to have... so...

Bottom line: We should have a "library", but i think we should encourage mappers to use their own pickmaps, unless said pickmaps are utterly plain (sand pickmap, for example)

Cheers,
Unislash

Well, until you mentioned it here, I (and I suspect most others) didn't know Ragnor was changing the way pickmaps are shown in the Editor. My proposal was mainly to avoid tab clutter. Let's see how the new system works out when it arrives.

By a "billion pickmap files in arch/dev/editor/pickmaps", I assume you mean the 7 that are there now (plus a few more if you include the style pickmaps on daiserv).

Anyway, style pickmaps should not be confused with potential library material.

Well ok, 'billion' may have been slight exaggeration. But I meant the generalist library of pickmaps being proposed.

Gridarta at present allows the creation of pickmap folders, but does not allow for changing which directory the folder goes in.

Personally I wish it was in /editor instead of /arches so it did not get erased when we update /arch from 2 or 3 svn's in order to make a collection.

With at least 4 dev's building Gridarta from their svn one of us could put the .jar in /editor if /editor was in the trunk's svn.

I think that there should definitely be "theme" pickmaps for the basis of things like, the shadoaks forest, GT, etc. (no everything, but the basic floor tiles, the plant life, the average extra maps needs this type of stuff, wall decor, etc.)  So if these places were ever expanded upon (by someone other than the original author), the pickmaps are there.  They don't necessarily have to be in the original "Pickmaps" folder, but could be swapped when needed manually.

In case there is any confusion, when I say 'style' and TPK says 'theme', we mean the same thing. These are pickmaps to "enforce" the same style on a particular map theme (set of maps).

heh. sorry!