Custom JASS Natives - (Requests & Submissions)

[Waffle]

TSA useful for reset OP limit counter. (i actually found a use that made sense believe it or not)

 

[Malhorne]

There is many ways to reset op limit counter IIRC.
But I don't really remember them ^^'

 

[edo494]

TriggerSleepAction
ExecuteFunc
TriggerExecute
TriggerEvaluate

Im pretty sure all of those will reset the OP counter

 

[Malhorne]

Yeah that makes sense.
But I though there was more

 

[WaterKnight]

TSA lets you stay in the same thread but it is not available in triggerconditions. Anyway, it makes the actions vaguely delayed, so it's often not suitable for real gameplay mechanics. If you are at the point that you hit the oplimit, you are likely to strongly strain the performance, which should be avoided. Dangerous parts should ofc be outsourced in separate threads. The only time lags are granted are inits and pauses. Since those are linear, static, limited, it does not really matter how you realize them.

-->what I want to point to: Avoid ExecuteFunc because if you call it with a dynamic argument, the compiler cannot safely rename the functions and you miss the compiling advantages. Apart from inits and maybe special cases, avoid TSA. If you scrap TSA, you can just always go with triggerconditions as they are literally superior to triggeractions.

 

[Waffle]

like i said i found a use that actually does make sense.. (its in a huge init function.)

Also.. you really should not go shitting on functions just cuz you don't like it. a function does what it does, it may not behave as is intuitive, it may even be broken and buggy but the hatemail just discredits you.

If you have issue with TSA (obvious) then please note specifically in what circumstances it should be avoided and stop there.

misc notes:
a) Warcraft may be multithreaded but the JASS VM is not (well it IS but after the very first versions they have essentially been locked to sequential execution as far as ive heard.. correct me if mistaken) so i cant really see any issues that could arise except lag (and some loops breaking.. dont use in loops).

b) conditions are meant to be the short test that is run BEFORE the function body, if you really need to counter the OP limit then it really does make sense to just put the heavy lifting as the trigger action. (codeClarity++ && overhead<epsilon )

 

[Rui]

Well I've used TSA a lot in initialization functions. I've also used it a few times during cinematic sequences. I have only ever used DestroyTrigger( GetTriggeringTrigger() ) as the last action statement of a function, as I thought the trigger would stop running after that call?

 

[Malhorne]

That shall stop the trigger running another time.
But if there was actions in this trigger it will leak.

 

[WaterKnight]

@Waffle: TSA is imprecise, low-capped, said to be able to cause desyncs (which I have not experienced yet) but at least it has to be synced (=net traffic), it is not interruptable or treated as object and timers have extra functions like getting the elapsed time, it's more modulary to call functions in extra threads. As I have mentioned before, inits are commonly written linear, you do not have any disturbing user events there that would have gameplay effects, so surely using waits there is no problem.

misc notes:
a) Warcraft may be multithreaded but the JASS VM is not (well it IS but after the very first versions they have essentially been locked to sequential execution as far as ive heard.. correct me if mistaken) so i cant really see any issues that could arise except lag (and some loops breaking.. dont use in loops).

There are no real processor threads but TSA/timers halt the current thrigger call/run in background and meanwhile other parts of code can be executed.

b) conditions are meant to be the short test that is run BEFORE the function body, if you really need to counter the OP limit then it really does make sense to just put the heavy lifting as the trigger action. (codeClarity++ && overhead<epsilon )

We use a lot of stuff in unusual ways in wc3. I would not even be so sure that Blizzard actively wanted TSA to refresh the oplimit. You should not need to break the limit during the game because it will put heavy stress on the computer executing that many instructions at once. And if you must, the heavy part should be outsourced yes. But using TSA or any delay in a gameplay-relevant trigger that you actually want to be instant would require all the other parts of the game and/or caller to wait for this trigger, which is fatal.

 

[GhostWolf]

The caller, yes, other triggers, not likely.
As far as I know, what you call Jass "threads" is a similar implementation to Lua's (and other languages) yield.
As in, you are simply telling the VM that it can go run other stuff and check every once in a while if it should continue again the code that yielded.

At least that was the belief some years ago, maybe things changed (but probably not).

 

[WaterKnight]

The caller, yes, other triggers, not likely.

I do not mean that it does automatically wait for completion but you want a consistent order of actions as mapmaker. For example, you search the closest grass tile from a certain spot, therefore need some huge iterations, then move a unit to this grass tile. You would expect to have the unit moved instantly and not make the outer code consider that there may be a delay. Furthermore, we do not work solely in the jass environment, it has to match up with the game events, so certain actions have to be done at certain times.

Your description of what we call "threads" in jass fits.

 

[TriggerHappy]

I have a request:
native StopWatchFrequency takes nothing returns integer
Should be easy because C# already offers this feature. I think it is important because miliseconds are not exact and the duration for ticks depends on the system.

Hey man sorry it took so long, here you go. I've also included a few extra natives.

These should also work on the newest version. I haven't tested so sorry if there's any issues.

native StopWatchCreate  takes nothing returns integer
native StopWatchTicks   takes integer id returns integer
native StopWatchMark    takes integer id returns integer
native StopWatchDestroy takes integer id returns nothing

// new
native StopWatchFrequency takes nothing returns integer
native StopWatchStart takes integer id returns boolean
native StopWatchStop takes integer id returns boolean
native IsStopWatchRunning takes integer id returns boolean
native IsStopWatchHighResolution takes nothing returns boolean

MindWorX is about to release something special so I'll be updating all my plugins when he does.

 

[Waffle]

StopWatch natives are among ones imo, that could be implemented safely without risking crashing native clients imo.

not sure how useful.. but i think it would be quite easy to start with as a proof of concept..

 

[Eleandor]

Could anyone create

native GetDestructableZ takes destructable d returns real
native GetDestructableFacing takes destructable d returns real

or point me in the right direction? Creating natives seems easy enough but I have no clue how to get this information out of a JassDestructable...

 

[Cataract92]

I think the easiest way to do it is reading the informations out of the .doo file...another way could be hooking the CreateDestructable() function and strore the facing-parameter in a hashtable...i got that working once...but you have to "initalize" the destructable in GUI first and you can screw up your map quite easy.

I have no idea about the GetDestructableZ()....Sorry

 

[Almia]

I would like to see FTP
or how about some OS functions like OsGetTime() for retrieving the current time(hh:mm)
or IO system

(you might wanna try looking for Lua esp. LuaSocket or LuaFS)

 

[Malhorne]

GetDestructableZ has been made in the JASS section

EDIT : Only GetUnitZ and GetTerrainZ have been made.... Sorry

 

[WaterKnight]

Can easily be hooked. If the destructable is created via CreateDestructable, it's clipped to the ground -> get the terrain height. If it is created via CreateDestructableZ, it remains on the given height.

 

[Eleandor]

Uh... I think I asked for GetDestructableZ, not any workarounds. I know the workarounds.
GetTerrainZ is no option because it assumes the destructable wasn't raised in the editor.
Hooking CreateDestructableZ is no option since the destructables are placed in the editor.
Converting a .doo file to a bunch of CreateDestructableZ calls is the only viable option, but honestly, the whole reason why I asked for GetDestructableZ is exactly to avoid this option.

 

[edo494]

but wont the editor create jass calls to CreateDestructableZ, since the same stuff happens with units when placed in editor?

 

[WaterKnight]

but wont the editor create jass calls to CreateDestructableZ, since the same stuff happens with units when placed in editor?

Positive. The only problem is if there are walkable destructables which alter the terrain height.

 

[Almia]

How about GetWidgetZ?

 

[chobibo]

Yeah, GetWidgetZ and GetUnitZ (Is it already implemented?)

 

[edo494]

GetUnitZ exists in library, GetWidgetZ not yet

 

[EdwardElric]

REQUEST

Feel free to request anything you would like to see in JASS ...

Also already PM-ed you TriggerHappy via wc3c.net as user "MasterofSickness".
What I want/need is another function in the plugin Input.cs, sth. like:

SetMouseTerrainX            takes real x                 returns nothing
SetMouseTerrainY            takes real y                 returns nothing

Similiar like already done here in the thread MouseAPI from MindWorX:
http://www.hiveworkshop.com/forums/miscellaneous-460/mouseapi-36613/
Im using SharpCraft 1.2.4.0, because I dont know how to use the current one. Already wrote it in MindWorX's thread on wc3c.net:
http://www.wc3c.net/showthread.php?t=110643&page=3

regards

 

[TriggerHappy]

Not sure if this will work for you because it's not relative to the terrain.

native SetMousePosition takes integer x, integer y returns nothing

You can also find a File I/O plugin below.

http://www.hiveworkshop.com/forums/2592341-post5.html

 

[EdwardElric]

thanks a lot for answering that fast!
although real terrain X Y would have been much easier for my approach, im happy that I can try the function with integer X Y you gave. By the way, why dont you have a function for receiving the terrain real values, is it more complicated than integer mouse window X Y?

and another thing, till now i never compiled a CS file (C-Sharp), but for using the new "Input.cs" I have to compile it to a DLL file right? i already found out that you simply can use a BAT file with "csc.exe" from Microsoft.NET like described here to get a DLL:
http://stackoverflow.com/questions/7811600/how-to-compile-this-c-sharp-code-into-a-dll
my BAT-file looks like this:

c:\Windows\Microsoft.NET\Framework\v4.0.30319\csc.exe /target:library Input.cs
cmd

but when i try to compile the code (the BAT is placed inside the SharpCraft plugins folder & aims the "Input.cs"), i get a bunch of errors, like:

error CS0246: type- or namespacename 'TinkerWorX' couldnt be found.
error CS0246: type- or namespacename 'GamePluginBase' couldnt be found.
error CS0246: type- or namespacename 'JassRealRet' couldnt be found.
...

how do i compile CS files for SharpCraft?
i guess i need the source code... ahh, where was it again?...

EDIT:
ok, got the source code for my SharpCraft version 1.2.4.0 from here:
https://github.com/TinkerWorX/SharpCraft/releases
but how to proceed?
do i really need to compile the CS-file to a DLL-file?
oh wait!
i compared the date of file creation & i guess the CS-files get compiled automatically?!
have to test!

EDIT2:
yush!
the CS-files are compiled automatically with every start of SharpCraft

 

[TriggerHappy]

Place the .cs in your plugins folder in your SharCraft directory. It will get compiled automatically.

 

[TriggerHappy]

Here's an updated THW Chatroom demo.

Ralle made some changes to the way the chat works so I had to update it.

 

[Almia]

@TriggerHappy Wow
So it can connect to the Hive Chatroom Right?

 

[Kazeon]

@TH:
Have you mentioned that mouse & keyboard natives should not been used in multiplayer map?

 

[EdwardElric]

@ Dalvengyr:
your question was adressed to TriggerHappy, but as I recently tried to get some mouse/keyboard natives to work in multiplayer, i think it's ok to post some of my experinces here.

the mouse & keyboard natives from TriggerHappy are declared in his "Input.cs" plugin for SharpCraft. i tried to use them in multiplayer, but all the event natives are causing a desync. these are the natives im talking about:

native TriggerRegisterAnyKeyEvent   takes trigger whichTrigger, integer state returns nothing
native TriggerRegisterAnyMouseEvent takes trigger whichTrigger, integer state returns nothing
native TriggerRegisterKeyEvent      takes trigger whichTrigger, integer vkey, integer state returns nothing
native TriggerRegisterMouseEvent    takes trigger whichTrigger, integer vkey, integer state returns nothing
native TriggerRegisterMouseWheelEvent takes trigger whichTrigger returns nothing

the reason behind the desync is a local execution of a trigger. when you use one of the above event natives in warcraft 3 world editor & register a trigger to the native, the plugin adds the trigger to a list of triggers which is called via "TriggerExecute" everytime the appropriate event fires. since you cant use "TriggerExecute", "ExecuteFunc", "EnableTrigger", "DisableTrigger ", "TriggerAddAction", "TriggerRemoveAction", and many more "common.j" natives locally, you get a desync. anyway, they work fine in singleplayer, only for multiplayer you must be aware that all mouse & keyboard natives are local natives, hence they are different on every machine. furthermore they arent synced automatically. but beside different syncing methods like:

• gamecache natives (slow)
• "network" from nestharus (faster than gamecache, search for it in the forums or - since most of nestharus resources seems to be removed - look here)
• common.j native "SelectUnit" (my favorite, easy use, faster than gamecache, however still quite slow, see here under "Save/Load:")

the other natives from TriggerHappy's SharpCraft mouse/keyboard plugin "Input.cs" arent causing direct desyncs as far as i remember, these are the ones:

native GetMouseX                    takes nothing returns real
native GetMouseY                    takes nothing returns real
native GetMouseTerrainX             takes nothing returns real
native GetMouseTerrainY             takes nothing returns real
native GetMouseUIX                  takes nothing returns real
native GetMouseUIY                  takes nothing returns real
native GetTriggerKey                takes nothing returns integer
native GetTriggerWheelDelta         takes nothing returns integer
native GetTriggerKeyString          takes nothing returns string
native IsMouseOverUI                takes nothing returns boolean
native IsKeyDown                    takes integer vkey returns boolean

if however you use them later on for natives which return handles (or even worse agents) its quite likely that the multiplayer game will desync!