- Joined
- Apr 3, 2010
- Messages
- 1,889
Good luck. xD
I wish that they had support for 16:9 screen display instead of 5:4(?)
Changing the resolution to 1920x1080 seems to only change the text size and
not really make it look to much better cause it's an old game.
I manually changed my monitor to the square view and it looks sooo much better.
Although I have to put up with not having a wide screen display.
I do the same with smash bro melee on my TV these days. :s
This could potentially break some maps in Wc3 and other things but it'll likely be worth it.
How did you came across that info?(...)
Can't say much here except that I leave the implementation validation side to Blizzard. Last time I checked wc3 used 35 threads but I think you were talking about the single-core single hardware thread limitation wc3 has?
(...)
There are several ways to do this. The easiest is probably a trick using bloodlust with the only known downside that you should not use other bloodlust based abilities with a non-zero scaling factor in your map which could be casted on the manipulated unit as this will interfere with the manipulation.I don't think there is a proper way to deal with this. -1.00 value that is supposed to solve everything removes just life bar, not selection scale, and bigger negative values starts to store memory that eventually leads to crashing.
Uh.. no, srry. Voice actors will not come back just for the demo campaign.Add voice-acting to the demo campaign outside of the actual demo
Can you explain this a bit more? I don't understand it I think. Also I can't think of a scenario right now where you could not easily use a hashtable..I'll find it more useful for an on initialization function for storing z values of a lot of destructibles.
Storing 100 different z values for each unique destructible on the map is impractical.
True.Anyway besides anyone that would actually find a use for this kind of function should have a good enough understanding with being aware of desyncing potential.
True. To be honest I don't know what's behind the decision that destructibles have to use the pathing map and the others don't..Doodads have this functionality as well.
Hm, can you provide a visual mock-up? So far I think that is by far not useful enough.The object editor already has this View dropdown menu for example, although eliminates entire categories.
This can be potential to hide code in the trigger editor that you don't want to see clustering your screen either.
The only valid reason I can think of to leave it this way is that currently we can enable local files for a player via editing the registry. Which is cool but the program must not be able to do that. Limiting it to the wc3 folder is essential. Maybe I should add "Enable local files by default" to the list? Can't be that harmful, can it?NONONONONONO! Don't say dat.
That is extremely useful in so many ways not many can even imagine.
While that tutorial is bad because the author does not understand how exactly his code works, it's true, that point should not be on the "important points" list. Hm, maybe I should really add a "convenience" list with things that can be done currently but only with nasty workarounds.Well we have some control over that, we can remove them with Remove Item Shadow so that is a bonus.... However it would be nice to have full control.
What do you mean? It's already on the list, right?If They Can Fix The Save Game Bug ! I Really Hate That Code Saving in Custom Maps !
Yep, after discussion in another thread I changed my mind and will put it on the list. Its too cool for the little unfair advantage someones gonna have.I wish that they had support for 16:9 screen display instead of 5:4(?)
Yes but the goal is only to not break most of the maps, so that's fine.This could potentially break some maps in Wc3 and other things but it'll likely be worth it.
The real people here want real widescreen support, currently the screen is only really stretched.Widescreen is supported. If you are talking about the camera distance, it's completely different thing.
Uh, some simple process analysis program : o..How did you came across that info?![]()
Uh.. no, srry. Voice actors will not come back just for the demo campaign.
I know it will never happen but I got a dream that one day we will have Blood Elf, Forsaken, Draenai or Naga races in melee maps.
There is some project I have seen that features these races, but I don't know where it went. It's called Warcraft III Nirvana.
And i highly recommend it.Its good.There is some project I have seen that features these races, but I don't know where it went. It's called Warcraft III Nirvana.
I think its finished and on Moddb.There is a thread about it on the hive somewhere as well.Is it finished? I haven't seen it. This is exaclty what I want if this is what I think it is.
Good idea. Do you happen to have a list?1.27 to add more functions to GUI that can only be accessed via JASS
What is OE?and also complete control over OE through triggers
I'm against this, it's a case of too much work for too small benefits.and ability to create new races.
What is OE?
1.27 to add more functions to GUI that can only be accessed via JASS
Good idea. Do you happen to have a list?
What is OE?
I'm against this, it's a case of too much work for too small benefits.
I think Patch 1.2.7 won't come out, because Blizzard is mostly workng on Heroes of the storm, WoW warlords of dreanor, or SC2 legacy of the void And Overwatch. Even If There is Going to be Anything said about WC RTS, It COULD be WC 4, not even WC 3 1.2.7.
So your point is "improve syncing" I guess. That could be in the list but I have seen so many threads about syncing that I'm not sure what to suggest here.Haven't seen sync natives in list? It takes ages to sync a string whereas chat messages in game synced instantly.
About what exactly are you talking here?I just wanna see the black screen cinematics issue fixed.
So your point is "improve syncing" I guess. That could be in the list but I have seen so many threads about syncing that I'm not sure what to suggest here.
Should the SyncStoredString native (and other ones not working) work? Would it be ideal if the Sync natives could be queued and executed with a new native which halts the thread until all players are synced to avoid hundreds of lines of additional code (as seen e.b. in Nestharus' lib).
If I knew what exactly the natives did, proposing a solution would be easy..
Here other list optional:
Undecided:
- Get data of the editor objects of a unit through triggers, --> (Here details) http://www.wc3c.net/showthread.php?t=108314 (Optional, Ability, Doodad, Buff, etc)
The best would be if the "<Ahea,DataA1>" system was extended to work on all fields and also was able to be used in triggers. I think this is a case of too much work too small gain though, as some attributes are allready reachable via trigger and for the other ones you can use plain old variables or the tool at the link you gave. I decided finally to make a new category, namely "Convenience" where I will put this.
- Rotate the models of an unit with triggers in angles X,Y,Z , ingame. This refers to getting and setting of the unit's pitch/roll. Also change model of unit/doodad/etc with triggers ingame. Setting pitch/roll is possible with some heavy limitations, will take this in the list. Changing model at runtime can be done to some extent with playing a doodad animation or using the passive transformation trick on units. I think this is enough. Thinking about putting it in the "Conveniene" corner..
* functionality full of the function native: SetUnitScale(unit, X, Y, Z) -> Enable Y and Z.
Hm, apart from some nice visual effects this is not of too much use, right?
- Control full of Missiles in warcraft 3 to through triggers (Needs: More Attacks Event "begins, launch, finish" , detection of damage in triggers for all units, also detection of launches projectile and impacts, etc)
The attack events and the getdamagetype proposals are already in there, which enables a lot in the realm of projectile detection. As for complete control over projectiles, I thought about this but it's just an huge amount of work to create a whole projectile API which can be done easily with a projectile system by the mapper.
Unfinished:
- Needs: A function or spell that does see the controls and skills of a unit allied/enemy, not touchable.
Hm, this should probably be an alliance setting and would be rather easy to implement.. hm hm
- Add Triggers for spells in the editor, cooldown modifiable, requeriments alternate, set position X/Y customizable, detection of cooldown (begins,finish), detection of effect passive, etc.
Cooldown is in the list, the rest can quite easily be done by the mapper.
- Stacks Customizable for spells, aura and buffs, (Example, orb lightning + barrage, Wind Walk + Wind Walk doble Stack, etc.). Also Customizable Aura equal to Channel.
Srry, no. This undermines all hardcoded mechanics and should be left to the mapper as it's not that hard to do.
- Buffs with Events and Trigger Control. (Add custom Buffs equal to Channel in the world editor)
I do not see a big use for this.
-Correction and update of objects, of type image. Update of lightning effects and triggers.
Ok, the image API is not finished, but can you specifiy what exactly you want updated (except probably that images no longer need an alpha border). And what should be changed about lightning effects?
- Create more than 1 screen filter and create more than 100 floating texts.
I also would like that but I think it's ok as it is. Everything else would require a lot of new natives and create confusion. Floating text limit increase should be easily codable, will take it in the list.
- Detection and customization of Cheats in single player.
Who wants to cheat in such a game should do so imo. Such an addition is also not worth it as players can simply change the script file.
Other:
- Add to Vertex coloring the white hues for models.
Not sure whether such a functionality is present in the engine.
- Change the effect (birth,attack,walk,etc) of launch SFX model how a normal model.
Do you mean that special effects should be able to play animations?
I hope it's not too exaggerated what is mentioned in the list XD...
About what exactly are you talking here?
I can comfort you that if they don't completely remake wc3 with a new codebase (which they won't) that your old computer will be able to run any ("hd") update for wc3.
-Fix the mouse-mash exploit (mashing the left mouse button (clicking/selecting it rapidly) on a building structure will make it build faster with each click)
-Add AA (Anti Aliasing)
Some more suggestions:
-Fix the mouse-mash exploit (mashing the left mouse button (clicking/selecting it rapidly) on a building structure will make it build faster with each click)
-Add AA (Anti Aliasing)
-Add real-time shadows and HDR (better lighting FTW)
-Make Warcraft 4 xD
actually, according to source code of WC3, it uses a loop to increase levels one by one until required. there are no real reason to not have negative loop function as well, just oversightAllow set upgrade level
should not be implemented, as the work to make this bug-free probably far outweighs the convenience benefits, which can also be reached by using a workaround
//these for object detection
native GetNearbyWidget takes real x, real y, real radius returns widget
native GetNearbyWidgetOfType takes integer widgettype, real x, real y, real radius returns widget
native GetUnitNearbyWidget takes unit u, real radius returns widget
native GetUnitNearbyWidgetofType takes integer widgettype, unit u, real radius returns widget
native TriggerRegisterWidgetInRange takes trigger whichTrigger, widget whichWidget, real range, boolexpr filter returns event
It is impossible to destroy global variables in WC3. Local variables automatically are destroyed on function return due to the stack nature of function calls.GUI trigger actions for destroying variables, I'm aware it's already easy to do via custom script -- but there is plenty of people that don't. Less custom maps leaking is always a plus.
Makes no sense. Are you referring to the path finder overload that occurs when a player tries to move several dozen units at once?* Multi-unit lag fix (there's a ton of lag if there are too many units around the map; the delay is basically unplayable could be fixed by optimization probably)
It is impossible to destroy global variables in WC3. Local variables automatically are destroyed on function return due to the stack nature of function calls.
It is impossible to destroy global variables in WC3. Local variables automatically are destroyed on function return due to the stack nature of function calls.
Makes no sense. Are you referring to the path finder overload that occurs when a player tries to move several dozen units at once?
By destroying variables, I meant things such as unit groups or points, where it's a very common mistake by newer map authors to keep leaks in their map. Hopefully, this would prevent that problem.
And yes, I'm referring to the pathing delay. It's a factor that's very problematic for many maps.
erh what if handle was saved in hashtable or into another, global var? Destroying it will cause malfunction. So compiler have to check such cases as well? I'd say "no", it's up to coders to decide when object should be destroyed.