Thanks to Alzarath for bringing the video to my attention! Rough transcription of the video for those who prefer to read or otherwise can't watch the video:

Quote

Hey guys, Grant here from Classic Games. Just wanna give you a real quick update on some of the features that we're working on right now on StarCraft: Remastered, but before I do that I wanna thank you guys for all the feedback that you've been giving us in the forums—telling us about the things that you like and what you don't like, and the issues we need to fix: that really helps us know what's going on in the community. So, please keep it up, and we're definitely listening to everything that you're saying.

So, matchmaking 1v1: it's awesome to see so many people that have jumped in and given matchmaking a go. We've had millions of matches made already in just over 6 weeks of StarCraft: Remastered being live. So it's awesome to see so many people playing the global matchmaker. The nature of the global matchmaker does mean we're seeing some issues of latency, and we've been doing a lot of work on that over the last few weeks to try and reduce that as much as possible. Just recently we doubled the number of proxy servers that we're using in Korea and we're already seeing some improvements based on that. We've made a number of other server-side improvements, and very recently you guys all participated in a turn rate experiment which we did which helped us nail down what was a pretty good happy medium turn rate of 10. That said, we want to run in the best—in the fastest—turn rate we can for the connection, so to that end we'll be rolling out a dynamic turn rate system (coming soon). And that will mean that the game will run in the highest possible turn rate that it can for a connection and if the connection has too much latency, it'll keep dropping down to a turn rate that makes sense for that connection. So that's something to look forward to coming soon, and we think that will alleviate a lot of the issues that we're seeing in the global matchmaker as far as latency is concerned.

One thing I want to talk about really quickly is the disconnecting that we saw happening, which it seems like it's no longer happening, or certainly a lot less. People were disconnecting before the end of the game when it looked like they were going to lose in order to not take the loss, and it was also unfortunately preventing the winner from getting a win. That's now been fixed about a week ago and the winner is getting their win, the guy who disconnects gets the loss AND the disconnect stat, so it's a pretty powerful disincentive for people to do this disconnect drop thing before they lose. So as I said, we've seen a lot less of that, and I would expect that to be the case in future.

So still on the topic of matchmaking, I wanna talk about 2v2 and group matchmaking, which is certainly something that a few of you guys are really interested in, and that is certainly been something that's been on our radar from the very beginning of Remastered. We do need to think a bit more about group matchmaking though for a couple of reasons, one of which is the pool size: do we have a large enough pool size to sustain a 2v2, 3v3, 4v4 matchmaking experience? Or is the small pool size going to devalue the experience a little bit? And probably more importantly are the latency issues that we're seeing in 1v1: they're only gonna be exacerbated in 2v2, 3v3, and 4v4 due to the nature of the turn-locked client-host networking infrastructure that StarCraft has. So I think we need to come up with a bit of a better solution for that before we start tackling matchmaking 2v2; so for that reason I would see 2v2/3v3/4v4 as more of a long-term feature rather than anything that we're going to get to in the short term.

Dynamic lighting (real-time lighting): one of the aspects of dynamic lighting is that it does take a lot of VRAM, and particularly when in a high-res 2D game like StarCraft: Remastered. That naturally requires a lot of VRAM, and dynamic lighting requires a whole bunch more VRAM. So one thing that we've been working really hard on is trying to bring that down as much as possible, and I don't make any promises here about what we can do, but that's something we're investigating and if we CAN do something, then I will hope to see that roll out in a patch very soon. Again, no promises, but we're trying to bring that down to 2 gigs so the people that have 2 gigs of VRAM will hopefully be able to experience the real-time lighting as well.

CCMU, sprite limit, bullet limit: I posted about this in the forums recently and I got a bunch of feedback. This is certainly something we want to do; we just wanted to make sure that you guys were okay with it, that you didn't think it was going to break anything in terms of gameplay, because we're certainly committed to not breaking gameplay. So I put that out there to see if you guys thought there were any problems with that, and it seems like overwhelmingly the feedback has been: look, it's fine to raise or eliminate the limits as far as the bullets and the sprites and the CCMU goes. So I see no reason why we shouldn't move forward with that probably in the mid-term future. But if anyone does have a problem with this in terms of gameplay, now's the time to jump in that thread and give us your feedback.

The final thing I want to talk about today is EUD. In 1.18 we kinda left EUD behind, and that's because we introduced some strong anti-cheat and tamper-proof measures to prevent people from cheating in games of StarCraft, and obviously this is the right thing to do: we want to protect the integrity of the game and make sure it's a fun experience for everyone. We don't want people cheating. But it did kinda leave behind EUD, and that made us a little sad because we like the idea that people can experience StarCraft in whatever way they want to, and if that's playing EUD maps, well, that's fine. Unfortunately we cannot release a game into the public with a security hole in it, so these are the reasons why we've continually patched out EUD over the years. Supporting every EUD offset would be a mountain of work and so it's probably not something that's ever going to be possible. But what we have been doing—we've had a very talented engineer here at Blzzard working on enabling SOME of the EUD offsets again—and right now in Remastered, we have a very popular tower defense map working, 100% complete. So that is kind of the start of EUD for us, and again in the mid-term future you can expect to see this map rolling out—this mapping being whitelisted and us saying it's now okay to play this map. And I would love to hear from you guys as to what maps you're playing and what maps are popular, and we'll see what we can do—once we make sure there's no security holes and seeing if we can actually emulate them successfully—we'll see if we can whitelist those maps going forward. So again, we'll never do every EUD offset and support every EUD map, but this is certainly the start of us bring back some measure of EUD, and I know there's gonna be a whole bunch of folks out there that are gonna be very excited about that.

So that's all I got time for today. Keep talking to us in the forums; we're definitely listening. We don't have time to respond to every comment or every question, but we are certainly listening to you guys, and we plan to do more of these video updates in the future. So, thanks for listening, and I'll see you soon!

I wonder if "support EUD" literally means allow EUDs to work, or to actually do what mapmakers want and make proper triggers for those conditions / actions, so we don't have to hack memory in order to achieve our goals.

If they were sensible, they'd just implement support for both. Make official triggers for the various actions they want to support, and then implement translations from EUD offsets into those officially sanctioned triggers. That way existing EUD maps could work.

Post has been edited 1 time(s), last time on Oct 16 2017, 5:19 am by Lanthanide.

I wonder if "support EUD" literally means allow EUDs to work, or to actually do what mapmakers want and make proper triggers for those conditions / actions, so we don't have to hack memory in order to achieve our goals.

If they were sensible, they'd just implement support for both. Make official triggers for the various actions they want to support, and then implement translations from EUD offsets into those officially sanctioned triggers. That way existing EUD maps could work.

It sounds like there's no consideration for keeping the overflow functionality, as it's officially considered a security vulnerability (I know the community can argue against this stance for EUD Conditions, but Blizzard doesn't make the distinction from EUDAs). I interpreted it to mean they have no plans to make EUDs work, but they want to bring back functionality found in the most commonly-played EUD maps in a proper way.

I like your idea of translating EUDs to newly supported triggers. If Blizzard was willing, it would be most ideal to have some system like you propose that would automatically fix 1.16.1 EUD maps without putting the burden on us.

Overall, it seems like Blizzard wants us to know that they aren't ignoring us, and they are letting the Classic Games team(s) do what the various communities of these older titles would like. We're a pretty quiet community ourselves, but most of the other major EUD-using communities are not English-speaking natively, so we have a pretty significant responsibility to be communicative with Blizzard if we want to encourage and help shape these developments.

I'll add some links to the news post for easy reference.

Post has been edited 5 time(s), last time on Oct 16 2017, 2:50 pm by Roy.

Well, they've said their approach is to simply whitelist certain EUD maps. This makes me think we're getting no official support of EUDs or new triggers - simply certain maps are gonna be blizz approved, probably via some arduous red tape filled Blizz process. What this means I imagine is only popular maps that receive enough support to be noticed by blizz will be whitelisted, while the vast majority of EUD maps will not be supported.

So, in summary, basically the worst approach they could have possibly taken, not to mention the laziest. Though I question how lazy it actually is as surely there will have to be some employee being paid to vet and whitelist EUD maps - who would of course be on a salary. Just how long is Blizz gonna support this whitelisting process, I wonder?? 5 years, 10, 50??

Well, they've said their approach is to simply whitelist certain EUD maps. This makes me think we're getting no official support of EUDs or new triggers - simply certain maps are gonna be blizz approved, probably via some arduous red tape filled Blizz process. What this means I imagine is only popular maps that receive enough support to be noticed by blizz will be whitelisted, while the vast majority of EUD maps will not be supported.

So, in summary, basically the worst approach they could have possibly taken, not to mention the laziest. Though I question how lazy it actually is as surely there will have to be some employee being paid to vet and whitelist EUD maps - who would of course be on a salary. Just how long is Blizz gonna support this whitelisting process, I wonder?? 5 years, 10, 50??

This does indeed seem to be the terminology they're using on the forums.

Quote from Matt Sherman

EUD (Extended Unit Death) was another tough nut to crack. A composite armored Abrams' walnut. Very rare. They taste too good not to crack though. Similar to CCMU, we have created methods to support a handful of the most popular existing maps. Another independent post will be created to cover this rich topic.

If that is truly their current approach, it is an unusual and ultimately disappointing one. But it's still too early in the game to know exactly what their final plans are, and as I mentioned, we may have a chance to influence what those plans will eventually manifest into.

EUD - we do not intend to rebuild maps. Rather, we basically have an EUD emulator to emulate hundreds of the offsets. That's why some EUD maps will be supported as we move forward, and not all.

So it looks like they're actually taking the ideal approach! I'm curious, however, what this means in regards to their use of the word "whitelisting": do they really mean they're whitelisting offsets, or that these offsets will only work on whitelisted maps?

Post has been edited 3 time(s), last time on Oct 16 2017, 2:19 pm by Roy.

I said this in the discord. They gave an example of an EUD tower defense map that they made functional. I imagine they looked at what offsets were used in the map, removed the actual EUD condition triggers and replaced them with new conditions that read the same values. It seems unlikely that they'll "whitelist" certain maps and have these maps somehow hardcoded into the game to allow them to work? seems like more work/not as timeless as just creating new conditions that check the same places in memory as widely used EUD offsets. The way they've worded it supports this thought as well.

Tho I'm mostly jus tryna rationalize the best case scenario based off what they've said LMAO. GIVE US NEW CONDITIONS.

EUD - we do not intend to rebuild maps. Rather, we basically have an EUD emulator to emulate hundreds of the offsets. That's why some EUD maps will be supported as we move forward, and not all.

So it looks like they're actually taking the ideal approach!

No, that's not that ideal approach.

That means if I want to make a new map today, I have to use EUD offsets, which are fiddly and annoying to use and change with each version of the game.

The ideal approach, as I stated, is to implement those functions as proper trigger conditions/actions, and then having their emulator translate classic EUDs offsets into those new trigger conditions/actions transparently.

That means if I want to make a new map today, I have to use EUD offsets, which are fiddly and annoying to use and change with each version of the game.

The ideal approach, as I stated, is to implement those functions as proper trigger conditions/actions, and then having their emulator translate classic EUDs offsets into those new trigger conditions/actions transparently.

I understand the criticism, as these are the pros/cons we're looking at:

Pros:

Existing maps will begin working, other than those with obscure EUDs.

Emulating offsets from 1.16.1 means that EUD offsets will not change with each version of the game.

Existing tools like EUDGen will still work for making EUDs, and the stability of it means EUD integration into editors could make it as seamless as if Blizzard added the new conditions/actions themselves.

It makes it trivial for Blizzard to extend some capabilities of the editor natively (more on this below).

Mac compatibility.

Cons:

We're going to have a much smaller list of possibilities than we had with unrestricted EUDs.

EUDs will still be complicated to create and use (especially reading byte/short values on the wrong offsets).

Blizzard has no real incentive to extend capabilities for SC this way, just "bugfixing" existing popular maps that broke compatibility.

Now, your multi-part solution is certainly forward-thinking, but you're conflating two features as one and then attacking the idea of only implementing one part of it. In other words, you're taking this opportunity of Blizzard extending EUD support to push the agenda of getting a more powerful editor. Blizzard's goal here is to make EUD maps functional again, and while I'd enjoy new conditions/actions to become available (especially in a cleaner fashion than EUDs) as much as anyone else, this is tangential to the actual conversation.

As for why I believe your solution is actually two separate features: classic EUDs do not translate well into new trigger conditions/actions. Due to the limitations of EUDs, we had to do certain things—absurd things—to read values, and I would rather the new conditions/actions not be a 1:1 translation to what we did with EUDs. I don't want Blizzard to make conditions and actions that ask for a unit index ID, for example, but classic EUDs will never translate over to a system that works like, say, Set Doodad State, which grabs the first matching unit at a given location. There also begins to be nuance with the meaning behind classic EUDs: a complete set of triggers, possibly spanning a hundred or more, can comprise a single conditional check, but it's not as trivial as looking at the entire set and determining what the meaning behind it is and mapping it to a new condition, unless you want to be destructive to all maps that use a partial set. For example, you could look for triggers that check all 11 chat lines for a keyword and say "Oh, this maps to our new condition of 'Display Text Detection'", but... that's not going to be as compatible as actually emulating what the EUDs are doing. How would it work if it was checking only a subset of chat lines? Or if it was intentionally not matching a string anywhere, but at a specific position? Or if it was leveraging locality? Don't get me wrong: chat detection is the de facto worst experience to write with EUDs, but Blizzard emulating it vs creating native support for it are two entirely distinct tasks.

Raising of limits is great. A lot of old maps wont break due to unit/bullet limit and it leaves a lot of possibilities for new maps as well. A few niche things like purposefully reaching the sprite limit will be harder to achieve now.

If Blizzard was willing, it would be most ideal to have some system like you propose

and then went on to say what they're doing is ideal, when they're (apparently) not doing what I proposed.

Sorry, I misread what you originally wrote and didn't know you were suggesting to shoehorn EUDs into new conditions/actions. That would not be the ideal solution for backwards compatibility, for the reasons I mentioned: one of these features would suffer from the other.

I didn't argue against your suggestion. In fact, new conditions/actions aren't taking it far enough: we need variables to track units instead of our limited means that we use today like LIDs. These suggestions are separate from the task of repairing the functionality of EUDs, which is an unexpected task Blizzard has taken on.

The unit limit was increased to 3400 (literally just doubled), and Excalibur tested the sprites and had them max out at 1000 with 3399 units on the map.

Memes gather, and now my watch begins. It shall not end until my death. I shall take no wife, hold no lands, father no children. I shall wear no crowns and win no glory. I shall live and die at my post. I am the sword in the darkness. I am the memer on the walls. I am the shield that guards the realms of memes. I pledge my life and honor to the Meme's Watch, for this meme and all the memes to come.

Blizzard so advanced. "Just double it, that's probably fine." Is it so hard to imagine that people might want more than ~200 units attacking at once that they just never included it in their testing? Double is certainly better, especially on the CCMU end, but it's pretty insufficient for sprite lag stuff.

The more I think about this, the more annoyed I get. Doubling the unit limit is one thing, but the same percentage of units can attack at any given time. What's the point of having twice the number of units if only 200 of them can attack? Same ratio. The sprite limit *obviously* needs to increase more than the unit limit or it's literally the same problem as before. Who the fuck thought this was good enough?

Post has been edited 1 time(s), last time on Dec 8 2017, 11:19 am by outlawpoet.

Notably missing:Queued orders: 2000. Seriously, that's less than one queued order for unit. And even when an order is issued immediatly, it still has to be queued first.Ai guards: 1000. Maps with lots of AI units are going to see them freeze if this doesn't get raised. Also only 1000 AI buildings, workers, and military, but they are still hard to reach; while almost anything given to a computer in UMS becomes a guard.