[JASS] Fog Modifiers and regions, could structs be beneficial?

[Emm-A-]

Hi everyone,

I have two questions relating to the same issue. I have a map, which also features an open world section similar to RPGs. In there I got different regions and a lot of stuff attached to them like two visibility modifiers and an initial black mask modifier for each region and so on.

The system works like this:

pseudo code

Init
Create regions and store them via a unique number
Create a fog modifier VISIBLE on the region's rects for each player and attach it to the unique number
Create a fog modifier FOG_OF_WAR ...
Create a fog modifier BLACK_MASK ....

A UNIT ENTERS REGION
Get the unique region number of triggering region
if unit enters first time then destroy BLACK_MASK and store the region as being discovered
if unit enters then 
Disable FOG_OF_WAR and enable VISIBILITY
if unit leaves then 
Enable FOG_OF_WAR and disable VISIBILITY

1. question: would it be beneficial to use structs in my case?
conceptual question, no coding issue

At the moment , regions are saved in a region array, numbers in a hashcache, fog modifiers in a fogModifier array. As there is also music and special camera settings attached to each region via the hashcache as well, obviously I am having A LOT of complicated and ugly code now. Its working quite ok, but I thought, I have to handle the regions as unique objects now and assign a struct to each created region which stores all this versatile data at once.

The problem is, I never used stucts for a purpose like this, so do you think, it would be beneficial in this case?

2. question: technical issue
technical issue

My problem is, that this system always hides a left area and shows an entered area. But there is one region I want to be visible for players the whole time. So I had the idea to just create a VISIBILITY modifier instead of FOG_OF_WAR modifier for this specific region.

Here is the function, that hides a left region for the requesting player:

function HideRegion

public function HideRegionForPlayer takes integer regionIndex, player p returns nothing
        // this function adjusts the invisibility for a requesting player. It starts an invisibility zone for the player in the specified
        // region. Depending on the region being openworld or not, this zone will be fogged or masked. 
        local integer playerId = GetPlayerId( p)
        // 1. Disable visibility zone for the requested region
        call FogModifierStop( udg_VISIBILITY_MOD[(playerId*500)+regionIndex])
        // 2. Enable invisibility zone for this region 
        call FogModifierStart( udg_VISIBILITY_MOD[(playerId*500)+regionIndex+172])
        // If Regions is a special AddRects attached rect, hide them now
        if (regionIndex == 60) or (regionIndex == 121) or (regionIndex == 170) then
            call AdjustAddedRectsAndHideForPlayer( regionIndex, playerId)
        endif
    endfunction

So, in this case

udg_VISIBILITY_MOD[(playerId*500)+regionIndex]) = type VISIBILITY
udg_VISIBILITY_MOD[(playerId*500)+regionIndex+172]) = type VISIBILITY

and as the respective function that shows the regions upon entry:

function ShowRegion

public function ShowRegionForPlayer takes integer regionIndex, player p returns nothing
        // this function adjusts the visibility for a requesting player. It starts a visibility zone for the player in the specified
        // region and disables any invisibility in this regions first. 
        local integer playerId = GetPlayerId( p)
        // 1. Disable invisibility zone for the requested region
        call FogModifierStop( udg_VISIBILITY_MOD[(playerId*500)+regionIndex+172])
        // 2. Enable visibility zone for this region 
        call FogModifierStart( udg_VISIBILITY_MOD[(playerId*500)+regionIndex])
        // If Regions is a special AddRects attached rect, Show them now
        if (regionIndex == 60) or (regionIndex == 121) or (regionIndex == 170) then
            call AdjustAddedRectsAndShowForPlayer( regionIndex, playerId)
        endif
    endfunction

does exactly the oposite of the hiding function, this special region should ALWAYS be visible

The problem is, IT IS NOT - it always turns black_masked, when u leave it. I really am wondering, why this is the case. Do u have any idea, why this could happen? I do not create any black mask modifier on this region, just the initial black mask by wc3 via BlackMaskEnable(true). I could just create one more "brute force" visibility modifier but this is more data that could be avoided ....


thank u for reading this long post and any suggestions are welcome.

 

[Emm-A-]

sry to bump this once again. I am really not sure whether or not it is beneficial to use structs for such a case described above.

Is there someone with experience in vJass that could share his opinion on this please?

(Is it more complicated using a struct there or using multiple data arrays?)

 

[Arad MNK]

You don't need a struct but it can be used.

 

[IcemanBo]

structs provide a new syntax, and and can/will be easier to write and read.
Also you mostly will have no, or less "[]" syntax which can be confusing if used too much and nested.

For example

set this.that.who = GetTriggerPlayer()

1. Instance this (must contain instance that as member)
2. Instance that (must contain instance who as member)
3. struct member who (must be from type player)

the struct could look like this:

struct a
    player who
endstruct

struct b
    a that

    method foo takes player p returns nothing
        set this.that.who = p
    endmethod
endstruct

So it would set the player who of struct a which is a member of struct b without any [] syntax.

Here are some tutorials vor structs at chatpter vJASS: http://www.hiveworkshop.com/forums/miscellaneous-tutorials-456/elemental-coder-guide-274346/

 

[Emm-A-]

Well, thanks for the answers. Thanks @IcemanBo for the details shared

I think I will change the code to use structs

I assume, these strange fog modifier behaviours will vanish then anyway, as it is probably some faulty writing ...

 

[IcemanBo]

For this special region maybe no function to modify fog/visibility should ever run but onInitialization, or?

 

[Emm-A-]

For this special region maybe no function to modify fog/visibility should ever run but onInitialization, or?

I guess you are right, thanks