Please keep it constructive guys. This is a very big engine update and issues are unfortunately to be expected. However, if you really want stuff to get fixed, try to describe your issues as detailed as possible so Blizzard can investigate further.
Also, this thread is primarily meant to be in the format issue -> solution and not for pure bug reports or rants.
The UI-Editor was very unstable and unreliable for me, too. Pretty much not possible to work with it right now. Must save as components and work in the raw UI XML. :(
Its not just the fact that it crashes, it also messes up the XML "behind the scenes", so what you enter into the UI-Editor is not neccesarily what the actual game loads later. (Even if the code is correct!) The new UI-Animation system for example doesnt seem to be supported by the UI-Editor at all, and completely trashes the XML. However, when testing raw XML input within the game, it works perfectly.
with Patch 3.0 for SC2 just around the corner, and it being one of the biggest patches for the game in its recent history, I thought it would be a good idea to have a thread where all pitfalls of the new update get collected and solutions figured out.
Maybe we can use a simple format such as:
New pitfall: ... Solution: ...
As such, I will start with the first issues and solutions I found with the new update:
New pitfall: All "Text Tags" are gone/invisible, but there are no trigger errors observed Solution: In this case, you probably have the default game ui hidden. Simply show the "Text Tags" UI frame to get your text tags back!
New pitfall: "Set Playable Map Area" not behaving correctly Solution: In the new update, one can no longer "Set Playable Map Area" to a region with bounds larger than 1-255 in the x- or y-axis. The function simply throws an error in this case, not having any effect. Make sure that every region you are using is fitting within the new bounds.
New pitfall: The game is displaying all sorts of errors that I never saw before! Solution: It seems like Blizzard has added new warnings and error messages to the game engine. This new messages are a good thing because they can help you to find errors. Make sure to pay close attention to new errors and try to fix them properly.
New pitfall: There seems to be an issue with compiling script that contains actions or functions with the "native" flag checked plus having a custom script identifier, pointing to a custom function. Solution: Instead of using a custom script identifier and the native flag, use the new "inline" flag to achieve the same.
New pitfall: The "Extra Data" feature allows editing multiple files (documents) at once. However, there seem to be some issues with script containing text values. The editor is not creating the proper entry within the GameStrings.txt file when changing text via Extra Data, so in game the text will show up as "PARAM/Value/...". Additionally, when opening the changed document the traditional way, the newly inserted text values get erased. Solution: Be careful with the "Extra Data" feature until all bugs have been fixed. :(
You could also contruct a different shape by creating multiple buttons, but setting the opacity for all but one to 0.
The one visible button gets the desired image. (Or you can even use a seperate dialog item for this).
Then you can run the same trigger for all of them.
You may also try to clean your battle.net cache. There might be some corrupted files preventing the download to continue properly. You should be able to find various tutorials online about how to do this.
Maybe you are right and I'm underestimating the average person. I guess I've just seen so many dumb things over the years that my expectations got lower and lower over time. That said, I still dont really agree with your logic.
I dont think anyone would "blame himself" if the client bank gets corrupted or destroyed. From my experience only IT-Experts really do backups, as they are the only people who really understand that Soft- and Hardware can sometimes fail. People always search mistakes elsewhere if they can. Do you really want to tell a customer who just lost all his progress because your software failed "Well... its your fault as you didnt do backups"? Hell... I dont. :D
The size limit of bank files got increased in a patch and, in fact, preloading banks of maximum size will not even work as the players time out far before finishing it. So the true limitation here is the battle.net timeout which will remove players who load for a too long time, not the actual size. When splitting the bank into multiple files (i.e. one per character), all banks still need to get preloaded as otherwise their information wont be available when choosing a certain character. Thus, splitting banks into multiple files will not increase the maximum amount of information you can effectively store, as it tackles the problem from the wrong side, so to say.
I agree that a custom SQL Database would be the 'wet dream' scenario, maybe Blizzard will surprise us with something cool for LotV! :)
One major argument in favour of server side banks is the fact that players would be able to keep their progress even when switching computers. All battle.net progress is linked to the battle.net account, however, currently bank files are an exception to that rule, causing confusion and anger.
Especially games like RPGs, which are really dependent on progress logging mechanisms, suffer from this problem. Players can get pretty pissed losing characters they worked on for weeks. And now try to explain a non technical person how to transfer his/her bank file to the new computer... Its a nightmare. I know because I already had to do this.
Quote:
Total loss of progress due to a map error.
The same would happen with client side banks, as most people do not keep backups and are not even aware how exactly their progress gets saved.
Quote:
Total loss of progress due to BattleNet error (not logging the change since obviously something server related would have to be used).
I dont really think this is a strong argument agains server side storage, as the same would apply to pretty much everything that battle.net stores in databases (Ladder Rank etc.)
Quote:
Inability to play map at all due to bank entering invalid state.
Again, same for client side banks. Most people wouldnt even know how to delete an existing bank.
Quote:
Inability to start multiple chains of progress (many characters).
Invalid, as this is strictly a problem of the chosen data structure. Each character could get its own bank section, mutliple banks are not necessarily required and there is always a way around them.
There must be a way to wipe a server side bank, however, I dont really think its an issue that it can no longer be performed "manually". I think 99% of all players dont know how to approach that anyways. I also think server side banks require their own, seperate API, so the modder can decide which technology he wants to use (Maybe even mix both).
This is mess up Zolden I have to see this sht. here and my little girls call my attention to explain wtf is this. You think you can put it as a link or just take it off. This is just not right.
The commonly used solution for this problem is the usage of the "panel" dialog item type. It behaves pretty much like a dialog. By using panels you can simulate dialogs by creating a global dialog in fullscreen mode, and then adding panels to it, containing all the dialog items. By creating the dialog items in a panel (by using the seperate function) you are able to, for example, hide all of them at once by just hiding the panel.
That said, if I was you, I would probably stay with dialogs, because:
- Even though the number of dialog items is theoretically limited, you will 100% not run into problems with it. I know that for a fact because I'm working on a project with a ridiculous number of dialogs and had no issues whatsoever.
- There are no performance problems from using Dialog Arrays for the players, the only disadvantage is slightly higher initialization time and higher memory usage, both doesnt really matter as it is minimal compared to other stuff going on. Memory usage doesnt matter either as there is far more available than you will ever need.
- It saves yourself the work and hassle to convert your existing systems. Judging from your posts, you dont seem to be a very advanced scripter either, so I think sticking to dialogs will be easier to understand.
Also, you dont need to "duplicate" anything really, you can just use loops to initialize a dialog for every player. If you are still at the beginning of your project and the total dialog count is low it may be a valueable option to convert them to panels, I wouldnt spend too much time converting existing systems though as the benefit will be very small.
No need to use banks for this. Create a global variable of type unit. Everytime the player highlights a unit, set the global variable to the triggering unit. Once he unhighlights the unit, set the variable to "No Unit".
If the map is designed for multiplayer you can make the variable an array and use triggering player as array index when setting or reading it.
It is. Everytime a unit is highlighted, store it as currently highlighted unit for the triggering player. When a player presses the right mouse button down, run your actions with the stored unit for that player.
0
Please keep it constructive guys. This is a very big engine update and issues are unfortunately to be expected. However, if you really want stuff to get fixed, try to describe your issues as detailed as possible so Blizzard can investigate further.
Also, this thread is primarily meant to be in the format issue -> solution and not for pure bug reports or rants.
0
@FunkyUserName: Go
The UI-Editor was very unstable and unreliable for me, too. Pretty much not possible to work with it right now. Must save as components and work in the raw UI XML. :(
Its not just the fact that it crashes, it also messes up the XML "behind the scenes", so what you enter into the UI-Editor is not neccesarily what the actual game loads later. (Even if the code is correct!) The new UI-Animation system for example doesnt seem to be supported by the UI-Editor at all, and completely trashes the XML. However, when testing raw XML input within the game, it works perfectly.
0
Hey guys,
with Patch 3.0 for SC2 just around the corner, and it being one of the biggest patches for the game in its recent history, I thought it would be a good idea to have a thread where all pitfalls of the new update get collected and solutions figured out.
Maybe we can use a simple format such as:
New pitfall: ...
Solution: ...
As such, I will start with the first issues and solutions I found with the new update:
New pitfall: All "Text Tags" are gone/invisible, but there are no trigger errors observed
Solution: In this case, you probably have the default game ui hidden. Simply show the "Text Tags" UI frame to get your text tags back!
New pitfall: "Set Playable Map Area" not behaving correctly
Solution: In the new update, one can no longer "Set Playable Map Area" to a region with bounds larger than 1-255 in the x- or y-axis. The function simply throws an error in this case, not having any effect. Make sure that every region you are using is fitting within the new bounds.
New pitfall: The game is displaying all sorts of errors that I never saw before!
Solution: It seems like Blizzard has added new warnings and error messages to the game engine. This new messages are a good thing because they can help you to find errors. Make sure to pay close attention to new errors and try to fix them properly.
New pitfall: There seems to be an issue with compiling script that contains actions or functions with the "native" flag checked plus having a custom script identifier, pointing to a custom function.
Solution: Instead of using a custom script identifier and the native flag, use the new "inline" flag to achieve the same.
New pitfall: The "Extra Data" feature allows editing multiple files (documents) at once. However, there seem to be some issues with script containing text values. The editor is not creating the proper entry within the GameStrings.txt file when changing text via Extra Data, so in game the text will show up as "PARAM/Value/...". Additionally, when opening the changed document the traditional way, the newly inserted text values get erased.
Solution: Be careful with the "Extra Data" feature until all bugs have been fixed. :(
0
You could also contruct a different shape by creating multiple buttons, but setting the opacity for all but one to 0.
The one visible button gets the desired image. (Or you can even use a seperate dialog item for this).
Then you can run the same trigger for all of them.
0
You may also try to clean your battle.net cache. There might be some corrupted files preventing the download to continue properly. You should be able to find various tutorials online about how to do this.
0
Just some food for thought:
RTS and MOBA games often use unsharp ground textures on purpose, so the important units stand out more from the terrain.
0
@ImperialGood: Go
Maybe you are right and I'm underestimating the average person. I guess I've just seen so many dumb things over the years that my expectations got lower and lower over time. That said, I still dont really agree with your logic.
I dont think anyone would "blame himself" if the client bank gets corrupted or destroyed. From my experience only IT-Experts really do backups, as they are the only people who really understand that Soft- and Hardware can sometimes fail. People always search mistakes elsewhere if they can. Do you really want to tell a customer who just lost all his progress because your software failed "Well... its your fault as you didnt do backups"? Hell... I dont. :D
The size limit of bank files got increased in a patch and, in fact, preloading banks of maximum size will not even work as the players time out far before finishing it. So the true limitation here is the battle.net timeout which will remove players who load for a too long time, not the actual size. When splitting the bank into multiple files (i.e. one per character), all banks still need to get preloaded as otherwise their information wont be available when choosing a certain character. Thus, splitting banks into multiple files will not increase the maximum amount of information you can effectively store, as it tackles the problem from the wrong side, so to say.
I agree that a custom SQL Database would be the 'wet dream' scenario, maybe Blizzard will surprise us with something cool for LotV! :)
0
One major argument in favour of server side banks is the fact that players would be able to keep their progress even when switching computers. All battle.net progress is linked to the battle.net account, however, currently bank files are an exception to that rule, causing confusion and anger.
Especially games like RPGs, which are really dependent on progress logging mechanisms, suffer from this problem. Players can get pretty pissed losing characters they worked on for weeks. And now try to explain a non technical person how to transfer his/her bank file to the new computer... Its a nightmare. I know because I already had to do this.
The same would happen with client side banks, as most people do not keep backups and are not even aware how exactly their progress gets saved.
I dont really think this is a strong argument agains server side storage, as the same would apply to pretty much everything that battle.net stores in databases (Ladder Rank etc.)
Again, same for client side banks. Most people wouldnt even know how to delete an existing bank.
Invalid, as this is strictly a problem of the chosen data structure. Each character could get its own bank section, mutliple banks are not necessarily required and there is always a way around them.
There must be a way to wipe a server side bank, however, I dont really think its an issue that it can no longer be performed "manually". I think 99% of all players dont know how to approach that anyways. I also think server side banks require their own, seperate API, so the modder can decide which technology he wants to use (Maybe even mix both).
0
7/10.
0
The commonly used solution for this problem is the usage of the "panel" dialog item type. It behaves pretty much like a dialog. By using panels you can simulate dialogs by creating a global dialog in fullscreen mode, and then adding panels to it, containing all the dialog items. By creating the dialog items in a panel (by using the seperate function) you are able to, for example, hide all of them at once by just hiding the panel.
That said, if I was you, I would probably stay with dialogs, because:
- Even though the number of dialog items is theoretically limited, you will 100% not run into problems with it. I know that for a fact because I'm working on a project with a ridiculous number of dialogs and had no issues whatsoever.
- There are no performance problems from using Dialog Arrays for the players, the only disadvantage is slightly higher initialization time and higher memory usage, both doesnt really matter as it is minimal compared to other stuff going on. Memory usage doesnt matter either as there is far more available than you will ever need.
- It saves yourself the work and hassle to convert your existing systems. Judging from your posts, you dont seem to be a very advanced scripter either, so I think sticking to dialogs will be easier to understand.
Also, you dont need to "duplicate" anything really, you can just use loops to initialize a dialog for every player. If you are still at the beginning of your project and the total dialog count is low it may be a valueable option to convert them to panels, I wouldnt spend too much time converting existing systems though as the benefit will be very small.
0
@Risquetal: Go
Correct. Just make sure that the array has enough elements for all possible triggering player values.
0
@Risquetal: Go
No need to use banks for this. Create a global variable of type unit. Everytime the player highlights a unit, set the global variable to the triggering unit. Once he unhighlights the unit, set the variable to "No Unit".
If the map is designed for multiplayer you can make the variable an array and use triggering player as array index when setting or reading it.
0
Won't work, as right click does not select units. Also the player might have multiple units selected.
0
Not sure what you are trying to do, but can't you just save the file as sc2components and work directly with the contents?
0
It is. Everytime a unit is highlighted, store it as currently highlighted unit for the triggering player. When a player presses the right mouse button down, run your actions with the stored unit for that player.