Well thats a horrible way to do it. A damage field won't stop the player from building outside of it.
They'll just waste scrap building out of it and get mad and rage quit....
But alas....
You want ServiceMasks....
And it'd be better to have the buildings simply do addHealth = -#. so they slowly die. Then make sure the service thingy services parallel and does == the damage self done, or more if u want them to slowly heal.
Then, just make sure the servicemask in gameobjectclass matches the one in the sbay under servicemask.
Relevant changelog entries:
Code: Select all
[SupplyDepotClass]
SupplyDepotClassServiceMask = 0
SupplyDepotClassServiceMatch = 0
SupplyDepotClassServiceProvides = 0
[GameObjectClass]
GameObjectClassServiceMask = 0
GameObjectClassServiceMatch = 0
GameObjectClassServiceProvides = 0;
Does the same as the scav/scrap/deposit mask/match/provides as
above. The first check is done when a person is trying to get into an
empty craft. The second is done when a powerup's hitting an
object. This is about it for what I want to do with these things. It's
a LOT of copy/paste stuff that's pretty boring to do. [NM]
Scavenger mask descriptions (I believe this is the longest changelog entry):
Code: Select all
- Fix for mantis #1521 and #509. Added
[DepositClass]
DepositClassMask = 0
DepositClassMatch = 0
DepositClassProvides = 0
[ScrapClass]
ScrapClassMask = 0
ScrapClassMatch = 0
ScrapClassProvides = 0
[ScavengerHClass] or [ScavengerClass]
ScavClassMask = 0
ScavClassMatch = 0
ScavClassProvides = 0
These are bitmasks. A pool (deposit) can be selected if, for a
given scav+deposit pair, (ScavClassProvides & [i.e. bitwise and]
DepositClassMask) == DepositClassMatch, and (DepositClassProvides &
ScavClassMask) == ScavClassMatch. Scrap is the same type of match. The
defaults are 0 for mask & match, making existing items all work. But,
if you start setting bits to 1, you can restrict what they match. As
scav masks are used for both deposits & scrap, then you may want to
use bits 0..15 (1..32768) for deposits, and 16..31 (65536 and up) for
scrap matches.
-- Extra expanation #1:
For example, if a pool wants to restrict access, it could do something
like DepositClassMask = 1, DepositClassMatch = 1. That will remove
access from all scavs, by default, until the scav adds
ScavClassProvides = 1 (or any provides with bit 1 set).
Alternatively, you could do the matching on the scav. You could do
ScavClassMask = 1, ScavClassMatch = 1. That'd restrict all pools until
the pool puts in DepositClassProvides = 1 (or any provides with bit 1
set).
Basically, the (SourceProvides & DestMask) must == DestMatch. Note,
if both sides do matching, then it must work symmetrically.
-- Extra explanation #2
Note: this has *nothing* to do with any race mask/typemasks used
elsewhere. This is a completely new system. If you're not familiar
with binary math, you should probably use Windows's calculator, and
put it into View -> Scientific mode to enable the option to show
binary mode, ANDing, etc. For example, if you have binary value 10110,
you should convert that to decimal mode and get 22, the value to enter
in the ODF. You can also test out ANDing by entering 10110, then press
the 'And' button, and and with 11111, and you'll end up with 10110.
(Anding simply means that for each bit, if both bits are 1 in the
inputs, it'll be 1 in the output. If either (or both) bits are 0 in
the inputs, the result is 0.
If you're working on restricting access, then you should start off
with the Match param, and work backwards. The default match is 0, and
so you want a combination of Provides AND Mask that equal zero. Note
that the default mask is also 0, so by the rules of binary math,
anything in provides ANDed with Mask 0 equals 0. So, access is
granted.
If, for example, you decided to set Match to 1, but left Mask at 0,
then it will *always fail*. Why? Because, as above, anything anded
with Mask 0 results in 0, but you're matching 0 against 1. Won't work.
Unless you're aiming for permanent "never match" state, then any bit
set in match must also be set in the mask.
Bit #1 is decimal value 1. So, if you want to restrict pools, as
above, you could set DepositClassMask = 1, DepositClassMatch = 1. That
will remove access from all scavs, by default, until the scav adds
ScavClassProvides = 1. Or, ScavClassProvides = 3 (binary 11),
ScavClassProvides = 5 (binary 101).
Another pool could set bit 2 (decimal value 2) DepositClassMask =
2, DepositClassMatch = 2. That'd prevent default scavs
(ScavClassProvides = 0) from deploying. And, it'll prevent
ScavClassProvides = 1 from working. But, ScavClassProvides = 2 and = 3
will work, because both have bit 2 set.
Another pool could set bit 3 (decimal value 4) DepositClassMask =
4, DepositClassMatch = 4. That'd prevent default scavs
(ScavClassProvides = 0) from deploying. And, it'll prevent
ScavClassProvides = 1 from working. But, ScavClassProvides = 4 and = 5
will work, because both have bit 3 set.
The three examples above restrict based on a single bit being set.
You could also combine bits the same way.
--
Compiles, but only minimal testing done. [NM]
Simple Explination: Bitmasks
Calculator > program/scientific mode > bin > #####.
If the numbers for match and provides match, it'll service.
Lets only pay attention to 3 bits to explain how it works...
0 = 000
1 = 001
2 = 010
3 = 011
4 = 100
5 = 101
6 = 110
7 = 111
Aligned vertically, each column acts as a separate servicing channel. Something servicing only 1 column will only service that column if the number in the ServiceBay match matches the GameObjectClass's provides. It also can check based on gameObject Match matching the ServiceBay's Provide.
Sooo, you can pretty much filter your head off all you want. I hope this helped...