The selection glitch either doesn't work anymore or is extremely difficult, so maybe.

Unless they patched it already, yea the PTR was launched with L1 instead of L2.

But how can you prove it's L1?

Not sure, other people looked into this. Mostly TL, might find more information there.

I've only read baseless statements about the latency being L1 everywhere I've looked. I personally confirmed the change in latency in 1.17.0, which is why I updated the Liquipedia LatencyChanger page: http://wiki.teamliquid.net/starcraft/LatencyChanger
The 1.18.0 patch uses anti reverse engineering techniques which makes it harder to actually confirm that the latency changed to L1.

just dumping my comments from the google doc here, so they are in a more permanent spot to refer to:

About the problem of "Fake Cliffs" (as referred to by by Koreans) or "Tank Holes" (or "Templar Holes", "Ghost Holes", "Zergling Holes", depending of the most devestating units that can be dropped in there):
This is mostly a map specific problem and especially the more severe cases are just a symptom of a lazy or unaware map maker. Good debugging tools (read: toggleable walkability overlays for both map and palettes) should be first priority here before considering changing stuff the tileset.


About the question of whether to add more tiles/doodads with unusual properties:


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

This is something I always wanted to see, hopefully there's time for it after the essentials.
I imagine they could just make it so normal substructure and floor terrain tiles are buildable, as each of those terrain types has a sub-terrain (plating) that looks unbuildable and could be left flagged as unbuildable.

The tileset would need a lot more to make it an actual feasible choice for a serious mêlée map concept, though. Being stuck with those very tight staircases as ramps is definitely limiting (if you have ever played the Protoss level Into the Darkness (I think it is called) from the original campaign and tried to micro the dragoon up and down those ramps, you know what I mean...

Before I get overly excited about how to improve existing tilesets, I need a stable editor with good extended functionality to actually use any shiny new stuff that may come out with...

https://us.battle.net/forums/en/starcraft/topic/20753916555

Seems that they are still occupied with crash bugs, user interface issues and just generally getting the whole gaming aspect running smoothly.
Guess we need to have some patience.

It would be cool if they'd give the player a choice between modern and classic mode, especially when it comes to campaign and UMS maps. Classic would use the old BW rules (12 unit selection, etc.) and modern would borrow some stuff known from SC2 like workers gathering automatically on rally or being able to select multiple buildings at once. Revisiting the original campaign and giving it some difficulty tweaks and improvements would be great too, since we've all played it 100000 times. Maybe adding some new content like acheivements that won't interfere with the story. I think it would really make BW great again and give a whole new dimension of possibilities to custom map makers. Blizzard should consider this if they really want to make this game alive.

Adding a bunch of superfluous SC2 features won't make the game any better. If you want SC2 features, go play SC2.

Giving us the option to use them would be nice, but I don't think it'll happen.

Hell, when did this emerge? I don't wanna miss a party!

A thing about trigger acceleration that haven't been specifically pointed out. Current techniques (spamming the wait(0) action and similar) allow us to force the SC engine execute triggers every second frame. It was great if there was an option to check triggers on every game frame.

Some triggering techniques will benefit from this: unit movement detection and a special technique of unit death detection that utilizes the feature of unit being unmoveable to another location for 1 frame after (during) death. Currently the latter works with 50% probability and movement detection isn't as precise and instantaneous as it can be.

However, I believe the change might affect an existing UMS maps if the behavior of the wait action was altered (it's an alter of the original engine behavior after all). To my opinion the best option is a map setting that is off by default (which means the old maps unaffected).

I'm not sure if all the new trigger actions and conditions proposals can or will be implemented without interference with the core engine. The thing that is obvious that all existing actions and conditions must work exactly like they did before. This includes (but not limited to) such "features" as:

• Differences in units count with bring at least/at most/exactly when referenced to buildings under construction and units in bunkers and transports.
  
• Create unit doesn't invalidate the location such that the successive bring won't detect newly created units.
  

If I was asked about the minimum list of backwards compatible additions to triggers that require minimum amount of work I would list the following:

• Increase conditions and actions limits (which are 16 and 64 respectively now).
  
• The change that I've mentioned about triggers check acceleration above.
  
• Arbitrary integer math operations with death counters, score and resources (allowing both constants and mentioned variables as both operands): addition, subtraction, multiplication, division, remainder, probably with integer exponentiation and logging. (The first two require us to generate lots of redundant triggers to accomplish, and the next two increase triggers number to the point where it becomes practically infeasible.)
  
• Comparison conditions between death counters, score and resources. (Currently these are only limited to a variable versus constant.)
  
• Generation of random numbers from a given range from 0 to b in a units death variable. (Though we are currently using random switch for this, generating a uniformly distributed random value on a segment, where b isn't a degree of 2 is tricky or very hard to do.)
  
• An option to display different leaderboards and etc. for different players. (Currently the display leaderboard and etc. actions affect all players and we have to use EUD techniques to detect the player number and execute the action locally on a players machine).
  
• An action that forces deselection of units of certain type for the given player. (Currently we mess with the give units action to simulate this, which is quite an expensive action in terms of cpu, affects units orders and forces other units to stop attacking or following.)
  
• An option for smooth center view in multiplayer (jump center view behavior preserved too).
  
• An option to restrict the camera magnification for third person maps.
  
• A possibility to remove map revealers at location (via the new action)
  

More additions to the triggers system that I would love to see but that may require more work or changes. (I know more of these are already listed in the document but below is my personal preference from those.)

• Referring to unit via it's ID (not only through location).
  
• Allow to retrieve a unit ID that is created via triggers.
  
• All things that mentioned by others about checking and changing units stats from hit points to weapon and attack types. However I believe just hit points, shield points, assigning shield to an arbitrary unit, and magic effects are the most important of these.
  
• More integer variables for internal usage (the thing we currently use death counters for).
  
• A possibility to run triggers for players 9-12.
  

Several crashes worth fixing that I can remember off my head:

• The crash that is triggered by creating many map revealers at a single point. (Can't remember the exact scenario to reproduce, but I'm pretty sure I was encountering one.)
  
• The crash that involves some unit death animations: when a ghost dies at a certain angle (sometimes encountered in so called "snipers" maps).
  
• A crash that happens while the player's vision is off for himself due to player's units move in and out of vision (that is provided by other players).
  

The are also some changes from the proposed list that need attention, because they break backwards compatibility with some UMS maps:

• A possibility to use players 9-12 as computer players.
  
• When a unit gets lost in the fog of war you do not lose selection of it.
  
• Right now if you have two players allied, and you constantly in the triggers set one of those players to allied, this disables you from attacking BOTH, but it should just disable you from attacking the one.
  

The following from the list is actually a nice thing to have but the phrasing is a bit wrong: "Allow for an option in triggers for them to only execute once when all the conditions are met, and in order to execute again these conditions must be unmet." I would say "in order to execute again these conditions must be unmet at least once before they met again."

Anyways! Let's hope at least something of those will be concerned! Maybe I can remember more important things later.

Post has been edited 7 time(s), last time on Apr 6 2017, 6:21 pm by Wormer.

Nice logic. If you do not want SC2 features, don't play modern mode.

I was just making a map for the first time in forever and came to the realization that a way to quickly disable triggers in the editor (something akin to commenting out code) for testing would be invaluable, rather than having to mess with or delete the trigger.

A great thing for testing maps would be being able to skip the 5 second countdown in the lobby... just BAM instantly into the game.

That exists. Just add the "Never" condition to the trigger.

Not quick enough. And doesn't work if you happen to have used all conditions.

Can't you just untick all trigger conditions, or is that a lie?