EPTNo Diflier or lurker
![[image loading]](http://i.imgur.com/PvsUK1q.jpg)
I checked every map on KR, I will check EU next
[A] Starcraft 2 Brood War - Page 223
| Forum Index > SC2 Maps & Custom Games |
|
WarpTV
205 Posts
No Diflier or lurker I checked every map on KR, I will check EU next | ||
|
L3monsta
New Zealand149 Posts
In case you haven't seen it already there's people asking for custom map with both SC2 and BW in it. Something I've wanted personally for a long time, however its a big project. Just thought you might like to know in case you wanted to get involved or take on the mantle.. here's the discussion on Battlenet http://us.battle.net/sc2/en/forum/topic/10014521427?page=1 | ||
|
WarpTV
205 Posts
| ||
|
RobertBrian
United Kingdom3 Posts
| ||
|
MavercK
Australia2181 Posts
On September 25 2013 00:32 WarpTV wrote: Hey, any luck getting the hotkeys fixed? me and my friends stopped playing b/c of it. Could you release you work so some one can copy then fix it. and republish it? I've stripped hotkeys entirely and doing them from scratch. Also trying to fix that hotkey profile editor. I'll try do an update this weekend. On September 25 2013 17:04 RobertBrian wrote: My friend is thinking of getting Starcraft and he wants to save money. Do you need to buy both Wings of Liberty and Heart of the Swarm to play or could he buy just Heart of The Swarm? presently, yea you'll need HotS, theres assets in HotS that i wanted to use. I tried looking at keeping in WoL but the general consensus is Blizzard will probably ban the mod if i include HotS in a WoL mod. | ||
|
MavercK
Australia2181 Posts
In preparation I'll be removing SC2BW from every region and re uploading it. Main changes in this version are hopefully a fix for Hotkeys Rework of Siege Tank damage in Siege mode Rework of air unit stacking, performance increase hopefully. I havn't done an Update in awhile, i fixed all the bugs i found as i came across them but there are probably a few remaining. I also have a nice virtual machine on a 1tb internet connection i can use to do updates which should speed everything up and remove 99% of the tedium in updating. | ||
|
LaLuSh
Sweden2358 Posts
Their first version was very similar to SC2BW. Turns out that matched BW income really well between 0 and 2 saturation. But between 2 and 3 saturation, the numbers were really off (BW's max income rate is much higher than either SC2BW or Starbow was). ![[image loading]](http://i.imgur.com/c2lATLe.png) Anyway. They identified some quirks of BW mining and set a couple of new triggers for workers. The most important of which I think was triggering out the way SC2 has hardcoded workers to queue rather than bounce if a currently mining worker has less than a defined time limit remaining before finishing up. This only applies if all patches have at least 1 current harvester (if there are 0 current harvesters at any patch, workers will always bounce immediately, even in SC2). This discrepancy seems to exist in SC2BW. As if you push harvest time below 5.412, the 2nd worker on a mineral patch will always queue (despite arriving there before the currently mining worker is finished). In order for the max income rate to be pushed higher though, the harvest time needs to be lowered. The other condition they found was that if all mineral patches were occupied (i.e. all of them currently/simultaneously being actively mined from, workers in BW would always queue as opposed to bounce). This meant that there was no wandering after 3 per patch saturation in BW (well, sometimes there was, but given 1-2 minutes, workers would settle in and mine optimally while always queueing and never wandering). In SC2BW and earlier version of Starbow workers keep wandering even towards infinity saturation. Decemberscalm in the starbow thread managed to set a trigger that makes workers settle in and mine optimally after 3 per patch saturation. Thought you might be interested. The only problem is, their results don't 100% mirror BW's income rate in the 0-2 saturation range. So they've resorted to even more triggers to make workers even more stupid (like making them turn before they can move when bouncing off from an occupied mineral patch to a new one). They are very close to BW income rate right now. I still think the feel of SC2BW units is superior, since you've scaled the unit speeds differently than they do (they do a 1:1 scale between maps of the same exact dimensions). So their mutalisk is 3.3 speed for example (I believe). Personally I don't think such slow speeds fit with for example the glide distance that SC2 engine allows. But that, like all things, is a matter of preference... I still want to get two koreans playing a showmatch in sc2bw somehow. But I don't know any non korea based ex-bw pros except forgg. | ||
|
MavercK
Australia2181 Posts
On September 29 2013 08:44 LaLuSh wrote: The people over at starbow have been downright obsessed about matching their income rate to BW's for the last 2 weeks now (ever since they switched to BW economy a month ago). Their first version was very similar to SC2BW. Turns out that matched BW income really well between 0 and 2 saturation. But between 2 and 3 saturation, the numbers were really off (BW's max income rate is much higher than either SC2BW or Starbow was). Anyway. They identified some quirks of BW mining and set a couple of new triggers for workers. The most important of which I think was triggering out the way SC2 has hardcoded workers to queue rather than bounce if a currently mining worker has less than a defined time limit remaining before finishing up. This only applies if all patches have at least 1 current harvester (if there are 0 current harvesters at any patch, workers will always bounce immediately, even in SC2). This discrepancy seems to exist in SC2BW. As if you push harvest time below 5.412, the 2nd worker on a mineral patch will always queue (despite arriving there before the currently mining worker is finished). In order for the max income rate to be pushed higher though, the harvest time needs to be lowered. The other condition they found was that if all mineral patches were occupied (i.e. all of them currently/simultaneously being actively mined from, workers in BW would always queue as opposed to bounce). This meant that there was no wandering after 3 per patch saturation in BW (well, sometimes there was, but given 1-2 minutes, workers would settle in and mine optimally while always queueing and never wandering). In SC2BW and earlier version of Starbow workers keep wandering even towards infinity saturation. Decemberscalm in the starbow thread managed to set a trigger that makes workers settle in and mine optimally after 3 per patch saturation. Thought you might be interested. The only problem is, their results don't 100% mirror BW's income rate in the 0-2 saturation range. So they've resorted to even more triggers to make workers even more stupid (like making them turn before they can move when bouncing off from an occupied mineral patch to a new one). They are very close to BW income rate right now. I still think the feel of SC2BW units is superior, since you've scaled the unit speeds differently than they do (they do a 1:1 scale between maps of the same exact dimensions). So their mutalisk is 3.3 speed for example (I believe). Personally I don't think such slow speeds fit with for example the glide distance that SC2 engine allows. But that, like all things, is a matter of preference... I still want to get two koreans playing a showmatch in sc2bw somehow. But I don't know any non korea based ex-bw pros except forgg. I'll look into it, the first thing you mentioned where works don't queue should already be implemented. | ||
|
decemberscalm
United States1353 Posts
Working vulture target fire while moving. Moving shot that toggles with an attack command instead of only having a small window aka true BW vultures. Different full damage to shield system. (something seemed wrong with yours). Eco triggers that ONLY target not currently being mined mineral fields. As far as I can tell yours don't do these making the third workers per patch really inefficient (as you can see in the graph). BTW, do you somehow have SC2 not playing at fastest? | ||
|
MavercK
Australia2181 Posts
On September 29 2013 13:15 decemberscalm wrote: If you want I have some useful stuff. Working vulture target fire while moving. Moving shot that toggles with an attack command instead of only having a small window aka true BW vultures. Different full damage to shield system. (something seemed wrong with yours). Eco triggers that ONLY target not currently being mined mineral fields. As far as I can tell yours don't do these making the third workers per patch really inefficient (as you can see in the graph). BTW, do you somehow have SC2 not playing at fastest? well when i initially tested what you're calling eco triggers, it seemed to always choose an unmined mineral patch by default anyway, i'll look into it more with more workers. Shield damage seems right to me but i recently reworked the Siege Tank because it's Splash wasn't working correctly at all. Not sure what you mean about the vulture stuff  I definitely have SC2 on fastest. | ||
|
decemberscalm
United States1353 Posts
On September 29 2013 13:39 MavercK wrote: well when i initially tested what you're calling eco triggers, it seemed to always choose an unmined mineral patch by default anyway, i'll look into it more with more workers. Shield damage seems right to me but i recently reworked the Siege Tank because it's Splash wasn't working correctly at all. Not sure what you mean about the vulture stuff I definitely have SC2 on fastest. What I had to do was mark mineral fields as a custom value 0 or 1 to represent mining or not. This allowed me to reorder the worker to harvest ONLY from a mineral field who had custom value 0 (not currently being mined). The rest of our tweaking mostly revolves around getting the second worker to stop being so smart at pathing. So if you have a vulture and try to right click a high templar while moving, it cannot specifically target the high templar. The moving weapon doesn't receive specific commands (weapon ordered to attack=dead stop). I made an ability - target unit with flag transient sharing a cooldown with the vulture weapons that smart commands to activate. So right clicking a unit target fires it. A+click doesn't work, but its a functional target fire. What size is your fighting spirit map dimensions? I've got pretty slow units to attain the same rush distance on a 1-1 bw FS. edit: Oi, and I thought me and Lalush figured out what was causing units to dead stop. Seperation radius to 0 or .001 and still not working properly, default sc2 unit speed, and lower decel. | ||
|
MavercK
Australia2181 Posts
On September 29 2013 13:15 decemberscalm wrote: edit: Oi, and I thought me and Lalush figured out what was causing units to dead stop. Seperation radius to 0 or .001 and still not working properly, default sc2 unit speed, and lower decel. the issue with that was my unit spreading trigger, since it needed to find a point between the two units stacked, if they had a seperation radius of 0. it would stop that dead stop thing, but air units wouldn't spread out, they'd simply move south together, still stacked lol. I'll try it again now since i've changed my unit spreading trigger since then to use a force effect instead of the triggered "move unit instantly" as this disjoints projectiles. | ||
|
decemberscalm
United States1353 Posts
On September 29 2013 14:08 MavercK wrote: the issue with that was my unit spreading trigger, since it needed to find a point between the two units stacked, if they had a seperation radius of 0. it would stop that dead stop thing, but air units wouldn't spread out, they'd simply move south together, still stacked lol. I'll try it again now since i've changed my unit spreading trigger since then to use a force effect instead of the triggered "move unit instantly" as this disjoints projectiles. Oh no no. Entirely different issue. I have an automatic spread already. Most obvious example of what I'm talking about (as discovered by lalush). Vikings stacking and trying to micro vs colossus. When units are overlapping each others radius, they will dead stop when attempting to do a moving shot. Deceleration is ignored. Hardcoded apparently. So setting separation to 0 seems required for reliable moving shots. | ||
|
MavercK
Australia2181 Posts
On September 29 2013 14:14 decemberscalm wrote: Oh no no. Entirely different issue. I have an automatic spread already. Most obvious example of what I'm talking about (as discovered by lalush). Vikings stacking and trying to micro vs colossus. When units are overlapping each others radius, they will dead stop when attempting to do a moving shot. Deceleration is ignored. Hardcoded apparently. So setting separation to 0 seems required for reliable moving shots. yea was referring to the same thing | ||
|
decemberscalm
United States1353 Posts
Aahahha. Yours work fine. I'm using the idle spread but tweaked for the mutalisk spread out, which won't "go south" due to how it works. It doesn't need to find a middle. Quite convenient. Looks natural too and only engages when not moving and no orders are currently given. Data based so no trigger overhead. Mutalisk in sc2 look unnatural going BW speed x.x. | ||
|
[SC]Django
Poland44 Posts
http://fc05.deviantart.net/fs70/f/2013/069/e/9/zerg_compare_by_phillgonzo-d5xjxg9.jpg http://i.imgur.com/55KVYS0.jpg | ||
|
SsDrKosS
330 Posts
SCV WITH 60 HP  The most op unit ever made in bw :p | ||
|
couponbook
United States4 Posts
| ||
|
MavercK
Australia2181 Posts
On October 07 2013 01:52 couponbook wrote: how do i make it work? i get error "sc2bw_-_music.sc2mod". nothing works. play it on battle.net in the arcade. | ||
|
GtC
United States546 Posts
| ||
| ||
