Listen to a special audio message from Bill Roper to the Hive Workshop community (Bill is a former Vice President of Blizzard Entertainment, Producer, Designer, Musician, Voice Actor) 🔗Click here to hear his message!
It is possible, just not in GUI I think, because the GUI event convert a rect (called a region in GUI) to a region (confusing I know).
The function to get the triggering region is constant native GetTriggeringRegion takes nothing returns region.
The problem with that event in GUI is that it hides the truth from the map maker. Unfortunately, the editor calls them "regions" everywhere, but their real type is "rect". The event works with "region" on the other hand.
This is what happens, in truth. When the game loads your trigger events, a real region is created and copies the size of the rect mentioned in the event. From now on, the new region is used.
For example:
Events
Unit - A unit enters Region 000 <gen>
-------- Region 000 <gen> is a rect --------
Upon map save, this is what the event turns into
JASS:
// The following line of code is responsible for adding "a unit enters region" event to a trigger.
call TriggerRegisterEnterRectSimple( gg_trg_Trigger_Name, gg_rct_Region_000 )
// Let's see how that function really works internally
function TriggerRegisterEnterRectSimple takes trigger trig, rect r returns event
local region rectRegion = CreateRegion() // Creates a new "region"
call RegionAddRect(rectRegion, r) // This copies the size of the rect mentioned
// in the GUI event and passes it to the newly created region.
return TriggerRegisterEnterRegion(trig, rectRegion, null) // Finally, this line will add the
// event to your trigger, and will only accept the new "region". The "rect" that was pre-placed
// on the map is now useless.
endfunction
GetTriggeringRegion() native will return the actual region that triggered the event, but it has nothing to do with rects.
It's possible to do what you want, but you'd have to edit the event yourself and use a hashtable to associate a rect with a region, and use GetTriggeringRegion to retrieve the rect. However, that might now be a problem for you, because you'll have to ditch the old event and use a custom script in order to add new events to triggers.
you could push GUI to do what you want, but
it would be awkward, making for some complex GUI
duplicate some logic, making changing triggered rects more of a process
and it might have performance issues if you had lots of rects or units that are triggering the event
to implement this feature with GUI you'd put all your evented rects into a rect array. when a unit-enters-rect event was triggered, you'd then iterate the array until you found the rect which contained the triggering unit
i don't love this approach because you're essentially reimplementing a large part of the logic for the unit enters rect event, just to stick with the GUI toolset. at the same time, i don't hate it either, because you're not really introducing any real problems. the biggest headache will be maintaining your evented rect array, and that's not that bad
the biggest draw to this approach is that you get to keep your GUI event, which makes it simple to handle that event with more GUI code
id recommend this approach if youre either not familiar with JASS (or another programming language) or your interest is mainly making the game, rather than coding logic
maybe. it'd definitely make getting the triggering rect more elegant, but that's more for your sake as a developer than the map's sake. the GUI unit-enters-region event declares its region in an inaccessible scope, preventing you from comparing it later on via GetTriggeringRegion.
replacing the unit-enters-region event is a good use for JASS or Lua. a custom implementation will let you easily access the triggered rect from the event's callback, simply passing it as a global rect, and the custom approach will be more flexible if you have performance issues or other custom needs down the road
that said, it'll also start you down the slippery slope of managing a map that's both JASS and GUI. the biggest drawback to this approach comes from having a JASS event, your new custom unit-enters-rect event, that you probably want to handle, at least occasionally, with GUI code. how will you call the GUI code from your JASS? what once was a nicely organized GUI trigger - clearly stating its event, conditions, and actions - will now be split across multiple different components of your implementation separating the event from the rest. none of this is a dealbreaker, but it is to say that some parts of your code will become cleaner, while other parts will become uglier
globals
Event OnUnitEntersRect
unit EventUnit
rect EventRect
endglobals
//psuedo jass
private function checkRects takes nothing returns nothing
foreach unit in units-of-interest
foreach rect in rects-with-events
if unit inside rect then
set EventUnit = unit
set EventRect = rect
call OnUnitEntersRect.fire()
endif
endloop
endloop
endfunction
public function registerRect takes rect r returns nothing
call rects-with-events.add(r)
endfunction
private function onInit takes nothing returns nothing
call checkRects() every .035 seconds //this is the time rate the vanilla event is based off
endfunction
hopefully units-of-interest is a small group in your map, one that you feel comfortable managing. if youre trying to check all the units on the map then you might run into performance issues using the vanilla approach. at that point, you should start looking at auto indexers, which will essentially cache that information for you to access quickly
i also like bloodsoul's suggestion as a middle ground. by wrapping the existing TriggerRegisterEnterRegion logic you get the existing logic plus your custom association between the rect and its region. this option still has the same issues as the JASS approach, connecting JASS to GUI. if you want to get this working ASAP, do bloodsoul's suggestion, if you want to make a lot of weird custom shit, go this other route
if all this is sounding horrifying, then just see how far you can get on the GUI approach
This is in a folder containing all the Warlock-triggers.
It's ok structure and straight forward, but split-up in multiple triggers.
I'm a developer, working with code every (work) day. But I have not put the time to get to know jass and all the natives and find a tool that's actually good.
When I work on my map, I usually want to get things done (because I don't have that much time to put on it and right now I kind of want to get the map to a good "finished" state).
Fairly often a few lines of custom code is needed to do stuff such as lightning effects (with height), math and ofc leak-proof stuff.
that's a good idea too, i didn't think of that. i like your approach, it's easier than my gui recommendation so long as you don't have too many rects that you need to do
in general i think focusing on the game aspect is a great way to fit a hobby in around work. it can be fun to just focus on making a game and not worry so much about how ideal the code is
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.