I wonder what will happen if they ever make a vote about the worst video games company worldwide... I guess EA still wins. That's the price to pay when you only make sequels of sequels. (damn, I still can't believe they turned Syndicate into an effing FPS that can be beaten in only 2 hours)
It's not as simple as just saying "do that and you'll win" (because it's also a matter of ratio), but I think fully upgraded marines are the best units at the moment. Build 4 barracks with reactors + stimpacks + shields + attack 3 + defense 3, and you can completely crush the AI in very hard with minimum micro. I guess you could do the same with fully upgraded Zealots + Stalkers (+ observers or warp prisms to gain mobility) if you play Protoss, but I don't know what could work if you play Zerg.
Galaxy isn't friendly like those school applications for begginers etc. You need minimum programming knowledge
Galaxy is amazingly user-friendly, on the contrary... Try Virtools once (which is still much more user-friendly than the average programming tool) and you'll see how hard it is to do something when you don't have such a powerful tool as the SC2 editor (or any popular game editor, for that matter).
I think you can adjust the variants per player (including locking the parameter or not)... which could mean only the host is allowed to change the speed settings. What exactly makes the difference between a grayed out box or a drop pod having no effect, I'm not sure... but it obviously has to do with how the variants are handled within the editor. I assume a grayed out box means the settings are locked in the Game/Attributes Variants window, while a drop box with no effect is probably just using the default parameters, overridden by a "map init" trigger forcing the speed settings at some point.
Action: if (Triggering unit==roach){Set Variable roaches_killed[triggering_player] = roaches_killed[triggering_player]+1 }
if (Triggering unit==zergling){Set Variable zerglings_killed[triggering_player] = zerglingss_killed[triggering_player]+1 }
When you have multiple cases like this, you can set a Switch to do sets of actions depending on "unit type of triggering unit", rather than a long list of If/Then/Else.
Add a "Wait N seconds" right before your "Wait for Conditions Checking every second" command.
N is the time it takes your Probe to leave the 1 radius circle around Point 3. (lets say 3 seconds?)
An even quicker fix would be to set the distance check to a value lower than 1 (ex: 0.1 or even 0.05). It prevents adding actions by dozens if you ever need to add more points in the path.
Let's deal with one problem at a time... First problem, the unit not stopping anymore after the first loop is done. I'm pretty sure this has to do with the fact that a unit's queue has a limit. Basically, your loop give orders faster than the unit can handle them. The Wait for Condition is not ignored, actually it's waiting for the condition forever. If you look at the Repeat loop closely, the last action is a "give order", and the first one is also a "give order"... which means when the loop is running, there is no wait between the last action and the first one, they are basically both ordered almost instantly to the probe. What you will need here is pretty much the same Wait for Condition used before, except you'll need to check the distance between your unit and point 01. It will allow orders to be given to the probe step by step, so that the unit's queue is never full. Ideally, use a Wait for Condition for each point in the track, this way you can make a track with as many points as you wish and it will run perfectly smooth.
About the little red diamond, yes, it's usually because there is a missing/undefined parameter somewhere. But it's also a very common bug happening when you undo something in the Triggers window (especially when using If/Then/Else, While loops, Switches, etc...). Just copy+paste the content of your trigger, either in a new trigger or where it has always been, the copy should be displayed normally again so you'll just have to remove the old one.
Not sure it can be considered an "outpost" so to speak, but here's a starting point from the survival map I'm working on these days. The map is still a WiP so the road on the left is not textured or anything, but I hope you don't mind.
The reason why your unit keeps moving is because it does this:
orders, make the game wait 10 seconds, more orders
Orders are given almost instantly, so the game automatically waits 10 seconds before adding more orders to the unit's queue. But it doesn't mean the unit is waiting 10 seconds, it just means the orders are given to the unit 10 seconds apart.
What you want is this:
orders, make the unit wait 10 seconds at a point, more orders
Right before the Wait, you should use a Wait for Condition. The condition you're looking for here is Distance between points, which allows you (among other things) to wait until a specific point (the position of your probe) is close enough to a specific position (point 003) before executing more actions.
Basically, you script will look like this:
Order to move (point 02)
Order to move (point 03)
Wait for condition: Distance between Position of Probe and Point 03 < 1
Order to stop (though ordering to hold position is probably better)
Wait 10 seconds
Order to move (point 04)
(etc etc...)
On a side note, if you want to make a unit really patrol an entire path (and attacking enemies on sight, if any), you just need to order it to patrol instead of just moving + repeating forever. It will move back and forth on the given path, and even patrol in circles if the last order is on the same spot as the first one.
Why wouldn't curse get a site for UDK? Is it because it isn't exclusively modding?
Probably because the UDK (and SDKs in general) is a tool allowing to completely tweak with the engine. When you edit a map with the SC2 editor, or the Skyrim Creation Kit (just to name a few), you don't mess with the engine itself. Using the UDK as a modding tool requires way much more skills in programming. It's clearly not as user-friendly as designing levels, because the possibilities are truly endless as long as you have the knowledge and skills. You can't really learn this kind of stuff except when you try it yourself. If you want to learn to use the UDK, you need a very good knowledge in programming languages (C, Assembler, LUA, Python, etc.).
The problem is when I search for a tutorial I get information on making visual stuff for an inventory. Also most tutorials just tell you want to do or what the main idea is, not what everything in the code does or why you use specific bits of code.
Some level editors (the Aurora Toolset for NeverWinter Nights comes to my mind) are more "programming-oriented" than others, meaning that you have to write your own lines of code just to make a specific key unlock a specific door. But usually when you search for tutorials about these editors, you'll find anything BUT help on programming. I remember having to use a third-party tool to generate scripts automatically in the Aurora Toolset, because my programming skills were not good enough to create quests on my own (and by "quest" I mean the "go there, kill the evil guy, go back and tell your mom" kind of mission). Programming is a job on its own and you quickly understand why when you try it yourself... My only advice for now will be to make sure which language is used in the UDK (it's probably based on C or Assembler, with its own functions already included), then learn the basics of this language. I don't think you'll ever find tutorials covering more than the basics though, because programming allows pretty much anything... and there is no tutorial for this, only practice.
Thanks Hobbidude, it works perfectly fine! I just tried and there is no more worm or drop-pod spawned on cliffs. I basically added 8 conditions "Line crosses cliff" in my current trigger to make sure there is nothing around the placement point, just as you suggested. A distance of 3 is perfect for a nydus worm, 2 should be enough for a drop-pod. The next step now is to find a way to prevent worms from being spawned on doodads... I'll probably just have to check for any actor around (since doodads are listed as actors) in addition to the long list of conditions.
I feel kind of worthless right now, I've been using this editor for years (from the first Unreal to UT3, including games like Rune... just for level design though, and my last map was made in 2007) but maybe I'm just not understanding what you're trying to achieve. I don't recall having to use pawns, as far as I can remember I've always placed units/actors directly and modified one of their parameters to give them a specific weapon and/or inventory. The truth is I haven't used the editor for years and never had enough motivation to create anything in UT3, so I'm probably not of much help here... There were a few tutorials back in the days of UT2004 which anyone could use to create levels and mods, I'm not sure if there is anything available since UT3 though. It's not much, but maybe you should try to find tutorials based on UT2004, it shouldn't be that different from the current version of the engine (programming-wise).
And just in case it's as obvious as I think it is (even though there are already lots of video tutorials for all beginner's needs here: http://www.sc2mapster.com/wiki/galaxy/tutorials/), open the Triggers window and delete the trigger named "Melee Initialization" that you will find there.
Every script you'll need for your map to work should be made in this window, basically everything that happens during a custom game is triggered by actions you have to define. By default there is a script initializing the melee rules (automatically placing the main building on the starting point + a few workers next to it), but you usually don't need it when you're making a custom map with your own set of rules and events.
The rest is up to which units you have placed on the Terrain window, you'll need to place at least one unit for player 1 on your map as it is the default player you're given control of when testing.
There are already a few threads about this issue, and basically this is all you'll find:
there is no easy way to display more than one tip during the loading screen
you can find the loading tips in the Data window (under UI or Game data tab, can't remember well) but modifying them doesn't seem to work... I actually spent hours on this with no result
Tips are classed by race (you'll see by yourself when you'll find them in Data), but I'm also assuming since a custom game is considered "random" race (unless your map is some kind of altered melee), tips from all races are displayed at random no matter what.
I use WASD movement in my Ikari Warriors map, and I know for sure the latency is a huge problem once you play on BNet, whether you're alone or not. It's a very well-known issue that can't be dealt with. You can however optimize your triggers and coding to reduce the amount of data exchanged with the servers, improving both the general performance and allowing the game to be more responsive. So far, I wasn't able to reduce the lag as much as I wanted, my map is basically very hard to play in co-op if you're new to the game, just because of the latency... No matter how much effort I put on improving the scripts.
It's far from being unplayable though, there is a latency you need to get accustomed to if you want to survive more than 30 seconds... I tested my map a few times on BNet in singleplayer Insane mode, it was way harder but I was able to win nonetheless. I played with a friend, I was able to play fine but he was not. We played again 2 days later and it was a bit better. As I said, what matters is to reduce the amount of data sent to the servers, so basically just try to avoid as often as possible executing triggers every second, or any kind of horrible coding causing lags even offline...
0
I wonder what will happen if they ever make a vote about the worst video games company worldwide... I guess EA still wins. That's the price to pay when you only make sequels of sequels. (damn, I still can't believe they turned Syndicate into an effing FPS that can be beaten in only 2 hours)
0
It's not as simple as just saying "do that and you'll win" (because it's also a matter of ratio), but I think fully upgraded marines are the best units at the moment. Build 4 barracks with reactors + stimpacks + shields + attack 3 + defense 3, and you can completely crush the AI in very hard with minimum micro. I guess you could do the same with fully upgraded Zealots + Stalkers (+ observers or warp prisms to gain mobility) if you play Protoss, but I don't know what could work if you play Zerg.
0
Galaxy is amazingly user-friendly, on the contrary... Try Virtools once (which is still much more user-friendly than the average programming tool) and you'll see how hard it is to do something when you don't have such a powerful tool as the SC2 editor (or any popular game editor, for that matter).
0
@Deadzergling: Go
I think you can adjust the variants per player (including locking the parameter or not)... which could mean only the host is allowed to change the speed settings. What exactly makes the difference between a grayed out box or a drop pod having no effect, I'm not sure... but it obviously has to do with how the variants are handled within the editor. I assume a grayed out box means the settings are locked in the Game/Attributes Variants window, while a drop box with no effect is probably just using the default parameters, overridden by a "map init" trigger forcing the speed settings at some point.
0
When you have multiple cases like this, you can set a Switch to do sets of actions depending on "unit type of triggering unit", rather than a long list of If/Then/Else.
0
An even quicker fix would be to set the distance check to a value lower than 1 (ex: 0.1 or even 0.05). It prevents adding actions by dozens if you ever need to add more points in the path.
0
Let's deal with one problem at a time... First problem, the unit not stopping anymore after the first loop is done. I'm pretty sure this has to do with the fact that a unit's queue has a limit. Basically, your loop give orders faster than the unit can handle them. The Wait for Condition is not ignored, actually it's waiting for the condition forever. If you look at the Repeat loop closely, the last action is a "give order", and the first one is also a "give order"... which means when the loop is running, there is no wait between the last action and the first one, they are basically both ordered almost instantly to the probe. What you will need here is pretty much the same Wait for Condition used before, except you'll need to check the distance between your unit and point 01. It will allow orders to be given to the probe step by step, so that the unit's queue is never full. Ideally, use a Wait for Condition for each point in the track, this way you can make a track with as many points as you wish and it will run perfectly smooth.
About the little red diamond, yes, it's usually because there is a missing/undefined parameter somewhere. But it's also a very common bug happening when you undo something in the Triggers window (especially when using If/Then/Else, While loops, Switches, etc...). Just copy+paste the content of your trigger, either in a new trigger or where it has always been, the copy should be displayed normally again so you'll just have to remove the old one.
0
Not sure it can be considered an "outpost" so to speak, but here's a starting point from the survival map I'm working on these days. The map is still a WiP so the road on the left is not textured or anything, but I hope you don't mind.
0
The reason why your unit keeps moving is because it does this:
orders, make the game wait 10 seconds, more orders
Orders are given almost instantly, so the game automatically waits 10 seconds before adding more orders to the unit's queue. But it doesn't mean the unit is waiting 10 seconds, it just means the orders are given to the unit 10 seconds apart.
What you want is this:
orders, make the unit wait 10 seconds at a point, more orders
Right before the Wait, you should use a Wait for Condition. The condition you're looking for here is Distance between points, which allows you (among other things) to wait until a specific point (the position of your probe) is close enough to a specific position (point 003) before executing more actions.
Basically, you script will look like this:
Order to move (point 02)
Order to move (point 03)
Wait for condition: Distance between Position of Probe and Point 03 < 1
Order to stop (though ordering to hold position is probably better)
Wait 10 seconds
Order to move (point 04)
(etc etc...)
On a side note, if you want to make a unit really patrol an entire path (and attacking enemies on sight, if any), you just need to order it to patrol instead of just moving + repeating forever. It will move back and forth on the given path, and even patrol in circles if the last order is on the same spot as the first one.
0
Probably because the UDK (and SDKs in general) is a tool allowing to completely tweak with the engine. When you edit a map with the SC2 editor, or the Skyrim Creation Kit (just to name a few), you don't mess with the engine itself. Using the UDK as a modding tool requires way much more skills in programming. It's clearly not as user-friendly as designing levels, because the possibilities are truly endless as long as you have the knowledge and skills. You can't really learn this kind of stuff except when you try it yourself. If you want to learn to use the UDK, you need a very good knowledge in programming languages (C, Assembler, LUA, Python, etc.).
Some level editors (the Aurora Toolset for NeverWinter Nights comes to my mind) are more "programming-oriented" than others, meaning that you have to write your own lines of code just to make a specific key unlock a specific door. But usually when you search for tutorials about these editors, you'll find anything BUT help on programming. I remember having to use a third-party tool to generate scripts automatically in the Aurora Toolset, because my programming skills were not good enough to create quests on my own (and by "quest" I mean the "go there, kill the evil guy, go back and tell your mom" kind of mission). Programming is a job on its own and you quickly understand why when you try it yourself... My only advice for now will be to make sure which language is used in the UDK (it's probably based on C or Assembler, with its own functions already included), then learn the basics of this language. I don't think you'll ever find tutorials covering more than the basics though, because programming allows pretty much anything... and there is no tutorial for this, only practice.
0
@hobbidude: Go
Thanks Hobbidude, it works perfectly fine! I just tried and there is no more worm or drop-pod spawned on cliffs. I basically added 8 conditions "Line crosses cliff" in my current trigger to make sure there is nothing around the placement point, just as you suggested. A distance of 3 is perfect for a nydus worm, 2 should be enough for a drop-pod. The next step now is to find a way to prevent worms from being spawned on doodads... I'll probably just have to check for any actor around (since doodads are listed as actors) in addition to the long list of conditions.
0
I feel kind of worthless right now, I've been using this editor for years (from the first Unreal to UT3, including games like Rune... just for level design though, and my last map was made in 2007) but maybe I'm just not understanding what you're trying to achieve. I don't recall having to use pawns, as far as I can remember I've always placed units/actors directly and modified one of their parameters to give them a specific weapon and/or inventory. The truth is I haven't used the editor for years and never had enough motivation to create anything in UT3, so I'm probably not of much help here... There were a few tutorials back in the days of UT2004 which anyone could use to create levels and mods, I'm not sure if there is anything available since UT3 though. It's not much, but maybe you should try to find tutorials based on UT2004, it shouldn't be that different from the current version of the engine (programming-wise).
0
And just in case it's as obvious as I think it is (even though there are already lots of video tutorials for all beginner's needs here: http://www.sc2mapster.com/wiki/galaxy/tutorials/), open the Triggers window and delete the trigger named "Melee Initialization" that you will find there.
Every script you'll need for your map to work should be made in this window, basically everything that happens during a custom game is triggered by actions you have to define. By default there is a script initializing the melee rules (automatically placing the main building on the starting point + a few workers next to it), but you usually don't need it when you're making a custom map with your own set of rules and events.
The rest is up to which units you have placed on the Terrain window, you'll need to place at least one unit for player 1 on your map as it is the default player you're given control of when testing.
0
There are already a few threads about this issue, and basically this is all you'll find:
Tips are classed by race (you'll see by yourself when you'll find them in Data), but I'm also assuming since a custom game is considered "random" race (unless your map is some kind of altered melee), tips from all races are displayed at random no matter what.
0
I use WASD movement in my Ikari Warriors map, and I know for sure the latency is a huge problem once you play on BNet, whether you're alone or not. It's a very well-known issue that can't be dealt with. You can however optimize your triggers and coding to reduce the amount of data exchanged with the servers, improving both the general performance and allowing the game to be more responsive. So far, I wasn't able to reduce the lag as much as I wanted, my map is basically very hard to play in co-op if you're new to the game, just because of the latency... No matter how much effort I put on improving the scripts.
It's far from being unplayable though, there is a latency you need to get accustomed to if you want to survive more than 30 seconds... I tested my map a few times on BNet in singleplayer Insane mode, it was way harder but I was able to win nonetheless. I played with a friend, I was able to play fine but he was not. We played again 2 days later and it was a bit better. As I said, what matters is to reduce the amount of data sent to the servers, so basically just try to avoid as often as possible executing triggers every second, or any kind of horrible coding causing lags even offline...