[time_area] issues in old code.

[opensourcejunkie]

Hey all,

I'm updating some old 1.6 code to 1.10, and I'm running into a couple of issue with the time_area tags. The code I'm updating is a macro which can be used to place a rune, which when stepped upon emits a light that changes the [time]s for the nearby hexes to daylight conditions (similar to the lighthouse in TRoW, except it can be switched on and off). Here's the code:

Code: Select all

#define SOL_NORTHERN_LIGHTS X Y
    ##|| Create Runes
    {SOL_RUNES_LIT {X} {Y} 4}
    
    ##|| Add Illumination
    [event]
        name=moveto
        first_time_only=no
        {ALLOW_UNDO}
        
        ##:: Reset State
        [remove_item]
            x,y={X},{Y}
        [/remove_item]
        {SOL_RUNES_LIT {X} {Y} 4}
        [time_area]
            id=rune_{X}_{Y}
            remove=yes
        [/time_area]
        
        ##:: Check For Depressed Runestone
        [if]
            [have_unit]
                x,y={X},{Y}
            [/have_unit]
            [then]
                # halo
                [item]
                    x,y={X},{Y}
                    halo=halo/lighthouse-aura.png
                [/item]
                
                # illuminate area
                [time_area]
                    id=rune_{X}_{Y}
                    x={X}
                    y={Y}
                    radius=2
                    {SILENT_AFTERNOON}
                    {SILENT_DUSK}
                    {SILENT_DAWN}
                    {SILENT_MORNING}
                    {SILENT_MORNING}
                    {SILENT_AFTERNOON}
                [/time_area]
            [/then]
        [/if]
    [/event]
    [event] # this event disallows undo when unit moves onto the runes
        name=moveto
        first_time_only=no
        [filter]
            x,y={X},{Y}
        [/filter]
    [/event]
#enddef

I'm running into two problems. First of all, the [time_area] doesn't seem to be removed at the beginning of the move_to event. When a unit steps off the hex, the light halo is removed, but the special time zone remains intact. Any help on figuring that one out would be greatly appreciated.

Second, the time area is no longer synchronized with the main time of the scenario. Before, when the time area was set in place, it would select the [time] which corresponded in position to the scenario's current [time]. In other words, regardless of when the [time_area] was put in play, if it was night in the scenario, it would be dawn in the time area, and if it was dawn in the scenario, it would be morning in the time area, etc.

Now, however, the time in the [time_area] seems to depend on when the [time_area] was put in play, not on the current [time] of the scenario. I did some searching on that, and I think it's a feature, not a bug. The functionality was changed (as far as I understand), so that a time area can have a different number of times than the scenario.

So I'm just wondering if there's any way in place to accomplish what used to be possible, to synchronize the time in the time area with the scenario's time, regardless of when it's turned 'on' or 'off'. I suppose I could have an if statement which checks the current time (or turn number), and launches the appropriate ordering of times so that it'll be synchronized. But, I'm wondering if anyone knows of a more elegant solution.

Thanks in advance for any help on these issues,
~ OSJ

[Anonymissimus]

I don't quite understand the first problem; perhaps the problem lies somewhere in your code. You could look into the savefiles from various states of your scenario, the currently active time area tags including their complete definition should be visible there.

As for the second, you could use [store_time_of_day] and the workaround you describe.
When I fixed those time area bugs (In fact, the schedule in your time_area tag probably wouldn't have worked.) I indeed had something like a [time_area]start_time=<some_time_id> parameter in mind (and perhaps as a subkey for [scenario] as well). This is what you need ? So I guess this makes up for a sensible feature request.

[opensourcejunkie]

Thanks, I'll give that a shot! And I'll check out some saves before and after the event firing; maybe that'll give me a clue for the first error.

I do also like the feature request idea, although since there is a viable workaround, I don't know how pressing it would be. Thanks for you help,
~ Nate

(though for the record, the schedule did work back in 1.6 :-)