DanReed-11233

Now that we’ve added tabs in the Custom Game Browser for Popular, Favorites, and Recent as well as the ability to add an official Mode Name to Custom Game settings (see the patch notes copied below), it’s important to understand how the system tracks what game mode is currently being played.

After creating a lobby from a mode in the Popular, Favorites, or Recent tab, OR after importing a code in the Settings screen, you should see the Game Code displayed beneath the mode’s Description text box. This tells you that you are “officially” playing that particular game mode. This means that 1) players searching by code or Mode Name in the browser will see your game, 2) the mode will show up in your Recent tab, and 3) your game will contribute to the overall popularity of the mode, which may help the mode show up in the Popular tab eventually (if enough people play it).

If you change the Maps, the Workshop Settings (but not the Workshop script itself), or most of the Lobby se...

Currently, we’ll show 0 or 1 “Trending” modes and 0 to 2 “Hot” modes. There’s a minimum threshold of popularity and ascension speed required for either label, at which point we first choose the “Trending” card followed by “Hot” cards if any remain.

At the risk of sounding like a broken record, this is all subject to change.

Regarding keeping things fresh, we will also be showing up-and-coming modes that have a recent increase in popularity, even if they aren’t yet as popular as the top modes. These will be given the “Trending” tag (representing a very rapid increase in popularity) or the “Hot” tag (possibly more popular than Trending modes, though not as rapid an ascent).

These are cool ideas! Thanks for the suggestions.

Though the popularity algorithm is always subject to change – we’ll be paying attention and tweaking it as necessary – popularity is currently based on the amount of time players spend playing your game mode. This means that if 12 people spend an hour playing your game – whether in a single 12 player instance or in 3 different 4 player instances – it counts 12 hours towards your mode’s popularity.

While we don’t currently have functionality in place to detect or prohibit a player from copying a mode, removing references to the original creator, and reuploading the mode to a new code (possibly with minor changes), we definitely share your concerns. We’ll be watching to see how the new tabs affect such behavior.

Not sure about the hero customization issue. Hopefully, that’s limited to PTR.

We currently save up to 32 favorites and 32 recents, though we may adjust that number as needed.

Thank you for taking part in the 1.64 PTR!

We need folks to get in there and play various custom game modes so we can test out the new tabs (see below), particularly the Popular tab, so please use the browser to join an existing game, or you can create a game and import your favorite code!

Copied from the patch notes:

Previously, it was difficult for players to keep track of the ever-growing collection of player-created game modes. The Custom Game Browser’s new tabs give these modes a chance to shine. The Popular tab shows off some of the most-played modes as well as modes that have started to trend. The Favorites tab lets you build a personal collection of modes – just select the star icon next to any mode you’d like to see in this list. The Recent tab shows modes that you have recently played. Finally, the All Games tab gives you the standard, familiar list of lobbies. We’ve also added the ability to search for lobbies by share co...

We’ve got some new Workshop features in the 1.48 PTR that we’re excited to share with you, including the ability to re-upload your Custom Game settings to one of your existing share codes, the ability to store strings into variables, new C-style syntax for summaries and copied text, and many others. For a full list, check out our patch notes.

For this PTR, we want to make sure that existing modes can be safely pasted from the old syntax, copied using the new syntax, and...

Thanks to everyone who helped us test the new Workshop features in the 1.45 PTR. We were able to fix many of the issues that you identified, and we hope that this leads to a smoother launch of 1.45.

If you have Custom Game creations that you would like to carry forward to the live game, please copy them out of Overwatch and into a text file (since user data from the PTR is not carried over into live). You can copy your mode by going into the Settings for your Custom Game and clicking the Copy button in the upper-right. You can then paste the mode as text into any text editor.

Once the patch goes live, you can restore your mode by copying your saved text onto the clipboard, navigating to the Custom Game Settings, and clicking the orange Paste button in the upper-right.

Thanks again for the help, and happy scripting!

Hi Spinky, here are some answers to your questions:

• It’s cheaper to have a global rule with a condition that checks if the Host Player is doing something rather than using Ongoing - Each Player with a condition that compares against the Host Player. The latter is checking 12 things (one for each player) instead of just 1 thing.
• I haven’t measured it, but it probably doesn’t make much difference whether you use a global variable or Host Player. I’d recommend the latter since you don’t have to worry about updating a variable that way.
• If you know the duration of the Wait in advance, and if it’s fairly long (that is, more than a few frames), then using a Wait and a Loop is better than using a condition since a condition just notices that it has a continuously-changing value and, seeing that it does, performs a check every frame. However, if you are going to be checking every frame anyway (or almost every frame), then a condition is cheaper since you don’t...

We’ve fixed this on our end, along with the bug that caused Nearest Walkable Position to fail near the statue on Chateau. We hope to push this to PTR some time this week. Thanks for the report!

Thanks for the report! We’ve fixed this on our end and hope to push it to PTR later this week.

In the first example, restricting at the event level is much less expensive than restricting via a condition, so rule(“B”) is less expensive.

The second example is interesting. In the first version, the server does a big spike of work up front and then never does anything again, leaving all the heavy lifting to be done by the client apps (since continuously changing values on effects and HUD elements are evaluated on the client). In the second version, both the server and client do some work whenever each player’s A switches between 42 and not 42. It’s hard to say which is “better”. Obviously, if the initial spike on the server in the first version is enough to trigger the server load threshold, then the second version is your only choice. If not, and you’re struggling with server load otherwise (and you don’t mind shifting some of the cost to the client), then the first version might be what you want. Overall, I think the second version is more desirable unless A is changing...

When testing Workshop scripts, the answer to the question “why did my server shut down?” is almost always due to what we call “server load”, which is a measurement we take to determine how much processing power a given game instance is consuming. In order to accommodate a large number of instances, we must shut down individual instances that have started to use too much of the available processing power.

So why does this happen? The short answer is that too many Workshop actions are executing. Sometimes it’s because a high number of actions have occurred over several seconds. Sometimes it’s because an extremely high number of actions happen on a single frame.

Not all actions impact server load the same amount, however. Creating and destroying dummy bots, for example, is very costly, while modifying variables is relatively inexpensive (especially starting in patch 1.45). The values you provide actions will affect server load as well. For example, the ray casting values ...

We just released a new PTR build that should fix many of the issues people had in the previous PTR build. If you have a chance, please test your creations using this new build and let us know if you encounter any incorrect behavior. Patch notes for this build can be found here. Thanks!

We’ve identified and fixed several bugs pertaining to variables, flow control, hero abilities, and the editor. Our next step is to test the codes that everyone has been posting to ensure that we’ve fixed them. We hope to push these changes to PTR within a few days. I’ll keep you guys updated.

We’ve confirmed that those 4 actions (Set/Modify Global/Player Variable at Index) report the wrong value to the Inspector, though with what I’ve seen so far, the actual variable has the correct value. More testing is needed, so stay tuned. In the meantime, see if you can make functioning logic using those actions and checking for values at a particular index (ignoring the Inspector for now). Thanks for the report!

Thanks for the codes! We may have questions for you, so please check back over the next day or so.

Hey everyone, Zach and I have been hard at work on several new Workshop features for 1.45. Our focus for this patch has been quality-of-life features for creators as well as performance improvements. Many of these changes are based on user feedback, so keep those suggestions coming!

These Workshop changes are active right now on the 1.45 Public Test Realm (PTR). Because of several optimizations to the core Workshop execution engine, we’re particularly interested in cases where existing Workshop creations work differently (or not at all) in 1.45. For that reason, we encourage creators and players of Workshop modes to test as many existing game modes as possible on the PTR . Existing Workshop codes were copied from the live game to PTR this morning. Please let us know if there is anything we need to fix! The sooner you let us know, the more likely that we’ll be able to fix any bugs before 1.45 is released.

Of course, we’ve added a lot more than optimizat...

Hi folks, it’s good to see everyone enjoying dummy bots and the other new Workshop features! We’ve fixed a few of the issues that you all have discovered, and they will be getting pushed to PTR next week (hopefully Monday, possibly later):

• Fixed a bug that sometimes caused Create Dummy Bot to spawn nothing.
• Fixed a bug that caused D.Va, Bob, turrets, barriers, and other “pets” to fail to spawn when using Create Dummy Bot.
• Fixed a bug that caused previously-stored presets containing the Create HUD Text or Create In-World Text actions to fail to convert to text properly (for the purposes of copying to clipboard and displaying the action summary in the action list) after being loaded.

We’ll continue to monitor these forums and push out fixes when we can. Happy scripting!