Do a write out about the issue and I'll include it, I don't know what the "Nooks and Crannies" error includes, and it is not feasible for someone that's not into BW UMS mapping to easily understand how yo fix it :><:

But yeah, explain it a bit, and I'll add it np

Ok here is the modified feature request list:
https://docs.google.com/document/d/1c8mJexKr29IuqqjetPqf-eLLfQEnAPMBiL8BflR04dI/edit#

Kantu, what do you think about changing the phrasing here:

Quote

Terrain size is something that some people would like to be increased though 256x256 is plenty in most situations, though it would be nice for minimap "art" purposes.

It doesn't represent the parties interested in a larger map dimension. In SC2 you can shrink units and zoom in to make 256x256 be as large as you like, the same is not possible in SCBW.

I would suggest dividing the suggestions into "Essential" which include bug fixes and increased triggering/scripting capabilities and "Stretch".

The latter would include things like:

Quote from Veta

Increase Max Map Dimensions to 512x512 - to facilitate more epic custom map scenarios, including conquest scenarios, RPGs, and single-map diversity.

Increased Player Count to 12-16 Players - to match WC3 or SC2

Map Setting to Enable Multi-Select - Modern RTS (like SC2) are more playable because they allow >12 unit selection. Custom map authors have had to develop hacky work arounds, let's modernize SC:R.

Map Setting to Enable Multi-Command - Multi-Command is a hotkey that will select all other units of the same type as currently selected. Example: Select one Zealot and press the Multi-Command hotkey (e.g. tilde "`") and alll Zealots for the player on the map are selected and under their command. This would be simplify all the "mass control" maps that use triggers for the same effect.

Under the essential list, we'd put something like:

Quote

Preservation of EUD functionality or replacement with Trigger Equivalents

Post has been edited 1 time(s), last time on Mar 31 2017, 11:42 pm by Veta.

Main bug I have spotted is the leaderboard colour is no longer present in top left. This needs to get fixed as it essentially makes leaderboards useless.

I'd say #3 and #1 should be swapped.

#4 should be removed.

#5 should probably be removed since a. We don't want to break previous maps and b. The work around we have currently is alright. Maybe keep it so long as you stress the importance of not breaking past maps. TBH I'd feel safer if they didn't mess with it though.

#8,9,10 should stretches.

Besides that I think it looks good.

Edit: upon rereading #5 I think its worded well enough to keep.

Post has been edited 1 time(s), last time on Apr 1 2017, 2:32 am by Zoan.

Done.

I condensed the scripting logic into a single point.

The Nooks and Crannies error plagues all map-makers, more so on larger maps (256x256). I forget what triggers it, but basically if you have complex terrain, in which the terrain pathing algorithm(run at the beginning of the game) exceeds some arbitrary number of iterations, the game will throw this error. Simply increasing memory capacity and/or doubling this number would fix it for the majority of cases. Though if you wanted to increase map size to something massive (say 512x512) then the Nooks and Crannies error would occur much more frequently. It's a blocker to increasing map size.

It's not too bad, but is annoying if you ever run into it, forcing you to alter your terrain.

See http://cafe.daum.net/_c21_/bbs_search_read?grpid=98vt&fldid=4gz&datanum=284 (screenshot) and http://www.staredit.net/topic/8581/0/ (topic).

Careful with the wording with #2. EUD buffer overflows will never be supported. I would expect #6 to get in. It would probably be super easy to do.

Increase unit selection should be down in the stretch features or not at all. I know there are tons of people who just want to mass select their whole army and throw it at things in those big UMS battle maps, but... They will not do it because I am sure they know if it is done, the melee community would be worried about someone making a hack to enable it on their side of the fence. The feature would never be accepted unless it was exclusive to UMS and even then it would likely cause drama.

You could honestly just cut the part about EUDs and Buffer Overflows, then add the feature references down to the extended trigger list.

Ok, I moved it to the stretch goals. I don't think the melee community would care since it's a map setting. And it would dissuade people from hacking and making hacks for this functionality.

I don't know why you basically list my bug report twice. The spreadsheet with the detailed listing of errors and my presentation on TL.net are referring to the same thing (the vision "inconsistencies" are caused by subtiles – or whole tiles, or even whole doodads being set to wrong terrain levels). It is probably a good thing to list both links for quick access, but they should be one point on the list.

There are also some essential features for a new editor still missing on that list. They may have just escaped your attention, when your focus is entirely on UMS mapping (although I daresay they would be very helpful here as well), but with a loooong list like that, please don't forget the very modest list of tools that we melee map makers actually need (I already mentioned these in the discussion on BWMN):

Essential features

• If I had to pick just one singular feature a future editor for melee maps cannot possibly go without, it is this one:
  We need options for ALL relevant tile/subtile attributes (buildability, walkability, terrain level, vision blocking properties and cover effect) to be displayed as a semi-transparent overlay as a debugging tool (just like now, when you select a unit to place, it shows an overlay of the unbuildable subtiles; CHKDraft's terrain level display option is invaluable, but unfortunately it is not semi-transparent, so you cannot see the terrain level and tile texture at the same time). Ideally it should also be possible to stack multiple layers (so if I am looking for a medium ground fully walkable tile which provides cover, I can just activate these three layers and start looking at the palette).
  It would also be great to have the same options available directly for the tile palette, so tiles do no longer need to be placed down to analyze them.
  
  
• Preserve unit sprite 299 functionality (also known as creep spawner) or gives us something similar in its place. This is a unit which simply creates a ~20x20 area of permanent creep (it also displays an exploding Overlord animation at game start...). It is just way too cool to have around, and there are already quite a few melee maps around which depend on it.
  
  
• Also, if the terrain level bugs (see my list) are fixed, nothing else ought to be changed, tile property-wise! Buildable unwalkable doodads, vision blocking fully walkable doodad tiles, cover providing fully walkable doodad tiles – we need all of these, they are essential for lots of melee concepts – if anything, we need MORE of these (like, at least one of each for every tileset and terrain level – those would be much better assets than some native inverted ramps).

Nice-to-have and probably not too hard to implement additions:

• optimized minimap scaling (in-game, not just in the editor, of course). There is no good reason why a 192² map should not fill the whole minimap screen!
  
  
• Make units, unit sprites and pure (unit) sprites freely convertible into each other and/or add a "display unit collision boxes" feature for unit sprites ; allow the unit ID of unit sprites to be changed, just like it can be done or normal units in SCMDraft ; create a stack option for unit sprites.
  
  
• Is there any chance to get into alpha/beta testing of a new editor 0_0 (and, just in general, get some more direct line of communication going with the devs?)

Post has been edited 4 time(s), last time on Apr 1 2017, 1:07 pm by Freakling.

Do you mean in the editor or via triggers? SI (the author of SCMDraft) is most likely going to be the one making UI changes to the editor.

In the editor (again: melee mapper, no use for triggers ;P) ; it is mostly to simplify things like putting neutral buildings down so they block properly, but leave a scarab gap (exact outline of collision box is important) and stacking them.
I elaborated on that point a bit more.

Post has been edited 1 time(s), last time on Apr 1 2017, 1:09 pm by Freakling.

Yeah none of us really dabble much in terrain beyond for aesthetic purposes, nor are many of us in contact with BWMN. Would actually assume very little people here know about the site actually, save for Excalibur, jj, and maybe some others. SI was actually recently here and one of the proposed UI changes to Draft in another topic is about expanding the overlay options. Feel free to shoot some questions out over to him, maybe he can relay to the Classic team if the option is available.

Also care to hear your opinion of symmetry tools. Obviously you guys craft maps very much tile by tile like we do, but are there any ways you could see it being useful beyond laying foundation?

From what I hear they are making their own reverse/backwards ramps to replace our blended ones, so we may see new tiles. This is also something you might want to talk about or request.

Freakling is probably one of the most creative minds at BWMN. Its good to see him here and he'd certainly be an asset in the discussions on these matters.

Nooks and Crannies is one of SC's oddest errors to my mind. There was a particular map (Battle of Raccoon City) that eliminated the error in the way it was protected however any attempt to open and re-protect it would cause the error to return. I speculated this was due to it editing or removing a non-essential section of the SCX originally but beyond Farty I'm not sure who could examine such a thing.

About the matter of native reversed ramps:
For the most part, I honestly think this is something that is mostly brought up by people who have never actually made any map themselves (or at least nothing sophisticated) and feel repelled by the prospect of having to manually tile-edit stuff.
A ramp is nothing more than a matrix of tiles with one terrain level at one end, another terrain level on the other and some decent looking cliffs on the side. We usually have all of these at hand, and then the option to freely control the properties and looks of these, angle ramps differently or even curve them around, widen or shrink them etc, are what is really important to advanced map concepts, and some pre-fabricated strips of terrain with fixed measures and angles does not help with that at all.

Some terrain transitions and custom cliffs may have to be rethought for aesthetic reasons with the new HD textures, but there will most probably be easy to find solutions (assuming textures which look similar now will not suddenly translate into something completely different looking)

As an easy-to use starter set for novice map makers, I'd suggest just releasing some "failsafe" custom-made ones as an official brush pack (SCMDraft already allows for creating and saving custom brushes for future use) – I'd even compile them myself.

However, if some better custom ramp support is aimed for, the devil is more in the details:

• many ramps like Temple, High Temple (Jungle), Outpost, High Outpost (Ice), Compound, High Compound (Desert) Structure (Badlands) or Elevated Catwalk (Space) look very blocky when expanded, because of the different shading along the width of the ramp. Just having some extension tiles that blend in well would make these more acceptable to use (if the terrain level bugs are resolved too, of course).
  
• Some ramps (all of the above, Sandy Sunken Pit, High Sandy Sunken Pit (Desert), Rusty Pit (Space), and to some degree Sunken ground, High Sunken Ground (Twilight), Low Platform (space) and some more (depending on your aesthetic tolerance levels, I guess) lack good reverse options, because there are no good tile to blend the transitions to normal terrain. So additional transitional textures for these would be an aesthetic improvement (and a ramp with too poor aesthetics is basically unusable, so...).

So I am actually not against such additions, but I feel like a lot of consideration and testing will be required to figure out the best way to do this. What would be bad is if somehow mapmakers ended up shoehorned into using a very limited set of ramps with fixed widths and angles, as in SC2.

Another question that needs to be considered here: How important is backwards-compatibility of maps? Any addition of new tiles would completely kick this out the door, and probably some forward-compatibility of old maps as well, is some null tiles some one used in their map suddenly turn into something else completely (although EUDs are probably the far greater concern for UMS mapping right now).

As for symmetry tools/checkboxes: They are basically just another one of these newbie-friendly lazy man's tools. I only ever find them useful for outlining the rough layout of a map's terrain (and only after already having made a pencil sketch or something similar ; and if it is a layout with simple symmetry to begin with, so it is useless for any odd-spawn layout, tilted axis geometries or most things involving distortion patterns).
If I were to suggest a change: We really need a "smart symmetry tool". Actually this seems an awfully braggy title for a very simple change I have in mind: Since the usable area of a map actually excludes the bottom row and part of the row above that of tiles, the symmetry centre should (at least optionally) be considered at one tile above the actual centre (so between tiles (63,62), (64,63) instead of (63,63), (64,64) for a 128² map). Right now there is only the workaround of starting the map as (x-dim, y-dim-2) and resizing it to the proper size later in the creation process – I wrote an article about this on BWMN some time ago.

And what is wrong with this damn website? It is always so bloody slow and completely dies on me half of the time I try to open or refresh a page...

Post has been edited 5 time(s), last time on Apr 1 2017, 2:28 pm by Freakling.

Well yea, it's just that with new doodads, come new tiles. This means more blending additions. That is more so what I was getting at, as everyone will still use blending due to the overall lack of depth the default brushes/doodads provide. We have been working with the same tiles for 15+ years, new ones are more than welcome. With what we have seen from the files so far, nothing will be changing in how we handle terrain or maps in general.


The later half is what I was getting at, no point in not asking as it is like I said, good for foundation. Any new tools to throw on the ol' belt is a good addition. New toys and all that. Though ex did explain the whole offset to me, as I never actually used the symmetry tool. No need for it in UMS.


We complain about it every day.

So I also looked at a similar wish list I posted a while ago in the CHKDraft topic:
There are some items on there I have not mentioned yet.

One last thing I would personally find very useful:

• A find & replace tool for tiles with a "smart select" functionality (basically like the "select by pixel colour range" kind of tool in a graphics program). This could be something as simple and flexible as numerically entering a tile index, list of tile indices or a whole palette area (with a syntax like top edge tile x bottom edge tile or something like that, as I did here via a text interface and getting a selection of all specified tiles on the map (and an option to replace them with something else quickly), but to make it more user (and particularly newbie) friendly, having some simple presets as checkboxes (like "all temple walls", "all jungle areas", "all ramp doodad tiles", "all dirt doodads", "all ruins borders", "all basic water tiles" etc., depending on the tileset ; easy enough to implement with how tiles are neatly sorted into palette sections) would be good ; the ability to select a tile by just clicking it in the map (like a pipette function in a graphics program)would also be an obvious addition to this...
  

Post has been edited 6 time(s), last time on Apr 1 2017, 7:32 pm by Freakling.

The pathfinding prediction / simulation mode is a very significant one, as most type of serious map bugs are related to pathfinding (bad miner pathing bugs, the infamous ramp vortex, retarded scout and rush paths...) and right now the only way to fix them is the long and arduous process of repeated gradual editing, in-game testing, rinsing and repeating and so on...


Now I think I am done with suggestions

added a few comments:
https://docs.google.com/document/d/1c8mJexKr29IuqqjetPqf-eLLfQEnAPMBiL8BflR04dI/edit#

added some comments, rephrased some issues I found represented in an unclear manner, cleaned up some double entries, added some comments...

A lot of people have been claiming that 1.18 uses L1 latency, but I haven't seen any proof of that. Can anyone confirm?