New Defrag Release

[Le another black niger]

- add: /ignore [clientnum]

what does it do?
i still see msgs of player im ignoring

also cant specify multiple numbers

[Le another black niger]

The main difference is that u can also activate it with
door/button/trigger...

triggers can be activated by other entities, if designed that way
(like trigger_multiple)
the only worthy effect of adding this odd entity is that you can manage ups in x and y directions separately :l

Target_>>trigger_

the only flaw of triggers is that they have to have brush model



Noted bug of new df version: clientkick kicks wrong players

also eastrun, moteof_final and av-df cant be played online from now

[|PsY|Shio]

triggers can be activated by other entities, if designed that way
(like trigger_multiple)

No, test it yourself. U cannot trigger any trigger_push_velocity :P
Works only with player-touch.

[Le another black niger]

triggers can be activated by other entities, if designed that way
(like trigger_multiple)

No, test it yourself. U cannot trigger any trigger_push_velocity
Works only with player-touch.

no, read the sentence, you are arguing with, better

[-O-marky]

- add: /ignore [clientnum]

what does it do?
i still see msgs of player im ignoring

also cant specify multiple numbers

Still a few bugs with this. Working on it but somewhat tricky as I can't always reproduce it.

IIRC the clientkick bug you talk about been around since atleast 1.91.08. Completely forgot about that, thanks for reminding me

[Le another black niger]

noob surf has notable flaw, it doesnt work if landing on edge or vertex

!dark_cave_noob_surf_bug.dm_68

worked fine at 2nd trick

also independent ff is still global
noted on map 'next'
when somebody is ingame with 3 frags, ff is blocked for other players

[BeRsErKeR]

The main difference is that u can also activate it with
door/button/trigger...

triggers can be activated by other entities, if designed that way
(like trigger_multiple)
the only worthy effect of adding this odd entity is that you can manage ups in x and y directions separately :l

Target_>>trigger_

the only flaw of triggers is that they have to have brush model

You may trigger "trigger_" entities by name like "target_" ones but you will have more work to do so as triggers are not designed for that kind of usage. Also you have to invest work to avoid activation by touching in those case. But as I said the best argument is: triggers are not designed that way.

And an unnecessary brush model is useless and also slightly decreases performance for hit testing and so on.

But most of all it isn't necessary to use a trigger for that as you always can use a trigger_multiple and target-entities in combination.

The target_speed entity also can slow you down, accelerate you, change your movement direction and so on. You may also create jump- and launch-pads with it or acceleration/slowing gates.

[sjuk]

I remember that uplifting feeling of drinking morning carrot juice and unwrapping some gaming magazine's CD with ChallengeProMode in it. After baseq3's skirmish finally a fresh look of Xaero armored in green, and Apheleon's cpm15 demo.
Ozone-junkies are busy at some other projects right now, so among other little additions in .23 version would be pleasant to credit '5centers' under quakewave-trip-hop audiotrack

[Le another black niger]

yo
I did mapping research of target_speed and trigger_push_velocity entities:
http://ws.q3df.org/maps/downloads/ok-dfjpads.pk3

basically i whined before about missing behaviour types and functionality, splitted between those two
target_speed is more universal one for sure, but has some flaws (imo)

1. speed and add cfg types dont act with 0 ups per wanted axises (initial direction needed)
this may cause possible exploits or just 'broken' behaviour
theres solution for case of single direction per single axis wanted: launcher+add setting
wont help with more axises, since launcher's formula is broken (another issue, i guess - for the case of two axises it produces twice more ups, than cfged, for 3 - 3x)
also it sets specific direction that way
using multiple entities, cfged as launcher+add is possible, but resulting speed value might be various, since calculations get completed separately per axis
solution, i suggest, is adding some 'force dir' spawnflag, which should work, when there are no ups withing any of selected axises
forced direction should be set obviously, when single direction on axis is marked and randomly, when more

2. launcher's direction setting is pretty discrete - 45 degrees
solution for simple launcher is using separate one within every axis (more entities that way.o)
case of complex settings, like launcher+percentage or launcher+add doesnt look solvable for me
also weird various speed output with these settings (not linear dependence on input), because of launcher's formula issue
i suggest to add alternate way of setting direction - via angle (p,y) key
its visualized, as arrow, in 1.5 radiant series

theres also missing 'bidirectional' behaviour from trigger_push_velocity for launchers - not sure if it is enough worthy


just figured out, that another unique behavior is missing: negative speed/percentage values work like 0
substracting ups might be amusing too

[-O-marky]

Cool Thanks for posting, I'll take a look this weekend.

I did push max checkpoints from 8 to 32, however there's the problem of what to do with the following:

http://speedcapture.com/~marky/q3a/2013_12_19-08_08_42-171.png

Note only 16 checkpoints are used here, you can imagine what 24 or 32 would look like...

Any suggestions?