Incoming Breaking Changes

Riley D. said: There are some incoming breaking changes that I want to make you all aware of in advance so you have time to update your scripts. New Status/Marker Tracking There's a new update on Dev today (post in the Mentor forums) introducing our new status markers with badges. This introduces a breaking change in the API. Instead of having several different properties (e.g. status_red, status_blue) now there is just one property on the token ("statusmarkers") which contains info on all the status effects and their badge numbers. I need to document this on the Wiki so you know how to use it properly, but the good news is you'll be able to take advantage of the new status effect icons and set badges on them as well via the API. The bad news is that all your old scripts need to be updated, although I'm going to do my best to put a "bridge" of sorts in place so that if you access/set the old properties your script will still function.  However, due to the fact that it works one way on Main and another on Dev right now, I won't be able to roll out the API changes until the update goes live on Main. In the mean time I will work on getting a "bridge" in place so existing scripts won't break. I should have more for you on this later today or first thing tomorrow. Image URL Restrictions Probably sometime in the next 2 - 4 weeks I'll be introducing new restrictions to the /direct command requiring that all image URLs are hosted by us. For now you can just upload an image to your account (e.g. through My Library) and then use the Developer Tools Network Inspector to see the URL and use that. When I roll out the restriction I will also introduce a tool you can use to upload images that are meant to be used with the API so they aren't tied to your specific account and won't be deleted on accident.  This is purely a security precaution, as if you can put any arbitrary URL in an image tag, it opens up a whole host of potential exploit vectors. This is a step on the path toward us offering the API Repository, where users may not review every line of code of an API script they use, so we need these sorts of protections in place by default going forward. So, I'll have more for you on both of these soon, but I wanted to let you know about them so you can at least start thinking about what changes will need to be made to your scripts. Thanks! Sounds fine, break what you like. I was looking forward to the extra status markers.

Any ETA yet when this will go live on Main and when we get access to the API functions?

Quatar said: Any ETA yet when this will go live on Main and when we get access to the API functions? Based on past experience the 31st is when I would expect that patch to go to Main unless we find any killer bugs for him to fix, and I would expect the API stuff to come when they come.

Ok, I don't know how that works internally, but is it possible to push out the API change to the Dev server and not Main? So that statusmarker_red keeps working on Main, and whatever new flashy function we'll get for it on Dev? Obviously that would mean that scripts will either work on Main or Dev, but if you add a big "WARNING ONLY ON DEV SERVER SO FAR!!!!!!" notice beside it, then people could use it at their own risk? As I said, not sure you can do that, or if the two APIs aren't actually separate enough. ==== Idea #2: This might be the bridge thing you were talking about. Let's call the flashy new function obj.setMarker(marker_name, badge_number, active) for now. for example: obj.setMarker("red", 8, true) would set the red marker with the badge 8 and show it. No badge could either be 0, "" or false or so. You'd probably name it differently, or got two separate ones for markers and badges, I'm just making up names here as I go along but you get the gist I suppose. Now what that function does internally: it checks if the new property for the new markers exist or not, I've no idea how you implemented those new ones, but pretty sure you can check for it without crashing it in case it doesn't. If it exists it means we're on the Dev server or the Main server got patched now. But by then you can take out these crutches and keep step 2 as the only remaining one. if the new property the new markers exist update that property as it should behave now => works now again on Dev server if the new property does not exist (aka Main server till patch) completely disregard badge_number if the new property does not exist and marker_name refers to one of the new badges like "skull" or "marker1" or whatever you end up calling them, disregard them as well, and abort at this point. Simply no marker gets set or removed, but also no error produced. if the new property does not exist and marker_name refers to one of the colors or dead, set the corresponding statusmarker_red etc property to true/false. => works now on Main. Unless I have a logic error in my thoughts here (it's possible, not too awake right now), that should mean it's working again on Dev but only with the new function. On Main the old way is still working, as well, so it doesn't break old API scripts. However the new way is not crashing the API with illegal commands or accessing properties that don't exist either, and in fact updates the correct statusmarker_ property, if the token was one that exists. Otherwise it simply gets ignored. So new API scripts can already be added to main server campaigns too and be ready for the update. The same would have to be done for getting the values of the markers. I guess if someone tries to read number of badges on Main, he'd always get 0, if he reads the status of one of the new markers, he'd always get false. If he tries to get the colors or dead, he'd get what their corresponding statusmaker_ property is set to.