• 🏆 Texturing Contest #33 is OPEN! Contestants must re-texture a SD unit model found in-game (Warcraft 3 Classic), recreating the unit into a peaceful NPC version. 🔗Click here to enter!
  • It's time for the first HD Modeling Contest of 2024. Join the theme discussion for Hive's HD Modeling Contest #6! Click here to post your idea!

[GUI] Undead Gold Gathering (Harvesting) Upgrade

Level 3
Joined
May 14, 2018
Messages
27
Intro
I was recently trying to build a map with "improved resource gathering" upgrades. This is very simple for Human and Orc (based off the Human "Improved Lumber Harvesting" upgrade), and semi-simple for Night Elf (the upgrade has to use a separate effect called "Gold harvesting bonus (Entangled)", or something close to that). However, it is ridiculously hard to implement for Undead. Hence, this tutorial will help explain why, and guide you through correct implementation of an effective Undead "Gold gathering upgrade".

Credits
To start with, I had found this sample map posted by Jampion: post. It worked fairly well; however, the trigger structure was a bit convoluted and confusing (especially the part where he sets a Unit-Group variable to "all units in playable map area" and then subsequently empties it). So I spent some time reverse-engineering it and refactoring it to make it A) more understandable, and B) much cleaner. The main problem with it, as I discovered, was the use of a nested "Pick every unit" loop, i.e. one inside another -- the references to "Picked Unit" inside the inner loop would not always refer to the correct unit.

Another helpful tip came from this thread (@ thehelper.net, not here, fair warning), where they posed the idea of using begins-construction & finishes-construction events to toggle a switch-value for a given building so that it could be checked by another trigger, e.g. so I could detect if it was still under construction or not.

Now, let's get into it.

What You Need
  1. World Editor (duh)
  2. Familiarity with Object Editor and Trigger Editor.

TL;DR
If you truly want to "just get going" and start playing around with the sample map and triggers, download them! You can choose between the full WCX, or just the triggers.zip file, which contains the WCT & WTG dump of the triggers, which you can import into any map using the Trigger Editor's "file \ import triggers" menu option.


A Quick Recap
If you're keeping things balanced, your other races will also have "resource gathering upgrades"; and as I said, it's quite simple for Human, Orc, and Night Elf. Use the Human "Improved Lumber Harvesting" (image 'R1') upgrade as a base. Copy and paste. Change the "Race" property, the requirements, names and tooltips. A few examples are shown at the end (not to detract from the main point of this guide). 'R2' shows the Human Gold Mining upgrade; as you can see, I just changed the "Data- Effect 1" to "Gold Harvest Bonus", and edited all the other stuff appropriately. 'R3' shows the Night Elf gold upgrade, in which I've circled the different Effect that you need to pick - "Gold Harvest Bonus (Entangle)".

Finally, the key thing you need to do to ensure this works, is to add the Upgrade to the Unit which will use it! In Human & Orcs, that's the Peasant or Peon. For Undead lumber, that's Ghoul (for Undead Gold, it's complicated, and that's hopefully why you're reading this tutorial!). For Night Elf, the Wisp gets the "improved lumber" upgrade, BUT the "improved gold harvesting (entangle)" upgrade goes on the Entangled Gold Mine building! See? Little tricksy, not bad. With that out of the way, we can move on to the main point of this tutorial!


Starting with Objects

y4mLofJ6z-kqce-tYXkqZH2JQ997csfV6P-Q4kvwoA8hnwyDZ4aSd9pKt4rY1n3H0zgzsIYtILyb4kfoAijSaBoTEA80YGqQen8Ez8eqxofVbYgzmmpDAgwdq5-GTNn0bIQ9WbN5MfgHnilV1fNOEyqdJ4NUuXF0pH3fdlw1bLWwetzDyicRRQ8z-DqXZvvcMwDuBoh0oMLPeYDS-XIKu9qZA

First, we'll need a new Custom Ability, based on the Undead "Blighted Gold Mine Ability". This is an ability that the Haunted Gold Mine (hereafter abbreviated as 'HGM') has, which has no UI (no icon or displayed text or tooltip), but which contains the data that governs the Acolytes' gold-gathering mechanics. See "Step 1" image. Note that you can (in theory) change other properties like "Max # of miners" and "Interval duration", but for simplicity, we're just going to double the "Gold per Interval", i.e. the 'gather rate', to 20.

y4mxtIzseLc_iBt8iZej4S8T6Z517Cff5vupuP5HqjE1M99pLxWkEqPrdZh78JhZiY4_8jOnuND3S_Hx6sp-zXiClnYx87muahhCCmfndSaIFFvXOZ5eKwpP-oi3qLEhrZaLBNCqJHBScp23wyTyGFDCvS7gs2K1T8Wcc3MxajQxwfqd_CyEXYbrRM4uTYVGTO7tVZ-MBXgnDG5jPf0PsK4Zg

Second, we need to create a new Custom Unit, based on the Undead "Haunted Gold Mine". Moar copy-pasta! Let's name the new unit "Haunted Gold Mine 2", to keep it simple. We edit its "Abilities - Normal" field to remove the default "Blighted Gold Mine Ability", and add our new one, "Blighted Gold Mine Ability 2". See "Step 2" image. Make sure to set its "Techtree - Requirements" to require the

y4mVxNEzn50k9saqCLUujlFdinCPjRKxxkOvTBulMOduAc9azMae2posHOMcaVZqj--x3kzmbmcKsao85OQAQZPB0c2uim0B3bz9-CQ0sOxusv_f0sTL500s6V5FKKvEpQTID4jpJU-G9H3-kPVJLeeq226RAHV8jpiRcQyNaIKA3LLBkGwCEr45Muy7XkHHqqsj-VIRHEr163SXCa9w31xuQ

Third, we'll add this new building to the "Structures Built" field for our Acolyte. See "Step 3". While this technically exceeds the available build-slots for a builder unit (you can only have up to 11 visible on the command-card), it doesn't matter because A) it's in the same spot as the default HGM, which overrides it, and B) it won't be available to build until the upgrade is researched (which we'll get to in Step 5).

y4m3AkO3GCdzsEGcRqrjXeSyBC7KX_urfGG0hRaRrw4dJi4Ku-wolIpICutG5zOi4sfPHMLN2Ig8wplcXZTkS1ZG8fSPfJcYZonRvbx1Ppsy4Ez5pujDlxIpVsIhblHSWILrujUgJpsdF-UFWtDr3OQaJfywnV5KcyuX9V6wOxPKBMCE3i2rkt5ULz0mXVtjnL9tB4QEoXgoVfRI-vB_Ykmpw

Fourth, we finally get to create our new Custom Upgrade! Here, we copy-paste from the Orc "Berserker Upgrade" upgrade. See "Step 4" image. We use this one because it's a built-in "unit swapper" upgrade, i.e. it replaces all existing units of one type with another type, while also making the first type "UNavailable" (to build/train) and the second "Available".

y4mFNa2khZi2yUwL5mReY8YHPDhcKeyRpq-qsUpAQHLf7-qaZpSOFcufNEBoFSmcK55_6UOWbIxWnm7WjUmwQQKXBS7PbO-5p7ZddwSqKNyTbXNMrMFJDL7LPbfjidD4oXl6WVHYulxjl9eAwQxkqy6OJ50VMOiJlSLI4SXZkz7GEbXMIOH3mmfGrF7sGd10uaAMIvu-HUT4jNRq01lrM2oJg

Fifth, just to be thorough, we go back to the HGM2 building and make it "require" this upgrade in its "Techtree - Requirements" field. See "Step 5" image. In practice, this is not 100% required, but it makes things easier for the game to understand and helps keep our build-tree normal.

y4mACZjhdeTK_OFEyQx020mxT-jymU0tMSewe_MaHYVh5PxOxlT9MsLC-Z7HVi7thwT0eFbqZ3uW1Z7gW-UT8vcuFF-ln3IYt8wWiqP8hFA4QZEPM2aIhdTsbZS7usisp_Ee_RBIIG9OCu4GXZcPLmHgTSB6nz75kv_z-zSH6PgOVDafUw90IJEow_leMk1_6YHG1U9jrTLmXKg-LxxNuqUqw

Step '5b', we have to actually assign the upgrade-research as an "Available Research" to a building where we want to research it from! The sample map puts it under the Necropolis, but this screenshot shows adding it to the Graveyard, since that's probably more appropriate. You can decide!


And Now the Hard Part: Triggers!

They're not really hard, just a little convoluted. The reasons behind this are complex, partially having to do with how Blizzard implemented the UD gold mine mechanics (and gold mines in general), and partially because we want to make the upgrade as seamless as possible to the user -- i.e. the player shouldn't need to know or be aware of how the unit-swapping and gold-gathering-rates are being done behind-the-scenes, nor should they have to worry about re-assigning their currently harvesting Acolytes to re-start harvesting on the new HGM2's! It should all "just work", like magic. And that's why you're here, because I spent over 12 hours futzing with and play-testing these triggers to make sure I covered as many use-cases and scenarios as I could!

y4mkhVKRWpXYqOz2el_UUupHSIKIXz54rGLQ1nQUFf04Dv6gKjQ-vUgLyesGNSCK6-b_ZoxQh4BXnTZ-vLrpADC9xkb0EFTed3c-TAcbUIZBFeiv1dxEVhzRYj9uoN6LT697FXtqqWkzbKhMgwKA3CYlImMh0K5eTwk5uT2sRyoV9u9AmVev--mlh_QIJ3A3scfXX0aNYtYGkFpwT3S5xohqA

In Step 6a, I set up my new trigger folder, some notes at the top of an empty trigger to provide some background and "issues". And in Step 6b, I create my variables -- probably the most important step.

y4mZvMnvSHwgqYpY2dRoXyoPMwtIGn0Q1LjohCUwHeqTExYPwPpLVizWx2QbLBiO8W39YVP2J_DqlcJ6adyz6UtsccynN21nwW7SptxLLAjUO2sqKmGdQ5DGA6ca6LI3fmA1y0hPzjVXM7LN8r8hI87cY9DlkIV31alqnrrPyD5Pd31BztViDk7NZIdaBJj7PBepDHJ7dimNRgRTXX9mCq1lA

Briefly, the purpose of each is as follows:
  1. HGM_Counter, integer: keep track of the # of HGM's found for a player during a Research-finished or Construction-finished event run (the Research trigger).
  2. Replace_Loop, integer: keep track of the HGM's replaced by HGM2's during the Replace trigger.
  3. HGM_Owner, Player array: keep track of player ownership of HGM's.
  4. TempPosition, point: current position of the HGM/GoldMine being replaced inside the Replace loop.
  5. HGM_Position, point array: all HGM positions found during the Research loop.
  6. HGM_Life, real array: hit-points for each HGM found during the Research loop.
  7. TimerZero, timer: used to signal the end of the Research trigger and fire the Replace trigger.
  8. TempGoldMine, unit: the currently-being-replaced Gold Mine in the Replace loop.
  9. HauntedMines, unit array: all HGM2's created during the Replace loop.
  10. Grp_ActiveMiners, unit group array: for each HGM, a group of its surrounding actively-mining Acolytes.
  11. Grp_NearbyUnits, unit group array: for each HGM, a group of all nearby units (not structures).
y4mtHpp_5DdYjp-MbPFCDSD0iV9jNRWIxxlfiN7vJFmlo0xtJw0fxANTkTNQR5TBP_TIdZ9tNARiMaX1urk2vugeNQXt-xCe3mvv1a6Y3RwqnEUCdO44izcwMvRzlN6n-TLjtdbARIb1-5Iz1jvUhhcq12hau_5niOwis1AV_bnmyisFWyIsPFSmdAloeZz-QS_KwKmva6_HOCkfsrhnErnMg

Now we get to real gory details of this operation. Step 7 is the "Research" trigger, which fires after the new "Gold Mine Upgrade" upgrade is done.. (OR after a new HGM is constructed, if it was not finished by the time the upgrade was done -- but we'll get to that later). I have provided copious notes about what it does and why, including some explanation of why things seem a little strange but are necessary for it to work out. If you aren't sure of how to find any particular Trigger Action in the menus, use the "search" feature, or just ask.

y4mqIZ3o1-0dE66U3Iw0z2bry74AjzsHCiHvCGXbJ-3F4air11flu50XskQMzZquGkTTJ-azu8qNLTTgkcXuSxKYOMS1JHkSNPYhD7g9zeIo-doZjegaj1pyPdAs0Okc50S_WhhymNVo36oic5PGthVShwtsKWvo13VrToz-QPHBqbZo0edsNx06stbd02zA90kEnMIBfWzug2ylOeMo7nz6Q

There are two main loops here, the "For each Unit of type HGM", aka the "HGM finder loop", and then the "For each Integer A" loop, aka the "Unit finder loop". As stated in the notes, we first have to find all existing HGM's for the player, and set some variables to store their positions and properties. Once that's all done, we proceed to set up the Unit-groups. We have "Nearby Units" (all non-structure units within 300 points of the HGM), which we have to HIDE so that they're not "in the way" when we go to create the new HGM2's later (i.e. they can't block placement of the new building). And of course we have "Active Miners", which we want to hide too, but also, we want to re-issue their "Harvest" orders once the new HGM2 is in-place.

y4mj87H_BUeePW8N2ahgAKVKArNQhY7-r19XPlNSFpgT9fq9cdxURLn2DrTZMBcP9lrFsoepUNW8Lq8eygoplk-88ge0dbriQqTpwNTAIvbzV6uXpwZJMqkIm4NpD2ev5UY5RzjXTQr5ATF32O3v7cdUsXf-8KGzZU_htjlPQLNBiu9X3POF8jw8Gc0WQG364DsHZ-PzOTSleQzd-D_HCaSiA

Step 8 shows the "Replace" trigger, which is fired after the "Research" trigger finishes and sets off 'TimerZero'. Here, we are looping through the previously determined set of HGM's (which, having been removed, now just have a standard Gold Mine in their place on the map), and replacing them with HGM2's with the appropriate life/gold-amount. Then, we UN-hide all the units that were hidden before. And finally, we re-issue the "Harvest" order to all previously detected harvesting Acolytes for the HGM (now HGM2!).

With me so far? Don't worry, it's almost over!

y4mjpNL-UfeNBwQb388ddo9Jk5DXEYHQaz6p9dp7ILkQ2cFPI2SIBDzLB98iNullV_pPJLAdFxYPG7I_BbOQVg1h9-JVIPtnwVElE07_qP0nYBJJh9qfMekKhBo7G0VzsIuanCS99f6K0xcyAtUAuTM_cAOU-EwH8tBxnVtlGqfiFvw-NJ-GYBJLaj1hpCSuUgB328dY-3K9CeplCHgvKcNaQ

Step 9 is more of a convenience than anything else. Because when you right-click to order a Unit to do something (its default action against whatever target that is), it's called a "Smart" order. But remember back in Step 7 where we had that disabled "Or" condition-block in the middle of our "unit-hiding loop"? This trigger makes it so we don't have to worry about that. Alternatively, we could remove this trigger and go back and enable that "Or" block instead, while also disabling/removing the single condition just above it ("Current order of picked unit equal to order(harvest)"). But I digress.

y4mIWD7WJrA5NkaNob6ycoLktVTEqWKhWI1qxORqKqfs-97ZQ9bzA-E7jlOWQFRKYifIIPc9kxMWddXhUAPM_CGcxl9DlHoeHODmA8XhlMRkfi7efheaJI6_xcNCI_DTlc9sCuz0PhHn_chKtEErLfRMsV-V_1k8FuAHtqlbWsTDc9YYxSZkcI3vRfBvavXBcnQBa_k2KPvZPnGd88cI8gNsw

Step 10 a/b are a pair of triggers that fixe the "bug" in the original wherein, if an HGM is under construction and the Gold Mine Upgrade is researched before said HGM is finished, it gets replaced with a full-on HGM2 instantly, instead of having to wait for construction to finish. Here, we use the unit's "Custom Value" (which is an Integer) -- we set it to '1' if it's under construction, and only when it finishes do we set it back to '0'. (It's actually un-initialized, by default, so it's neither 0 nor 1 nor any other number, on a unit that it's never touched for, but I digress. Again.)
y4mzi7PKHKh6mi4r-FZU1oj6WB3Csifp942oD0MRwfJVndOFgpN1D97zM0QKQHtI9u8yTBrmpe2I9ISQNmLZ6mvGWHf63R2P_3qKvpWXd6-qpCmKKRnFyu37m2PD9lLuepabWpK5A4NeFJO-BjoDTvublKn2C8NHX5Mxc9bUVezRUwRuZmjAtfp69C04e6FMxkD37tXhDPnMMd0UUuaiU6-_w


The whole reason we do this is so that very first "If" condition in our big "HGM finder loop" can be checked -- we only want to find (and thus replace) HGM's if they're fully constructed.

--------------------------------------------------

Phew! You did it, congratulations. You can now go forth and make your very own map with an Undead gold-harvesting-bonus upgrade, just like all the other races. Speaking of, here are the "recap" pics of sample upgrades for Human & Night Elf. As stated before, Orc would be same as Human for both kinds.

y4mhd4pb5C35hs5nx0d5PHz-yH8ABmIIGCHXtZkkUIs-bNHHJ98tPPGEfXEmMVUaLGFSVMdK5YOchcaRD0UxvgB3VgeGVz3-9COOEHpF7OdjxqNw2pFPJCXipzUXpnmYuZIikH11trxhlB6UKkGoApXhtIg-9uS80C1DJki3AoYtl-a_VoYbXUuoyfDeZAUavIa_gCvEYw2PmNQMKFlXCvOmQ

y4mJvkDFbnmNvlVggXJm3Pd6aaqr-icHYj5ooa5FKgJYfgz98_aWzPCKLu8IOrWqqVH5JYMK5J5Cnly8DyIZH0nxO8VnSSqS6LbcDTRObItQIfiDVU-4zx8marbsdtttHZacRuDISd4K7yy00D5vuqWJAXdMJG35Y2NNXNPaSqIZptXMzhDNihbtOWyz5v2hrCx8zeMY10amPsUC14NyAJtZQ

y4mN9ZNSejkoYOkDfIuu8S9Z_Vr2S9H3drT_yaRgE5PMSxmVHh3yPMNhveSwHdSsJgJhh2ODAqpjpZfy4AoDJKiUBVHaz6uSZGsWRwYF41bSEFvHwrwfDePyJerrw99oUxf1wbXOY0EeV1z4NiNAaFbPTJXl8y2nqlZ6E2YALsrC0gaqKsFgHQYMCthszOrZD2mJH0n7eN3R6qecnEd-TqNvg


Thanks again to all the folks here at HiveWorkshop and elsewhere whose ideas and posts from the past helped me fully and completely understand how to get this working and how to explain it in plain English. GL HF!
 

Attachments

  • ResUpg Tut all ScreenShots.zip
    1.7 MB · Views: 79
  • Acolyte Gold Mining Upg triggers.zip
    5.2 KB · Views: 79
  • Acolyte Gold Mining Upg sample.w3x
    33.1 KB · Views: 81
Last edited:
Level 7
Joined
May 30, 2013
Messages
210
what happens if you just give the haunted gold mine ability multiple levels and level it up (through research or triggers), will it bug
 
Level 3
Joined
May 14, 2018
Messages
27
Correct, multi-leveling/leveling-up the "Blighted Gold Mine Ability" ability was the first thing I tried that did NOT work. Hence the crazy work-around. ;)

Demo:
y4mDj8pqIX-I7VasNsmBVkUwzORnTR91P_CMDI5SRVSGSDaXgG6Z4Mf3QEQgqtIiqrogW9KiMWkefEbRf04w-GSVBi-EZmWcBxK57kvDI5__RxmCnU6VKRR75kv1ZIP8x-WXWZcZ2XEh44lhxu4LxjAZvopS-PToqITAQZk5RhtmS_NALY1K1v2c9hw02dMuKexZAmx8EfXyJoj1WZzZH2hVA

y4mp3mOeiHTnEKK9pioGIe2UxC2ry9ybscZ_DqIuTYrPLnCFplLmx-uklMxDGZCreUXW-1u6yvH9dMta00jR-UcBZ7WGuxIp1HcuHuysSVZ2vkyd8etlMkdaT6bgS2ljbmwxzr0JNx7x0A1nnT400KeR01hl5a7-s08IQgj1Pam8MY9FWfxR9d-BF9Zy_colC9MIs_GkJvaQlaEeDQjENC13g

y4mMv1K3auqhlvU_QSlF9XgE36CVus_dC-90lX2tJ-9pnsH7GhVcBccPij7OLqTe6SO3MotgXUMeG7L66d_q4l73HcWyjiDIwPiqBi1g2VV27zAofqvr1iSOhUEgxmUW2gS_nMA4KyJXcsxOgsAbvLYtBl6kFN25fiNtNAhSkl6jiVR348CU6CmE-gM_vY0riEKxRuhwHHK69zM2QRoB9VJ0w

y4mwFjGvLso3s4cxOWi51LSQrj6hXdr9HqOVuiQhzEGV4tEuviGNxFJan0IWoP-ykCUTys7kK_CsMvOAPTxJqLnWS1cbWiJNOH9sKlxfWz8tr7RQ91YzRdQrR6wsr8ArmqjKV-mj1t-vf7JB-Ga7h56ayJA4dJnevvfwUkb3UAxZ0q7GmMWL0j3W5nAxOT92aH1EFumwJwBi_BaA0eo2m29ag

y4m7vVMTFVgdgc0jgmzj1_h4R3R1GksL1XXjvR-5f0tFoSOQvRd8Hgl9QUyrmbY4kEjdJfWybJ8l1f0BoIiQTHpY0Q2FdOCi2BYBiJ2N5GBD-2IqHi520J49DHu-qaFQX9FccrLrrICinK4icPBtAbD6CLHaYEvJ8C4igICeJyNtaerGRvXVmlnJOIrMBe2r0zwT1IA2e8TX0cQf5UiYAJX1Q


You can see from the messages here that, after the upgrade is finished, before the trigger actions run for each HGM, the BGM ability level is STILL 1! So the Upgrade itself doesn't even work as-advertised.

So yes, unfortunately for us, whatever Blizzard did with the HGM/BGM mechanics has made it impossible for us to SIMPLY implement a gold harvesting upgrade for Undead. Thus, we had to get creative. =)
 

Attachments

  • BGM Ability Upg sample NOT WORKING.w3x
    20.2 KB · Views: 68
Last edited:
Level 3
Joined
May 14, 2018
Messages
27
Known bug 1, with sample map & tutorial: HGM constructed BEFORE upgrade is researched, will still get replaced with upgraded HGM2. Fixing soon!

Known bug 2: Acolytes trained from a Hall that's been ordered to "Rally" to a HGM, will not re-Harvest on the replaced HGM2. Fixing soon!

Known bug 3: Acolytes "on their way to" a HGM (i.e. moving towards it to harvest) when it's upgraded/replaced, will NOT retain their order, and will stop (having lost the target of their original order). Possibly complicated; fix unknown.
 
Last edited:
Level 38
Joined
Feb 27, 2007
Messages
4,951
Known bug 3: Acolytes "on their way to" a HGM (i.e. moving towards it to harvest) when it's upgraded/replaced, will NOT retain their order, and will stop (having lost the target of their original order). Possibly complicated; fix unknown.
These bugs also apply to allied units traveling to a HGM via right-click and hostile units that may be trying to attack the HGM before it becomes an HGM2, not just player owned acolytes. Hashtables make this easier; store 2 groups in the hashtable per HGM to keep track of ally and enemy units currently moving toward the HGM. 1 additional global group holds all units currently targeting an HGM.


A) When a unit is ordered to smart, move, or attack a haunted gold mine, you add it to the main HGM targeting group, add it to either the ally group or enemy group, and also store the HGM it's interacting with in the hashtable (under the ordered unit's handle ID, not the HGM's) so you can properly remove it from groups later. (if its issued the order for stun, which I think only has a # equivalent not an orderstring, just ignore it)

B) When a unit is ordered any other order (except stun) and it's in the HGM target group, remove it from the HGM target group.

C) When a unit dies, if its in the HGM target group remove it from all groups it is in and properly flush its hashtable data.

D) When an HGM is replaced with an HGM 2, loop through both its ally and enemy groups and re-order them to "smart" the new HGM2. (probably need to disable the A trigger while you do this)
 
Level 3
Joined
May 14, 2018
Messages
27
These bugs also apply to allied units traveling to a HGM via right-click and hostile units that may be trying to attack the HGM before it becomes an HGM2, not just player owned acolytes. Hashtables make this easier; store 2 groups in the hashtable per HGM to keep track of ally and enemy units currently moving toward the HGM. 1 additional global group holds all units currently targeting an HGM.

Awesome feedback, and I love your ideas to fix it. I'm going to upload the "bug 1 fix" soon. If you want to take the sample map and try your hand at implementing your solution, that would be amazing. I'm not a hashtable expert at this point, but I'd like to see them in action as you describe. =)

"Bug 2" is proving much more difficult than I thought. The new sample map will contain my "attempt to fix it" but the RallyStore trigger is not detecting every Necropolis's order-issued event, and thus the "RallyTrain" trigger is only working occasionally (to make rallied Acolytes re-Harvest against the replaced HGM2). Very frustrating.
 
Level 38
Joined
Feb 27, 2007
Messages
4,951
You just need to re-order them to "smart" the HGM2 after it gets replaced. Fixing bug 2 also involves storing orders and re-issuing them once the HGMs are replaced with HGM2s. Unless I misunderstand the problem. If you need to re-set the rally point after HGM->HGM2 conversion you can do that, and even get the unit's current rally point. If you get it before removing the old HGMs it will properly return a unit, but if you do it after removing the HGM it will return "no unit". For example:

  • Unit - Set Rally-Point for (Triggering unit) to (Rally-Point of (Picked unit) as a unit)[trigger]
 
Level 3
Joined
May 14, 2018
Messages
27
You just need to re-order them to "smart" the HGM2 after it gets replaced. Fixing bug 2 also involves storing orders and re-issuing them once the HGMs are replaced with HGM2s. Unless I misunderstand the problem. If you need to re-set the rally point after HGM->HGM2 conversion you can do that, and even get the unit's current rally point. If you get it before removing the old HGMs it will properly return a unit, but if you do it after removing the HGM it will return "no unit".
Thanks bud, I'll fiddle with it some more. Do you mean that I should store the individual Acolytes' orders to re-issue? Not (just) the Necropolis's? Because.. I thought that's what my "ReOrder" trigger was doing -- it was detecting Acolyte 'smart' orders against an HGM, and re-issuing them as 'harvest'. But that doesn't seem to affect the rallied Acolytes.

Bug fix #1 is up; full update to original post with new screenshots, new map, and new trigger-dump. :D
 
Level 3
Joined
May 14, 2018
Messages
27
At this point, it's easier to just assume ALL nearby Acolytes to a given HGM should be re-issued the Harvest order on the new HGM2. If there are more than 5, the remainder just do nothing. Tough beans.

New "step 7" trigger with revised "unit-finder loop" logic:
y4mAwdKLHimcnls_hnV3QDMzlyL-w-5OSzYYMlTYzfFxR9Ow7MHYl3O2rhRlgpyGdeFcblXGzipDOh6Z7r7fym1Ql8YvYEEn6mZMFV1_nNyB_RJkAPS1UXmjReC7ZYKG0BZrxXf-5rCdwXfjvnXKNGz1-6gNR0rGkubOn2HIqPdmgi_TLawMR-_i7pI_THr7j0ntI_18ZGjTpouX8wWD_i77A



Here's the thing that's really bothering me. I made a trigger like so:
y4mqrVQ5von_XF7EIy9i9eSBZH2LzVsJOuZ0woKqcezqziIAY8cOKRKTEyzFgiJgYk3sQN4byGzt0PaVRGdJ-vdgADoAoURm9_1pJelLJn69O0PV7vxn5QA8l4zwSQ_thSrIPelw_RluMGieICgaHDPskmMUUVRgFVgm0dCHGdYmY9Y4sZIPS3yQOxeYZHFC1NGM--xAtrFf7DBLM92LljCVQ


It correctly detects AND replaces the trained Acolyte's order from empty(none) into 'harvest'. The debug-messages prove it. AND YET, when the Research trigger runs thru its "unit-finder loop", and detects the current order-string on the picked Acolyte, IT'S STILL EMPTY!! WTF. I give up for today. As I said, it's a helluva lot easier to just re-issue Harvest to all nearby Acolytes on each HGM.

As for the more general issue of "resuming ANY in-progress orders having targeted a replaced unit", that's a big topic and probably deserves its own tutorial (or at least its own thread somewhere). I'm not going to tackle that here. @Pyrogasm has a good framework/outline in his head, so maybe someone can give that a try at some point.

Final note on this: As I said above, I don't feel it's justified to spend hours upon hours on the task of making 'swapped-in' HGM's retain pending unit orders (in which they are the target), other than Acolyte harvesting. My reasoning stands thus: It's literally a one-or-two-time event in the entire course of play. You upgrade your existing mines, you MAYBE have one in-build-progress that gets swapped when it's done. That's it. Frankly, if you've got enemy units after your gold mines, or you're ordering your own units in a queue that involves a mine, you're probably a bit loony. =P So, GLHFDD!
 
Last edited:

Jampion

Code Reviewer
Level 15
Joined
Mar 25, 2016
Messages
1,327
You can achieve the same much easier by using chaos to morph the building. This way the unit stays the same and variables or orders referencing the building do not have to be updated.
All you need to do is to reset gold amount and reorder currently mining acolytes to stop and then mine again.
It seems you need to wait a short time before you can reset the gold and reorder to mine. 0.03 seconds worked for me and won't be noticeable.
 

Jampion

Code Reviewer
Level 15
Joined
Mar 25, 2016
Messages
1,327
I'll provide a simple one, because I am lazy. I think Raen7 already has solutions for the points my simplified map ignores.

Only works when you manually order to harvest and not use right click. It's not MUI, leaks and picking the currently mining acolytes is not 100% accurate. It's a showcase of the idea rather than a template.

Regarding gold mines in construction, this system can be applied independent from upgrades, so you could just replace gold mines once they are finished constructing.
 

Attachments

  • UndeadGoldMine.w3x
    19.2 KB · Views: 56
Level 38
Joined
Feb 27, 2007
Messages
4,951
Only works when you manually order to harvest and not use right click.
Is that some limitation of the chaos morph on buildings process, or just a limitation of the test map because you only listened for the harvest order and not also the smart order? Maybe I misunderstand what you meant but I'm out of town without a computer so I cannot look at the map code.
 

Jampion

Code Reviewer
Level 15
Joined
Mar 25, 2016
Messages
1,327
Just my test map. I pick nearby acolytes with order harvest and order them to harvest again. With smart it would be more difficult, cause I would have to filter them to only pick the ones that were ordered smart on a gold mine. Smart is used for moving, repairing and other things as well, so you cannot simply assume all acolytes on smart are supposed to mine.

Even with harvest it's not accurate, because an acolyte could have been ordered to harvest another gold mine, but still be close enough to the first gold mine to be ordered to harvest it. Ideally one would have to use a system that keeps track of orders and targets to only pick acolytes that have been ordered to harvest/smart the relevant gold mine.

This however goes far beyond what I wanted to show, so it would only confuse people, trying to figure out how it works. I might release a fully working version later.

Edit: here is a better working map. Works with buildings in construction and right click. Acolytes are only reordered to mine if they have been mining the exact mine before.
Known Issue: if the gold mine is frozen (Freezing Breath) during the time it is upgraded, the unit morph is delayed. Since the gold mine loses its gold at the morph, the trigger to restore the gold runs before the morph resulting in 0 gold for the mine.
Possible solution: When a gold mine is upgraded it is added to a group and periodically checked wether it already morphed. Once it is morphed, the gold is restored and the unit is removed from the group.
 

Attachments

  • UndeadGoldMine2.w3x
    25.9 KB · Views: 66
Last edited:
Level 3
Joined
May 14, 2018
Messages
27
@Jampion nicely done buddy. I thought that the troll Berserker form was just another flavor of Chaos. If your method is easier to implement I'd sure love to see it done as a tutorial.

EDIT: I see yours is heavy on the JASS. Mine is aimed at pure GUI users, but I can definitely see the value and efficiency that the custom scripting adds. :)
 
Last edited:

Jampion

Code Reviewer
Level 15
Joined
Mar 25, 2016
Messages
1,327
@Jampion nicely done buddy. I thought that the troll Berserker form was just another flavor of Chaos.
Yeah, you are right, I think it does the same. But I thought this tutorial (step 8) and my map I initially posted back then use the GUI replace function to replace the gold mines, which is problematical and is the main cause why so many workaround triggers (that can never be perfect) had to be created.
Replacing the unit removes it, so everything that references the gold mine no longer works (orders, variables, handle id). You can probably create triggers in a way, that this does not affect your triggers. However orders cannot fully be restored due to the order queue: If you ordered a unit to attack the gold mine and then do something else with shift, the something else part would be lost, because a trigger orders the unit to attack the gold mine after replacing it.
Berserker form or chaos has certainly issues as well, but they aren't as fundamental.

If your method is easier to implement I'd sure love to see it done as a tutorial.
Not sure if it is easier, but it should be working better. I also think that the total trigger length is shorter, just because you don't have to create so many workarounds.
The unit indexer I used in the map is from Bribe's Damage Engine, so it's not something one would have to do yourself.
I split the triggers into two parts: core and upgarde
Core handles upgrading a single gold mine and upgrade is a possible implementation of how to upgrade all gold mines, when you research an upgrade.
I would certainly try to use unit morph instead of replacing the gold mine. The replace function simply breaks to much stuff, including all buffs currently on the gold mine.
You can use as much from my map in your tutorial as you want.

EDIT: I see yours is heavy on the JASS. Mine is aimed at pure GUI users, but I can definitely see the value and efficiency that the custom scripting adds. :)
The UpgradeMine trigger is mostly JASS, apart from that it is all GUI. It's not like it cannot be created in GUI, it's just a lot easier and faster for me to do it in JASS.
The only difficulty for GUI I see is how to implement the 0.03 seconds delay. But even that could be done with dynamic indexing and a periodic timer, though it would be less accurate. What is the common technique to get accurate delays in GUI, while being MUI?
 
Level 38
Joined
Feb 27, 2007
Messages
4,951
What is the common technique to get accurate delays in GUI, while being MUI?
dynamic indexing and a periodic timer, though it would be less accurate
Or using TimerStart() on a function that ExecuteFunc()s a trigger's Action function. Trying to call a trigger's action function directly from the timer callback function usually results in an error because you can't force one trigger's functions to be before another's in the compiled war3map.j
 

Jampion

Code Reviewer
Level 15
Joined
Mar 25, 2016
Messages
1,327
I actually used a similar approach in this map, but I was more looking for a method that would be used by GUI users, since Raen7 said the tutorial was aimed at pure GUI users.
But I guess you have to use local timers, if you want MUI and accuracy.
 

Chaosy

Tutorial Reviewer
Level 40
Joined
Jun 9, 2011
Messages
13,182
Based on the feedback by @Jampion I choose to graveyard this for the following reasons:
  • This is a very niche tutorial, I would say. Not a dealbreaker but worth considering
  • There are other solutions to this that is arguably easier to work with
  • Images should either be smaller or put in hidden tags
  • There are a few other minor tweaks I would prefer when reading through long tutorials, makes structure/layout a lot more important
  • I would also argue that it would be more user friendly to simply make it a system and upload it to the spell section rather than following a step by step guide. Although there is an argument to be made that learning is better.
I think this CAN be salvaged, but as the author is inactive (for 2 years) I graveyard it until updated.
I want to applaud the effort however, salute.
 
Top