I'd love to see photoshop like layers, but with object grouping, I'm feeling like this is already being tested or included and I missed it.

So what I have to suggest is a simpler idea.

As of now, tables must be added by the dm, and the dm must give permission for others to view the table.I'd like the option for players to add tables of their choices that could be made visible to all. This would not let them see hidden DM tables, but would allow them to see their own. This would make it easy for players to add animation tools without DM assistance, as well as benefit from their own custom tables for rp shenanigans. Tables are an enourmous tool and resource. I feel like the major hurdle for this would only be integrating that functionality to the network aspect of MT, since the system that uses tables is already there. Perhaps even that would be a small amount of work if for some reason the way tables are disseminated between clients happens to work even if a player adds one. As of now, the GM only aspect of tables makes it another layer of player requests they must address in addition to all other responsibilities of running an online game with a map system. I'd love for the players clients of mt to be able to take advantage of the functionality of tables without forcing the gm into even more of a mother may I situation.

Last edited by femanon on Sun Jul 17, 2016 11:32 pm, edited 1 time in total.

Having glanced inside the latest build, and read these posts, I have to wonder two things.

Are there any plans to make new arrangable layers? The current hard coded format of token hidden object and background is not that usefull at all when it comes to map creation issues

Compounding this issue is my next question. The new draw features exist to group drawings, but so far as I can tell, Grouping image objects you've dropped into the map do not seem to be able to link to the drawing sorting table and therefore be locked into place as a set feature rather than a million little moving parts. Am I simply mistaken on how this should be accomplished? If not, what benefit does drawing even add given the design and draw tools are so unwieldy? The main feature seems to be that we are able to arrange parts of the map together as if numerous things where one object.

as an addendum I feel like my question involving the tables was completely ignored as well. is there any comment on whether that will be a fix in the near future?

Re: Tables, it's needs a overhaul so we probably will not extend the usability of tables much. Jagged already has added several macros to add/delete/edit them to help bridge the gap until we can get there. It may still not help much but honestly, I think most people have gotten around the limitation by just using lib tokens and creating json objects/arrays on those to do more complicated data manipulation.

Re: Drawings, they can move between layers and grouped/deleted but moving them around the map is not possible AFAIK. It's still pretty powerful, I did this map using just objects and drawing back with 1.3.b89 (all the swamp and insided tiles are textured drawings using gradient fills to blend).

Attachment:

dcc17.JPG [ 501.63 KiB | Viewed 819 times ]

Most people move to photoshop/gimp if they need to get more complicated. I don't think we have plans to create a full fledged drawing editor inside MT. There are plenty of other options and it's a matter of priority.

Re: Layers, it's as is for now. I wanted to add more layers once, it's just a "list" right? How hard could it be to add more? Then you look and see how many macros have to expand to include X layers vs the known 4 "TOKEN|HIDDEN aka GM|OBJECT|BACKGROUND". Now look through the code and see how many places have if/then logic to handle special logic for the layers. Pointer tool and such work differently for Token/Hidden vs the other two. Hidden has a bunch of logic everywhere. Token is the only one available to Players. Then you have the FoW which is a huge chunk of code which has to draw all these layers and draw them specifically for every object/token depending on their layer, if they are visible, if they are owned, if VBL is in the way, if Lighting is available, if it's isometric, the list goes on.

TL;DR; Tables is getting a overhaul, planned for 1.4.4.x currently more details TBD. Drawings are as is. Layers are as is, complicated to touch/change, possible will get looked at in a future overhaul down the road.

Tables, it's needs a overhaul so we probably will not extend the usability of tables much. Jagged already has added several macros to add/delete/edit them to help bridge the gap until we can get there. It may still not help much but honestly, I think most people have gotten around the limitation by just using lib tokens and creating json objects/arrays on those to do more complicated data manipulation.

would it really be that much work to add the control panel that lets you add them to the player side for tables? isn't it more work to have it taken out if connected as a player? it seems like a line of code that could just be commented out partially. I dont really need extra functionality right now, just playerside access.

Quote:

Re: Layers, it's as is for now. I wanted to add more layers once, it's just a "list" right? How hard could it be to add more? Then you look and see how many macros have to expand to include X layers vs the known 4 "TOKEN|HIDDEN aka GM|OBJECT|BACKGROUND". Now look through the code and see how many places have if/then logic to handle special logic for the layers. Pointer tool and such work differently for Token/Hidden vs the other two. Hidden has a bunch of logic everywhere. Token is the only one available to Players. Then you have the FoW which is a huge chunk of code which has to draw all these layers and draw them specifically for every object/token depending on their layer, if they are visible, if they are owned, if VBL is in the way, if Lighting is available, if it's isometric, the list goes on.

wouldn't it be possible then to have that layer functionality be limited to the certain layers that already exist? No one said it had to be perfect, so I don't really see the issue if extra features only work on certain layers as long as you can use the extra layers to deal with object clutter and reaching buried objects with the mouse tool for manipulation. Honestly I dont see the need for draw tools being much expanded, about the only two other features I can think of that I think map tools actually needs in its drawing toolkit is the ability to adjust or add transparency (either total or gradient) to any object. and the ability to hide layers from view.

To be honest drawing never felt like something I should care about since I was convinced the clunky draw tools couldn't produce something of the quality you have shown. While I consider my maps to be a bit more detailed, its clear I may need to rethink how I apply drawing to maps, and if it can get as good as you have shown, I can't think of anything else that's needed. The drawtools are clearly good enough. maybe for the draw tool specifically add the ability to gradient two different textures? but with the effects of adjustable transparency with gradients as previously mentioned, even that wouldn't really be needed.

I seem to recall table discussions a few years ago. My personal experience with them is that they mostly hold some bits of data used in a campaign framework but not much else. Usually the GM/framework coder is the one creating tables/macros/etc. If a player really needed something in a table he could export it and give it to the GM to import.

I'm not saying you don't have valid reasons and honestly, I have not even looked at the table code so I don't know if it's one line or if it's more involved to make sure it doesn't break/expose something elsewhere.

Re: the layers, yes, it does seem simple. But again, like I said, there are hard coded values all over the place looking for "if layer == "TOKEN" then" (basically). So even adding a layer that was just TOKEN_1 or TOKEN_2, we would still need to change all classes to "if layer.startsWith("TOKEN")" or some such (it's actually a enum so yata yata).

But I digress, maybe it's simpler than that for others. It's not a technological issue, just time and energy. I encourage, no, implore others to feel free to jump in! We can always use more developers. Fork the repo, make some changes, submit a pull request! Worst case it's not accepted and you have your own fork with exactly what you need. Best case, it's merged to the master branch and becomes official.

I seem to recall table discussions a few years ago. My personal experience with them is that they mostly hold some bits of data used in a campaign framework but not much else. Usually the GM/framework coder is the one creating tables/macros/etc. If a player really needed something in a table he could export it and give it to the GM to import.

One of the most powerful parts of maptools is that it has the opportunity to have the players take up some of their own creative burden. the tables can be used to store data on various images and even create simple animations. Asking the dm if you can add something will always involve more work than just doing it, and it will be work they have to do to all of their maps and campaigns, it would be the same as keeping track of the players tokens. that's our job.

Quote:

Re: the layers, yes, it does seem simple. But again, like I said, there are hard coded values all over the place looking for "if layer == "TOKEN" then" (basically). So even adding a layer that was just TOKEN_1 or TOKEN_2, we would still need to change all classes to "if layer.startsWith("TOKEN")" or some such (it's actually a enum so yata yata).

I don't have the knowledge or skill to do something like code a function that creates a new layer I would surmise, nor likely build a java program. I am struggling right now just to figure out how to use Jsons instead of lists to store nested objects and to retrieve them properly in mt with a tool tip. I do however have the """skill""" enough to go through and find certain stuff and rename that stuff. That endevour is mostly just time. IF your worried about a function like layer.startsWith("Token") you could just label the new layers Bonustoken_1 Bonusbackground_1. They don't have the same functionality anyway, and unless that is integrated later they don't really need to share label space with Token. I imagine the draw order would be set with numerical values that would either use decimal or high value integers to determine which order to draw each layer. Token Hidden Object Background all having set to 1-4 or 100-400, and each bonus map assigned a value or decimal that could put it before or after each core layer. I would lack the technical skill to do this sort of thing though.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum