To my knowledge, this is impossible as this is a local information and there wouldn't be much sense to it to share that info. They don't even share the size of the screen (directly).
The lag that you should estimate to exist in a game should be 4-6 game frames on fastest speed.
I've published a small simple map that measures the lag trigger input will have. It's called "Ping Test". The map measures the time it takes for a "mouse moves over dialog item"-event to be executed in the game. Obviously the time is different for you on each server:
- EU: I have 2-4 game frames delay (130ms real time)
- US: I have 6-7 game frames (300ms real time).
You can measure your own connection with that. Maybe you want to add that into your map, too.
People complaining about lag in an arcade map playing on any other of their home server, if the map is published in their region, are fairly stupid and should be ignored. They can avoid a big portion of the noticeable lag, but they fail to do so, instead they want you to be a magician.
Btw, I loled at "Whiners want Enter Key" trigger name. I took the liberty to crack the map to see if you do weird things in your triggers. :D I think the core problem is the clearing the text in the edit box because that currently overrides the input made shortly after space.
I'm not sure if that can be improved, though. I'm not using text fields in my maps, so I don't know.
edit:
In theory, you would require an action for the text field to just remove the first # chars of the current value instead of overriding its whole content. But there is no such feature, afaIk.
Solution approaches I would try to look into:
- Are there events for the input after the space after clearing the text that you throw away? I assume yes, but you throw them away. You might be able to add the inputted chars after the space to a label in front of the text box. Players wouldn't be able to edit their whole word anymore, but the input would still be there and input wouldn't be thrown away. Maybe there is a way to add the chars to the text field, but I assume that would be really tricky.
- use the button press events for typing instead of a chat box. This only works if the input is in order (or reverse order, so not random to allow you reconstruct the typed in word).
I might test a bit in the next days because this is a fun little problem.
I don't have privileged players. The most I do is add ingame messages (e.g. uploader on NA before global play was added) and name ingame items after them as a special reward for consistent contributions/feedback/etc or for being awesome in the past. But that's about it. Nobody has more powers than anyone else.
But I agree that it can be required if players can just destroy the game for everyone else. If I would have to deal with beggars, I would just ignore them.
Designing a map in a way that you don't need "moderators" would be the general way to go. E.g. Blizzard removed global chat in Hearthstone and Heroes of the Storm as it is usually used to flame people which then leads to reports and more "work" for community managers, etc. But changing aspects of the game is not always possible. I guess it depends on how much your game relies on a social component.
Did Blizzard allow and fix the "speed #" console/chat command with # being a speed factor (1=normal, 1.4=faster)?
It was buggy and failed to speed up the vital addition rate of construction abilities when used on battle.net, I believe. I reported that problem, but I didn't check it in the meantime.
- StarCraft Broodwar. I made horrible campaign maps when I was a small kid, I revisited the editor after downloading campaigns and playing them a few years later. Then I played on battle.net and I got seriously interested in learning it as I've seen that people made defense maps using it. Then my projects became bigger and insane. My last, unfinished project was creating Diablo 1 in SCBW with a real inventory including trade and repair system and original combat formulas. I stopped after I failed to debug the battlefield where you should have been battling with WASD and mouse clicks. Also, I hit the game's trigger limit where save games crashed the game. I had 73k triggers at the end which is the highest amount someone put into a legitimate map so far in SCBW. (Math only using + and - and not even = to copy values... fun fun fun, it makes everything huge... As a personal success, I found out how to divide two variables only using + and -, but I wasn't the first doing that.)
- Followed by SCBW, I started to pick up the SC2 Editor in May 2010.
Other tiny editor experiments, but never doing anything I released:
- C&C Red Alert
- Age of Empires 2
- Empire Earth (its UI feels horrible once you started.)
- Some small, free car racing game where you could build your own tracks and you drove from a top down view. I forgot the name. I should try to find that game again. :( (edit: I found it, it is "gene rally")
- I did a few more free game editor things, but I can't remember them at all anymore.
- I tried to use C&C Generals' editor, but I just didn't understand anything in the editor, so I stopped after failing a few times. I was fairly young when I tried that. :D
ZXCVB are the GRID hotkey settings. GRID will always override the command card's hotkeys and reassign buttons depending on the position of the abilities on the command card.
So, to use QWER, you have to put the abilities in the top row in the first four abilitys. Then GRID will result in QWER.
Btw, it will use the hotkeys you define when you use the standard hotkeys.
Does this still work or is it out of date, because I tried adding a new layout to the UI tab of the editor, but it won't overwrite the original command card and it won't let me change the original file because that would mess up everything on all my maps.
The method to edit UI elements presented here hasn't been changed and is still working.
Overall useful though your dogmatic inclination towards while loops and condemnation of for loops is bothersome and has no legitimate grounds. Hence the name though, I guess...
The initial implementation of loops was horrible. The problem is described here. Blizzard fixed it in some patch making for-loops more efficient. Now I would advise people to use for-loops as they are slightly faster to code than a while.
You can change the command tooltip's position with UI xml.
@glowing button
-> Change the used images (image and hover image).
@Animated image:
Have a look at my example map for that: https://dl.dropboxusercontent.com/u/4479839/CooldownImageDemo.SC2Map
But this requires you to put each animation frame into the same image which can be very annoying, too. It is possible to control the animation manually or just make it automated running as fast as it can (and running during pauses, lags, so the automated one is not useful for game-related data).
Btw, the texture coordinates are percentages of the whole image. 0.0000 to 0.2500 would mean top left up to 25% of the whole image's size.
How about creating a panel/frame behind the minimap, hooking it up and adding your dialog items into that panel instead (low render priority set in that panel, maybe even HDR rendering required)?
Well, you can create dialog items using templates which can also create a second minimap, but that one has a few less features than the original one (e.g. no pings, if I remember it correctly).
It's not possible to add bars that automatically show the value via hidden magic. But the labels are possible as the unitpanel has these labels.
What you can do is to add bars in xml and then hook them to give them logic.
You can open "Temple Siege 2" in the editor in battle.net. I've coded pretty much that into its UI. It is using the original life, shield and energy labels, so these values update instantly when you select a unit and the bars are updated when the selection event fires. So, the bars will lag behind.
The limitation of the labels are that they are forcefully positioned below each other, you just can define where the shield label is (other labels are positioned below it) and if the unit has no shields where the wireframe is (other labels are positioned below it).
Since I've recently dealt with that input stuff again, I should post the collection of my knowledge regarding mouse/button input:
On battle.net, the mouse move event will be fired 15-22 times per player per game loop (most likely not every game loop due to latency changes).
Most likely you would want the last position where the mouse has been, so you are required to save the position of the player's last event ("last event" according to A1win). To do so, you are required to save all input data as checking anything just easily adds a lot more overhead than just saving the values.
To properly use the input data, you should have one thread that processes it for each player in every game loop. Since code in a thread can run up to two times between the game updates, you would want to make sure that the input-using code runs after the new input was thrown in. So, it should run in the second code execution phase and not during the first. To push the execution from the first to the second phase, you need to add a wait of exactly 0.0 game seconds in addition to your normal wait (like 0.0625 game seconds) [yes, you are using 2 waits!].
That's what I'm currently using in my WASD shooter and it seems to run fine. But I didn't test how many players this can support. Since A1win did essentially the same and he told me that his implementation works fine for 8 players, I assume that my approach will run the equally good.
- A: In addition to that, there might be optimization possibilities. Mille25 reported that they are disabling triggers which appears to stop input events from being sent. But I don't know any details or had no chance to test that. In case this is true, it might be possible to enable/disable the bandwith usage for that system when it is not required.
- Btw, I've noticed that JademusSreg toggled the values of the saved button inputs instead of setting values to true/false based on the event. I've tested that and they do not seem to fail at all!
Setting values to true/false has problems when you double-hit a button within one game frame as the input state will be corrupted. It will process "down, down, up" resulting in a saved "no input"-state while the player is in fact holding down the button after that. -> Toggles handle that case properly and should be used.
- B: Another aspect that hasn't been researched, yet, is that if it is better to use one generic event or only the specific buttons for a player.
Also, it is possible to block button presses from being detected by the events, if you are using that button in a toggle in your game's UI. In case every normal button press is creating bandwith usage, you should be able to reduce it using these UI xml toggles.
If we would know the unclear aspects A and B, it might be possible to create the bnet-performance-wise best implementation.
I swear its almost as if you guys are creating a black hole that sucks me into this discussion sometimes.
I seriously cannot even grasp or understand 1% of what you guys are saying. You really think that content creators should have to pay money themselves and receive nothing in return? Am I really reading this correctly?
The problem is that it is exploitable and can potentially cause a lot of work for Blizzard, if uploaders of questionable content cannot be harmed in any way. Since Heroes will be free to play, you cannot ban people from the game. Therefore, they need to find a way to punish players having a bought game that you are banned from instead.
Most people that want to upload maps for Heroes should already own at least 1 of Blizzard games, so the number of effected persons are limited. And if you want access, you just get another game of your choice which is better than only paying for access.
But this discussion is leading far from the contest, so I guess that Heroes' mapmaking should be discussed in its own topic and not here.
Btw, I've forseen the problem with patching maps after the contest's deadline before the contest ended and mentioned it in my reply mail (to quote myself: "I hope you are capable of disabling the updates for that map. If I had not asked, I would have updated it regardless."). But they didn't seem to have understood the hint or reacted at all. Oh well, now I can enjoy and watch how they will attempt to solve that problem.
0
To my knowledge, this is impossible as this is a local information and there wouldn't be much sense to it to share that info. They don't even share the size of the screen (directly).
0
The lag that you should estimate to exist in a game should be 4-6 game frames on fastest speed.
I've published a small simple map that measures the lag trigger input will have. It's called "Ping Test". The map measures the time it takes for a "mouse moves over dialog item"-event to be executed in the game. Obviously the time is different for you on each server:
- EU: I have 2-4 game frames delay (130ms real time)
- US: I have 6-7 game frames (300ms real time).
You can measure your own connection with that. Maybe you want to add that into your map, too.
People complaining about lag in an arcade map playing on any other of their home server, if the map is published in their region, are fairly stupid and should be ignored. They can avoid a big portion of the noticeable lag, but they fail to do so, instead they want you to be a magician.
Btw, I loled at "Whiners want Enter Key" trigger name. I took the liberty to crack the map to see if you do weird things in your triggers. :D
I think the core problem is the clearing the text in the edit box because that currently overrides the input made shortly after space.
I'm not sure if that can be improved, though. I'm not using text fields in my maps, so I don't know.
edit:
In theory, you would require an action for the text field to just remove the first # chars of the current value instead of overriding its whole content. But there is no such feature, afaIk.
Solution approaches I would try to look into:
- Are there events for the input after the space after clearing the text that you throw away? I assume yes, but you throw them away. You might be able to add the inputted chars after the space to a label in front of the text box. Players wouldn't be able to edit their whole word anymore, but the input would still be there and input wouldn't be thrown away. Maybe there is a way to add the chars to the text field, but I assume that would be really tricky.
- use the button press events for typing instead of a chat box. This only works if the input is in order (or reverse order, so not random to allow you reconstruct the typed in word).
I might test a bit in the next days because this is a fun little problem.
0
I don't have privileged players. The most I do is add ingame messages (e.g. uploader on NA before global play was added) and name ingame items after them as a special reward for consistent contributions/feedback/etc or for being awesome in the past. But that's about it. Nobody has more powers than anyone else.
But I agree that it can be required if players can just destroy the game for everyone else. If I would have to deal with beggars, I would just ignore them.
Designing a map in a way that you don't need "moderators" would be the general way to go. E.g. Blizzard removed global chat in Hearthstone and Heroes of the Storm as it is usually used to flame people which then leads to reports and more "work" for community managers, etc. But changing aspects of the game is not always possible. I guess it depends on how much your game relies on a social component.
0
Did Blizzard allow and fix the "speed #" console/chat command with # being a speed factor (1=normal, 1.4=faster)?
It was buggy and failed to speed up the vital addition rate of construction abilities when used on battle.net, I believe. I reported that problem, but I didn't check it in the meantime.
0
- StarCraft Broodwar. I made horrible campaign maps when I was a small kid, I revisited the editor after downloading campaigns and playing them a few years later. Then I played on battle.net and I got seriously interested in learning it as I've seen that people made defense maps using it. Then my projects became bigger and insane. My last, unfinished project was creating Diablo 1 in SCBW with a real inventory including trade and repair system and original combat formulas. I stopped after I failed to debug the battlefield where you should have been battling with WASD and mouse clicks. Also, I hit the game's trigger limit where save games crashed the game. I had 73k triggers at the end which is the highest amount someone put into a legitimate map so far in SCBW. (Math only using + and - and not even = to copy values... fun fun fun, it makes everything huge... As a personal success, I found out how to divide two variables only using + and -, but I wasn't the first doing that.)
- Followed by SCBW, I started to pick up the SC2 Editor in May 2010.
Other tiny editor experiments, but never doing anything I released:
- C&C Red Alert
- Age of Empires 2
- Empire Earth (its UI feels horrible once you started.)
- Some small, free car racing game where you could build your own tracks and you drove from a top down view. I forgot the name. I should try to find that game again. :( (edit: I found it, it is "gene rally")
- I did a few more free game editor things, but I can't remember them at all anymore.
- I tried to use C&C Generals' editor, but I just didn't understand anything in the editor, so I stopped after failing a few times. I was fairly young when I tried that. :D
0
ZXCVB are the GRID hotkey settings. GRID will always override the command card's hotkeys and reassign buttons depending on the position of the abilities on the command card.
So, to use QWER, you have to put the abilities in the top row in the first four abilitys. Then GRID will result in QWER.
Btw, it will use the hotkeys you define when you use the standard hotkeys.
0
The method to edit UI elements presented here hasn't been changed and is still working.
0
"No Death Event" Unit flag?
0
The initial implementation of loops was horrible. The problem is described here. Blizzard fixed it in some patch making for-loops more efficient. Now I would advise people to use for-loops as they are slightly faster to code than a while.
0
Interesting find. :D
Btw, to allows us to compile the code, we need to change this line
edit: yay, the BBCode tag handling is broken...
0
You can change the command tooltip's position with UI xml.
@glowing button
-> Change the used images (image and hover image).
@Animated image:
Have a look at my example map for that:
https://dl.dropboxusercontent.com/u/4479839/CooldownImageDemo.SC2Map
But this requires you to put each animation frame into the same image which can be very annoying, too. It is possible to control the animation manually or just make it automated running as fast as it can (and running during pauses, lags, so the automated one is not useful for game-related data).
Btw, the texture coordinates are percentages of the whole image. 0.0000 to 0.2500 would mean top left up to 25% of the whole image's size.
0
How about creating a panel/frame behind the minimap, hooking it up and adding your dialog items into that panel instead (low render priority set in that panel, maybe even HDR rendering required)?
Well, you can create dialog items using templates which can also create a second minimap, but that one has a few less features than the original one (e.g. no pings, if I remember it correctly).
0
The answer is what you said... kind of.
It's not possible to add bars that automatically show the value via hidden magic. But the labels are possible as the unitpanel has these labels.
What you can do is to add bars in xml and then hook them to give them logic.
You can open "Temple Siege 2" in the editor in battle.net. I've coded pretty much that into its UI. It is using the original life, shield and energy labels, so these values update instantly when you select a unit and the bars are updated when the selection event fires. So, the bars will lag behind.
The limitation of the labels are that they are forcefully positioned below each other, you just can define where the shield label is (other labels are positioned below it) and if the unit has no shields where the wireframe is (other labels are positioned below it).
0
Since I've recently dealt with that input stuff again, I should post the collection of my knowledge regarding mouse/button input:
On battle.net, the mouse move event will be fired 15-22 times per player per game loop (most likely not every game loop due to latency changes).
Most likely you would want the last position where the mouse has been, so you are required to save the position of the player's last event ("last event" according to A1win). To do so, you are required to save all input data as checking anything just easily adds a lot more overhead than just saving the values.
To properly use the input data, you should have one thread that processes it for each player in every game loop. Since code in a thread can run up to two times between the game updates, you would want to make sure that the input-using code runs after the new input was thrown in. So, it should run in the second code execution phase and not during the first. To push the execution from the first to the second phase, you need to add a wait of exactly 0.0 game seconds in addition to your normal wait (like 0.0625 game seconds) [yes, you are using 2 waits!].
That's what I'm currently using in my WASD shooter and it seems to run fine. But I didn't test how many players this can support. Since A1win did essentially the same and he told me that his implementation works fine for 8 players, I assume that my approach will run the equally good.
- A: In addition to that, there might be optimization possibilities. Mille25 reported that they are disabling triggers which appears to stop input events from being sent. But I don't know any details or had no chance to test that. In case this is true, it might be possible to enable/disable the bandwith usage for that system when it is not required.
- Btw, I've noticed that JademusSreg toggled the values of the saved button inputs instead of setting values to true/false based on the event. I've tested that and they do not seem to fail at all!
Setting values to true/false has problems when you double-hit a button within one game frame as the input state will be corrupted. It will process "down, down, up" resulting in a saved "no input"-state while the player is in fact holding down the button after that. -> Toggles handle that case properly and should be used.
- B: Another aspect that hasn't been researched, yet, is that if it is better to use one generic event or only the specific buttons for a player.
Also, it is possible to block button presses from being detected by the events, if you are using that button in a toggle in your game's UI. In case every normal button press is creating bandwith usage, you should be able to reduce it using these UI xml toggles.
If we would know the unclear aspects A and B, it might be possible to create the bnet-performance-wise best implementation.
0
The problem is that it is exploitable and can potentially cause a lot of work for Blizzard, if uploaders of questionable content cannot be harmed in any way. Since Heroes will be free to play, you cannot ban people from the game. Therefore, they need to find a way to punish players having a bought game that you are banned from instead.
Most people that want to upload maps for Heroes should already own at least 1 of Blizzard games, so the number of effected persons are limited. And if you want access, you just get another game of your choice which is better than only paying for access.
But this discussion is leading far from the contest, so I guess that Heroes' mapmaking should be discussed in its own topic and not here.
Btw, I've forseen the problem with patching maps after the contest's deadline before the contest ended and mentioned it in my reply mail (to quote myself: "I hope you are capable of disabling the updates for that map. If I had not asked, I would have updated it regardless."). But they didn't seem to have understood the hint or reacted at all. Oh well, now I can enjoy and watch how they will attempt to solve that problem.