Re: [glob2-devel] Checking for nondeterminism

[Erik Søe Sørensen]

Joe Wells skrev:

> Erik Søe Sørensen <address@hidden> writes:
>  
>
> Are you proposing to implement and _maintain_ this?  If so, great.
> :-)
>  
Having researched and thought a bit more, I have refined my stance 
(which, I might add, was modified with an "in case this doesn't exist 
already" :-) to the following (not more that a rehash of earlier posts, 
I think, but anyway):
- Splitting '-nox' up into a '-nox' (for running headless[1]), 
'-profiling' (for stopping automatically and/or repeating runs), and 
'-loadgame' for loading games automatically
- In some way make sure that a net-game may also be loaded and/or 
started; I don't know how much is saved in a net save game (e.g. the 
competing hosts), maybe '-loadgame' is enough?
- Enabling the possibility of computations of more exhaustive checksums
- Writing a separate script to automating set up a localhost-network 
game for reliability testing.

As I hope is apparent, this reduces the amount of code written 
exclusively for this purpose somewhat; the two first items would be nice 
for developing in general (right?), the script should merely build on 
these features, and the exhaustive checksumming should be manageable 
(and not too involved with other code).

[1] But not around in circles, screaming...

> Otherwise it likely won't happen.  :-(  Even if implemented, without
> active maintenance it will quickly rot.
>  
True. Is the revised proposition more edible?
I'd think that options present for the sake of developers (and in use by 
these) would not be at the same risk of rotting?

> > > I don't really know this part of the code.  I think there are two
> > > versions of “locked”: one for not-reachable by non-swimmers and one
> > > for not-reachable by swimmers.  I think this information is used by
> > > some of the AIs.
> > >
> > >      
> > Yes, looking at the code I figured 'locked' must mean 'reachable'.
> > But, reachable from where exactly? Any point on the border of the
> > local gradient? That would have been my guess, but that's not how I
> > read the code.
> >    
>
> I seem to remember that one place it is used is for determining if
> _enemy_ buildings are reachable.  Maybe it is also used for other
> purposes.  Anyway, I guess that it means “reachable from my home
> base”, so it is per-player.  (Please verify this information before
> relying on it!  I don't really know these implementation details.)
>  
Actually I have just figured it out - I think the intention is to 
iterate through all the squares directly surrounding the building to see 
if at least one of them is non-blocked.
It is just rather convoluted code, and seems to rely on the assumption 
that the building is as high as it is wide (e.g. that it is posW*posW 
squares).
I suggest rewriting it into four loops, one for each side of the 
building; I'll do it myself if a second opinion will confirm that this 
is what the code seems to be doing?
(It's Map::updateLocalGradient(), the part about building->locked).

/Erik