It would be like that:
Line_fence(height,block_upper,block_lower);
height: height of the fence
block_upper: blocking flags above the height
block_lower: blocking flags below the height
Blocking flags:
0: No blocking
1: Block player
2: Block monsters
4: Block projectiles
Line_fence special
Moderator: GZDoom Developers
- MartinHowe
- Posts: 2097
- Joined: Mon Aug 11, 2003 1:50 pm
- Preferred Pronouns: He/Him
- Location: East Suffolk (UK)
This has been asked for in various forms, including by me. Seconded. Fences are a pain because their visual height in the game bears no relationship to their actual height; with 2-sided textures, this is impossible even then.
This would be useful also for full-height fences as well. Example: in Sapphire, you can shoot through a fence at some spiders, but they can't shoot through it at you.
I would add "8: Block hitscans" also.
This would be useful also for full-height fences as well. Example: in Sapphire, you can shoot through a fence at some spiders, but they can't shoot through it at you.
I would add "8: Block hitscans" also.
I 'third' this (assuming that even makes sense), then. 
Since Zdoom already has the code to block lines only up to certain heights (BLOCK_RAILING), would it really be that hard to make this ability non-hardcoded?
Samurai Jack's implementation sounds perfect with the addition of the Block Hitscans as well. However, could we also have a "block middle" parameter as well? Although I assume that with the said implementation the middle texture's blocking settings would be inherited from the existing properties of the line, it would be better if we could have the added flexibility of the flag methods mentioned (so for example, you could have a line block projectiles and hitscans, but allow players to cross).
Since Zdoom already has the code to block lines only up to certain heights (BLOCK_RAILING), would it really be that hard to make this ability non-hardcoded?
Samurai Jack's implementation sounds perfect with the addition of the Block Hitscans as well. However, could we also have a "block middle" parameter as well? Although I assume that with the said implementation the middle texture's blocking settings would be inherited from the existing properties of the line, it would be better if we could have the added flexibility of the flag methods mentioned (so for example, you could have a line block projectiles and hitscans, but allow players to cross).
- MartinHowe
- Posts: 2097
- Joined: Mon Aug 11, 2003 1:50 pm
- Preferred Pronouns: He/Him
- Location: East Suffolk (UK)
So what we're looking at seems to be two specials:
EDIT: Or for "default", instead of -1, use 0x8000000 and have a "BLOCK_DEFAULT" symbol for it in zdefs.acs.
Incidentally, zdefs.acs already has these (never noticed them before):What are they used for?
Code: Select all
Line_fence1(height,block_above,block_below);
height: height of the fence
block_above: blocking flags above the height
block_below: blocking flags below the height
Line_fence2(block_upper,block_middle,block_lower);
block_upper: blocking flags for the upper texture
block_middle: blocking flags for the middle texture
block_lower: blocking flags for the lower texture
Blocking flags:
0: 0x00000000 No blocking
1: 0x00000001 Block player
2: 0x00000002 Block monsters
4: 0x00000004 Block projectiles
8: 0x00000008 Block hitscans
I suggest also:
-1: 0xFFFFFFFF Default for line type
Incidentally, zdefs.acs already has these (never noticed them before):
Code: Select all
#define BLOCK_NOTHING 0
#define BLOCK_CREATURES 1
#define BLOCK_EVERYTHING 2
#define BLOCK_RAILING 3
- Cutmanmike
- Posts: 11354
- Joined: Mon Oct 06, 2003 3:41 pm
- Operating System Version (Optional): Windows 10
- Location: United Kingdom
- Contact:
Re: Line_fence special
Seeing as how this is mentioned here, I suppose I could do a memory jog to see if my request of a "block players only" could be possible. Reasons why are explained hereJack wrote:1: Block player
http://forum.zdoom.org/potato.php?t=9895
