Solution was to not use *Picked X* outside of the loop definitions. But often times people had triggers bound so much to the old design that simply adapting to changed mechanics is not convenient.
Thus I put together library that can be used to revert what Blizzard did in relation to PickEach loops:
While p2p term might not apply here, it comes very close in how I envision it.
On a network level it is client-server. But not the communication method is what I refered to, but the process of evaluating game state.
If server is not responsible for its computation, then it has no relevance under these terms.
Its role here is just to broadcast game input coming from its clients. There is no centralised unit. Each of the clients processes input on its own. And it's up to the clients to determine whether input they receive is valid at all for the current state. And now tell me that is not similar to parallel data processing - where p2p term applies.
Though, I do realize that clients are transfering only inputs of their own actions, and not the results of the computation, what I suppose make it invalid to describe as p2p.. still, not outrageously wrong as you would want it to be.
Also, I'm aware that Blizzard might have put some additional tasks on the server in order to get the best of this model. Tasks beyond wraping input packets with client id and instantly passing them over. But it's not what I was after.
No peer-to-peer transfers happen as most people are behind NATs.
While it's true, and having just said I didn't refer to network model. I'll just add it's not a showstopper. Techniques like udp hole punching exist and are used with great success as far as I'm aware.
If we are not talking about banks, then preloading is indeed only a way to optimize the map. All others assets can be read on demand if not preloaded.
Banks however are special. Loading them on demand would not be feasible. Not in a multiplayer game, with p2p netcode. Where each player would need to transfer bank data to every other player in this particular game. Some banks can go over 1MB.. and since the current bank API is not asynchrous it would cause a lag spike that could last seconds.
The game could preload all the existing banks certain player has. But that would not be wise given the fact that banks are scoped to publishers account, and not the map. Thus it could preload a lot of irrevelant data. That's why we were given system as such, where map must declare what banks it wants to use by listing them under preload section, with an option to limit it to certain player.
edit:
I need to correct myself on one thing. Even though game protocol is P2P, the bnet servers are used as broadcasters, thus clients do not have to transfer the bank data to every other client in the game, as bnet server will do that. But it doesn't change the fact that you've to receive the bank data of every other player in the game in order to stay in sync.
I have zero experience with Wave AI, but I don't think you can freely reorder units that have been created from Wave AI. It seems like they want to reach their origin destination that was declared by Wave, what makes sense.
You probably should issue orders to units managed by AI, using its API. There's a bunch of functions there. The proper way seems to be get the *waveinfo* from unit and change its *wavetarget*.
You could also try workaround and remove mentioned unit from the Wave. By calling *Remove Unit From All Waves* action. This should likely stop the AI from redirecting your unit.
Hey prodigy, I looked into what you said. Mind posting where you might find this function's definition? I opened up the code browse via the command line, no luck. Thanks!
Mentioned function is located in Void Campaign UI / VCUI library.
You must explictly declare which banks you want to preload in map properties. There's option for it somewhere in menu, should be called "Preload info".
In case of using Trigger GUI elements, the editor does that for you (at least it used to), but in case of raw script it doesn't, as it doesn't process it.
btw. Small notice in regards to your code, when bank fails to verify it doesn't mean the data from it hasn't been loaded, but only that the signature check failed. And calling BankLoad again won't erase the data here (unless you do that manually by iterating over sections). Thus you likely want to call BankRemove after BankVerify fails. This guarantees it will be cleared.
There are some screenies in README so you can just take a peek before considering using it.
If you're not familiar with Visual Studio Code, don't mistake it with Visual Studio. These are totally different, despite the name. The former is totally free and pretty lightweight.
The initial setup can be done within minutes, really.
In the past I've attempted to build such extension for Sublime Text. But I failed in developing it further.. it was also awfully slow. The processing backend was written in Python, which isn't known to be fast.. though the slowness was mostly because of design mistakes I made in code parser.
The new backend is written in TypeScript, and is at least x10 faster (I think way more, didn't really measure it). So the feedback is pretty robust - real time code diagnostic messages etc.
I'm quite happy with the overall result. There's a lot that can be added though, and I do plan to work on it.
Backend is LSP compilant, thus it could be ported to other editors with relatively low effort. But I don't plan it myself, as I'm totally settled on VS Code these days. I've been using Sublime and Atom in the past, but in the end I found VS Code to be superior.
Although it is likely that, this alone won't make the frame to appear.
If you're saying that you do have VoidStory dependency then lets just use mentioned function. From what I can see the code looks correct in post #4. What was the error it printed? I suppose it could not work because VCUI library is not loaded. Some libraries aren't auto loaded until you actually take use of functions/triggers it exports. But it does that only when you use it through GUI elements.
The easiest way to force autoload would be probably to have dummy trigger w/o any events. And just one action: Create Timer Window (Campaign) the one from UI (Void) library. Provide some fake arguments in order for it to compile.
Once you do that the library should auto load, and all its functions will be accessible from custom script.
Mentioned function relies on several other functions and variables from VoidStory dependency. So you'll either have to copy-paste all of these, or attach the dependency itself into your map.
If you wnat just the fix, this should do it:
// ... THIS PART SHOULD COME AFTER TimerWindowCreate
DialogControlHookupStandard(c_triggerControlTypePanel, "UIContainer\\ConsoleUIContainer\\TriggerWindowPanel\\TimerWindowTemplate");
DialogControlSendAnimationEvent(DialogControlLastCreated(), PlayerGroupAll(), "HighlightStop");
But if you're going to create multiple TimerWindows through the game, you'll need to save the hookup id to variable, as it is not possible to create multiple hookups to the same Standard frame IIRC.
For that you'll need additional global variable, like:
Should work, but keep it mind that I didn't test it at all.
The code from libVCUI_gf_TimerWindowCreate is for some reason destroying previously created hookup, and then hooks it up again.. but I don't think that's needed.
Okay, I've found out the source of it. It's because you've used special BattleUI frame as custom layout frame for loading screen.. BattleUI is actually root frame for Battle.net UI. Apparently trying to use it for loading screen is pretty disruptive :D And something from SC2 cannot recover without a full game restart.
By curiosity I've tried to use couple of other frames that should not be used for loading screen, but none of it resulted in broken game. I don't know what made you use custom layout, and why did you actually pick BattleUI. But this together was worst case possible, haha.
Generally editor should report about issues like that, but I haven't been seeing anything in the log. So it took a while to find. In fact it can be considered as bug, because ideally maps should be sandboxed in SC2. That is nothing you do inside the map should affect the game itself after you quit the map. And destroying Battle.net UI is certainly something that negatively affects user experience ;D
To summarize, to fix it just just go to *Map -> Map Loading Screen*. Unlink *BattleUI* frame. OK.
Okay, I've played with this for a while, and I must say the Allied Commanders mod is not the one to blame. I've dettached it from your map, and also removed quite a lot of other things.. and this weird behavior is still happening.
This is what I'm observing in my offline tests: If I launch your map while being logged in SC2, then I quit it and I'm back at login screen. That means I've been silently disconnected. Also I have black background on login screen, instead of planets. But what's most important I'm unable to login again unless I restart SC2 (it hangs on 'Authorizating..'). If I launch your map while having SC2 closed, then after map is loaded I quit it (just the map). And that also results in ability to login to bnet.
This is veeeery weird. I'll get back to this later.
What I can tell you know is that I'm getting the same issue when I'm trying to watch replay/resume it. In fact you're already disconnected before the map reaches post init phase - that is before loading screen is gone.
And the source of it is certainly Allied Commanders mod. I'm not sure why though. Likely it might take use of some blizzard exclusive functions. What results in disconnect when done online (probably because publisher's account doesn't have necessary permissions).
Although I've read about people using this mod before, w/o any disconnect. So it might be new thing - coming either from recent patch, or update to the mod itself.
Also it's worth to check if your local version of this mod is the same you linked against in Battle.net (that is v0.36).
So the question is, do you actually need this mod - are using anything implemented there?
I'll try to identify what exactly this mod does during its initialization process that ends with disconnect from bnet. But if you want easy fix, just remove this mod from your map dependencies.
One thing that I noticed before trying out your checklist.
When I launch my published map through SC2, while the editor is still running in the background, the Editor spits out these error messages when the map causes the disconnection:
"[10/6/2017 11:52:38 PM] Warning: Battle.net connection is closing: You have been disconnected from Battle.net because another computer connected using your account. [10/6/2017 11:52:38 PM] Warning: Battle.net connection was lost"
That is normal. Editor acts as SC2 client. So when you login in it to the same account and region, and then launch SC2 for the same account and region, you get this exact message. Since server only allows one active connection.
Nope. There's nothing special you need to do, for your map to work correctly in Battle.net. The behavior you experience is either caused by some obscure bug in SC2 which reason I cannot guess. Or there's *something* in your map that causes this freeze.
It's good that you were able to save the replay. And what's better, it seems like the bug can be reproduced by running the replay. If you could attach the replay here, or upload it somewhere and post the link, then I'd look into it myself (yes, replay from online game is all I need). If the bug will also occur on my end, I should be able to track down the cause. Also, what's the length of the replay? Because if the freeze actually happens right after start, I'd expect it to have ~0s.
In the meantime, here's small checklist you could do, to narrow the area. Proceed it until you'll confirm the freeze doesn't happen anymore. (Of course before doing anything of this, backup your map.) - Simply republish the map w/o changing anything. To make sure this is not result of some error during publishing process.
- Remove custom dependencies/mods (if you have any). Publish & retry. - Remove triggers that are running at the start of the game. Publish & retry. - Remove ALL of the triggers. Publish & retry. - Remove ALL preplaced units on the map. Publish & retry. If at this point the freeze will still be occuring, I'll be suprised. But you should keep going and remove remaining things such as: custom imported assets (if you have any), lobby attributes/variants, data entries.. it might sound funny, but I'm serious - when you can't guess the source of your trouble, then removing the possibilities piece by piece is smart way to approach it. Unless you'll end up with empty map, haha.
Given the fact it works flawless in test mode, it does seem pretty weird.
I could see infinite loop in triggers or infinite recursion in Data causing something like this, where game freezes for a while thus putting you in a state of being not available to Battle.net. Although in such scenario it should unlock after a while - when SC2 detects things went wrong, to put it simple.
But.. if you can't reproduce it offline in test mode, I don't think that's the problem you're running into.
Does the disconnect happen every time? Are you able to quit the game before getting "attempting to reconnect" screen pop up, and have a score screen visible? Does the replay file save after the game?
0
Solution was to not use *Picked X* outside of the loop definitions. But often times people had triggers bound so much to the old design that simply adapting to changed mechanics is not convenient.
Thus I put together library that can be used to revert what Blizzard did in relation to PickEach loops:
https://us.battle.net/forums/en/sc2/topic/20759576052
0
While p2p term might not apply here, it comes very close in how I envision it.
On a network level it is client-server. But not the communication method is what I refered to, but the process of evaluating game state.
If server is not responsible for its computation, then it has no relevance under these terms.
Its role here is just to broadcast game input coming from its clients. There is no centralised unit. Each of the clients processes input on its own. And it's up to the clients to determine whether input they receive is valid at all for the current state.
And now tell me that is not similar to parallel data processing - where p2p term applies.
Though, I do realize that clients are transfering only inputs of their own actions, and not the results of the computation, what I suppose make it invalid to describe as p2p.. still, not outrageously wrong as you would want it to be.
Also, I'm aware that Blizzard might have put some additional tasks on the server in order to get the best of this model. Tasks beyond wraping input packets with client id and instantly passing them over. But it's not what I was after.
While it's true, and having just said I didn't refer to network model.
I'll just add it's not a showstopper. Techniques like udp hole punching exist and are used with great success as far as I'm aware.
0
If we are not talking about banks, then preloading is indeed only a way to optimize the map. All others assets can be read on demand if not preloaded.
Banks however are special. Loading them on demand would not be feasible. Not in a multiplayer game, with p2p netcode. Where each player would need to transfer bank data to every other player in this particular game. Some banks can go over 1MB.. and since the current bank API is not asynchrous it would cause a lag spike that could last seconds.
The game could preload all the existing banks certain player has. But that would not be wise given the fact that banks are scoped to publishers account, and not the map. Thus it could preload a lot of irrevelant data.
That's why we were given system as such, where map must declare what banks it wants to use by listing them under preload section, with an option to limit it to certain player.
edit:
I need to correct myself on one thing. Even though game protocol is P2P, the bnet servers are used as broadcasters, thus clients do not have to transfer the bank data to every other client in the game, as bnet server will do that. But it doesn't change the fact that you've to receive the bank data of every other player in the game in order to stay in sync.
0
I have zero experience with Wave AI, but I don't think you can freely reorder units that have been created from Wave AI. It seems like they want to reach their origin destination that was declared by Wave, what makes sense.
You probably should issue orders to units managed by AI, using its API. There's a bunch of functions there.
The proper way seems to be get the *waveinfo* from unit and change its *wavetarget*.
You could also try workaround and remove mentioned unit from the Wave. By calling *Remove Unit From All Waves* action. This should likely stop the AI from redirecting your unit.
0
https://github.com/Talv/sc2-data-trigger/blob/c8ca574f086cf12f61820d88abfcf096145ff964/campaigns/voidstory.sc2campaign/base.sc2data/TriggerLibs/VoidCampaignUILib.galaxy#L5279
0
You must explictly declare which banks you want to preload in map properties. There's option for it somewhere in menu, should be called "Preload info".
In case of using Trigger GUI elements, the editor does that for you (at least it used to), but in case of raw script it doesn't, as it doesn't process it.
btw. Small notice in regards to your code, when bank fails to verify it doesn't mean the data from it hasn't been loaded, but only that the signature check failed.
And calling BankLoad again won't erase the data here (unless you do that manually by iterating over sections). Thus you likely want to call BankRemove after BankVerify fails. This guarantees it will be cleared.
0
Extension for Visual Studio Code, it attempts to provide IDE-like capabilities for Galaxy Script.
More about it: https://github.com/Talv/vscode-sc2-galaxy
There are some screenies in README so you can just take a peek before considering using it.
If you're not familiar with Visual Studio Code, don't mistake it with Visual Studio. These are totally different, despite the name. The former is totally free and pretty lightweight.
Can be downloaded here:
https://code.visualstudio.com/Download
The extension itself is also published on marketplace, thus can be easly installed:
https://marketplace.visualstudio.com/items?itemName=talv.sc2galaxy
The initial setup can be done within minutes, really.
In the past I've attempted to build such extension for Sublime Text. But I failed in developing it further.. it was also awfully slow. The processing backend was written in Python, which isn't known to be fast.. though the slowness was mostly because of design mistakes I made in code parser.
The new backend is written in TypeScript, and is at least x10 faster (I think way more, didn't really measure it). So the feedback is pretty robust - real time code diagnostic messages etc.
I'm quite happy with the overall result. There's a lot that can be added though, and I do plan to work on it.
Backend is LSP compilant, thus it could be ported to other editors with relatively low effort. But I don't plan it myself, as I'm totally settled on VS Code these days. I've been using Sublime and Atom in the past, but in the end I found VS Code to be superior.
0.963887065003283
You did alright. Apparently we're missing some relevant part of code.. try to add this:
(After TimerWindowCreate)
Although it is likely that, this alone won't make the frame to appear.
If you're saying that you do have VoidStory dependency then lets just use mentioned function. From what I can see the code looks correct in post #4. What was the error it printed?
I suppose it could not work because VCUI library is not loaded. Some libraries aren't auto loaded until you actually take use of functions/triggers it exports. But it does that only when you use it through GUI elements.
The easiest way to force autoload would be probably to have dummy trigger w/o any events. And just one action:
Create Timer Window (Campaign)
the one from UI (Void) library.
Provide some fake arguments in order for it to compile.
Once you do that the library should auto load, and all its functions will be accessible from custom script.
0.963648380700595
Mentioned function relies on several other functions and variables from VoidStory dependency. So you'll either have to copy-paste all of these, or attach the dependency itself into your map.
If you wnat just the fix, this should do it:
http://peeeq.de/code.php?id=29105
But if you're going to create multiple TimerWindows through the game, you'll need to save the hookup id to variable, as it is not possible to create multiple hookups to the same Standard frame IIRC.
For that you'll need additional global variable, like:
And the code above would expand to:
if (gv_timer_frame == -1) { gv_timer_frame = DialogControlHookupStandard(c_triggerControlTypePanel, "UIContainer\\ConsoleUIContainer\\TriggerWindowPanel\\TimerWindowTemplate"); } DialogControlSendAnimationEvent(gv_timer_frame, PlayerGroupAll(), "HighlightStop");http://peeeq.de/code.php?id=29106
Should work, but keep it mind that I didn't test it at all.
The code from libVCUI_gf_TimerWindowCreate is for some reason destroying previously created hookup, and then hooks it up again.. but I don't think that's needed.
0.965277777777778
Okay, I've found out the source of it.
It's because you've used special BattleUI frame as custom layout frame for loading screen.. BattleUI is actually root frame for Battle.net UI. Apparently trying to use it for loading screen is pretty disruptive :D And something from SC2 cannot recover without a full game restart.
By curiosity I've tried to use couple of other frames that should not be used for loading screen, but none of it resulted in broken game.
I don't know what made you use custom layout, and why did you actually pick BattleUI. But this together was worst case possible, haha.
Generally editor should report about issues like that, but I haven't been seeing anything in the log. So it took a while to find.
In fact it can be considered as bug, because ideally maps should be sandboxed in SC2. That is nothing you do inside the map should affect the game itself after you quit the map. And destroying Battle.net UI is certainly something that negatively affects user experience ;D
To summarize, to fix it just just go to *Map -> Map Loading Screen*. Unlink *BattleUI* frame. OK.
0
Okay, I've played with this for a while, and I must say the Allied Commanders mod is not the one to blame. I've dettached it from your map, and also removed quite a lot of other things.. and this weird behavior is still happening.
This is what I'm observing in my offline tests:
If I launch your map while being logged in SC2, then I quit it and I'm back at login screen. That means I've been silently disconnected. Also I have black background on login screen, instead of planets. But what's most important I'm unable to login again unless I restart SC2 (it hangs on 'Authorizating..').
If I launch your map while having SC2 closed, then after map is loaded I quit it (just the map). And that also results in ability to login to bnet.
This is veeeery weird. I'll get back to this later.
0
What I can tell you know is that I'm getting the same issue when I'm trying to watch replay/resume it. In fact you're already disconnected before the map reaches post init phase - that is before loading screen is gone.
And the source of it is certainly Allied Commanders mod. I'm not sure why though. Likely it might take use of some blizzard exclusive functions. What results in disconnect when done online (probably because publisher's account doesn't have necessary permissions).
Although I've read about people using this mod before, w/o any disconnect. So it might be new thing - coming either from recent patch, or update to the mod itself.
Also it's worth to check if your local version of this mod is the same you linked against in Battle.net (that is v0.36).
So the question is, do you actually need this mod - are using anything implemented there?
I'll try to identify what exactly this mod does during its initialization process that ends with disconnect from bnet. But if you want easy fix, just remove this mod from your map dependencies.
That is normal. Editor acts as SC2 client. So when you login in it to the same account and region, and then launch SC2 for the same account and region, you get this exact message. Since server only allows one active connection.
0
https://www.sc2mapster.com/forums/development/triggers/229728-timer-opacity?comment=3
0.96575821104123
Nope. There's nothing special you need to do, for your map to work correctly in Battle.net. The behavior you experience is either caused by some obscure bug in SC2 which reason I cannot guess. Or there's *something* in your map that causes this freeze.
It's good that you were able to save the replay. And what's better, it seems like the bug can be reproduced by running the replay.
If you could attach the replay here, or upload it somewhere and post the link, then I'd look into it myself (yes, replay from online game is all I need). If the bug will also occur on my end, I should be able to track down the cause.
Also, what's the length of the replay? Because if the freeze actually happens right after start, I'd expect it to have ~0s.
In the meantime, here's small checklist you could do, to narrow the area. Proceed it until you'll confirm the freeze doesn't happen anymore.
(Of course before doing anything of this, backup your map.)
- Simply republish the map w/o changing anything. To make sure this is not result of some error during publishing process.
- Remove custom dependencies/mods (if you have any). Publish & retry.
- Remove triggers that are running at the start of the game. Publish & retry.
- Remove ALL of the triggers. Publish & retry.
- Remove ALL preplaced units on the map. Publish & retry.
If at this point the freeze will still be occuring, I'll be suprised. But you should keep going and remove remaining things such as: custom imported assets (if you have any), lobby attributes/variants, data entries.. it might sound funny, but I'm serious - when you can't guess the source of your trouble, then removing the possibilities piece by piece is smart way to approach it.
Unless you'll end up with empty map, haha.
0.964936886395512
Given the fact it works flawless in test mode, it does seem pretty weird.
I could see infinite loop in triggers or infinite recursion in Data causing something like this, where game freezes for a while thus putting you in a state of being not available to Battle.net. Although in such scenario it should unlock after a while - when SC2 detects things went wrong, to put it simple.
But.. if you can't reproduce it offline in test mode, I don't think that's the problem you're running into.
Does the disconnect happen every time? Are you able to quit the game before getting "attempting to reconnect" screen pop up, and have a score screen visible? Does the replay file save after the game?