[Ohrrpgce] SVN: teeemcee/5077 Set the visibility of map layers based on whether they're set to visible

[James Paige]

On Wed, Feb 29, 2012 at 12:25:44PM +1300, Ralph Versteegen wrote:
> On 29 February 2012 12:01, James Paige <Bob at hamsterrepublic.com> wrote:
> > On Wed, Feb 29, 2012 at 11:51:26AM +1300, Ralph Versteegen wrote:
> >> On 29 February 2012 04:01, James Paige <Bob at hamsterrepublic.com> wrote:
> >> > On Mon, Feb 27, 2012 at 11:14:57PM -0800, subversion at HamsterRepublic.com wrote:
> >> >> teeemcee
> >> >> 2012-02-27 23:14:57 -0800 (Mon, 27 Feb 2012)
> >> >> 106
> >> >> Set the visibility of map layers based on whether they're set to visible in the map editor (fixes bug 952)
> >> >> ---
> >> >> U   wip/game.bas
> >> >
> >> > I wonder if this breaks any games that left layers disabled in the
> >> > editor but that did not intend them to be disabled in the game? Seems
> >> > like rpgbatch could tell us, maybe?
> >> >
> >> > ---
> >> > James
> >>
> >> Luckily that would only affect games made with nightlies since Zenzizenzic.
> >
> > Yeah, you are right. The chances of a game being broken by this are
> > pretty slim, so I am not worried.
> >
> > One thing that I am^H^Hwas a little worried about is that if I read the
> > code correctly, the visibility of map layers was never changed when you
> > moved from map to map, and now with this fix it is. That means a script
> > might have hidden a map layer and then expected it to stay hidden as the
> > player moved from map to map. That would have been bad scripting, but it
> > seemed like a real enough possibility that it scared me into
> > double-checking to see if I do that in any of my own games (Turns out
> > that I don't)
> >
> > However, in spite of my fear, I think it is not that huge a deal. the
> > chances of somebody doing something like that are probably even slimmer
> > than the other issue :)
> 
> It worried me too, but I don't see any reasonable alternative. For
> example, if we added a second mapslice-specific enabled bit, then we
> can't sleep soundly either, because we wouldn't be emulating the old
> original behaviour of not drawing anything parented to the map slice
> when it's disabled.
> 
> It's horrible that we have to worry about breaking games every single
> time we fix a slice-related bug.
> 
> We still don't have enough restrictions in place to prevent people
> from doing bad things with slices. Rather than a single narrow
> 'Protect' member, I think we should have a bitfield of allowable
> actions, and have semi-restricted reparenting. For example, a
> SelectableSlice belonging to a menu shouldn't be reparentable to
> something that isn't a descendent of its root menu slice.
> 
> All the walkabout slice stuff was added since the last release, so I
> want to get the extra checking in place before the next release. I
> think there's a small chance that anyone has done anything naughty so
> far, but I bet they'll try it eventually.
> 

Ah, yes, I think a ->Protections bitfield member is better than just a 
->Protect member.

What sort of protections do we want to impose on walkabout slices?

We don't want users changing the parenting of walkabouts. We do want to 
let users parent their own slices to walkabouts, but they need to 
understand that slices parented to a walkabout can get unloaded when 
you change maps.

---
James