Multiple references/reference chains lead to slow (infinite?) load times

[GoogleCodeExporter]

While tweaking some shadow/overload definitions with the new xvm config, I came 
onto a situation where a certain set of configs would seemingly prevent the 
game from ever starting (or taking *way* longer than expected).

Basically I fiddled around a bit with a file from issue 400 (markersShared.xc) 
and reduced the file size by ~30% through some shadows & overloads, *but* when 
using this config the game never reached the login screen - the screen stays 
black.

xvm.log reads:
[...]
2013.06.20 10:44:43 [i] Starting game process: WorldOfTanks.exe 
2013.06.20 10:44:43 [D] Check game process
2013.06.20 10:44:44 [D] wotProcess: 
                        File:             H:\Spiele\World_of_Tanks\WorldOfTanks.exe
                        InternalName:     
                        OriginalFilename: WorldOfTanks.exe
                        FileVersion:      0, 8, 6, 0
                        FileDescription:  World of Tanks
                        Product:          WorldOfTanks
                        ProductVersion:   0, 8, 6, 0
                        Debug:            False
                        Patched:          False
                        PreRelease:       False
                        PrivateBuild:     False
                        SpecialBuild:     False
                        Language:         English (Australia)
2013.06.20 10:44:44 [D] Wait for process to exit
2013.06.20 10:44:49 [i] [L:000] xvm-> [ "gameloading" ]
2013.06.20 10:44:49 [i] [L:001] LoadFiles: ['xvm.xc']
2013.06.20 10:44:49 [i] [L:002] LoadFiles: ['markers.xc']
2013.06.20 10:44:49 [i] [L:003] LoadFiles: ['markersAliveNormal.xc', 
'markersAliveExtended.xc', 'markersDeadNormal.xc', 'markersDeadExtended.xc']

There is *nothing* after this line until you manually terminate the WoT process 
- so far I've tried waiting 10 minutes and more :(

Example config that triggers the behaviour:
https://docs.google.com/file/d/0B2GJ6pU1K8cKdFRqRFdXc3JMNnc/edit

I have no idea if this is actually just a _massive_ slowdown, or if the json 
parser is stuck in some kind of loop. Or if it's a side effect of issue 400.

----
Bah - for now here go my plans to cook Alastanka's 600 special minimap circles 
down just 4 base types with different distances :(

Original issue reported on code.google.com by emh...@gmail.com on 20 Jun 2013 at 9:09

[GoogleCodeExporter]

You are trying to mix short and full ref syntax:
"$ref": ${"markersShared.xc":"def.fontField"},

fixed version is:
"$ref": { "file":"markersShared.xc", path:"def.fontField" }

I'll try to fix endless loop in this case.

Original comment by m.schedr...@gmail.com on 20 Jun 2013 at 10:01

• Changed state: Accepted

[GoogleCodeExporter]

And
      "font": {                    
        "$ref": ${"def.fontOverhead" }
      }             
can be replaces with
      "font": ${"def.fontOverhead" }

Original comment by m.schedr...@gmail.com on 20 Jun 2013 at 10:22

[GoogleCodeExporter]

Fixed, now exception will be thown when ref-to-ref found.

Original comment by m.schedr...@gmail.com on 20 Jun 2013 at 12:08

• Changed state: Fixed

[GoogleCodeExporter]

I think your 'ref-to-ref' error check is insufficient or misleading.

With r1997 you added a check for data.$ref.$ref and subsequently throw an error 
with text: "endless reference recursion in...".

You're checking for a situation A -> B -> C, but the error message states A <-> 
B or (A -> B -> C -> A). 
So what you are disallowing are multi level references, but you throw an error 
as if it was a cyclic reference.

So, which should it be: 
a) No multi level references
b) No cyclic references

(b) *cannot* ever work, but I don't know if you want to go to the trouble to 
check for cycles in the reference graph (possible implementation: DFS and not 
allowing any back edges). I think this may be *way* too much work - I'd simply 
let the parser hang/blow up if someone manages a configuration with cyclic 
dependencies.
(a) on the other hand should be workable. There's no inherent obstacle to 
converting the JSON config to Actionscript. Maybe there's a speed issue in 
there, but that could be dealt with once it occurs.

Also a simple 'no multi level references' cannot even catch all possible cycles:
{
  "foo": {
    "$ref": {"file":"example.xc", "path":"foo"}
  }
}
this (admittedly dumb self reference) is never caught, or similarly:
{
  "foo": {
     "value": {
        "$ref": {"file":"example.xc", "path":"bar"}
     }
  }
  "bar": {
     "value": {
        "$ref": {"file":"example.xc", "path":"foo"}
     }
  }
}
So unless the no multi level references check is in there intentionally, I 
think it doesn't help catching all possible errors, but removes a lot of nice 
possibilities.

Original comment by emh...@gmail.com on 20 Jun 2013 at 10:02

[GoogleCodeExporter]

Thats enough, because only "$ref": { "$ref": are leading to endless recursion.

Multi level references are allowed:
"foo": { "$ref": { "path":"..." } }
"bar": { "$ref": { "path":"foo" } }
"baz": { "$ref": { "path":"bar" } }

And even if endless loop will present, it will be limited with 32 level of 
recursion:

        // limit of recursion
        if (level > 32)
            return data;

I can change error message, if you think it is misleading.

Original comment by m.schedr...@gmail.com on 21 Jun 2013 at 7:35