by Skippy » Thu Sep 06, 2007 10:34 am
@HotWax: I see nothing wrong per se with the concept; it's more that it seems totally unnecessary for the implementation being discussed. From what dochist has said, his is a complex underwater environment, and having to stick a WaterZone thing in ever single sector would be problematic to keep track of (though no, I'm not purporting to be any bastion of immaculate mapping practices here
).
Yes, having to use Transfer_Heights may seem unnecessary in a totally flooded sector, but once set up it is easily tweaked and adjusted, and offers much more editing flexibility (the potential to drain the flooded areas later, for one - as you point out, WaterZone things can't be destroyed or deactivated). The idea of using a deep water thing for every single sector that needs to be swimmable could quickly get out of hand, and has the potential to be a nightmare if, say, the colour of the water needs changing at any point. The actual WaterZone thing itself is practically redundant due to the 'swimmable' flag bit available in the line special anyway, in my opinion (I certainly never use it when mapping, at least).
I agree that setting up swimmable sectors can frequently be more trouble than it should be, but in the case of Transfer_Heights it at least offers a degree of flexibility should the need arise. If this get's No'd, it would most likely be that it's an unneccesary addition to achieve something perfectly within the capabilities of the existing featureset. Still, as you say, it's up to the devs (all hail).
EDIT: not to hijack the original suggestion, but a better use of the args for a WaterZone thing might be in setting the warping speed of the fake floor and ceiling textures - it would allow for a better indication of a liquid's viscosity, rather than just having to pick between warp and warp 2 in ANIMDEFS. The WaterZone thing is initialized at map load, IIRC. Just an idea.
@HotWax: I see nothing wrong per se with the concept; it's more that it seems totally unnecessary for the implementation being discussed. From what dochist has said, his is a complex underwater environment, and having to stick a WaterZone thing in ever single sector would be problematic to keep track of (though no, I'm not purporting to be any bastion of immaculate mapping practices here :)).
Yes, having to use Transfer_Heights may seem unnecessary in a totally flooded sector, but once set up it is easily tweaked and adjusted, and offers much more editing flexibility (the potential to drain the flooded areas later, for one - as you point out, WaterZone things can't be destroyed or deactivated). The idea of using a deep water thing for every single sector that needs to be swimmable could quickly get out of hand, and has the potential to be a nightmare if, say, the colour of the water needs changing at any point. The actual WaterZone thing itself is practically redundant due to the 'swimmable' flag bit available in the line special anyway, in my opinion (I certainly never use it when mapping, at least).
I agree that setting up swimmable sectors can frequently be more trouble than it should be, but in the case of Transfer_Heights it at least offers a degree of flexibility should the need arise. If this get's No'd, it would most likely be that it's an unneccesary addition to achieve something perfectly within the capabilities of the existing featureset. Still, as you say, it's up to the devs (all hail). :wink:
EDIT: not to hijack the original suggestion, but a better use of the args for a WaterZone thing might be in setting the warping speed of the fake floor and ceiling textures - it would allow for a better indication of a liquid's viscosity, rather than just having to pick between warp and warp 2 in ANIMDEFS. The WaterZone thing is initialized at map load, IIRC. Just an idea.