Spring - User contributions [en]

Shield Interception Tag Use

2007-02-26T19:21:36Z

Relinquished: /* <center>Charts</center> */

== <center>Shield Interception Tags</center> ==

The two following tags can be used to control what types of shields can intercept what types of weapons:

'''InterceptedByShieldType:''' This is defined in the weapon that is to be intercepted. It represents a bitfield that is checked against a similar bitfield on the shield for a positive or negative interception (see examples).

'''ShieldInterceptType:''' This is defined in the shield. It represents a bitfield that is checked against a similar bitfield on the weapon to determine a positive or negative interception (see examples).

== <center>Examples</center> ==

In order to check for shield collisions, the two tags above are converted into binary format, for example: 
 
InterceptedByShieldType=5; becomes 101 in binary 
ShieldInterceptType=7; becomes 111 in binary 
 
To then check that weapon's interception status against the shield, the bitfields need to be lined up as follows: 
 
101 (Weapon) 
111 (Shield) 
 
If any of the columns made by this line-up contains two ones, the shield will positively intercept the weapon. In this case there are two columns with two ones in them, so the weapon is intercepted. A final example: 
 
InterceptedByShieldType=7; becomes 111 in binary 
ShieldInterceptType=24; becomes 11000 in binary 
 
00111 (Weapon) 
11000 (Shield) 
 
No interception is registered because no columns contain two ones.

== <center>Charts</center> ==

I (Relinquished) felt that it may help some people to have a few charts or reference tables to quickly see which shields work with what.

'''Table of Shield type hit detections''' (X's indicate a collision)

[http://i170.photobucket.com/albums/u257/apurelinquished/ShieldGroups.jpg Collision Chart]
http://i170.photobucket.com/albums/u257/apurelinquished/ShieldGroups.jpg

'''Binary Collision Shield Groups'''

1 2 4 8 16 32 Are the only 6 possible distinct shield groups.

Anything in each of the following categories will collide with any other one in the same category:

000001 Shields:
1 3 5 7 9
11 13 15 17 19
21 23 25 27 29
31

000010 Shields:
2 3 6 7 10
11 14 15 18 19
22 23 26 27 30
31

000100 Shields:
4 5 6 7 12
13 14 15 20 21
22 23 28 29 30
31

001000 Shields:
8 9 10 11 12
13 14 15 24 25
26 27 28 29 30
31

010000 Shields:
16 17 18 19 20
21 22 23 24 25
26 27 28 29 30
31

100000 Shields:
32

Shield Interception Tag Use

2007-02-26T19:21:16Z

Relinquished: /* <center>Charts</center> */

Shield Interception Tag Use

2007-02-26T19:20:19Z

Relinquished: /* <center>Charts</center> */

== <center>Shield Interception Tags</center> ==

The two following tags can be used to control what types of shields can intercept what types of weapons:

'''InterceptedByShieldType:''' This is defined in the weapon that is to be intercepted. It represents a bitfield that is checked against a similar bitfield on the shield for a positive or negative interception (see examples).

'''ShieldInterceptType:''' This is defined in the shield. It represents a bitfield that is checked against a similar bitfield on the weapon to determine a positive or negative interception (see examples).

== <center>Examples</center> ==

In order to check for shield collisions, the two tags above are converted into binary format, for example: 
 
InterceptedByShieldType=5; becomes 101 in binary 
ShieldInterceptType=7; becomes 111 in binary 
 
To then check that weapon's interception status against the shield, the bitfields need to be lined up as follows: 
 
101 (Weapon) 
111 (Shield) 
 
If any of the columns made by this line-up contains two ones, the shield will positively intercept the weapon. In this case there are two columns with two ones in them, so the weapon is intercepted. A final example: 
 
InterceptedByShieldType=7; becomes 111 in binary 
ShieldInterceptType=24; becomes 11000 in binary 
 
00111 (Weapon) 
11000 (Shield) 
 
No interception is registered because no columns contain two ones.

== <center>Charts</center> ==

I (Relinquished) felt that it may help some people to have a few charts or reference tables to quickly see which shields work with what.

'''Table of Shield type hit detections''' (X's indicate a collision)

http://i170.photobucket.com/albums/u257/apurelinquished/ShieldGroups.jpg

'''Binary Collision Shield Groups'''

1 2 4 8 16 32 Are the only 6 possible distinct shield groups.

Anything in each of the following categories will collide with any other one in the same category:

000001 Shields:
1 3 5 7 9
11 13 15 17 19
21 23 25 27 29
31

000010 Shields:
2 3 6 7 10
11 14 15 18 19
22 23 26 27 30
31

000100 Shields:
4 5 6 7 12
13 14 15 20 21
22 23 28 29 30
31

001000 Shields:
8 9 10 11 12
13 14 15 24 25
26 27 28 29 30
31

010000 Shields:
16 17 18 19 20
21 22 23 24 25
26 27 28 29 30
31

100000 Shields:
32

Shield Interception Tag Use

2007-02-26T19:08:30Z

Relinquished: /* <center>Charts</center> */

== <center>Shield Interception Tags</center> ==

The two following tags can be used to control what types of shields can intercept what types of weapons:

'''InterceptedByShieldType:''' This is defined in the weapon that is to be intercepted. It represents a bitfield that is checked against a similar bitfield on the shield for a positive or negative interception (see examples).

'''ShieldInterceptType:''' This is defined in the shield. It represents a bitfield that is checked against a similar bitfield on the weapon to determine a positive or negative interception (see examples).

== <center>Examples</center> ==

In order to check for shield collisions, the two tags above are converted into binary format, for example: 
 
InterceptedByShieldType=5; becomes 101 in binary 
ShieldInterceptType=7; becomes 111 in binary 
 
To then check that weapon's interception status against the shield, the bitfields need to be lined up as follows: 
 
101 (Weapon) 
111 (Shield) 
 
If any of the columns made by this line-up contains two ones, the shield will positively intercept the weapon. In this case there are two columns with two ones in them, so the weapon is intercepted. A final example: 
 
InterceptedByShieldType=7; becomes 111 in binary 
ShieldInterceptType=24; becomes 11000 in binary 
 
00111 (Weapon) 
11000 (Shield) 
 
No interception is registered because no columns contain two ones.

== <center>Charts</center> ==

I (Relinquished) felt that it may help some people to have a few charts or reference tables to quickly see which shields work with what.

'''Table of Shield type hit detections''' (X's indicate a collision)

http://i170.photobucket.com/albums/u257/apurelinquished/ShieldGroups.jpg

'''Binary Collision Shield Groups'''

1 2 4 8 16 32 Are the only 6 possible distinct shield groups.

Anything in each of the following categories will collide with any other one in the same category:

000001 Shields:
1 3 5 7 9
11 13 15 17 19
21 23 25 27 29
31

000010 Shields:
2 3 6 7 10
11 14 15 18 19
22 23 26 27 30
31

000100 Shields:
4 5 6 7 12
13 14 15 20 21
22 23 28 29 30
31

001000 Shields:
8 9 10 11 12
13 14 15 24 25
26 27 28 29 30
31

010000 Shields:
16 17 18 19 20
21 22 23 24 25
26 27 28 29 30
31

100000 Shields:
32

Shield Interception Tag Use

2007-02-26T19:05:36Z

Relinquished: /* <center>Charts</center> */

== <center>Shield Interception Tags</center> ==

The two following tags can be used to control what types of shields can intercept what types of weapons:

'''InterceptedByShieldType:''' This is defined in the weapon that is to be intercepted. It represents a bitfield that is checked against a similar bitfield on the shield for a positive or negative interception (see examples).

'''ShieldInterceptType:''' This is defined in the shield. It represents a bitfield that is checked against a similar bitfield on the weapon to determine a positive or negative interception (see examples).

== <center>Examples</center> ==

In order to check for shield collisions, the two tags above are converted into binary format, for example: 
 
InterceptedByShieldType=5; becomes 101 in binary 
ShieldInterceptType=7; becomes 111 in binary 
 
To then check that weapon's interception status against the shield, the bitfields need to be lined up as follows: 
 
101 (Weapon) 
111 (Shield) 
 
If any of the columns made by this line-up contains two ones, the shield will positively intercept the weapon. In this case there are two columns with two ones in them, so the weapon is intercepted. A final example: 
 
InterceptedByShieldType=7; becomes 111 in binary 
ShieldInterceptType=24; becomes 11000 in binary 
 
00111 (Weapon) 
11000 (Shield) 
 
No interception is registered because no columns contain two ones.

== <center>Charts</center> ==

I (Relinquished) felt that it may help some people to have a few charts or reference tables to quickly see which shields work with what.

'''Table of Shield type hit detections''' (X's indicate a collision)

http://i170.photobucket.com/albums/u257/apurelinquished/ShieldGroups

'''Binary Collision Shield Groups'''

1 2 4 8 16 32 Are the only 6 possible distinct shield groups. Anything in each of the categories will collide with any other one in the same category.

000001 Shields:
1 3 5 7 9
11 13 15 17 19
21 23 25 27 29
31

000010 Shields:
2 3 6 7 10
11 14 15 18 19
22 23 26 27 30
31

000100 Shields:
4 5 6 7 12
13 14 15 20 21
22 23 28 29 30
31

001000 Shields:
8 9 10 11 12
13 14 15 24 25
26 27 28 29 30
31

010000 Shields:
16 17 18 19 20
21 22 23 24 25
26 27 28 29 30
31

100000 Shields:
32

Shield Interception Tag Use

2007-02-26T19:05:24Z

Relinquished: /* <center>Charts</center> */

== <center>Shield Interception Tags</center> ==

The two following tags can be used to control what types of shields can intercept what types of weapons:

'''InterceptedByShieldType:''' This is defined in the weapon that is to be intercepted. It represents a bitfield that is checked against a similar bitfield on the shield for a positive or negative interception (see examples).

'''ShieldInterceptType:''' This is defined in the shield. It represents a bitfield that is checked against a similar bitfield on the weapon to determine a positive or negative interception (see examples).

== <center>Examples</center> ==

In order to check for shield collisions, the two tags above are converted into binary format, for example: 
 
InterceptedByShieldType=5; becomes 101 in binary 
ShieldInterceptType=7; becomes 111 in binary 
 
To then check that weapon's interception status against the shield, the bitfields need to be lined up as follows: 
 
101 (Weapon) 
111 (Shield) 
 
If any of the columns made by this line-up contains two ones, the shield will positively intercept the weapon. In this case there are two columns with two ones in them, so the weapon is intercepted. A final example: 
 
InterceptedByShieldType=7; becomes 111 in binary 
ShieldInterceptType=24; becomes 11000 in binary 
 
00111 (Weapon) 
11000 (Shield) 
 
No interception is registered because no columns contain two ones.

== <center>Charts</center> ==

I (Relinquished) felt that it may help some people to have a few charts or reference tables to quickly see which shields work with what.

'''Table of Shield type hit detections''' (X's indicate a collision)

[http://i170.photobucket.com/albums/u257/apurelinquished/ShieldGroups.jpg CollisionChart]
http://i170.photobucket.com/albums/u257/apurelinquished/ShieldGroups

'''Binary Collision Shield Groups'''

1 2 4 8 16 32 Are the only 6 possible distinct shield groups. Anything in each of the categories will collide with any other one in the same category.

000001 Shields:
1 3 5 7 9
11 13 15 17 19
21 23 25 27 29
31

000010 Shields:
2 3 6 7 10
11 14 15 18 19
22 23 26 27 30
31

000100 Shields:
4 5 6 7 12
13 14 15 20 21
22 23 28 29 30
31

001000 Shields:
8 9 10 11 12
13 14 15 24 25
26 27 28 29 30
31

010000 Shields:
16 17 18 19 20
21 22 23 24 25
26 27 28 29 30
31

100000 Shields:
32

Shield Interception Tag Use

2007-02-20T11:39:10Z

Relinquished: /* <center>Charts</center> */

== <center>Shield Interception Tags</center> ==

The two following tags can be used to control what types of shields can intercept what types of weapons:

'''InterceptedByShieldType:''' This is defined in the weapon that is to be intercepted. It represents a bitfield that is checked against a similar bitfield on the shield for a positive or negative interception (see examples).

'''ShieldInterceptType:''' This is defined in the shield. It represents a bitfield that is checked against a similar bitfield on the weapon to determine a positive or negative interception (see examples).

== <center>Examples</center> ==

In order to check for shield collisions, the two tags above are converted into binary format, for example: 
 
InterceptedByShieldType=5; becomes 101 in binary 
ShieldInterceptType=7; becomes 111 in binary 
 
To then check that weapon's interception status against the shield, the bitfields need to be lined up as follows: 
 
101 (Weapon) 
111 (Shield) 
 
If any of the columns made by this line-up contains two ones, the shield will positively intercept the weapon. In this case there are two columns with two ones in them, so the weapon is intercepted. A final example: 
 
InterceptedByShieldType=7; becomes 111 in binary 
ShieldInterceptType=24; becomes 11000 in binary 
 
00111 (Weapon) 
11000 (Shield) 
 
No interception is registered because no columns contain two ones.

== <center>Charts</center> ==

I (Relinquished) felt that it may help some people to have a few charts or reference tables to quickly see which shields work with what.

'''Table of Shield type hit detections''' (X's indicate a collision)

[http://i170.photobucket.com/albums/u257/apurelinquished/ShieldGroups.jpg CollisionChart]

'''Binary Collision Shield Groups'''

1 2 4 8 16 32 Are the only 6 possible distinct shield groups. Anything in each of the categories will collide with any other one in the same category.

000001 Shields:
1 3 5 7 9
11 13 15 17 19
21 23 25 27 29
31

000010 Shields:
2 3 6 7 10
11 14 15 18 19
22 23 26 27 30
31

000100 Shields:
4 5 6 7 12
13 14 15 20 21
22 23 28 29 30
31

001000 Shields:
8 9 10 11 12
13 14 15 24 25
26 27 28 29 30
31

010000 Shields:
16 17 18 19 20
21 22 23 24 25
26 27 28 29 30
31

100000 Shields:
32

Shield Interception Tag Use

2007-02-20T01:56:48Z

Relinquished: /* <center>Charts</center> */

== <center>Shield Interception Tags</center> ==

The two following tags can be used to control what types of shields can intercept what types of weapons:

'''InterceptedByShieldType:''' This is defined in the weapon that is to be intercepted. It represents a bitfield that is checked against a similar bitfield on the shield for a positive or negative interception (see examples).

'''ShieldInterceptType:''' This is defined in the shield. It represents a bitfield that is checked against a similar bitfield on the weapon to determine a positive or negative interception (see examples).

== <center>Examples</center> ==

In order to check for shield collisions, the two tags above are converted into binary format, for example: 
 
InterceptedByShieldType=5; becomes 101 in binary 
ShieldInterceptType=7; becomes 111 in binary 
 
To then check that weapon's interception status against the shield, the bitfields need to be lined up as follows: 
 
101 (Weapon) 
111 (Shield) 
 
If any of the columns made by this line-up contains two ones, the shield will positively intercept the weapon. In this case there are two columns with two ones in them, so the weapon is intercepted. A final example: 
 
InterceptedByShieldType=7; becomes 111 in binary 
ShieldInterceptType=24; becomes 11000 in binary 
 
00111 (Weapon) 
11000 (Shield) 
 
No interception is registered because no columns contain two ones.

== <center>Charts</center> ==

I (Relinquished) felt that it may help some people to have a few charts or reference tables to quickly see which shields work with what.

'''Table of Shield type hit detections''' (X's indicate a collision)

[http://i170.photobucket.com/albums/u257/apurelinquished/ShieldGroups.jpg CollisionChart]

'''Binary Collision Shield Groups'''

1 2 4 8 16 32 Are the only 6 possible distinct shield groups. Anything in each of the categories will collide with any other one in the same category.

000001 Shields:
1 3 5 7 9
11 13 15 17 19
21 23 25 27 29
31

000010 Shields:
2 3 6 7 10
11 14 15 18 19
22 23 26 27 30
31

000100 Shields:
4 5 6 7 12
13 14 15 20 21
22 23 28 29 30
31

001000 Shields:
8 9 10 11 12
13 14 15 24 25
26 27 28 29 30
31

010000 Shields:
16 17 18 19 20
21 22 23 24 25
26 27 28 29 30
31

100000 Shields:
32

Shield Interception Tag Use

2007-02-19T23:32:29Z

Relinquished: /* <center>Charts</center> */

== <center>Shield Interception Tags</center> ==

The two following tags can be used to control what types of shields can intercept what types of weapons:

'''InterceptedByShieldType:''' This is defined in the weapon that is to be intercepted. It represents a bitfield that is checked against a similar bitfield on the shield for a positive or negative interception (see examples).

'''ShieldInterceptType:''' This is defined in the shield. It represents a bitfield that is checked against a similar bitfield on the weapon to determine a positive or negative interception (see examples).

== <center>Examples</center> ==

In order to check for shield collisions, the two tags above are converted into binary format, for example: 
 
InterceptedByShieldType=5; becomes 101 in binary 
ShieldInterceptType=7; becomes 111 in binary 
 
To then check that weapon's interception status against the shield, the bitfields need to be lined up as follows: 
 
101 (Weapon) 
111 (Shield) 
 
If any of the columns made by this line-up contains two ones, the shield will positively intercept the weapon. In this case there are two columns with two ones in them, so the weapon is intercepted. A final example: 
 
InterceptedByShieldType=7; becomes 111 in binary 
ShieldInterceptType=24; becomes 11000 in binary 
 
00111 (Weapon) 
11000 (Shield) 
 
No interception is registered because no columns contain two ones.

== <center>Charts</center> ==

I (Relinquished) felt that it may help some people to have a few charts or reference tables to quickly see which shields work with what.

'''Table of Shield type hit detections''' (X's indicate a collision)

[http://i170.photobucket.com/albums/u257/apurelinquished/ShieldGroups.jpg CollisionChart]

'''Binary Collision Shield Groups'''

1 2 4 8 16 32 Are the only 6 possible distinct shield groups. Anything in each of the categories will collide with any other one in the same category.

000001 Shields:
1 3 5 7 9
11 13 15 17 19
21 23 25 27 29
31

000010 Shields:
2 3 6 7 10
11 14 15 18 19
22 23 26 27 30
31

000100 Shields:
4 5 6 7 12
13 14 15 20 21
22 23 28 29 30
31

001000 Shields:
8 9 10 11 12
13 14 15 24 25
26 27 28 29 30
31

010000 Shields:
16 17 18 19 20
21 22 23 24 25
26 27 28 29 30
31

100000 Shields:
32

Shield Interception Tag Use

2007-02-19T23:32:17Z

Relinquished: /* <center>Charts</center> */

== <center>Shield Interception Tags</center> ==

The two following tags can be used to control what types of shields can intercept what types of weapons:

'''InterceptedByShieldType:''' This is defined in the weapon that is to be intercepted. It represents a bitfield that is checked against a similar bitfield on the shield for a positive or negative interception (see examples).

'''ShieldInterceptType:''' This is defined in the shield. It represents a bitfield that is checked against a similar bitfield on the weapon to determine a positive or negative interception (see examples).

== <center>Examples</center> ==

In order to check for shield collisions, the two tags above are converted into binary format, for example: 
 
InterceptedByShieldType=5; becomes 101 in binary 
ShieldInterceptType=7; becomes 111 in binary 
 
To then check that weapon's interception status against the shield, the bitfields need to be lined up as follows: 
 
101 (Weapon) 
111 (Shield) 
 
If any of the columns made by this line-up contains two ones, the shield will positively intercept the weapon. In this case there are two columns with two ones in them, so the weapon is intercepted. A final example: 
 
InterceptedByShieldType=7; becomes 111 in binary 
ShieldInterceptType=24; becomes 11000 in binary 
 
00111 (Weapon) 
11000 (Shield) 
 
No interception is registered because no columns contain two ones.

== <center>Charts</center> ==

I (Relinquished) felt that it may help some people to have a few charts or reference tables to quickly see which shields work with what.

'''Table of Shield type hit detections''' (X's indicate a collision)

[http://i170.photobucket.com/albums/u257/apurelinquished/ShieldGroups.jpg CollisionChart]

'''Binary Collision Shield Groups'''

1 2 4 8 16 32 Are the only 6 possible distinct shield groups. Anything in each of the categories will collide with any other one in the same category.

000001 Shields:
1 3 5 7 9
11 13 15 17 19
21 23 25 27 29
31

000010 Shields:
2 3 6 7 10
11 14 15 18 19
22 23 26 27 30
31

000100 Shields:
4 5 6 7 12
13 14 15 20 21
22 23 28 29 30
31

001000 Shields:
8 9 10 11 12
13 14 15 24 25
26 27 28 29 30
31

010000 Shields:
16 17 18 19 20
21 22 23 24 25
26 27 28 29 30
31

100000 Shields:
32

Shield Interception Tag Use

2007-02-19T23:32:00Z

Relinquished: /* <center>Charts</center> */

== <center>Shield Interception Tags</center> ==

The two following tags can be used to control what types of shields can intercept what types of weapons:

'''InterceptedByShieldType:''' This is defined in the weapon that is to be intercepted. It represents a bitfield that is checked against a similar bitfield on the shield for a positive or negative interception (see examples).

'''ShieldInterceptType:''' This is defined in the shield. It represents a bitfield that is checked against a similar bitfield on the weapon to determine a positive or negative interception (see examples).

== <center>Examples</center> ==

In order to check for shield collisions, the two tags above are converted into binary format, for example: 
 
InterceptedByShieldType=5; becomes 101 in binary 
ShieldInterceptType=7; becomes 111 in binary 
 
To then check that weapon's interception status against the shield, the bitfields need to be lined up as follows: 
 
101 (Weapon) 
111 (Shield) 
 
If any of the columns made by this line-up contains two ones, the shield will positively intercept the weapon. In this case there are two columns with two ones in them, so the weapon is intercepted. A final example: 
 
InterceptedByShieldType=7; becomes 111 in binary 
ShieldInterceptType=24; becomes 11000 in binary 
 
00111 (Weapon) 
11000 (Shield) 
 
No interception is registered because no columns contain two ones.

== <center>Charts</center> ==

I (Relinquished) felt that it may help some people to have a few charts or reference tables to quickly see which shields work with what.

'''Table of Shield type hit detections''' (X's indicate a collision)

[http://i170.photobucket.com/albums/u257/apurelinquished/ShieldGroups.jpg CollisionChart]

'''Binary Collision Shield Groups'''

1 2 4 8 16 32 Are the only 6 possible distinct shield groups. Anything in each of the categories will collide with any other one in the same category.

000001 Shields:
1 3 5 7 9
11 13 15 17 19
21 23 25 27 29
31

000010 Shields:
2 3 6 7 10
11 14 15 18 19
22 23 26 27 30
31

000100 Shields:
4 5 6 7 12
13 14 15 20 21
22 23 28 29 30
31

001000 Shields:
8 9 10 11 12
13 14 15 24 25
26 27 28 29 30
31

010000 Shields:
16 17 18 19 20
21 22 23 24 25
26 27 28 29 30
31

100000 Shields:
32

Shield Interception Tag Use

2007-02-19T23:23:46Z

Relinquished: /* <center>Charts</center> */

== <center>Shield Interception Tags</center> ==

The two following tags can be used to control what types of shields can intercept what types of weapons:

'''InterceptedByShieldType:''' This is defined in the weapon that is to be intercepted. It represents a bitfield that is checked against a similar bitfield on the shield for a positive or negative interception (see examples).

'''ShieldInterceptType:''' This is defined in the shield. It represents a bitfield that is checked against a similar bitfield on the weapon to determine a positive or negative interception (see examples).

== <center>Examples</center> ==

In order to check for shield collisions, the two tags above are converted into binary format, for example: 
 
InterceptedByShieldType=5; becomes 101 in binary 
ShieldInterceptType=7; becomes 111 in binary 
 
To then check that weapon's interception status against the shield, the bitfields need to be lined up as follows: 
 
101 (Weapon) 
111 (Shield) 
 
If any of the columns made by this line-up contains two ones, the shield will positively intercept the weapon. In this case there are two columns with two ones in them, so the weapon is intercepted. A final example: 
 
InterceptedByShieldType=7; becomes 111 in binary 
ShieldInterceptType=24; becomes 11000 in binary 
 
00111 (Weapon) 
11000 (Shield) 
 
No interception is registered because no columns contain two ones.

== <center>Charts</center> ==

I (Relinquished) felt that it may help some people to have a few charts or reference tables to quickly see which shields work with what.

'''Table of Shield type hit detections''' (X's indicate a collision)

[http://i170.photobucket.com/albums/u257/apurelinquished/ShieldGroups.jpg CollisionChart]

'''Binary Collision Shield Groups'''

1 2 4 8 16 32 Are the only 6 possible distinct shield groups. Anything in each of the categories will collide with any other one in the same category.

000001 Shields:
1 3 5 7 9
11 13 15 17 19
21 23 25 27 29
31

000010 Shields:
2 3 6 7 10
11 14 15 18 19
22 23 26 27 30
31

000100 Shields:
4 5 6 7 12
13 14 15 20 21
22 23 28 29 30
31

001000 Shields:
8 9 10 11 12
13 14 15 24 25
26 27 28 29 30
31

010000 Shields:
16 17 18 19 20
21 22 23 24 25
26 27 28 29 30
31

100000 Shields:
32

Shield Interception Tag Use

2007-02-19T23:21:34Z

Relinquished: /* <center>Examples</center> */

== <center>Shield Interception Tags</center> ==

The two following tags can be used to control what types of shields can intercept what types of weapons:

'''InterceptedByShieldType:''' This is defined in the weapon that is to be intercepted. It represents a bitfield that is checked against a similar bitfield on the shield for a positive or negative interception (see examples).

'''ShieldInterceptType:''' This is defined in the shield. It represents a bitfield that is checked against a similar bitfield on the weapon to determine a positive or negative interception (see examples).

== <center>Examples</center> ==

In order to check for shield collisions, the two tags above are converted into binary format, for example: 
 
InterceptedByShieldType=5; becomes 101 in binary 
ShieldInterceptType=7; becomes 111 in binary 
 
To then check that weapon's interception status against the shield, the bitfields need to be lined up as follows: 
 
101 (Weapon) 
111 (Shield) 
 
If any of the columns made by this line-up contains two ones, the shield will positively intercept the weapon. In this case there are two columns with two ones in them, so the weapon is intercepted. A final example: 
 
InterceptedByShieldType=7; becomes 111 in binary 
ShieldInterceptType=24; becomes 11000 in binary 
 
00111 (Weapon) 
11000 (Shield) 
 
No interception is registered because no columns contain two ones.

== <center>Charts</center> ==
I (Relinquished) felt that it may help some people to have a few charts or reference tables to quickly see which shields work with what.

'''Table of Shield type hit detections''' (X's indicate a collision)

[http://i170.photobucket.com/albums/u257/apurelinquished/ShieldGroups.jpg CollisionChart]

'''Binary Collision Shield Groups'''

1 2 4 8 16 32 Are the only 6 possible distinct shield groups

000001 Shields:
1 3 5 7 9
11 13 15 17 19
21 23 25 27 29
31

000010 Shields:
2 3 6 7 10
11 14 15 18 19
22 23 26 27 30
31

000100 Shields:
4 5 6 7 12
13 14 15 20 21
22 23 28 29 30
31

001000 Shields:
8 9 10 11 12
13 14 15 24 25
26 27 28 29 30
31

010000 Shields:
16 17 18 19 20
21 22 23 24 25
26 27 28 29 30
31

100000 Shields:
32

SM3 Map Format

2006-12-05T02:43:26Z

Relinquished: /* Feature placement */

== Introduction ==

As opposed to the original SMF renderer, the SM3 map renderer allows multiple texture layers rendered on the terrain. This allows for higher texture resolutions and improved lighting such as bumpmapping/specular mapping.

== Map specification ==

Instead of a binary SMF file and a SMD file, all map information is now stored in a text based .SM3 file. This has the same basic layout as the original .SMD file, but it includes a [TERRAIN] section and an [INFOMAPS] section. It also has an extra tag in LIGHT (GroundSpecularColor):

[MAP]
{
... regular smd information, such as start positions,
[WATER] and [ATMOSPHERE] sections...

[LIGHT]
{
// specular color, defaults to 0.1 0.1 0.1
GroundSpecularColor=0.3 0.3 0.3;

... other standard tags shared with SMF (such as GroundSunColor)...

}

[INFOMAPS]
{
metal=Maps/dry_data/metalmap.png;
type=Maps/dry_data/typemap.png;
}
[TERRAIN]
{
HeightScale=400.0;
HeightOffset=10.0;
Heightmap=Maps/dry_data/1026.png;

NumTextureStages=2; // all texture stages are multiplied
SpecularExponent=16; // specular exponent AKA
//shininess or polishedness. defaults to 8

[texstage0]
{
// the first texture stage operation is ignored
source=Snow;
}
[texstage1]
{
// use the incoming alpha to blend between 2 textures
operation=blend;
source=CrackedDirt;
blender=RockBlender1026;
}
/* texture definitions */
[CrackedDirt]
{
File=Maps/dry_data/dirt2.jpg;
Bumpmap=Maps/dry_data/dirt2_bm.jpg;
TileSize=50;
}
[Snow]
{
File=Maps/dry_data/Snow_Sand.jpg;
TileSize=20;
}

/* blender definition, all blenders have "Blendmap=1" */
// a rock blender loaded from file for a specific map
[RockBlender1026]
{
Blendmap=1;
File=Maps/dry_data/1026_bm_small.png;
}
}

== Heightmap specification ==

The heightmap is specified with 3 tags located in the [TERRAIN] section:

'''Heightmap:''' This should be either:
*An 8 or 16 bit image file readable by DevIL
*A 8 or 16 bit RAW file, such as generated by Terragen

'''HeightScale and HeightOffset:''' The actual height of a heightmap pixel is calculated scaled by HeightScale, after which HeightOffset is added to it (height = pixel * HeightScale + HeightOffset)

== Texturing method specification (how are the textures applied) ==

=== Texture stages/layers ===

Texturing of SM3 terrains works by a series of texture layers that are applied on top of eachother. These layers are called "texture stages". The stages can be added, multiplied, or alpha blended with the previous stage. This is defined by the stage operation.

The number of stages is given with the tag NumTextureStages like:

NumTextureStages=2;

Keep in mind that the stages are directly executed on your videocard. This means the more stages you make the slower the map will render.

The first stage never has an operation:

[texstage0]
{
source=Snow;
}

Following stages can have "operation=add", "operation=mul", "operation=blend"

==== Operation Add ====

The add operation needs a texture to add to the previous stage, which is specified with the "source=TextureName" tag. The texture specification is explained below.

[texstage1]
{
operation=add;
source=CrackedDirt;
}

==== Operation Multiply ====

Same as add, but with operation=mul

[texstage1]
{
operation=mul;
source=CrackedDirt;
}

==== Operation Blend ====

The blend operation does alpha blending with an extra grayscale alpha texture. Specification of these alpha textures ("Blendmaps") is explained later in this doc. The blend operation needs a "blender=BlenderName" tag to work. I'm guessing most maps will only be using this operation.

[texstage1]
{
operation=blend;
source=CrackedDirt;
blender=RockBlender1026;
}

The avaiable operations are limited to add/mul/blend for techical reasons:
This way even the most complex maps can be executed with multipass operations on any card with at least 2 textures units. It would even work on a Riva TNT I think.

Obviously because the first stage doesn't have any previous stage, the operation of the first stage is ignored

=== Textures ===

==== Tiled textures ====

The operations usually have "source=texturename" in them, which points to the name of a tiled texture.

Example:

NumTextureStages=1;
[texstage0]
{
source=Snow;
}

[Snow]
{
File=Maps/dry_data/Snow_Sand.jpg;
TileSize=20;
}

Tilesize is how big a single tile is in the 3D spring world, when the texture is tiled across the map. Imagine a heightmap of 1025x1025 (In spring world space this is 1024*8= 8192x8192 units).
When you set tilesize=4096, you will see the complete texture 4 times on the map (2 by 2). Set it to 8192 and you'll see the map completely covered.

==== Blendmap specification ====

Blendmaps can either be loaded from file or generated from the terrain. They are stretched across the full terrain, so in combination with the blend operation you can specify exactly where you want to see a specific texture on the terrain.

===== Blendmaps from file =====

Blendmaps can be loaded from any grayscale file that DevIL can load:

[RockBlender]
{
Blendmap=1;
File=Maps/dry_data/1026_bm_small.png;
}

===== Generated blendmaps =====

Blendmaps can be generated from the heightmap. The final value is computed by

blendmap_value = SlopeTerm * HeightTerm * coverage * noise

The slope of the terrain is a value between 0 and 1, with 0 being flat and 1 being completely steep. Ofcourse with a heightmap the slope can only be near 1 and not exactly 1

The height of the terrain is between 0 and 1 (the minimum and maximum height value)
If the height is between minHeight and maxHeight, HeightTerm will be 1. maxHeightFuzzy and minHeightFuzzy determine the "border" size between having a HeightTerm of 0 and a HeightTerm of 1.

GeneratorLOD indicates at which resolution the blendmap should be generated. The blendmap size will be (heightmapsize-1) / (2 ^ generatorLOD). For example with a heightmap width of 1025 and a generatorlod of 2, the blendmap size will be 1024/4=256.

(Images illustrating this will be added later)

== Infomaps ==

The infomaps section defines the metal map and typemap. Both should be 8 bit images in any format DevIL accepts.

== Image file sizes ==

* The heightmap has to be square and its dimensions have to be a power-of-two + 1, like 257x257, 513x513, 1025x1025
* The blendmaps have to be square too, with power-of-two dimensions like: 256x256, 512x512, 1024x1024. They should be smaller than the heightmap.
* The tiled textures should have power-of-two dimensions, but don't have to be square
* The minimap can be anything, but it will be resized to an image of 1024x1024. Specifying a 1024x1024 will allow faster loading because no resizing is needed.
* Typemap and metalmaps dimensions should be (heightmapsize - 1) / 2, so when the heightmap is 1025x1025, the typemap is 512x512.
* The heightmap can be any [http://openil.sourceforge.net/features.php DevIL] supported format, or RAW such as exported by terragen. All the other maps/texture files can only be a DevIL format.
[edit by relinquished: fixed typo "to be square two" instead of "to be square too"]

== Feature placement ==

The feature specification is done with a list of feature type names in the SM3 itself, and with a binary datafile that contains all the feature positions, orientations.
Feature types are specified like this:

[FeatureTypes]
{
NumTypes=4;
type0=TreeType0; // a tree
type1=MyFeature;
type2=MyOtherFeature;
type3=GeoVent; // a geothermal
}

The feature binary file should be made with an editor. I'm hoping Maelstrom will add feature placing to his startpoint editor, but until then there's only http://user.supradigital.org/jcnossen/FeaturePlacer.zip

[[Image:Featureplacer.png]]

The "Pos:" fields are ment to enter the feature X,Y,Z. You can use zero for Y because spring will automatically put the feature on the ground when it loads.
Type is the index into the feature type list specified in the SM3 file.

The feature data file should be linked to the SM3 with:

[map]
{
.. other map tags ...

featuredata=FeatureDataFileName;

.. other map tags ...
}

== TODO ==

* dynamic shadow mapping support
* shadowmap storage, so the resolution can be increased

[[Category:Map making]]
[[Category:SM3 map format]]

SM3 Map Format

2006-12-05T02:40:11Z

Relinquished: /* Image file sizes */

== Introduction ==

As opposed to the original SMF renderer, the SM3 map renderer allows multiple texture layers rendered on the terrain. This allows for higher texture resolutions and improved lighting such as bumpmapping/specular mapping.

== Map specification ==

Instead of a binary SMF file and a SMD file, all map information is now stored in a text based .SM3 file. This has the same basic layout as the original .SMD file, but it includes a [TERRAIN] section and an [INFOMAPS] section. It also has an extra tag in LIGHT (GroundSpecularColor):

[MAP]
{
... regular smd information, such as start positions,
[WATER] and [ATMOSPHERE] sections...

[LIGHT]
{
// specular color, defaults to 0.1 0.1 0.1
GroundSpecularColor=0.3 0.3 0.3;

... other standard tags shared with SMF (such as GroundSunColor)...

}

[INFOMAPS]
{
metal=Maps/dry_data/metalmap.png;
type=Maps/dry_data/typemap.png;
}
[TERRAIN]
{
HeightScale=400.0;
HeightOffset=10.0;
Heightmap=Maps/dry_data/1026.png;

NumTextureStages=2; // all texture stages are multiplied
SpecularExponent=16; // specular exponent AKA
//shininess or polishedness. defaults to 8

[texstage0]
{
// the first texture stage operation is ignored
source=Snow;
}
[texstage1]
{
// use the incoming alpha to blend between 2 textures
operation=blend;
source=CrackedDirt;
blender=RockBlender1026;
}
/* texture definitions */
[CrackedDirt]
{
File=Maps/dry_data/dirt2.jpg;
Bumpmap=Maps/dry_data/dirt2_bm.jpg;
TileSize=50;
}
[Snow]
{
File=Maps/dry_data/Snow_Sand.jpg;
TileSize=20;
}

/* blender definition, all blenders have "Blendmap=1" */
// a rock blender loaded from file for a specific map
[RockBlender1026]
{
Blendmap=1;
File=Maps/dry_data/1026_bm_small.png;
}
}

== Heightmap specification ==

The heightmap is specified with 3 tags located in the [TERRAIN] section:

'''Heightmap:''' This should be either:
*An 8 or 16 bit image file readable by DevIL
*A 8 or 16 bit RAW file, such as generated by Terragen

'''HeightScale and HeightOffset:''' The actual height of a heightmap pixel is calculated scaled by HeightScale, after which HeightOffset is added to it (height = pixel * HeightScale + HeightOffset)

== Texturing method specification (how are the textures applied) ==

=== Texture stages/layers ===

Texturing of SM3 terrains works by a series of texture layers that are applied on top of eachother. These layers are called "texture stages". The stages can be added, multiplied, or alpha blended with the previous stage. This is defined by the stage operation.

The number of stages is given with the tag NumTextureStages like:

NumTextureStages=2;

Keep in mind that the stages are directly executed on your videocard. This means the more stages you make the slower the map will render.

The first stage never has an operation:

[texstage0]
{
source=Snow;
}

Following stages can have "operation=add", "operation=mul", "operation=blend"

==== Operation Add ====

The add operation needs a texture to add to the previous stage, which is specified with the "source=TextureName" tag. The texture specification is explained below.

[texstage1]
{
operation=add;
source=CrackedDirt;
}

==== Operation Multiply ====

Same as add, but with operation=mul

[texstage1]
{
operation=mul;
source=CrackedDirt;
}

==== Operation Blend ====

The blend operation does alpha blending with an extra grayscale alpha texture. Specification of these alpha textures ("Blendmaps") is explained later in this doc. The blend operation needs a "blender=BlenderName" tag to work. I'm guessing most maps will only be using this operation.

[texstage1]
{
operation=blend;
source=CrackedDirt;
blender=RockBlender1026;
}

The avaiable operations are limited to add/mul/blend for techical reasons:
This way even the most complex maps can be executed with multipass operations on any card with at least 2 textures units. It would even work on a Riva TNT I think.

Obviously because the first stage doesn't have any previous stage, the operation of the first stage is ignored

=== Textures ===

==== Tiled textures ====

The operations usually have "source=texturename" in them, which points to the name of a tiled texture.

Example:

NumTextureStages=1;
[texstage0]
{
source=Snow;
}

[Snow]
{
File=Maps/dry_data/Snow_Sand.jpg;
TileSize=20;
}

Tilesize is how big a single tile is in the 3D spring world, when the texture is tiled across the map. Imagine a heightmap of 1025x1025 (In spring world space this is 1024*8= 8192x8192 units).
When you set tilesize=4096, you will see the complete texture 4 times on the map (2 by 2). Set it to 8192 and you'll see the map completely covered.

==== Blendmap specification ====

Blendmaps can either be loaded from file or generated from the terrain. They are stretched across the full terrain, so in combination with the blend operation you can specify exactly where you want to see a specific texture on the terrain.

===== Blendmaps from file =====

Blendmaps can be loaded from any grayscale file that DevIL can load:

[RockBlender]
{
Blendmap=1;
File=Maps/dry_data/1026_bm_small.png;
}

===== Generated blendmaps =====

Blendmaps can be generated from the heightmap. The final value is computed by

blendmap_value = SlopeTerm * HeightTerm * coverage * noise

The slope of the terrain is a value between 0 and 1, with 0 being flat and 1 being completely steep. Ofcourse with a heightmap the slope can only be near 1 and not exactly 1

The height of the terrain is between 0 and 1 (the minimum and maximum height value)
If the height is between minHeight and maxHeight, HeightTerm will be 1. maxHeightFuzzy and minHeightFuzzy determine the "border" size between having a HeightTerm of 0 and a HeightTerm of 1.

GeneratorLOD indicates at which resolution the blendmap should be generated. The blendmap size will be (heightmapsize-1) / (2 ^ generatorLOD). For example with a heightmap width of 1025 and a generatorlod of 2, the blendmap size will be 1024/4=256.

(Images illustrating this will be added later)

== Infomaps ==

The infomaps section defines the metal map and typemap. Both should be 8 bit images in any format DevIL accepts.

== Image file sizes ==

* The heightmap has to be square and its dimensions have to be a power-of-two + 1, like 257x257, 513x513, 1025x1025
* The blendmaps have to be square too, with power-of-two dimensions like: 256x256, 512x512, 1024x1024. They should be smaller than the heightmap.
* The tiled textures should have power-of-two dimensions, but don't have to be square
* The minimap can be anything, but it will be resized to an image of 1024x1024. Specifying a 1024x1024 will allow faster loading because no resizing is needed.
* Typemap and metalmaps dimensions should be (heightmapsize - 1) / 2, so when the heightmap is 1025x1025, the typemap is 512x512.
* The heightmap can be any [http://openil.sourceforge.net/features.php DevIL] supported format, or RAW such as exported by terragen. All the other maps/texture files can only be a DevIL format.
[edit by relinquished: fixed typo "to be square two" instead of "to be square too"]

== Feature placement ==

The feature specification is done with a list of feature type names in the SM3 itself, and with an binary datafile that contains all the feature positions, orientations.
Feature types are specified like this:

[FeatureTypes]
{
NumTypes=4;
type0=TreeType0; // a tree
type1=MyFeature;
type2=MyOtherFeature;
type3=GeoVent; // a geothermal
}

The feature binary file should be made with an editor. I'm hoping Maelstrom will add feature placing to his startpoint editor, but until then there's only http://user.supradigital.org/jcnossen/FeaturePlacer.zip

[[Image:Featureplacer.png]]

The "Pos:" fields are ment to enter the feature X,Y,Z. You can use zero for Y because spring will automatically put the feature on the ground when it loads.
Type is the index into the feature type list specified in the SM3 file.

The feature data file should be linked to the SM3 with:

[map]
{
.. other map tags ...

featuredata=FeatureDataFileName;

.. other map tags ...
}

== TODO ==

* dynamic shadow mapping support
* shadowmap storage, so the resolution can be increased

[[Category:Map making]]
[[Category:SM3 map format]]