deepstrasz
Map Reviewer
- Joined
- Jun 4, 2009
- Messages
- 20,219
Maybe because it doesn't really tell us much?Campaigned-scoped triggers for campaigns. How come no one has mentioned this yet?
Maybe because it doesn't really tell us much?Campaigned-scoped triggers for campaigns. How come no one has mentioned this yet?
Maybe because it doesn't really tell us much?
I actually did mention this a few back IIRC.Triggers/scripts that applies to all maps in a campaign. Instead of having to copy/paste triggers into all the maps every time you want to change or add something.
Why implement something that already exists?I remembered another one!
17) Let us manipulate individual Doodads with triggers! Play animations, etc.
That's where you're wrong. More variants of the same thing just adds redundancy, and people will get confused at what exactly each one does in particular from each other. Like deepstrasz said, new natives and stuff are meant to broad possibilities from stuff we either couldn't do or had pretty annoying workarounds, not because someone is lazy to do small and easy tasks.A lot of my proposals are easy to do with triggers. Its still nice to have native variants of all those.
Again, you don't seem to understand the actual point of adding new stuff in the editor. It looks like you're aiming at new players, who don't know how the game works and are trying to use the editor, thus, not experienced. People who don't know how to do something, they learn and get taught, and then get used to do their thing. People scared of Trigger Editor Button? Sounds like something a 50-80 year old person would say. Yeah my mother says this often when working on pc, it's pretty much an irrational fear. Again this has nothing to do with memory leaks nor bugs (ironically each patch they release always brings new bugs)(...) it helps people who don't know how to trigger and are scared of Trigger Editor button, it reduces amount of potential memory leaks, it doesn't introduce new bugs, etc. Plus even for trigger pros new natives would expand their capabilities.
Basically an item with expiration timer like units, but shown expiration timer in items NO way.As for item creation, the main point was items with duration, so they would automatically despawn (and preferably show expiration timer, like units).
Have access to what data exactly? Owner of the buff (the player who casted it)?Buffs still carry some kind of data, presumably a snapshot of ability at the moment of casting (in fact this should be interesting to test with new ability editing at runtime). We should have access to that data.
And Buff handle would be extremely useful for all kinds of triggered effects.
Add Buff is very easy with dummy units.
No, it would make this pretty much useless, since we already have hashtables and unit index method.I got anotheronetwo.
18) Add SEVERAL (ideally, a user-set number) Custom Value fields to units. And maybe also in different data types. Custom Data (int), Custom Data (bool), Custom Data (real), Custom Data (string), at least 3 of each. Would make coding so much more flexible.
Since when Show Multiboard leaks....?19) Make it possible to Show Multiboard to specific players without resorting to getting local player. That would speed things us and prevent possible leaks and desyncs.
Hm? Maybe with Jass, dunno, don't use that. You can't do it with GUI at the moment. Unless you are talking about Destructibles.Why implement something that already exists?
Indeed. Warcraft should have launched with just one spell - Channel. No other spells needed.That's where you're wrong. More variants of the same thing just adds redundancy, and people will get confused at what exactly each one does in particular from each other. Like deepstrasz said, new natives and stuff are meant to broad possibilities from stuff we either couldn't do or had pretty annoying workarounds, not because someone is lazy to do small and easy tasks.
Again, you don't seem to understand the actual point of adding new stuff in the editor. It looks like you're aiming at new players, who don't know how the game works and are trying to use the editor, thus, not experienced. People who don't know how to do something, they learn and get taught, and then get used to do their thing. People scared of Trigger Editor Button? Sounds like something a 50-80 year old person would say. Yeah my mother says this often when working on pc, it's pretty much an irrational fear. Again this has nothing to do with memory leaks nor bugs (ironically each patch they release always brings new bugs)
Why not add visible expiration timers to, say, tooltips? Or item icons?Basically an item with expiration timer like units, but shown expiration timer in items NO way.
Damage it deals per second, for instance. Unit that applied. Ability that applied it. Effects it causes.Have access to what data exactly? Owner of the buff (the player who casted it)?
What's your point with the last sentence?
We need buffs to last after firing the units death event, it's impossible for us to detect which buff the unit had when he died, although black arrow somehow does this.
Yes, because adding every unit to a hashtable, then running a loop to find that unit in a hashable, all to get a value, is so much more efficient than just getting a number that game already keeps track for you.No, it would make this pretty much useless, since we already have hashtables and unit index method.
Eh, loops, lots of data, hassle to make that leakless.Since when Show Multiboard leaks....?
Who cares about Leaderboards?You forgot Leaderboard.
Hey @Wrda try being less toxic, will you?Why implement something that already exists?
I doWho cares about Leaderboards?
You mean like a blue text in the tooltip that ticks down?Why not add visible expiration timers to, say, tooltips? Or item icons?
What about this?3. Allow users to cancel/hide timed life at will (The current native is broken - it kills the unit, instead of canceling timed-life).
Hiding health/mana bars would be great for units with Locust on which spells cannot be cast like Finger of Death. Or, make Locust be more targetable. I mean, it's a real annoyance to create visible Locust units and then another round for those (which are supposed to be hit) but invisible overlapping them. Sure, it's OK for a few units but when you have to work with a dozen... imagine the crazy variables and triggers.- show/hide Temporary health bar under heath bar
K. Swear I'm living this site. Buy!NEIN
Well, if you don't have protoss shields maybe. What's next though, anti-magic shield life bar?Talking of which, ya gits, we could have timed life show alongside health/mana as well, so you can see who will expire by simply holding Alt, instead of selecting each summoned unit.
Well, if you don't have protoss shields maybe. What's next though, anti-magic shield life bar?
Yes, all the bars
Stats - Bars [int]Well, if you don't have protoss shields maybe. What's next though, anti-magic shield life bar?
Well, if you don't have protoss shields maybe. What's next though, anti-magic shield life bar?
Could you be more explicit please? I mean you can use an event with conditions and set the unit to a variable.A way to detect which worker started/finished building.
There's no event response for the worker who is constructing or constructed a structure. So you can't reference to it in anyway.Could you be more explicit please? I mean you can use an event with conditions and set the unit to a variable.
You're right, even if there are events for that. There are only conditions for the buildings they construct.There's no event response for the worker who is constructing or constructed a structure. So you can't reference to it in anyway.
What? Isn't that the already"normal dependencies"? I'm confused.Negative dependencies (i.e. an ability/unit/building/technology/whatever are disabled as long as a specific unit is present or technology is researched).
Dependencies only allow, they can't preclude. E.g. I want Call to Arms be disabled as long as at least one Footman is alive. Right now its only possible with dummy units that are destroyed when a Footman is created and created when not Footmans are alive, but that's very imperfect solution.What? Isn't that the already"normal dependencies"? I'm confused.
Then we're talking about Requirements, not Dependencies. A dependency is about when a unit/building is dependent of another one's stats, this is mostly used for morphed units.Dependencies only allow, they can't preclude. E.g. I want Call to Arms be disabled as long as at least one Footman is alive.
That's a #2 solution. The best solution was added like a few patches ago. You can increase the research level and also decrease it, so you can just create a dummy research and trigger your desired effect, no need dummy units.Right now its only possible with dummy units that are destroyed when a Footman is created and created when not Footmans are alive, but that's very imperfect solution.
That's a great idea, afaik it currently can't be done without using dummy units that are created when the condition is fulfilled. (As you already mentioned.)Negative dependencies (i.e. an ability/unit/building/technology/whatever are disabled as long as a specific unit is present or technology is researched).
I think you didn't quite get what @Trill meant, for one reason or another, but afaik it can't be done with regular tech tree requirements.Then we're talking about Requirements, not Dependencies. A dependency is about when a unit/building is dependent of another one's stats, this is mostly used for morphed units.
A requirement says it all, a unit/building/technology that is required to enable the funcionality/allow further production of stuff.
That's a #2 solution. The best solution was added like a few patches ago. You can increase the research level and also decrease it, so you can just create a dummy research and trigger your desired effect, no need dummy units.
CanUnitMoveToXY takes unit u, real x, real y returns boolean
^Allows map maker to access in-game pathing system to understand if a unit can actually reach its destination.
Here you go:
Now this might be a bit late to say this, but I was just reminded of it today... It would be really nice if "curving" unit (movement) paths would get fixed along with the arrival of Warcraft Reforged.
Creep curving, and how to fix it. (despite the title there's actually no fix or proper workaround for it as far as I know, though one can split up longer stretches into multiple shorter ones to mitigate it)
For those not in the know, basically what happens is that if you want a unit to move from point A to point B, the unit won't move in a straight line (even if the points are aligned perfectly, it's especially noticeable if the points are from straight up-down), instead the unit will "curve" a bit.
Here's some of the screenshots in the linked thread:
![]()
![]()