I don't see how this will improve when millions of people (mostly koreans :P) swarm the servers in the retail version. Just let us host our own games, alrdy! I'm used to it and I have a very nice internet connection, so I can host laggless games as well. JUST GIEF POWAHS TO ME!
I do. Server hosting is a very easily parallelized algorithm. It takes minimal CPU power, and can be distributed across hundreds if not thousands of servers. Blizzard does this successfully with their WoW servers, albeit on a slightly smaller scale per realm. The only problems they have at the moment is a few bottlenecks in code speed, and perhaps too few servers, both of which are now addressed and can be fixed.
It's a beta, did you really expect them to get it perfect the first time?
The reason for the lag has nothing to do with key press events, the 125ms tick rate, UDP, etc. It's simply that the games are now hosted by Battle.net's servers, and they're overloaded at the moment.
It's like Battle.net 2.0 is your own personal GHost bot, except it's lagging atm.
Yeah. Atm I'm just working around it by having a periodic event that checks whether conditions the event would be fired under are met. It's rather sloppy but I imagine Blizzard will eventually fix it. I have the exact same custom library situation. Lol
I did some work with this stuff the other day. As far as I can tell, it's absolutely impossible in GUI.
In Galaxy itself, it's also messy because you have to maintain a list of the triggers that are "listening" on the event (big array potentially).
The problem, as you pointed out, lies with the first "implicit" parameter of trigger that GUI seems to completely forget about and ignore.
I've clarified on the Script Editor part. My apologies for the misunderstanding. I do not use any other part of the editor at all, so that was all I thought about.
As I said, 1.2 is only a quick fix for Windows XP enUS clients that maintain the default path of C:\Documents and Settings\USERNAME\Local Settings\Application Data\. If the path is any different at all, it'll fail.
Edit #2: I will be updating MapCraft again with a rewrite soon to fix Windows support once and for all, and enhance overall usability.
I was driving home today just singing it over and over when a deer jumped in front of me. I didn't let it ruin the singing though. It's too good of a song to let something like that stop me.
I haven't played SC2 melee at all. It simply doesn't interest me. I wouldn't try to make a melee map without understanding the concepts presented regularly to melee players, but I sure know how to make other great custom games. Melee does not relate to your performance as a map maker, unless you're making a melee map.
I've added 1.2 for Windows XP users on the downloads page. This may solve issues a lot of you had. It's not a proper fix but it'll work for probably 98% of XP users. I've gotta' learn JNI and call the Windows API to do it properly later. It won't work if your path isn't completely standard, or if you're not on an English build of Windows.
If you're playing on the highest settings in the game you should be aware that things like textures, models, etc. will use significantly more RAM and VRAM. I'm 99% sure though based on your description that this is probably not a Blizzard issue. Maybe your RAM is faulty? Try running a test like Memtest and see what it says.
Or you could just try running on Medium and see how it affects memory usage. You're going to have to run through and eliminate potential causes one by one before you can make an accurate bug report that will stand up to scrutiny and get fixed.
No one but you is having these drastic memory issues, BeLugh. If this were the case, Blizzard would've picked up on that drastic of a leak in their extensive testing of melee games. I suggest looking into what is wrong with your installation or possibly even Operating System or hardware.
Again, calling functions like that does not cause a memory leak either. Certainly not presenting in the way you explained. There's no difference to SC2 in whether or not a variable is stored in a local variable or discarded as soon as it's called. Either way the refcount becomes 0 either as soon as it's called and passed to the next method, or as soon as the scope is existed, and the garbage collector reclaims the data.
I have a map that deals with so many calls like this it's not even funny and I have yet to notice any memory leaks as a result of Galaxy.
I'm not saying that the bug you're experiencing with the maps isn't real. I'm just saying it's because of something else.
0
I do. Server hosting is a very easily parallelized algorithm. It takes minimal CPU power, and can be distributed across hundreds if not thousands of servers. Blizzard does this successfully with their WoW servers, albeit on a slightly smaller scale per realm. The only problems they have at the moment is a few bottlenecks in code speed, and perhaps too few servers, both of which are now addressed and can be fixed.
It's a beta, did you really expect them to get it perfect the first time?
0
The reason for the lag has nothing to do with key press events, the 125ms tick rate, UDP, etc. It's simply that the games are now hosted by Battle.net's servers, and they're overloaded at the moment.
It's like Battle.net 2.0 is your own personal GHost bot, except it's lagging atm.
Nothing to see here, just a beta, move along.
0
@ubermikeleet: Go
Yeah. Atm I'm just working around it by having a periodic event that checks whether conditions the event would be fired under are met. It's rather sloppy but I imagine Blizzard will eventually fix it. I have the exact same custom library situation. Lol
0
Also note, a bank can be up to 1 MB in file size, and you can have up to 128 banks.
0
I did some work with this stuff the other day. As far as I can tell, it's absolutely impossible in GUI.
In Galaxy itself, it's also messy because you have to maintain a list of the triggers that are "listening" on the event (big array potentially).
The problem, as you pointed out, lies with the first "implicit" parameter of trigger that GUI seems to completely forget about and ignore.
0
I've clarified on the Script Editor part. My apologies for the misunderstanding. I do not use any other part of the editor at all, so that was all I thought about.
0
@Waxxy91: Go
As I said, 1.2 is only a quick fix for Windows XP enUS clients that maintain the default path of C:\Documents and Settings\USERNAME\Local Settings\Application Data\. If the path is any different at all, it'll fail.
Edit #2: I will be updating MapCraft again with a rewrite soon to fix Windows support once and for all, and enhance overall usability.
0
@Logikz0: Go
If you close w/o hitting restore, it should restore the file anyways. There's a hook on the window close action that takes care of it.
0
@Sixen: Go
I was driving home today just singing it over and over when a deer jumped in front of me. I didn't let it ruin the singing though. It's too good of a song to let something like that stop me.
And "Soul Sister" is pretty good, too.
0
Did you finally get the chance to dance along the light of day, and head back to the milky way?
0
@BlastYoBoots: Go
I haven't played SC2 melee at all. It simply doesn't interest me. I wouldn't try to make a melee map without understanding the concepts presented regularly to melee players, but I sure know how to make other great custom games. Melee does not relate to your performance as a map maker, unless you're making a melee map.
0
I've added 1.2 for Windows XP users on the downloads page. This may solve issues a lot of you had. It's not a proper fix but it'll work for probably 98% of XP users. I've gotta' learn JNI and call the Windows API to do it properly later. It won't work if your path isn't completely standard, or if you're not on an English build of Windows.
0
@BeLugh: Go
If you're playing on the highest settings in the game you should be aware that things like textures, models, etc. will use significantly more RAM and VRAM. I'm 99% sure though based on your description that this is probably not a Blizzard issue. Maybe your RAM is faulty? Try running a test like Memtest and see what it says.
Or you could just try running on Medium and see how it affects memory usage. You're going to have to run through and eliminate potential causes one by one before you can make an accurate bug report that will stand up to scrutiny and get fixed.
0
@BeLugh: Go
No one but you is having these drastic memory issues, BeLugh. If this were the case, Blizzard would've picked up on that drastic of a leak in their extensive testing of melee games. I suggest looking into what is wrong with your installation or possibly even Operating System or hardware.
0
@BeLugh: Go
Again, calling functions like that does not cause a memory leak either. Certainly not presenting in the way you explained. There's no difference to SC2 in whether or not a variable is stored in a local variable or discarded as soon as it's called. Either way the refcount becomes 0 either as soon as it's called and passed to the next method, or as soon as the scope is existed, and the garbage collector reclaims the data.
I have a map that deals with so many calls like this it's not even funny and I have yet to notice any memory leaks as a result of Galaxy.
I'm not saying that the bug you're experiencing with the maps isn't real. I'm just saying it's because of something else.