Staredit Network > Forums > SC1 UMS Theory and Ideas > Topic: SC1 map making wishlist
SC1 map making wishlist
Mar 30 2016, 6:17 pm
By: Clokr_  

Apr 2 2016, 5:12 pm jjf28 Post #21

Cartography Artisan

Modern Hyper Triggers tho



Rs_yes-im4real - Clan Aura - jjf28.net84.net

Reached the top of StarCraft theory crafting 2:12 AM CST, August 2nd, 2014.

Apr 2 2016, 5:42 pm Clokr_ Post #22



Quote from zsnakezz
[Default Hyper Triggers] - Adds correct number of hyper trigger copies to all usable players.

By hyper triggers I mean making SC checking the triggers more often, not including them by default.



Heh neat. Still changing the code so that SC would check triggers more often has some advantages. For example waits wouldn't interfere with them.



?????

Apr 2 2016, 5:44 pm BloodyZombie117 Post #23

I have no idea what to put here... So I guess I'll just put this here.

I guess one additional thing I'd like to see is for them to implement a variable system. That way we don't have to use Death counts and we could have tons of them too. That'd be pretty nifty.




Apr 2 2016, 8:02 pm Roy Post #24

An artist's depiction of an Extended Unit Death

Quote from Clokr_
Quote from zsnakezz
[Default Hyper Triggers] - Adds correct number of hyper trigger copies to all usable players.

By hyper triggers I mean making SC checking the triggers more often, not including them by default.
This would single-handedly destroy what remains of the UMS scene, as it would break so many maps. Snake's suggestion could be included in any third-party editor right now, without Blizzard needing to do anything.

Quote from Clokr_
Still changing the code so that SC would check triggers more often has some advantages. For example waits wouldn't interfere with them.
Wouldn't it be better to make waits non-blocking instead?

Quote from BloodyZombie117
I guess one additional thing I'd like to see is for them to implement a variable system. That way we don't have to use Death counts and we could have tons of them too. That'd be pretty nifty.
Variables and arrays were introduced in Warcraft III. Like I said, if they want to make the mapmaking tools better, they're most likely to just copy/paste the tools they have already.

Let's not forget that Blizzard's current tool for SC is staredit.exe. I doubt they'd even bring all the existing functionality we have from third-party editors into a new tool that they develop.




Apr 2 2016, 8:08 pm Clokr_ Post #25



Quote from Roy
Quote from Clokr_
Quote from zsnakezz
[Default Hyper Triggers] - Adds correct number of hyper trigger copies to all usable players.

By hyper triggers I mean making SC checking the triggers more often, not including them by default.
This would single-handedly destroy what remains of the UMS scene, as it would break so many maps. Snake's suggestion could be included in any third-party editor right now, without Blizzard needing to do anything.

Quote from Clokr_
Still changing the code so that SC would check triggers more often has some advantages. For example waits wouldn't interfere with them.
Wouldn't it be better to make waits non-blocking instead?

Again they don't have to be that way by default. They could add a flag somewhere so that you can choose whether you want your triggers to be hyper or not. Or, more simply, a trigger action that lets you choose how often triggers should be checked (every 1.5 sec, every 0.5 sec, etc.).

Making waits non-blocking can be tricky, because you have to stored all the ongoing wait counters somewhere and SC doesn't use dynamic memory. You could have a finite number of non-blocking waits which could be like 100 per player, but that would probably require more recoding (although not much more). Again it could break existing maps, so I'm going to go for a non-blocking wait action.



?????

Apr 2 2016, 8:21 pm Roy Post #26

An artist's depiction of an Extended Unit Death

Quote from Clokr_
Again they don't have to be that way by default. They could add a flag somewhere so that you can choose whether you want your triggers to be hyper or not. Or, more simply, a trigger action that lets you choose how often triggers should be checked (every 1.5 sec, every 0.5 sec, etc.).
Again, this could be done through a third-party editor. Blizzard doesn't need to do anything. You could silently add/remove the hyper trigger with a checkbox instead of showing the trigger in the UI in an editor.

Quote from Clokr_
Making waits non-blocking can be tricky, because you have to stored all the ongoing wait counters somewhere and SC doesn't use dynamic memory. You could have a finite number of non-blocking waits which could be like 100 per player, but that would probably require more recoding (although not much more). Again it could break existing maps, so I'm going to go for a non-blocking wait action.
Asynchronous processing already happens for triggers: wait blocks are on a per-player basis because that's the way they were decided to work. Any changes are going to require recoding, so I'm not sure what point you're making here.

Wait blocks are an unintuitive mapmaking quirk that is the source of many of the bugs reported on these forums. Granted, without them, traditional hyper triggers wouldn't work, so you're right that it would break many maps.




Apr 2 2016, 10:08 pm Clokr_ Post #27



I have modified the first post, adding most of the suggestions and explaining them a bit more. Anyone can suggest a feature to be modified/removed.

I don't think Blizzard will care about this either, or if they do they will just get 2 or 3 simple ones done and leave it at that. Still, if we don't give them any suggestions then we know for sure what is going to happen.

Quote from Roy
Again, this could be done through a third-party editor. Blizzard doesn't need to do anything. You could silently add/remove the hyper trigger with a checkbox instead of showing the trigger in the UI in an editor.
Alright, removed hyper triggers from the list. They are not necessary as a hardcoded feature if non-blocking waits are available, but they are a more elegant solution than having a trigger in every map to produce that effect.

Quote from Roy
Asynchronous processing already happens for triggers: wait blocks are on a per-player basis because that's the way they were decided to work. Any changes are going to require recoding, so I'm not sure what point you're making here.

Wait blocks are an unintuitive mapmaking quirk that is the source of many of the bugs reported on these forums. Granted, without them, traditional hyper triggers wouldn't work, so you're right that it would break many maps.
I was talking about how expensive would be time-wise for the developer to modify each thing. Modifying how often triggers get executed is as simple as modifying one constant. Adding a trigger action which modifies how often triggers get executed is as simple as adding a global variable, subtituting the constant by the global variable and adding a line in a switch statement to set the new global variable. To have non-blocking waits you need to increase the number of waiting counters per player and edit any piece of code that uses them. The option I have listed (adding a new non-blocking wait action) does not require editing any piece of code working with the old counters, but still requires writing code to update the counters properly and resume trigger execution. But you are right any of this options require some amount of recoding, and this one in particular is not that bad.

I want to ask you what setting the game 'latency' does. It makes it wait a longer amount of time between frames?



?????

Apr 3 2016, 4:08 am zsnakezz Post #28



Quote from Roy
Quote from Clokr_
Quote from zsnakezz
[Default Hyper Triggers] - Adds correct number of hyper trigger copies to all usable players.

By hyper triggers I mean making SC checking the triggers more often, not including them by default.
Snake's suggestion could be included in any third-party editor right now, without Blizzard needing to do anything.

It appears I should read the contents within threads before posting in them.



I made the following maps; Hyperion 2, The Undead, The Undead Coop, Realm Rpg beta, and Overlords. Follow me on twitch at https://www.twitch.tv/zsnakezz

Apr 3 2016, 5:16 am Roy Post #29

An artist's depiction of an Extended Unit Death

Quote from Clokr_
I want to ask you what setting the game 'latency' does. It makes it wait a longer amount of time between frames?
Not sure if this is what you're asking, but a brief background: game latency is a multiplayer setting that affects the time between when you issue an order to a unit and when the unit acts upon that order. Low latency means the unit acts in a short amount of time, and high latency means it takes a while before the unit responds to your command. You can set the game latency between "Low", "High", and "Extra High" in the game options (Options -> Network -> Latency). Setting the game to a higher latency sometimes reduces lag in the event one player's internet connection is too slow to send and receive game network traffic in a timely manner.

In regards to EUDs, we can detect what the latency is set to, and we can set the latency if EUDAs are enabled. Latency technically is implemented on a local level, so players can have different latencies (in fact, there's a latency hack that allows the player to set their latency to an "Extra Low" setting that makes the game about as responsive as a LAN-hosted game). Locking the game at a certain latency can prevent cheesing, and being able to read latency allows us to detect if someone may be cheating.




Apr 3 2016, 9:05 am Clokr_ Post #30



Quote from Roy
Not sure if this is what you're asking, but a brief background: game latency is a multiplayer setting that affects the time between when you issue an order to a unit and when the unit acts upon that order. Low latency means the unit acts in a short amount of time, and high latency means it takes a while before the unit responds to your command. You can set the game latency between "Low", "High", and "Extra High" in the game options (Options -> Network -> Latency). Setting the game to a higher latency sometimes reduces lag in the event one player's internet connection is too slow to send and receive game network traffic in a timely manner.

In regards to EUDs, we can detect what the latency is set to, and we can set the latency if EUDAs are enabled. Latency technically is implemented on a local level, so players can have different latencies (in fact, there's a latency hack that allows the player to set their latency to an "Extra Low" setting that makes the game about as responsive as a LAN-hosted game). Locking the game at a certain latency can prevent cheesing, and being able to read latency allows us to detect if someone may be cheating.

I see, so I suppose that when you issue an order what SC does is choosing a fordward frame for it to be executed (for example +20 frames from the current frame) and then tries to get all the players to acknowledge they have received the order before that frame comes to avoid the game desyncing. That's pretty clever. I never knew how latency worked.



?????

Apr 9 2016, 9:37 am Clokr_ Post #31



Blizzard has decided that the bnet forums should be split between world regions and users should only be able to post on the forums associated to their region. Sadly Blizzard interns only lurk the american section of the forums, and I'm locked out. Can someone from the US (probably Canada would also work) post here these suggestions?

EDIT: Already done (see next post).


Quote
Staredit Network (www.staredit.net) has been a world-wide reference for novice and expert StarCraft map makers since 2003. Now that we are aware that Blizzard is fixing and tweaking their old games we thought it was the perfect opportunity to do some small improvements to the game with the objective of reviving the Use Map Settings scene, while leaving the ordinary melee gameplay unchanged. We provide below a list of suggestions that we have compiled on the site forums. While we are aware that some of them require extensive recoding, others could be implemented by adding a couple of code lines (specially the ones regarding new trigger actions). Special care has been taken to make them retrocompatible with old maps, so that they are still playable after any new patch.

  • Increase the existing limits of in-game units, sprites, doodads, etc.
  • More than two heights of terrain and more doodads, including wider ramps.
  • More complex unit/weapon/upgrade settings, such as unit walking speed, ammount of supply it provides, permanent cloaking, weapon attack range, ammount of defense provided by each upgrade, etc.
  • Being able to modify the orders available for a specific unit, such as if it can move or attack or in case of factories/workers the units/buildings they can build.
  • Include the following extra trigger conditions/actions:
    • Non-blocking waits: each time a wait trigger action is executed for one player any other trigger for the same player trying to execute a wait action gets put on hold until the first wait ends. A non-blocking wait action would be able to run even if there is already some wait in action.
    • Variables: at the moment StarCraft only support boolean variables named switches. Some integer counters (such as death counters for unused units) are often used as integer variables, but their avalability strongly depends on the map, and doing simple arithmetic with them is extremely difficult. Trigger conditions/actions are needed to store/compare integer values and perform simple arithmetical operations with them.
    • Unit identifiers: several techniques exist to keep track of a single unit in a custom map and make trigger actions operate upon it, but all of them are very limited. A trigger action is needed to assign a specific unit identifier to a particular unit and then have the option in the remaining trigger actions to target it.
    • Unit stats: unit stats such as HP, energy and shields at the moment cannot be read and can only be set to a certain percentage. We would like to have trigger conditions and actions to check their values (equal, less than, more than) and to set them (to a fixed value or increase/decrease them a fixed ammount). Other stats such as ensnare, parasite, defense matrix, etc. cannot be checked or set in any form, and should also have corresponding trigger conditions/actions.

      Other unit stats worth being modifiable by triggers: unit color, unit facing direction, unit build queue (factories), building being built (workers), unit weapon cooldown, unit target (in case it is attacking something or moving towards something), unit kill count, unit current speed.
    • Unit/weapon/upgrade/technology properties: a lot of attributes (such as unit max HP, cost, weapon damage, upgrade building time, etc.) can be modified on the map editor but remain fixed for the rest of the game. Trigger conditions/actions are needed to retrieve this information and modify it dynamically. This also includes the extended unit settings/possible orders included in the above suggestions.
    • Player stats: a lot of attributes (such as which units the player can build, how many upgrades the player currently has, the force the player is in, etc.) can be modified on the map editor but remain fixed for the rest of the game. Trigger conditions/actions are needed to retrieve this information and modify it dynamically.

      Other player stats would include the current player selection or the remaining game pauses the player still has.
    • Moving locations: actually locations can only be moved on top of a unit in another location. A trigger action is needed to move a location to a particular set of fixed coordinates. If variables are implemented, a trigger action will also be needed to save to a variable the position coordinates of a certain unit in a certain location.
    • Orders: the order trigger action should be expanded to include other orders such as 'non-move', 'patrol', 'attack specific target', 'build unit' (factory buildings) or 'build building' (workers) or 'cast spell' (spell-casting units).
    • Text commands: a trigger condition is needed which parses the text when a new message is sent by a certain player to interpret basic commands.
    • Game data: trigger conditions/actions to check and modify the current game speed and the networking latency settings (even outside the range allowed by the game options menu), the force names, the map title, and the minimap color state (allies vs foes, or player color), and a trigger condition to check whether the map is being played in single player or in battle.net. These would provide a much better ambientation for the player.


Post has been edited 2 time(s), last time on Apr 9 2016, 5:11 pm by Clokr_.



?????

Apr 9 2016, 5:06 pm Pr0nogo Post #32



Done.




Apr 9 2016, 5:10 pm Clokr_ Post #33



Thank you Pr0nogo!

I will edit my previous post in case anyone gets confused.

EDIT: Pr0nogo's topic was closed because site advertising is forbidden (my fault). Also it turns out I only had to wait until the Bnet servers refreshed to be able to post on the US forums. So I have created a new thread, that will hopefully last.

Post has been edited 2 time(s), last time on Apr 9 2016, 9:12 pm by Clokr_.



?????

Apr 26 2016, 9:06 am Heinermann Post #34

SDE, BWAPI owner, hacker.

Quote from Clokr_
Quote from Oh_Man
Is there really no way to contact a dev directly? You have to go through support??

Not that I know of. You can either get through support or post it on Bnet forums where some Blizzard intern will probably take a peek at it but there's no guarantee they'll forward it to the dev team.
Are interns not actually part of dev teams at Blizzard?

Personally, I would love to see a toggleable(ALT+Enter), resizable windowed mode. This will eliminate about 800-1000 lines of code(including whitespace/comments, sorry), quite a few hooks, and a couple of tracked issues from BWAPI, making it easier for me to maintain. =)

That's really it.




Apr 27 2016, 9:35 am Clokr_ Post #35



Quote from Heinermann
Are interns not actually part of dev teams at Blizzard?
I guess they are. What I meant is that you cannot contact a specific dev team directly. You can only hope someone from that dev team will take a look at your topic or someone from another dev team will do and contact the right team.

Quote from Heinermann
Personally, I would love to see a toggleable(ALT+Enter), resizable windowed mode. This will eliminate about 800-1000 lines of code(including whitespace/comments, sorry), quite a few hooks, and a couple of tracked issues from BWAPI, making it easier for me to maintain. =)

That's really it.
1000 lines? ;o I thought that would be simpler, like install the hook, listen for keyboard presses, change window mode.



?????

Apr 30 2016, 9:33 am DevliN Post #36

OVERWATCH STATUS GO

Bumped the thread on the Battle.net forum. I think this is an important thing to get across if they really are doing more than just making an HD version or integrating it into current Bnet.

EDIT:
I recommend liking the top post in that thread, too.

Post has been edited 1 time(s), last time on Apr 30 2016, 10:20 am by DevliN.



\:devlin\: Currently Working On: \:devlin\:
My Overwatch addiction.

Apr 30 2016, 10:49 am Lanthanide Post #37



I doubt they're going to make any improvements to the game engine at all.

But something that should be pretty easy for them to do, and would make a pretty big impact for mappers, is allow the kill count of units to be set. Then we wouldn't need all those crude 'kills to cash' systems.



None.

May 4 2016, 8:27 pm ClansAreForGays Post #38



Quote from Pr0nogo
broken link




May 4 2016, 8:45 pm jjf28 Post #39

Cartography Artisan

Quote from ClansAreForGays
Quote from Pr0nogo
broken link

see

Quote from Clokr_
Thank you Pr0nogo!

I will edit my previous post in case anyone gets confused.

EDIT: Pr0nogo's topic was closed because site advertising is forbidden (my fault). Also it turns out I only had to wait until the Bnet servers refreshed to be able to post on the US forums. So I have created a new thread, that will hopefully last.




Rs_yes-im4real - Clan Aura - jjf28.net84.net

Reached the top of StarCraft theory crafting 2:12 AM CST, August 2nd, 2014.

Options
  Back to forum
Please log in to reply to this topic or to report it.
Members in this topic: None.
[11:21 am]
UEDCommander -- That worker hardcode shit is annoying
[11:15 am]
UEDCommander -- I would like to point out that "successfully modded" and "done everything i want" are two big differences
[05:46 am]
O)FaRTy1billion[MM] -- 🥝
[04:47 am]
Pr0nogo -- kiwi
[04:46 am]
A_of-s_t -- I think Corbo made it a mango at one point
[04:46 am]
jjf28 -- what was it.. like... a peach originally?
[04:46 am]
A_of-s_t -- lol :aofst: forgot about that one
[04:45 am]
jjf28 -- :aofst:
[04:44 am]
A_of-s_t -- Sweet, thanks :)
[04:42 am]
Pr0nogo -- only a select few are done in scr due to its constraints
Please log in to shout.


Members Online: Roy, gfty, UEDCommander