OK, so I've continued to tinker away in my spare time. DORFL is NOT near completion. It is SOOOOOooo far from being finalized.
But none the less... I decided to battle it against the Blizzard AI just for a laugh. And laugh I did, I also facepalmed... OK mostly facepalmed... a lot!
At one point DORFL is up in supply something crazy like 110 to 30 but it's actions were just so stupid that it couldn't possibly pull the victory. At one point it build an army out of observers
I am providing the replay for comedy purposes if anyone else wants to see. Ignore the first few seconds when it sets everything up. Also ignore all the text scrolling up the screen.
Here is the replay file which I uploaded to spawningtool.com
Player 1 in the bottom left corner is controlled by the Blizzard AI (I think it is on easy but not sure). The top right corner is player 2 which is controlled by DORFL.
before you laugh at me too much remember that this is the computers FIRST EVER game of SC2. I want you to think back to YOUR first ever game of SC2 and remember how bad you were in comparisson. Grab the popcorn, don't take it seriously, and enjoy.
Something I've found is that printing a lot to the screen or to a bank file slows things down a LOT. So for instance if you have a debugging string printed to the screen every 5 seconds while you test something and leave it running for 10 minutes it will slow down the system more and more as time goes on. Same with a bank file which gets larger and larger.
What FunkyUserNarr said will help too. Instead of having 9 triggers that fire when a unit dies it might be better to have 1 trigger which does all 9 things.
That is only 1172 variables needed NOT 1.8 million!
It sounds like you are being very inneficient with how you are storing your data.
If you wanted to be even more efficient with how you store data you could drastically cut down on that number even further. If you stored only the achievements and items that the player DID have, say that each player typically has half the items and achievements available then that is only about 500 variables needed for the average player.
If you combined all those boolean states for whether a player has an item or achievement into a string you could probably reduce it so that each player only needed 7 variables.
From what you describe I don't see why you need more than 7 variables so I don't know how you manage to have 1.8 million lol.
If the players in each team must have the same race then why make a selection for each player? that doesn't make sense.
From the sounds of what you are trying to do I would create a single dialog and make it visible to everyone. then for each team have a drop down menu or buttons or whatever to select the race for that team. You can chose to disable dialog items for certain players/player groups. So disable the controls for team 1 for team 2, and disable the controls for team 2 for team 1. Then they are all looking at the same buttons and see the changes as they are made. You still have the issue of players fighting over which race their team should be or changing the race at the last minute so the enemy is not able to know or respond to what race they are.
This function will return a pathable point on the map.
I'm assuming you're using the GUI. point is passable and repeat forever are both listed in the GUI if you search for them. I'm not sure what the function names would be in Galaxy, but you can do the same.
For the link you provided, is that all there is to the trigger? If so I am not surprised it does not work. You have declared the two variables "unit waypoint" and "unit owner" in the "variables" section but have not given the variables a value.
When you declare a variable in SC2 triggers it is given a default value. For integers they default to 0 and for points it defaults to "no point" which is a nonexistent point on the map.
With that in mind, look over the code you wrote.
The 1st line says to pick each unit in (any units) owned by player 0. Usually player zero is for neutral things on the map like minerals, vespene guysers, neutral supply depots, destructable rocks, etc. Human players are usually listed from 1 onwards. The last line tells the units to attack "no point". So what this code does is command all the minerals and vespene guysers to attack a non existent location.
If you added these lines to the start of the actions list
Then that would tell the function to send all of the first human players units on attack move towards the centre of the map.
I'm assuming this is a high school or university introduction to programming course? Is the teacher getting students to do stuff in the SC2 editor or did they give you enough freedom to demonstrate programming ability in whatever medium you chose? Either way that is really cool. I wish I had ever gotten assignments which were so flexible or interesting.
PS. I'm just assuming that the human player is player 1. This is usually the case but can be changed around, so make sure to set the variable to the correct value.
"This is for setting the path, the line that shows for orders normally. Now one can use this to easily determine the pathing range that a created path goes."
I'm not sure I understand what this is about. Could you explain a bit? Thanks.
I can imagine how scary it would be seeing beautiful terrain through fog (when planning my next scout/attack location) with the occasional spiky minerals out of nowhere :P .
There's a particular action that lets you reveal a certain sized circular area around a point. You set the reveal area high enough so that the target unit appears through fog (the grey one) and can be targeted by any unit but also keep the reveal area low enough so that part of the map isn't actually revealed to the player.
yeah, that's what I do with XelNaga towers. But for all other neutral units like minerals and destructable rocks I set their vision range to zero and then share vision between the player and those units. It has the same effect but it's much quicker and easier than creating 200 revealers.
I need to create an exact snap shot of the game at a given time with enough data to completely recreate the game state so that it would be completely indistinguishable. That is down to every behaviour, cooldown, unit stat, rally point, control group, training slot, upgrade level, player camera position, saved camera location, hotkeys, etcetcetc and an important part of that is that I need to know every detail about every order issued so that it can be 100% recreated. And I need to do this whenever and however many times the player wants to.
When I have a specific question I limit the scope to what is relevant information otherwise I am just wasting everyones time and obscuring what the actual problem is. Then discussion gets side tracked away from what the origional question was about.
Hopefuly, if anyone has any ideas on how I could get at the data I need they can offer a suggestion.
Have you tried using the event Unit uses ability? I'm thinking of the move ability and checking the triggering ability target unit might work.
The unit won't use the ability until it reaches its target. Maybe I could try using the "unit is issued order" event and try to see if "triggering ability target unit" can give me the information needed, but I doubt that will be a lead. It's worth trying though, thanks :)
Origionally I wanted an AI that would be compatible with another project where the default AIs do not work. But I started writting it generalized enough that I realized it could become a stand alone AI.
So now it's
10% compatibility with the other project
20% because I think it would make for a good practice partner for melee players
35% because I think AIs are really cool and want to make one and
The existing melee AI was already written by professionals.
Everyone knows the best maps were created by community members not Blizzard, the best arcade games were created by community menbers not Blizzard, the best balance/playstyle/improvement ideas have come from community members not Blizzard.
I never played the origional Green tea AIs but I've heard other people saying they were far better AIs than the Blizzard ones so it's already been done before.
That's not putting down Blizzard either. I know the employees at Blizzard are smarter and more qualified than I am. Spending untold resources on creating a better AI does not really improve their product. Half the people only play campaign and most of the rest play against humans. Blizzard has to make maps/AIs/changes which apeal to everyone. They have to be easy and predictable. The community is not bound by those restrictions.
Also if anyone is curious I open sourced the project on US server for anyone who wants to investigate for themselves. It's under the name "SALT". Here are the steps required at the moment to get the AI up and running:
So much that will encompass the AI is not yet written. and so much of what IS written I am going to rewrite, replace or update. So it is NOT what the final product will be, it's just a stepping stone.
0
OK, so I've continued to tinker away in my spare time. DORFL is NOT near completion. It is SOOOOOooo far from being finalized.
But none the less... I decided to battle it against the Blizzard AI just for a laugh. And laugh I did, I also facepalmed... OK mostly facepalmed... a lot!
At one point DORFL is up in supply something crazy like 110 to 30 but it's actions were just so stupid that it couldn't possibly pull the victory. At one point it build an army out of observers
I am providing the replay for comedy purposes if anyone else wants to see. Ignore the first few seconds when it sets everything up. Also ignore all the text scrolling up the screen.
Here is the replay file which I uploaded to spawningtool.com
Player 1 in the bottom left corner is controlled by the Blizzard AI (I think it is on easy but not sure). The top right corner is player 2 which is controlled by DORFL.
before you laugh at me too much remember that this is the computers FIRST EVER game of SC2. I want you to think back to YOUR first ever game of SC2 and remember how bad you were in comparisson. Grab the popcorn, don't take it seriously, and enjoy.
Here is the replay, provided at spawningtool.com
0
Something I've found is that printing a lot to the screen or to a bank file slows things down a LOT. So for instance if you have a debugging string printed to the screen every 5 seconds while you test something and leave it running for 10 minutes it will slow down the system more and more as time goes on. Same with a bank file which gets larger and larger.
What FunkyUserNarr said will help too. Instead of having 9 triggers that fire when a unit dies it might be better to have 1 trigger which does all 9 things.
0
That is NOT 1.8 million integers being saved!
amount of Exp = 1 integer variable
credits = 1 integer variable
play count = 1 integer variable
win count = 1 integer variable
amount of heroes = 28
play count for each hero = 1 integer variable
items gained = 840 boolean variables
achievements earned = 300 boolean variables
ACTUALLY the maths is
1 + 1 + 1 + 1 + 28*1 + 840 + 300 = 1172
That is only 1172 variables needed NOT 1.8 million!
It sounds like you are being very inneficient with how you are storing your data.
If you wanted to be even more efficient with how you store data you could drastically cut down on that number even further. If you stored only the achievements and items that the player DID have, say that each player typically has half the items and achievements available then that is only about 500 variables needed for the average player.
If you combined all those boolean states for whether a player has an item or achievement into a string you could probably reduce it so that each player only needed 7 variables.
From what you describe I don't see why you need more than 7 variables so I don't know how you manage to have 1.8 million lol.
0
If the players in each team must have the same race then why make a selection for each player? that doesn't make sense.
From the sounds of what you are trying to do I would create a single dialog and make it visible to everyone. then for each team have a drop down menu or buttons or whatever to select the race for that team. You can chose to disable dialog items for certain players/player groups. So disable the controls for team 1 for team 2, and disable the controls for team 2 for team 1. Then they are all looking at the same buttons and see the changes as they are made. You still have the issue of players fighting over which race their team should be or changing the race at the last minute so the enemy is not able to know or respond to what race they are.
0
Huh, I did not know those things about player groups.
It also took me a long time to figure out that unit groups are the same. Hopefully this saves headaches for others if they read it.
0
Use the "point is pathable" function to test if it is pathable to ground units.
This function will return a pathable point on the map.
I'm assuming you're using the GUI. point is passable and repeat forever are both listed in the GUI if you search for them. I'm not sure what the function names would be in Galaxy, but you can do the same.
0
I love a happy ending.
FOR THE SWARM! :D
0
@gemcollectersummer: Go
Use UnitGroupUnit to get the unit at a specific index and something like UnitGroupSize or something like that to know how many units there are.
If you don't know just do it using the GUI and then look at the code it generates.
0
@vic9050: Go
For the link you provided, is that all there is to the trigger? If so I am not surprised it does not work. You have declared the two variables "unit waypoint" and "unit owner" in the "variables" section but have not given the variables a value.
When you declare a variable in SC2 triggers it is given a default value. For integers they default to 0 and for points it defaults to "no point" which is a nonexistent point on the map.
With that in mind, look over the code you wrote.
The 1st line says to pick each unit in (any units) owned by player 0. Usually player zero is for neutral things on the map like minerals, vespene guysers, neutral supply depots, destructable rocks, etc. Human players are usually listed from 1 onwards. The last line tells the units to attack "no point". So what this code does is command all the minerals and vespene guysers to attack a non existent location.
If you added these lines to the start of the actions list
Then that would tell the function to send all of the first human players units on attack move towards the centre of the map.
I'm assuming this is a high school or university introduction to programming course? Is the teacher getting students to do stuff in the SC2 editor or did they give you enough freedom to demonstrate programming ability in whatever medium you chose? Either way that is really cool. I wish I had ever gotten assignments which were so flexible or interesting.
PS. I'm just assuming that the human player is player 1. This is usually the case but can be changed around, so make sure to set the variable to the correct value.
0
thanks for the explanation.
0
"This is for setting the path, the line that shows for orders normally. Now one can use this to easily determine the pathing range that a created path goes."
I'm not sure I understand what this is about. Could you explain a bit? Thanks.
0
If it is only orders which it effects you can have an array of orders, fill it with the units orders, change ownership and then reinstate the orders.
I'm not sure if changing ownership effects other things like unit IDs, rally points, behaviours, etc. So it might be more work than that.
0
Lol I totally agree :P
yeah, that's what I do with XelNaga towers. But for all other neutral units like minerals and destructable rocks I set their vision range to zero and then share vision between the player and those units. It has the same effect but it's much quicker and easier than creating 200 revealers.
0
I need to create an exact snap shot of the game at a given time with enough data to completely recreate the game state so that it would be completely indistinguishable. That is down to every behaviour, cooldown, unit stat, rally point, control group, training slot, upgrade level, player camera position, saved camera location, hotkeys, etcetcetc and an important part of that is that I need to know every detail about every order issued so that it can be 100% recreated. And I need to do this whenever and however many times the player wants to.
When I have a specific question I limit the scope to what is relevant information otherwise I am just wasting everyones time and obscuring what the actual problem is. Then discussion gets side tracked away from what the origional question was about.
Hopefuly, if anyone has any ideas on how I could get at the data I need they can offer a suggestion.
The unit won't use the ability until it reaches its target. Maybe I could try using the "unit is issued order" event and try to see if "triggering ability target unit" can give me the information needed, but I doubt that will be a lead. It's worth trying though, thanks :)
0
Origionally I wanted an AI that would be compatible with another project where the default AIs do not work. But I started writting it generalized enough that I realized it could become a stand alone AI.
So now it's
I don't think I can do a "slightly" better melee AI, I think I can do a MUCH better melee AI. The existing melee AI is terrible.
I'm ready to eat my words on that matter. Maybe I can't. But I think that I can. So I'm going to. :)
Everyone knows the best maps were created by community members not Blizzard, the best arcade games were created by community menbers not Blizzard, the best balance/playstyle/improvement ideas have come from community members not Blizzard.
I never played the origional Green tea AIs but I've heard other people saying they were far better AIs than the Blizzard ones so it's already been done before.
That's not putting down Blizzard either. I know the employees at Blizzard are smarter and more qualified than I am. Spending untold resources on creating a better AI does not really improve their product. Half the people only play campaign and most of the rest play against humans. Blizzard has to make maps/AIs/changes which apeal to everyone. They have to be easy and predictable. The community is not bound by those restrictions.
Also if anyone is curious I open sourced the project on US server for anyone who wants to investigate for themselves. It's under the name "SALT". Here are the steps required at the moment to get the AI up and running:
So much that will encompass the AI is not yet written. and so much of what IS written I am going to rewrite, replace or update. So it is NOT what the final product will be, it's just a stepping stone.