Created attachment 2899[details]
alter trigger wait timers a bit, remove duplicate code
specifically, do not disable triggers for some if the triggering failed. the change's author is ==Troy==.
Created attachment 2901[details]
mover team code defucktardization
if there is any piece of Tremulous code that is retarded, it's the mover team code. when mover teams are used, then:
- the behaviour depends on which individual entity becomes the so-called team master, and (somewhat) as a result:
- mover sounds are not played properly,
- triggers are not triggered properly.
- stupid things happen when teaming different mover types (eg., func_bobbing + func_door + etc.).
- within one mover team, different mover movement times and wait times are not supported (contrary to what is "advertised"), causing prediction errors, abrupt mover teleportation, solidity of areas not matching the display, etc. whenever such mover teams are used.
as a reference, see the doors in compact-b1 and the large door and the conveyor movers in dryout_b5a.
in this patch, i attempt to fix some of the above issues.
- sounds should be played properly for all individual movers in a team.
- (in case of different movement times) a mover team is considered to have transitioned from one position to the other when all of the individual movers of the team have transitioned; the mover team starts returning from pos2 to pos1 after all of the individual movers have waited the defined amount after reaching pos2.
i am not confident about the correctness of this patch, but i am confident about the incorrectness of the current state of the code.
mover starting sounds being played for all mover of a mover team simultaneously may sound weird with the openal sound interface.
heterogenous teams are still not handled. teaming non-func_doors should probably be removed (protected against), anyway.
Created attachment 2902[details]
multitarget support
adds 3 additional spawn vars to specify additional targets: target2, target3, and target4.
adds 3 additional spawn vars to specify additional targetnames: targetname2, targetname3, and targetname4.
the idea (and the original implementation) is courtesy of ==Troy==.
Created attachment 2905[details]
new AMP entities
i will not attempt to document the workings (spawnflags, etc.) of the new entities.
originally by ==Troy==, now fully rewritten.
2 entity types are separated: target_power and target_creep, these will follow in a patch that "makes a lot of noise".
Created attachment 2906[details]
target_power and target_creep, power range logic rewrite
the introduction of these entities is followed by an attempt to alter the workings of power and creep zones to a well-defined method, which is then fully implemented.
the formal specification of the target_power entity and human power zones is:
- there are 4 types of target_powers:
{master|non-master} target_power {reactor|repeater}
- each target_power has its own range setting for its (sphere shaped) zone
- terminology: the "small union" is the union of master target_power reactor
zones, the "big union" is the union of the reactor zone and all
(master/non-master) target_power reactor zones
- (master/non-master) target_power reactors extend the reactor's zone
- in the big union, repeaters can't be built (existing repeaters blow up)
- if there is a reactor, then the big zone is powered, and otherwise only
the small zone is powered; in both cases, (human, non-support) buildables
in the appropriate powered zone are powered opportunistically as governed
by the following rule:
- in the small/big union, at most g_humanbuildpoints worth of buildables are
powered (in case of an excessive set of buildables, the powered subset is
determined by some internal mechanism, but is guaranteed stabilize
quickly; unpowered buildables blow up shortly)
- (master/non-master) target_power repeaters provide repeater-like local power
- each target_power repeater has its own buildpoint setting (buildable
repeaters have the setting at g_humanrepeaterbuildpoints)
- a master target_power repeater is always said to be powered, a non-master
target_power repeater (also, a repeater) is said to be powered if and only
if there is a reactor
- any (human, non-support) buildable outside the big zone, if in range of at
least 1 power repeater or powered target_power repeater, is powered by
only the nearest such repeater or target_power repeater, opportunistically
as governed by the following rule:
- a repeater or target_repeater powers at most X worth of buildables, where
X is the repeater's buildpoint setting if the repeater or target_repeater
is powered, and 0 otherwise (in case of an excessive set of (human,
non-support) buildables closest to this repeater or target_repeater, the
powered subset is determined by some internal mechanism, but is guaranteed
stabilize quickly; unpowered buildables blow up shortly)
Created attachment 2907[details]
allow a special trigger to bring movers down manually
this is ==Troy=='s change, and i have no idea what this is about.
Created attachment 2912[details]
add an AMP compat hack for target_force_win
adds target_force_win, an old, redundant (use target_{alien|human}_win instead!) entity.
Created attachment 2919[details]
target_power amendment
to finish the target_power functionality as described.
Comment 21/dev/humancontroller
2011-11-09 07:03:21 EST
Created attachment 3004[details]
another multitarget support amendment
fixes trigger targeting when there are "gaps" in the [targetname, targetname2, targetname3, targetname4] list.
Comment 22/dev/humancontroller
2011-11-12 08:33:53 EST
Created attachment 3005[details]
another multitarget support amendment
this is a slightly different version of the above patch, this one retains more compatibility with existing AMP maps.
Created attachment 2898 [details] expose G_RoomForClassChange()Created attachment 2899 [details] alter trigger wait timers a bit, remove duplicate code specifically, do not disable triggers for some if the triggering failed. the change's author is ==Troy==.Created attachment 2900 [details] allow maps to override buildpoint limitsCreated attachment 2901 [details] mover team code defucktardization if there is any piece of Tremulous code that is retarded, it's the mover team code. when mover teams are used, then: - the behaviour depends on which individual entity becomes the so-called team master, and (somewhat) as a result: - mover sounds are not played properly, - triggers are not triggered properly. - stupid things happen when teaming different mover types (eg., func_bobbing + func_door + etc.). - within one mover team, different mover movement times and wait times are not supported (contrary to what is "advertised"), causing prediction errors, abrupt mover teleportation, solidity of areas not matching the display, etc. whenever such mover teams are used. as a reference, see the doors in compact-b1 and the large door and the conveyor movers in dryout_b5a. in this patch, i attempt to fix some of the above issues. - sounds should be played properly for all individual movers in a team. - (in case of different movement times) a mover team is considered to have transitioned from one position to the other when all of the individual movers of the team have transitioned; the mover team starts returning from pos2 to pos1 after all of the individual movers have waited the defined amount after reaching pos2. i am not confident about the correctness of this patch, but i am confident about the incorrectness of the current state of the code. mover starting sounds being played for all mover of a mover team simultaneously may sound weird with the openal sound interface. heterogenous teams are still not handled. teaming non-func_doors should probably be removed (protected against), anyway.Created attachment 2902 [details] multitarget support adds 3 additional spawn vars to specify additional targets: target2, target3, and target4. adds 3 additional spawn vars to specify additional targetnames: targetname2, targetname3, and targetname4. the idea (and the original implementation) is courtesy of ==Troy==.Created attachment 2903 [details] allow movers to have >1 health, and be immune to specified attacks the idea comes from ==Troy==.Created attachment 2904 [details] functionality for players to use trigger_multiples by holding +buttons the author of this change is ==Troy==.Created attachment 2905 [details] new AMP entities i will not attempt to document the workings (spawnflags, etc.) of the new entities. originally by ==Troy==, now fully rewritten. 2 entity types are separated: target_power and target_creep, these will follow in a patch that "makes a lot of noise".Created attachment 2906 [details] target_power and target_creep, power range logic rewrite the introduction of these entities is followed by an attempt to alter the workings of power and creep zones to a well-defined method, which is then fully implemented. the formal specification of the target_power entity and human power zones is: - there are 4 types of target_powers: {master|non-master} target_power {reactor|repeater} - each target_power has its own range setting for its (sphere shaped) zone - terminology: the "small union" is the union of master target_power reactor zones, the "big union" is the union of the reactor zone and all (master/non-master) target_power reactor zones - (master/non-master) target_power reactors extend the reactor's zone - in the big union, repeaters can't be built (existing repeaters blow up) - if there is a reactor, then the big zone is powered, and otherwise only the small zone is powered; in both cases, (human, non-support) buildables in the appropriate powered zone are powered opportunistically as governed by the following rule: - in the small/big union, at most g_humanbuildpoints worth of buildables are powered (in case of an excessive set of buildables, the powered subset is determined by some internal mechanism, but is guaranteed stabilize quickly; unpowered buildables blow up shortly) - (master/non-master) target_power repeaters provide repeater-like local power - each target_power repeater has its own buildpoint setting (buildable repeaters have the setting at g_humanrepeaterbuildpoints) - a master target_power repeater is always said to be powered, a non-master target_power repeater (also, a repeater) is said to be powered if and only if there is a reactor - any (human, non-support) buildable outside the big zone, if in range of at least 1 power repeater or powered target_power repeater, is powered by only the nearest such repeater or target_power repeater, opportunistically as governed by the following rule: - a repeater or target_repeater powers at most X worth of buildables, where X is the repeater's buildpoint setting if the repeater or target_repeater is powered, and 0 otherwise (in case of an excessive set of (human, non-support) buildables closest to this repeater or target_repeater, the powered subset is determined by some internal mechanism, but is guaranteed stabilize quickly; unpowered buildables blow up shortly)Created attachment 2907 [details] allow a special trigger to bring movers down manually this is ==Troy=='s change, and i have no idea what this is about.Created attachment 2909 [details] add a string duplicating function into the game moduleCreated attachment 2910 [details] AMP DEBUG displays trigger interaction. ==Troy== had a similar system.Created attachment 2911 [details] AMP DEBUG PLUS attempts to cut down the noise in the AMP debug output.Created attachment 2912 [details] add an AMP compat hack for target_force_win adds target_force_win, an old, redundant (use target_{alien|human}_win instead!) entity.Created attachment 2916 [details] defucktardization amendment this requires the (already posted) string duplicating function.Created attachment 2917 [details] amendment for new AMP entities this requires the (already posted) string duplicating function.Created attachment 2918 [details] multitarget support amendment just a minor fix for a quirk to remove redundant sp4m.Created attachment 2919 [details] target_power amendment to finish the target_power functionality as described.Created attachment 3004 [details] another multitarget support amendment fixes trigger targeting when there are "gaps" in the [targetname, targetname2, targetname3, targetname4] list.Created attachment 3005 [details] another multitarget support amendment this is a slightly different version of the above patch, this one retains more compatibility with existing AMP maps.