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 then pasted using the new syntax, all without errors. To that end, we encourage anyone trying out the new features on PTR to do just that: paste in one of your existing modes from text that you have saved off somewhere, copy the mode back to text, then paste it back in again. If you run into any errors while doing so, please respond to this thread!

And of course, please check out the rest of the new features as well, and let us know if you run into any trouble. Thanks for helping us test, and happy scripting!

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 have the overhead of executing a...

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 so fast t...

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 are very expensiv...

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 optimizations, so we invite creators to hea...

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!

We have a fix for this coming soon! It should show up in our next 1.38 PTR push. If possible, we’re also hoping to apply a mid-patch fix for this in 1.37.

Yes, we made a change that inadvertently broke that. We should have a fix for you soon.

Overwatch PTR Patch Notes – May 6, 2019

A new Overwatch patch is in development and now available for testing! To share your feedback or report any issues, please post in the PTR Feedback or PTR Bug Report forums.

Please note that the below patch notes only include changes currently available for testing on the PTR. While many of these changes may also be available on PlayStation 4 and Xbox One in a future patch, the PTR is PC-only and only reflects changes coming specifically to that platform.

Workshop

• Fixed several “Disable Built-In Game Mode” actions not working in certain situations.
• Fixed several player modifications (such as movement speed) not carrying over between rounds of a Control map.
• Fixed “Set Max Health” action not working consistently.
• Fixed “Is Using Ultimate” not working for some heroes.
• Fixed “Disallow Button” not being able to disable button input for Bastion’s Gatling Gun.
• Fixed “Player Carrying Flag” resulting in a non-player entity.
• Fixed a bug where it could ...

Should be fixed now! Try reloading, and you should have access to that Action again.

Edit: That is to say, we reenabled it dynamically, so once you reload, it should show up.

Overwatch PTR Patch Notes – May 3, 2019

A new Overwatch patch is in development and now available for testing! To share your feedback or report any issues, please post in the PTR Feedback or PTR Bug Report forums.

Please note that the below patch notes only include changes currently available for testing on the PTR. While many of these changes may also be available on PlayStation 4 and Xbox One in a future patch, the PTR is PC-only and only reflects changes coming specifically to that platform.

Workshop

• Added Actions:
  • Set Primary Fire Enabled
  • Set Secondary Fire Enabled
• Lowered minimum Wait time from 0.25 seconds to 0.016 seconds.
• Lowered minimum projectile speed and gravity to 0%.
• Increased number of entities (icons and effects) from 32 to 64.
• Increased significant digits of number entries from 2 to 3.
• Because “Team” and “Teams” were accidentally included twice in the list of available strings, one pair has been renamed to “Teammate” and “Teammates”.
  • If you used the “Team” or “T...

Yes, QA has identified several issues with the “Disable Built-In” actions, so I’ll take a look at those as well.

Yup, we’re currently looking into increasing entity count as well.