I know many people have been making some amazing things with doors in the past few weeks. They have become extremely popular. I just thought it would be useful if there were more doors. Im not sure if this is in any way possible, but I thought I would just throw the idea out here.

Possible Doors:

- Doors in all colors
- Well, everying else...

_________________

And like Fdoors or something that acts like Tdoors in that they let fluids through when activated, but only reappear when triggered to do so like odoors

Doors in all block types are a planned possibility (adding more block byte checks, yay(!)), but other than remote doors, and toggle doors, I don't really see what other type you can have.

When HawkServ is released, the active liquid blocks will be default to Operators anyway, and so won't be commonly used by anyone to constitute enough cause for a door that allows fluids through it.

I've just been using the active_water that flows on the map when I need active water, so unless that is no longer going to be available I could still see applications for the block. True that it wouldn't be in common use, but I've never seen anyone complain about having more options whether they choose to optimize on them or not. Perhaps there is an invisible cost associated with having more commands that I'm not aware of?


Edit: Also with the sudden surge of people learning how to make odoor bridges, an "fdoor" would actually make a reasonable amount of sense as the odoor leaves an odd looking hole in the water since it doesn't allow fluids to flow through it.

The cost of making more doors means more time (granted, only points of a millisecond) scanning block byte codes for the type of block placed, more time storing that into an undo file for the user, and searching strings for the byte conversion.

Consider the fact that usually once a *door has been placed, it turns to two stages. The physical block when closed, and an air block when open. You can't place blocks in this open space, as it'll return an error saying that the block is active. This is the easiest way and is all hardcoded. The only way I can think of to make fdoors a viable solution is to check its surrounding blocks (which will take 6 times longer (one for each face)), and if face 0-5 are touching a fluid, to set the open state into the fluid. Logistically this is a pain, since I'd need to figure out the numbers of each face (which I highly doubt is possible, but is using positional coding, yay trig) and determining the block state of surrounding blocks, which will take more time.

This also relies on all servers using HawkServ being the same, which I can assure you, will not happen depending on how well HawkServ picks up. It will also not make any difference on a map that does not have Physics enabled, or does not use an active fluid type, and can be considered misleading.

Logistically, writing a fluid block into HawkServ is a nightmare, for not a lot of gain. Especially since I'll be doing it all by myself, as well as everything else I do for Hawknet.

The easiest way around this is to use a drawbridge build that is higher than the fluid. Most drawbridges are not at water level, and are built to account for a rise or drop in water levels.

Would it not be possible to just copy the code from tdoors which already allow liquid blocks to flow through them when activated? Then add the perameter from the odoors that tells them not to re-reactivate until triggered? The code is already implemented in your software to allow blocks to pass through certain doors, I'd even be happy if the Tdoors that we already have were just changed to not automatically close.

Edit: I used tdoors in an experiment in architect2 and I used them to great effect as a trap for zombies and creepers in redfox's map