I've been invoked!
@HerlySQR @Daffa why hello there
@Frotty long time :D
If issue persists after all help from Frotty, it is advised to provide reproduction steps - step by step what you do to encounter the issue.
@GhostHunter123 your reply is much appreciated.
Unfortunately, both GetEventPlayerChatString and GetEventPlayerChatStringMatched are intended to work with TriggerRegisterPlayerChatEvent rather than TriggerRegisterPlayerEvent - this is implicitly suggested by the very location of mentioned...
You do not need Warcraft3 installed to do compilation checks. I'm working via VisualCode with vJass and Wurst both. And only when required, I'm injecting .j code into the map and testing. Even wrote a tutorial about this.
@AGD thanks for your feedback, this complements latest addition of UnregisterNativeEventHandler() nicely.
RegisterNativeEvent: Return triggercondition handle on event register
has been pushed to github repo. Opening post has been also updated.
@AGD I believe you want me to update both of the following, yes?
function RegisterIndexNativeEvent takes integer whichIndex, integer whichEvent, code func returns nothing
function RegisterNativeEvent takes integer whichEvent, code func returns nothing
Given the existing return type - void...
Well, that changes things, thanks for sharing @SinisterLuffy . So, I don't see anything wrong with adding unregister function. Hope you didn't wait for my update and instead modified library by hand in your map ^)^
@Bribe, please correct me if I'm wrong, but removing conditions did not yield expected results in the past. In order for one to be truly sure about event-handler being removed, one had to destroy trigger handle and re-add all the conditions except for those which are to be "removed". Has this...
@_Guhun_ Thanks for your input. In general, releasing new resources that cover base/primitive subjects which fuel high-level stuff above (e.g. spells and effects) should be avoided. Bribe brought you a all-around resource which has found many extensions and usages such as Vector<T> and List<T>...
@SinisterLuffy and others, could you provide a more elaborate explanation? After all this time, I still believe the library feels complete as is. Perhaps I'm wrong.
And thus, a life example (actual need, not a nice-to-have) would help - all of us.
On hive meet people from many different IOT and programming domains, and more often than not, from none at all - hobbyists. Each group has their own preferences, and one cannot possibly satisfy them all. Provided naming is biased towards c-syntax rather than the java one. Thanks for your input.
@SinisterLuffy just bumping so that you know your comment has been noted. Since the launch of Reforged I haven't been working with WE, really. Compatibility with existing WE version would have to checked first, then status of custom functions that I'd added - see if some aren't deprecated...
ITT dev team pretty much did nothing since my last pull request. You can check discord history/ github history. No posts, no tests no pull requests. They do not even test changes because they are too lazy.
Got ownership of of soundwire within linux drivers/ and co-ownership for sound/soc/intel...
List<T> already defines front/ back and first/ last.
"Mandatory" is a very subjective term. History shows that successful jass collection snippets were small. Range of utility functions you've posted out there won't be used by 98% users.
Professional approach is to wrap such utilities within...
If you speak about collections, then non-generic versions are available in plenty. E.g.: Nes' github has both non-generic and semi-generic collections.
I'm happy with my solutions, which after some time became popular within community due to them being easy to use and jass-friendly (cascade)...
.erase expects argument of $TYPE$Item type. Your example compiles only because vJass is not type safe.
I've added .removeElem method for conveniency some time ago. It will be renamed to .remove in nearest future - deprecation period slowly comes to an end.
exists: find(...) != 0
no indexOf per se.
You see, the initial version had dozens of methods much like its c++ inspiration. However, after brainstorming for a bit and reading some feedback from my jass bros, I've decided to strip container libs (both, vec and list) from most of...
To me this looks like sophisticated "event".
Something similar can be achieved with typical event library:
- register event handler
- retrieve event trigger
- evaluate trigger
Both are "lightweight in implementation".
Thanks @IcemanBo for providing the examples!
I made that mistake in the past, should have added different method for pop/pop-cascade. Didn't remove it for compatibility reasons.
I could start deprecation process now, like I did for several methods in multiple libs, although..
..in JASS world...
It uses newest RegisterNativeEvent library already - RegisterPlayerUnitEvent requires it. If I'm missing something, please, quote code part so I can fix it.
START / FINISH - obvious. FINISH is mainly for the sake of completeness.
CANCEL - intentional construction stop event e.g. ESC press...
I've already explained why safety/ accuracy is needed in my snippet's thread and shortly here. My snippet is a work not only of my own, but also @Troll-Brain's. I've expanded on TB idea and validated more cases.
None of the math included in ConstructionEvent is made by mistake or could be easily...
Even if so, I'd probably add it as extension snippet rather than append new code to existing one.
RegisterNativeEvent is supposed to provide one simple functionality without any real overhead in form of blizzard-like streamlined api. Anything that comes after is what I call the noise.
ListT core should be left as simple as possible. If jasshelper properly eliminated constants and unused methods then it would have been an entirely different case. And btw, I don't care about optimizer, this job should be done on compiler level.
Back to the topic. getRandom implementation for...
First things first: thanks for your feedback, appreciated.
In general you want a better documentation. I haven't noticed any code changes per se that you would like to see.
- Ingredient list does not have static size of 6, the size is arbitrary. See the 'test' methods again. This...
I believe we do not approve uncompatible resources. You can leave such subjects in The Lab.
You cannot expect users to use outdated software. Most users moved to new patch already. Even Chinese ladder did.
Ask a mod to move the thread or close it.
As stated earlier, both item-related libraries cannot be approved. In any case, one would have to ungraveyard older scripts and grayveard these instead. Until Blizzard folks fix all the issues, subject is closed.
Please ask a mod to move your thread from The Lab to Submissions subforum and delete this one.
By creating new thread you've negated all the topics and issues take have been discussed and addressed in previous thread. Let's keep the history of this subject coherent.
One cannot ask for more...
If what you say is true, then the order of execution and event fire is different in 1.26 than in patches 1.28+.
Currently, order "stop" that will be auto invoked for unit attempting to pickup item with full inventory will happen BEFORE artificial move is triggered. The only exception for the...