Function differentiate between Replays and actual gameplay

09-01-2007, 09:55 AM

EDIT: Forgot to initilize the Cache

This is the last time I will post this (I promise

). As some people may already know, Captain Griffen and I recently discovered a way to differentiate between replays and actual game play. I figured out that the behaviour of camera along with the fact that any actions during pauses are skipped during replays but suspended during game play we managed to create a function that will return true if you're playing the actual game, and false if it's a replay

The only problem is since we are dealing with Cameras there were syncing problems. Captain Griffen used PitzerMike's 12bitSynInt function, which worked without problems; however, it needs to create dummy units and the camera work is too noticable. This version of the function only requires a gamecache; it uses syncing through gamecache as a pose to selections with dummy units

NOTES
- It uses up one pause during game play (if anyone knows how to prevent the pause going towards the 3 limit on Bnet please tell)
- It creates noticable lag when called, do not do it during actual game play and only call it once (its a good idea to call it when the map starts and your loading other things in your map)
- The message that <player> paused the game will also come up

JASS:

//<- InGame function created by PandaMine with help from Captain Griffein
globals
    gamecache InGameCache
endglobals

function InGameCacheSetup takes nothing returns nothing
    call FlushGameCache(InitGameCache("InGameCache"))
    set InGameCache=InitGameCache("InGameCache")
endfunction

function IsInGame takes nothing returns boolean
    local boolean output
    local integer counter = 1
    local real currentx
    local real currenty
    local real x
    local real y
    local integer firstplayer

    loop
        exitwhen counter > 12
        if GetPlayerSlotState(Player(counter - 1)) == PLAYER_SLOT_STATE_PLAYING then
            set firstplayer = counter - 1
            set counter = 13
        endif
        set counter = counter + 1
    endloop

    call PauseGame(true)
    call TriggerSleepAction(0)

    call StoreReal(InGameCache,"sync","x", GetCameraTargetPositionX())
    call StoreReal(InGameCache,"sync","y", GetCameraTargetPositionY())
    call TriggerSyncStart()
    call SyncStoredReal(InGameCache,"sync","x")
    call SyncStoredReal(InGameCache,"sync","y")
    call TriggerSyncReady()
    set currentx = GetStoredReal(InGameCache,"sync","x")
    set currenty = GetStoredReal(InGameCache,"sync","y")

    call SetCameraPositionForPlayer(Player(firstplayer),currentx+1,currenty + 1)

    call TriggerSleepAction(0)
    call PauseGame(false)

    call StoreReal(InGameCache,"sync","x", GetCameraTargetPositionX())
    call TriggerSyncStart()
    call SyncStoredReal(InGameCache,"sync","x")
    call TriggerSyncReady()
    set x = GetStoredReal(InGameCache,"sync","x")
    if x == currentx + 1 then
        set output = true
    else
        set output = false
    endif
    call SetCameraPositionForPlayer(Player(firstplayer),currentx,currenty)
    set counter = 0
    set x = 0
    set y = 0
    set currentx = 0
    set currenty = 0
    set firstplayer = 0
    return output
endfunction

09-01-2007, 10:26 AM	#2
Pyrogasm	Reals, Integers, and Booleans don't leak. Thus, these lines are unnecessary: JASS: set counter = 0 set x = 0 set y = 0 set currentx = 0 set currenty = 0 set firstplayer = 0 Additionally, you could just declare output as false and remove the else statement: JASS: local boolean output = false //... if x == currentx + 1 then set output = true endif

09-01-2007, 10:56 AM

PandaMine

Quote:

Originally Posted by Pyrogasm

Reals, Integers, and Booleans don't leak. Thus, these lines are unnecessary:

JASS:

set counter = 0
set x = 0
set y = 0
set currentx = 0
set currenty = 0
set firstplayer = 0

Additionally, you could just declare output as false and remove the else statement:

JASS:

local boolean output = false
//...
if x == currentx + 1 then
     set output = true
endif

They do leak, just incredibly minor. They leak the pointer location and not the actual value. Also apparently wc3 parses faster if you have an else in there

09-01-2007, 11:01 AM

Pyrogasm

Quote:

Originally Posted by PandaMine

They do leak, just incredibly minor.

So why does it matter to you since this function will only be run 1 time per game and the leak is apparently "incredibly minor"?

As for the else parsing, I didn't know that.

09-01-2007, 11:10 AM	#5
PandaMine	Well exactly it doesn't really matter, no point in removing it thogh. It is proprably good to know because if you have a timer that happens very often and you dont set integers/reals to 0 and bools to false you can create some lag (although highly unlikely)

09-01-2007, 01:30 PM

Anitarf

Quote:

Originally Posted by PandaMine

They do leak, just incredibly minor. They leak the pointer location and not the actual value. Also apparently wc3 parses faster if you have an else in there

Where do you get this stuff from?

09-01-2007, 01:33 PM	#7
MindWorX	PandaMine, try doing a return bug conversion of a real, or a boolean, you'll see they defiantly doesn't leak... Why would they ever need a pointer to point at something that can be written as a long alone?

09-02-2007, 12:00 AM	#8
PandaMine	Vexorian mentioned somewhere (I cant remember where) that putting variables equal to 0 means that wc3 can recycle the use of variables. I think it was mentioned in his CSCache somewhere or on the forums. He mentioned it was incredibly minor and you shouldn't worry about it. Its more of a habit for me :)

09-02-2007, 12:15 AM	#9
Pyrogasm	You only need to do it for handles. Not primitives.

09-02-2007, 12:42 AM	#10
Toadcop	+ it not leaks. This handle will be simple not recycled, thats all =)

09-02-2007, 01:50 AM	#11
PandaMine	Must have gotten confused, but I swear I saw it somewhere for even hard coded variables