What are the invisible blocks intended for? being that they are not detected by c_trace or c_move.

How can I create an invisible obstacle? Setting surface to none creates shadows and holes in other blocks.

Is there any chance this behavior will change in the future?

Thanks, Orange. This should be a workaround for invisible blocks.

Thanks, Grimber, for pointing me to the search page.


So, one question was answered.


What I want to Ask Conitec is, why are invisible blocks also passable?
I wish to understand if there is any use for the invisible blocks as they work now, or otherwise, if there's a technical engine issue that would prevent an invisible block of being detected.

Because blocks have TWO flags for a reason (invisible and passable). If there is not a technical problem for that, these Passable and Invisible flags should work in an independent way, and thus invisible blocks would be of some use (and save a lot of work like the Map entity workaround). That is was my third question was about.

Or, maybe there IS a use for these invisible blocks right as they work now. Note that the manual defines invisible blocks as "invisible obstacles". I just can't find out how they can become obstacles.

It is a limit of the collision engine as it is right now. Invisible blocks are culled before they are passed to the collision engine (however, invisible map entities are not).

There are plans to change this, but it isn't a priority. It will probably have to wait until we rework the collision engine.

Thanks, Doug!

Well, it's good to know the truth
I will use invisible sprites for simple barriers. They're less work than creating map entities.

They are great for simple wall-like barriers, I use them too .. Only disadvantage is when you need like a very long wall, using multiple sprites sometimes makes it possible to pass by the invisible wall ... That's kinda not so nice hehehe,

Cheers

In fact it was already taken care of almost a year ago, but maybe not announced loud enough. Just check the [Invisible = None] box in the Map Compiler dialogue.

OoOOOOO!

That is a great step!
Now I don't have to go thru all block surfaces and set to none, which may be an annoying deal of work indeed.

Just in case... (asking won't harm anyone):

Is there a way to avoid the 'holes' when these NONE blocks touch other blocks? For instance, if I make a passable stairway, but put an INVISIBLE BLOCK as a non-passable slope.

If I check invisible == none, the block will behave as surface = none. But it will create an invisible part in the stair steps too!




Another thing in which a surface NONE block differs from a true Invisible block is in shadows. It's great for creating static shadows for model objects... but, maybe there is a hidden flag or something to avoid this?

In this picture, the 'invisible' block (with invisible == none) creates holes in touching surfaces (the floor). Also, it always renders shadows. YOu can see the colored terrain object behind the holes.



Emilio

Yes, the problem is logical - the block still affects the BSP tree although it's invisible. I'll think about a solution for truly invisible blocks.