SDE, BWAPI owner, hacker.
The selection glitch either doesn't work anymore or is extremely difficult, so maybe.
Let me show you how to hump without making love.
A lot of people have been claiming that 1.18 uses L1 latency, but I haven't seen any proof of that. Can anyone confirm?
Unless they patched it already, yea the PTR was launched with L1 instead of L2.
None.
A lot of people have been claiming that 1.18 uses L1 latency, but I haven't seen any proof of that. Can anyone confirm?
Unless they patched it already, yea the PTR was launched with L1 instead of L2.
But how can you prove it's L1?
None.
Let me show you how to hump without making love.
A lot of people have been claiming that 1.18 uses L1 latency, but I haven't seen any proof of that. Can anyone confirm?
Unless they patched it already, yea the PTR was launched with L1 instead of L2.
But how can you prove it's L1?
Not sure, other people looked into this. Mostly TL, might find more information there.
None.
A lot of people have been claiming that 1.18 uses L1 latency, but I haven't seen any proof of that. Can anyone confirm?
Unless they patched it already, yea the PTR was launched with L1 instead of L2.
But how can you prove it's L1?
Not sure, other people looked into this. Mostly TL, might find more information there.
I've only read baseless statements about the latency being L1 everywhere I've looked. I personally confirmed the change in latency in 1.17.0, which is why I updated the Liquipedia LatencyChanger page:
http://wiki.teamliquid.net/starcraft/LatencyChangerThe 1.18.0 patch uses anti reverse engineering techniques which makes it harder to actually confirm that the latency changed to L1.
None.
*sluuuuuuuuuuuuuuuuuurp!* Melee Map Maker
just dumping my comments from the google doc here, so they are in a more permanent spot to refer to:
About the problem of "Fake Cliffs" (as referred to by by Koreans) or "Tank Holes" (or "Templar Holes", "Ghost Holes", "Zergling Holes", depending of the most devestating units that can be dropped in there):
The problem is that there are many small spots on many kinds of even double cliffs (like used for cliff clutter), it is particularly bad for Ash World. Additionally, there is no direct transition for backside cliffs to unwalkable terrain (like water and its tileset-specific counterparts), leaving a gap bewteen the two clifss that often allow units to be dropped there or even create a path where units can walk (again Ash World is particularly infamous for this)
This is mostly a map specific problem and especially the more severe cases are just a symptom of a lazy or unaware map maker. Good debugging tools (read: toggleable walkability overlays for both map and palettes) should be first priority here before considering changing stuff the tileset.
The problem though lies with legacy maps depending on exact walkability properties for things like tight (sometimes unit size selective) choke points, wall-ins and the likes.
Additionally changing walkability properties of common tiles like cliffs edges would invariably induce a ton of pathing related issues into existing maps.
Overall I feel like this, like ramp support, is an issue that cannot be summarized into one simple point but would need a lot of very careful consideration and fine tuning on a tileset-by-tileset basis.
About the question of whether to add more tiles/doodads with unusual properties:
Making Installation actually melee compatible by adding creep tiles as well as some buildable terrain and enabling use in melee mode would be a start... Buildable High Ground for for not just Space Platform would also allow for new map concepts (or at least for less forced tileset choices).
However, I would much prefer to have serious bugs fixed and a stable editor with extended debugging features and improved interfaces at hand first before I chose which cherries I want on my cake.
(speaking of the cherries on the cake: Making Unit Sprite 204 (Floor Hatch [Unused]) more useful as a deco element and building indicator would be a personal wish of mine (just make it non-selectable like scarabs and installation doors, ideally tweak it a bit to not prevent building placement in its vicinity and not hide burrowed units or mines from the players' view...)
I am not quite sure what you mean with the "clear collision check". I can tell you that buildable tiles with unwalkable subtiles (like many of the little rocks and bushes in Ash World terrain or the unused rock doodads for Desert High Dirt) are a desireble thing to have, because they block building (rendering them effectively unbuidable) but still allow for free creep spread, which makes it possible to create a tight wall-in against a cliff at the bottom for Zerg (normally the gap would prevent this).
If you actually mean ramp and bridge tiles (and lots of other doodad tiles) which seem to have an affect on pathfinding (hard to pin down exactly, but one can definitely observe the difference in unit behaviour in-game) despite being fully walkable – this may actually have been put in deliberately to help units not getting stuck on doodads and small chokes (with BW pathfinding being as it is...)
Post has been edited 1 time(s), last time on Apr 2 2017, 5:01 pm by Freakling.
None.
Making Installation actually melee compatible by adding creep tiles as well as some buildable terrain and enabling use in melee mode would be a start...
This is something I always wanted to see, hopefully there's time for it after the essentials.
I imagine they could just make it so normal substructure and floor terrain tiles are buildable, as each of those terrain types has a sub-terrain (plating) that looks unbuildable and could be left flagged as unbuildable.
🤙ðŸ¾
*sluuuuuuuuuuuuuuuuuurp!* Melee Map Maker
The tileset would need a lot more to make it an actual feasible choice for a serious mêlée map concept, though. Being stuck with those very tight staircases as ramps is definitely limiting (if you have ever played the Protoss level Into the Darkness (I think it is called) from the original campaign and tried to micro the dragoon up and down those ramps, you know what I mean...
Before I get overly excited about how to improve existing tilesets, I need a stable editor with good extended functionality to actually use any shiny new stuff that may come out with...
None.
Find Me On Discord (Brood War UMS Community & Staredit Network)
https://us.battle.net/forums/en/starcraft/topic/20753916555Details on the update:
Specific Changes & Improvements
The Mac *Beta*
Updated the background image for Chat Channels
Filter by Game Type available in the Join Game screen
Increased the password length allowance
FPS cap set to 200
Text size has been reduced in several panels to better utilize space
Up to 256 messages are saved per Chat session, and are displayed in grey text when navigating back to the Chat Channel
Chat colors are now unique based on source type: whisper is pink, channel is dark blue, info is yellow, emote is orange, join channel is green, old messages are grey
Message prefixes, such as Usernames, in the chat log appear as a darker color than their message
Players can respond to a whisper in both the UI menus and the Game Client with the command ‘/r’
Attempting to reset the hotkeys will prompt the user with a confirmation panel
Game information no longer covers multiple lines
Private and Replay icons now appear beside the player count
Expanded crash report logging to improve troubleshooting
Bug Fixes
Fixed various crashes
Fixed mouse speed in windowed mode
Fixed an issue with players disconnecting after inputting Korean characters
Navigation buttons and hotkeys have returned to parity with 1.16 values
Map downloads getting stuck in game lobby
Known Issues
UTF-8 is not supported in Chat Channels; work is required to update the legacy chat system
Hotkey configurations still undergoing iteration
Group selection hotkeys 6 and 8 are not functional on AZERTY keyboards; being fixed for next build
*sluuuuuuuuuuuuuuuuuurp!* Melee Map Maker
Seems that they are still occupied with crash bugs, user interface issues and just generally getting the whole gaming aspect running smoothly.
Guess we need to have some patience.
None.
It would be cool if they'd give the player a choice between modern and classic mode, especially when it comes to campaign and UMS maps. Classic would use the old BW rules (12 unit selection, etc.) and modern would borrow some stuff known from SC2 like workers gathering automatically on rally or being able to select multiple buildings at once. Revisiting the original campaign and giving it some difficulty tweaks and improvements would be great too, since we've all played it 100000 times. Maybe adding some new content like acheivements that won't interfere with the story. I think it would really make BW great again and give a whole new dimension of possibilities to custom map makers. Blizzard should consider this if they really want to make this game alive.
None.
Adding a bunch of superfluous SC2 features won't make the game any better. If you want SC2 features, go play SC2.
Giving us the option to use them would be nice, but I don't think it'll happen.
Hell, when did this emerge? I don't wanna miss a party!
A thing about trigger acceleration that haven't been specifically pointed out. Current techniques (spamming the wait(0) action and similar) allow us to force the SC engine execute triggers every second frame. It was great if there was an option to check triggers on every game frame.
Some triggering techniques will benefit from this: unit movement detection and a special technique of unit death detection that utilizes the feature of unit being unmoveable to another location for 1 frame after (during) death. Currently the latter works with 50% probability and movement detection isn't as precise and instantaneous as it can be.
However, I believe the change
might affect an existing UMS maps if the behavior of the wait action was altered (it's an alter of the original engine behavior after all). To my opinion the best option is a map setting that is off by default (which means the old maps unaffected).
I'm not sure if all the new trigger actions and conditions proposals can or will be implemented without interference with the core engine. The thing that is obvious that all existing actions and conditions must work exactly like they did before. This includes (but not limited to) such "features" as:
- Differences in units count with bring at least/at most/exactly when referenced to buildings under construction and units in bunkers and transports.
- Create unit doesn't invalidate the location such that the successive bring won't detect newly created units.
If I was asked about the minimum list of backwards compatible additions to triggers that require minimum amount of work I would list the following:
- Increase conditions and actions limits (which are 16 and 64 respectively now).
- The change that I've mentioned about triggers check acceleration above.
- Arbitrary integer math operations with death counters, score and resources (allowing both constants and mentioned variables as both operands): addition, subtraction, multiplication, division, remainder, probably with integer exponentiation and logging. (The first two require us to generate lots of redundant triggers to accomplish, and the next two increase triggers number to the point where it becomes practically infeasible.)
- Comparison conditions between death counters, score and resources. (Currently these are only limited to a variable versus constant.)
- Generation of random numbers from a given range from 0 to b in a units death variable. (Though we are currently using random switch for this, generating a uniformly distributed random value on a segment, where b isn't a degree of 2 is tricky or very hard to do.)
- An option to display different leaderboards and etc. for different players. (Currently the display leaderboard and etc. actions affect all players and we have to use EUD techniques to detect the player number and execute the action locally on a players machine).
- An action that forces deselection of units of certain type for the given player. (Currently we mess with the give units action to simulate this, which is quite an expensive action in terms of cpu, affects units orders and forces other units to stop attacking or following.)
- An option for smooth center view in multiplayer (jump center view behavior preserved too).
- An option to restrict the camera magnification for third person maps.
- A possibility to remove map revealers at location (via the new action)
More additions to the triggers system that I would love to see but that may require more work or changes. (I know more of these are already listed in the document but below is my personal preference from those.)
- Referring to unit via it's ID (not only through location).
- Allow to retrieve a unit ID that is created via triggers.
- All things that mentioned by others about checking and changing units stats from hit points to weapon and attack types. However I believe just hit points, shield points, assigning shield to an arbitrary unit, and magic effects are the most important of these.
- More integer variables for internal usage (the thing we currently use death counters for).
- A possibility to run triggers for players 9-12.
Several crashes worth fixing that I can remember off my head:
- The crash that is triggered by creating many map revealers at a single point. (Can't remember the exact scenario to reproduce, but I'm pretty sure I was encountering one.)
- The crash that involves some unit death animations: when a ghost dies at a certain angle (sometimes encountered in so called "snipers" maps).
- A crash that happens while the player's vision is off for himself due to player's units move in and out of vision (that is provided by other players).
The are also some changes from the proposed list that need attention, because they break backwards compatibility with some UMS maps:
- A possibility to use players 9-12 as computer players.
- When a unit gets lost in the fog of war you do not lose selection of it.
- Right now if you have two players allied, and you constantly in the triggers set one of those players to allied, this disables you from attacking BOTH, but it should just disable you from attacking the one.
The following from the list is actually a nice thing to have but the phrasing is a bit wrong: "Allow for an option in triggers for them to only execute once when all the conditions are met, and in order to execute again these conditions must be unmet." I would say "in order to execute again these conditions must be unmet at least once before they met again."
Anyways! Let's hope at least something of those will be concerned! Maybe I can remember more important things later.
Post has been edited 7 time(s), last time on Apr 6 2017, 6:21 pm by Wormer.
Some.
Adding a bunch of superfluous SC2 features won't make the game any better. If you want SC2 features, go play SC2.
Nice logic. If you do not want SC2 features, don't play modern mode.
None.
I was just making a map for the first time in forever and came to the realization that a way to quickly disable triggers in the editor (something akin to commenting out code) for testing would be invaluable, rather than having to mess with or delete the trigger.
this too shall pass
Find Me On Discord (Brood War UMS Community & Staredit Network)
I was just making a map for the first time in forever and came to the realization that a way to quickly disable triggers in the editor (something akin to commenting out code) for testing would be invaluable, rather than having to mess with or delete the trigger.
A great thing for testing maps would be being able to skip the 5 second countdown in the lobby... just BAM instantly into the game.
Math + Physics + StarCraft = Zoan
I was just making a map for the first time in forever and came to the realization that a way to quickly disable triggers in the editor (something akin to commenting out code) for testing would be invaluable, rather than having to mess with or delete the trigger.
That exists. Just add the "Never" condition to the trigger.
We can't explain the universe, just describe it; and we don't know whether our theories are true, we just know they're not wrong. >Harald Lesch
I was just making a map for the first time in forever and came to the realization that a way to quickly disable triggers in the editor (something akin to commenting out code) for testing would be invaluable, rather than having to mess with or delete the trigger.
That exists. Just add the "Never" condition to the trigger.
Not quick enough. And doesn't work if you happen to have used all conditions.
Can't you just untick all trigger conditions, or is that a lie?