Player Resource Monitoring v1.01

This bundle is marked as approved. It works and satisfies the submission rules.
"Player Resources Monitoring" --> fires an event when gold/lumber has changed.

Player Resources Monitoring ver 1.01
fires an event when gold/lumber has changed
Use Event: "Game PRM_EVENT becomes Equal to 1.00" to detect gold changes
Use Event: "Game PRM_EVENT becomes Equal to 2.00" to detect lumber changes
Use "PRM_Player" to filter who's resource changed
"PRM_Change" is the amount of gold (or lumber) player gain or lose on event
(can be positive or negative).
If boolean "PRM_MonitorPlayer[gui-player-number]" is set to false then corresponding
player will not be monitored, anyway by default all (16) players are monitored.
If you want to add/subtract/set resource *inside* PRM_EVENT trigger then:
1. set boolean "PRM_FireEvent" to false
2. add/subtract/set resource
3. set boolean "PRM_FireEvent" to true

How To Import:
1. Enable "Automatically create unknown variables while pasting trigger data" in World Editor general preferences.
2. Copy the trigger "PRMVars" from demo map and paste into your map.
3. Copy the trigger "PRM" from demo map and paste into your map.

Example:

  • GoldChanged
    • Events
      • Game - PRM_Event becomes Equal to 1.00
    • Conditions
    • Actions
      • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
        • If - Conditions
          • PRM_Change Greater than 0
        • Then - Actions
          • Game - Display to (All players) the text: (((Name of PRM_Player) + 's gold |cff00ff00increases|r by: ) + (String(PRM_Change)))
        • Else - Actions
          • Game - Display to (All players) the text: (((Name of PRM_Player) + 's gold |cffff0000decreases|r by: ) + (String(PRM_Change)))
  • LumberChanged
    • Events
      • Game - PRM_Event becomes Equal to 2.00
    • Conditions
    • Actions
      • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
        • If - Conditions
          • PRM_Change Greater than 0
        • Then - Actions
          • Game - Display to (All players) the text: (((Name of PRM_Player) + 's lumber |cff00ff00increases|r by: ) + (String(PRM_Change)))
          • Set PRM_FireEvent = False
          • Player - Add 10 to PRM_Player Current lumber
          • Set PRM_FireEvent = True
        • Else - Actions
          • Game - Display to (All players) the text: (((Name of PRM_Player) + 's lumber |cffff0000decreases|r by: ) + (String(PRM_Change)))
  • esc
    • Events
      • Player - Player 1 (Red) skips a cinematic sequence
    • Conditions
    • Actions
      • If (All Conditions are True) then do (Then Actions) else do (Else Actions)
        • If - Conditions
          • PRM_MonitorPlayer[1] Equal to True
        • Then - Actions
          • Game - Display to (All players) the text: PLAYER RED NOT MONI...
          • Set PRM_MonitorPlayer[1] = False
        • Else - Actions
          • Game - Display to (All players) the text: PLAYER RED MONITORED
          • Set PRM_MonitorPlayer[1] = True



Variable creator:

  • PRMVars
    • Events
      • Map initialization
    • Conditions
    • Actions
      • Set PRM_EVENT = 0.00
      • Set PRM_Change = 0
      • Set PRM_FireEvent = True
      • Set PRM_GoldLevel[0] = 0
      • Set PRM_LumberLevel[0] = 0
      • Set PRM_Player = Player 1 (Red)
      • -------- ----------- --------
      • -------- set to "false" these player(s) you do *not* want to monitor for resource changes --------
      • -------- you can change those booleans whenever you want also later --------
      • -------- players 1-12 (from red player[1] to brown player[12]) --------
      • -------- nr13 - player neutral hostile, nr14 - player neutral victim --------
      • -------- nr15 - player neutral extra, nr16 - player neutral passive --------
      • -------- by default all (16) players are monitored --------
      • -------- ----------- --------
      • -------- example: here we set to not monitor players: teal[3] and neutral hostile[13] --------
      • Set PRM_MonitorPlayer[3] = False
      • Set PRM_MonitorPlayer[13] = False
      • -------- ----------- --------


Main Trigger:

JASS:
//===============================================
// Player Resources Monitoring ver 1.01
// fires an event when gold/lumber has changed
// Use Event: "Game PRM_EVENT becomes Equal to 1.00" to detect gold changes
// Use Event: "Game PRM_EVENT becomes Equal to 2.00" to detect lumber changes
// Use "PRM_Player" to filter who's resource changed
// "PRM_Change" is the amount of gold (or lumber) player gain or lose on event 
//      (can be positive or negative).
// If boolean "PRM_MonitorPlayer[gui-player-number]" is set to false then corresponding
//      player will not be monitored, anyway by default all (16) players are monitored.
// If you want to add/subtract/set resource *inside* PRM_EVENT trigger then:
// 1. set boolean "PRM_FireEvent" to false
// 2. add/subtract/set resource
// 3. set boolean "PRM_FireEvent" to true
// --------------------------------------
// happy mapping;] ZibiTheWand3r3r
//================================================
function PRM_Monitor takes nothing returns boolean
    local player p = GetTriggerPlayer()
    local integer id = GetPlayerId(p)
    local integer g = GetPlayerState(p, PLAYER_STATE_RESOURCE_GOLD)
    local integer l = GetPlayerState(p, PLAYER_STATE_RESOURCE_LUMBER)

    if not udg_PRM_MonitorPlayer[id+1] then // keep up-to date player's resources:
        set udg_PRM_GoldLevel[id] = g
        set udg_PRM_LumberLevel[id] = l            
        return false
    endif    
    set udg_PRM_Player = p
    if g != udg_PRM_GoldLevel[id] then //gold change detected
        set udg_PRM_Change = g - udg_PRM_GoldLevel[id]
        set udg_PRM_GoldLevel[id] = g
        if udg_PRM_FireEvent then
            set udg_PRM_EVENT = 0.00
            set udg_PRM_EVENT = 1.00
        endif
    elseif l != udg_PRM_LumberLevel[id] then // lumber change detected
        set udg_PRM_Change = l - udg_PRM_LumberLevel[id]
        set udg_PRM_LumberLevel[id] = l
        if udg_PRM_FireEvent then
            set udg_PRM_EVENT = 0.00
            set udg_PRM_EVENT = 2.00
        endif
    endif
    return false
endfunction
//================================================
//================================================
function InitTrig_PRM takes nothing returns nothing
    local integer id=0
    set gg_trg_PRM = CreateTrigger(  )
    set udg_PRM_EVENT = 0.00
    set udg_PRM_Change = 0
    set udg_PRM_FireEvent = true
    set udg_PRM_Player = Player(0)
    
    loop
        set udg_PRM_GoldLevel[id] = GetPlayerState(Player(id), PLAYER_STATE_RESOURCE_GOLD)
        set udg_PRM_LumberLevel[id] = GetPlayerState(Player(id), PLAYER_STATE_RESOURCE_LUMBER)
        set udg_PRM_MonitorPlayer[id+1] = true // for gui use range: 1-16
        call TriggerRegisterPlayerStateEvent(gg_trg_PRM, Player(id), PLAYER_STATE_RESOURCE_GOLD, NOT_EQUAL, 0.00)
        call TriggerRegisterPlayerStateEvent(gg_trg_PRM, Player(id), PLAYER_STATE_RESOURCE_GOLD, EQUAL, 0.00)
        call TriggerRegisterPlayerStateEvent(gg_trg_PRM, Player(id), PLAYER_STATE_RESOURCE_LUMBER, NOT_EQUAL, 0.00)
        call TriggerRegisterPlayerStateEvent(gg_trg_PRM, Player(id), PLAYER_STATE_RESOURCE_LUMBER, EQUAL, 0.00)
        set id=id+1
        exitwhen id == bj_MAX_PLAYER_SLOTS
    endloop
        call TriggerAddCondition(gg_trg_PRM, Condition(function PRM_Monitor))
endfunction


Keywords:
gold change, lumber change, changed, resource changed event
Contents

Player Resource Monitoring ver 1.01 (Map)

Reviews
17:30, 11th March 2016 Tank-Commander: V1.01 - The indentation of one line in the initTrig function is wrong, but the system is in an approvable state - a very simple small piece of code; has some useful application (also just for future reference...

Moderator

M

Moderator

17:30, 11th March 2016
Tank-Commander: V1.01 - The indentation of one line in the initTrig function is wrong, but the system is in an approvable state - a very simple small piece of code; has some useful application (also just for future reference you don't need to name the trigger variable gg_trig(blah) can just use t as you had before)


19:30, 10th March 2016
Tank-Commander: There's a few issues remaining with the system, please refer to my post and address them accordingly

00:20, 28th Feb 2016
Tank-Commander: Flux's post covers everything that needs to be said about the system
 
Level 22
Joined
Feb 6, 2014
Messages
2,468
Took a quick look without testing,
- Why create function PRM_Init? Why not just put its content above where you called "PRM_Init"? If I'm not mistaken, Init_TrigPRM will be generated at the bottom of the script so you'll do fine.
- If a player loses gold and lumber at the same time, will trigger PRM run twice? If not, then you won't detect PRM lumber since you're using "elseif".
- You called GetTriggerPlayer twice in PRM_Monitor.
- You're using 1 trigger for all players that means players that didn't change gold/lumber will get registered again. I think it's more efficient to have 1 trigger per player to avoid the loop. Imagine a 12 player melee map, assume each player changes gold/lumber every sec, then your trigger will be 'refreshed' 12 times every second and in those 12 times, you have to loop at all players where 11 of them didn't change their gold/lumber at that point in time.
- Why not make this in JASS since more than 80% is in custom script?
 

Chaosy

Tutorial Reviewer
Level 39
Joined
Jun 9, 2011
Messages
13,083
There's basically no reason for this to be in a GUI trigger format - you use so much custom script it should just be in JASS, other than that Flux covers pretty much everything else - it's pretty false to be claiming this is GUI/Triggers at this point (though it is GUI-Friendly)

udg, not that debate again. Had it with the mods in the comments of my conversation system.

I'll just say I disagree and leave it at that.
 
Level 17
Joined
Nov 21, 2012
Messages
836
thanks guys for feedback
Init_TrigPRM will be generated at the bottom of the script
no, at the top, so it should be like it is ;]
If a player loses gold and lumber at the same time, will trigger PRM run twice?
no, once, but then next recreated trigger runs second time for lumber change. Try build barrack (cost gold + lumber), it works fine. It recreates trigger after any change detected.
You called GetTriggerPlayer twice in PRM_Monitor
ok, added local player. Got silly question: should I null local player or not? Im not sure :razz:
You're using 1 trigger for all players
ok I'll change: 1 trigger for each player. Every trigger with 2 events.
Why not make this in JASS since more than 80% is in custom script?
It is in vJass, but I copied to gui-trigger for one reason. Make it as easy for GUI users as possible. No worries for creating variables, just CnP one trigger.

it should not be else if, it should just be if.
Its fine in my opinion.. Trigger runs one time only for one event only, then is destroyed and new one is created. So if you build barracks (costs gld+lumber) then 1st event (gold spend) triggers --> trigger runs, trigger destroyed, new one created --> triggers 2nd event (lumber spend) this new created trigger runs. Thats the way I understand jass, correct me if I wrong.

I will update this today. zibi

ok, updated;]
 
Last edited:
Level 22
Joined
Feb 6, 2014
Messages
2,468
no, at the top, so it should be like it is ;]
You're right, the Actions part are generated at the top, my mistake. But if it is written in JASS, then function PRM_Init is not needed so I suggest just write it in JASS.

no, once, but then next recreated trigger runs second time for lumber change. Try build barrack (cost gold + lumber), it works fine. It recreates trigger after any change detected.
I see, therefore 'elseif' is correct.

ok I'll change: 1 trigger for each player. Every trigger with 2 events.
You could add (if you want) a feature where users will be able to define who to monitor, something like PlayerResourceMonitor(player) and PlayerResourceUnmonitor(player). That way, it doesn't monitor neutral players' resources by default and gives better control.

It is in vJass, but I copied to gui-trigger for one reason. Make it as easy for GUI users as possible. No worries for creating variables, just CnP one trigger.
How does this make it "easy for GUI users" since almost all is in custom script? I think it would be better if it is in JASS (not vJASS) format since it still doesn't require JNGP but gives better readability.

Overall, it's a nice addition to the Spells Section, this is without a doubt a useful resource, well done.
 
Level 19
Joined
Mar 18, 2012
Messages
1,717
Maybe you need to build in a recursion safety.
I can see users adding resource on resource event.
In that case it's a con that it's impossible to disable the custom event trigger.

You should use local player p instead of Player(id).

udg, not that debate again. Had it with the mods in the comments of my conversation system.

I'll just say I disagree and leave it at that.
That's just your opinion. Custom script in GUI triggers hurts inarguably read-ability.

should I null local player or not? Im not sure
Player handles don't leak, nulling them is optional.

It is in vJass, but I copied to gui-trigger for one reason. Make it as easy for GUI users as possible. No worries for creating variables, just CnP one trigger.
You don't use vJass keywords. It's pure JASS expressed in custom script.
 
Level 17
Joined
Nov 21, 2012
Messages
836
Yeah, ok let it be in Jass. Added recursion safety, thanks BPower for suggestion. Also added PRM_PlayerMonitor[] variable, thanks Flux!
You know, today I changed idea: recreating trigger is not necessary, I added 2 events for gold/lumber: "equal to 0", and "not equal to 0" ;] it's cover all our needs to fire trigger for any gold/lumber changes;]

EDIT:
forgot to remove few I2R, R2I conversion since now all they can be integers
i'll wait when you look at this new code,
zibi
edit:
updated those I2R, R2I
 
Last edited:
Level 12
Joined
Jan 2, 2016
Messages
972
I'd really love it if this system has an indicator - if the resource is 'gained' trough harvesting - have a variable, that points towards the event response worker (the worker that has returned the resource) :p
I do realize, that this is going to be a pain in the ass to do, but it will be a nice addition, and this system will have a wider use :p
 
Add a version number to the system, other critique:

Major:
- All the code within Trig_PRM_Actions could be placed within initTrig_PRM (the code currently in initTrig_PRM is uneccessary
- udg_PRM_FireEvent should be either a constant function (removing the need for the variable) or should be set in a config function (along with other properties like it) or set in the initTrig function. As it stands the system lacks a configuration
- You only need to create one trigger for the resource monitoring (don't need a new trigger for each set of event listeners)

Minor:
- When setting up the event listeners you could use bj_MAX_PLAYERS instead of the hardcoded 15 (I'd suggest checking if this interferes with monitoring of neutral players)
- For clarity the event variable could be capitalised (fairly standard)
 
Level 17
Joined
Nov 21, 2012
Messages
836
All the code within Trig_PRM_Actions could be placed within initTrig_PRM
done

udg_PRM_FireEvent should be .. or set in the initTrig function
done

You only need to create one trigger for the resource monitoring
yes, it's now only PRM trigger

When setting up the event listeners you could use bj_MAX_PLAYER_SLOTS
done

event variable could be capitalised
changed

@WereElf: I'd really love it if this system has an indicator - if the resource is 'gained' trough harvesting
hmm;] it's suppose to be simple snippet (I personaly like small additions)
..maybe in the future ;]
 
Top