RC/repeater ''power rings''

[Plague Bringer]

Just tried out the current brindus mod power spheres and wanted to highlight this. The sphere doesn't quite represent the range properly (for turrets at least).

Eh. That's in the sphere. If you were to adjust the sphere to fully engulf the building you'd have to have the size of it be dynamic, since buildings are of different sizes. It's better to have less than more.

[Nux]

If you look again, you'll see that not even the center of the model is within the sphere (as I would have found fully acceptable).

[Plague Bringer]

If you look again, you'll see that not even the center of the model is within the sphere (as I would have found fully acceptable).

No, I saw that. It's not a problem with the sphere model, but the way the build range works. As I understand it, if any part of the bbox is in the build range, the building can be built. With larger buildings, the center of the building is further away from the edge of the build range, making it impossible to have a static size sphere that do what you want.

[Nux]

Ah. If it works like that then knowing that is enough to interpret the sphere correctly. Sadly, I can't help but feel others will misunderstand how the range works as I did.

[/dev/humancontroller]

if any part of the bbox is in the build range, the building can be built.

bullshit

[/dev/humancontroller]

IMO the power range should be up all the time for builders, and attack ranges when they have an attack buildings blueprint up.

EDIT:  Maybe have a cvar controlled?  Then we can have binds to toggle it etc.

u will be able to display any combination of: the surface of the range marker (as a semi-transparent sphere or spherical cone), the intersection between the world and the range marker (as a line on the map geometry), and the so-called outline of the range marker (as a line on the map geometry or in the air). u will be able to filter which buildable types u want to have ranges displayed for.

[/dev/humancontroller]

Looking good. How much does all this cost (in processing)?

all this will physically burn ur video card to a crisp. </sarcasm> i'd say all this has acceptable performance.

[Plague Bringer]

if any part of the bbox is in the build range, the building can be built.

bullshit

As I understand it...

Fuck off.

If that ISN'T the way it works, the Nux is on the ball with saying it should be fixed (tweaked) to better display the build range. Now, would you care to tell us how building works (since we're obviously in the dark and making assumptions), or are you going to just spew crude one word responses. If it's not any part of the bbox, then it must be that either all of the bbox or half of the bbox (all, preferably) that has to be in power range for a structure to be built. If that's the case, then the sphere is too small. Not too much of an issue, but an issue none the less.

[/dev/humancontroller]

Now, would you care to tell us how building works (since we're obviously in the dark and making assumptions)

for each buildable there is an internal point called the origin. the distance between origins of the two buildables must be no more than 500 (in case of repeaters) or 1000 (in case of the reactor). to find where the origin of a buildable is, read the configs/buildables/<buildable>.cfg file (can be found in one of the distributed GPP pk3 files). for example, in configs/buildables/reactor.cfg, we have:

mins        -41 -41 -15
maxs        41 41 95

which means that the bounding box for the reactor extends, from the reactor's origin, down by 15 qunits and up by 95 qunits; this means that the origin of the reactor is closer to the bottom of the reactor, being at the 13.6% "height mark" of the reactor. similarly, the origin of a machinegun turret is at the exact center of the turret, and the origin of a repeater is at the 37.5% height mark of the repeater.

to me, the sphere in Nux's screenshot appears to be too small and/or misplaced. or it can be that the Brindus server has different build logic, which i somehow doubt.

[Plague Bringer]

Alright, thanks /dev/h. I just checked and all origins are centered on X and Z, so it's likely too small a sphere model.

/dev/h: Is it possible to not draw sphere overlap?

[/dev/humancontroller]

Is it possible to merge power spheres? Rather than showing the overlap, not drawing it?

i haven't explored that possibility yet, but u should ask Uniq PhoeniX.
note however that this may not be the most appropriate for offensive buildables, because overlapping areas can be under extensive fire.

[gimhael]

to me, the sphere in Nux's screenshot appears to be too small and/or misplaced. or it can be that the Brindus server has different build logic, which i somehow doubt.

It's probably just a precision problem. The build range is drawn by using a radius 1 sphere MD3 model scaled by the build range (1000 for the RC), but the .md3 format has only a precision of 1/64 units, so the rounding error of the scaled sphere can be up to ~15 game units, which is like 1/3rd of a turret width. I guess it could be fixed by using a radius 1000 sphere model and adapting the scale factor accordingly.

[F50]

It is possible to use a 10, or even 100 unit sphere and then multiply the scaling factor by 1/10th or 1/100th? That should give you a lot more accuracy.

u will be able to display any combination of: the surface of the range marker (as a semi-transparent sphere or spherical cone), the intersection between the world and the range marker (as a line on the map geometry), and the so-called outline of the range marker (as a line on the map geometry or in the air). u will be able to filter which buildable types u want to have ranges displayed for.

/dev/humancontroller: unless you have plans to release within the next month, please just lay off and leave this to people who actually have code to share.


As for merging power spheres, I think that's a bad idea. The main use I personally have for power spheres is to know which repeater(s) are likely to be powering a buildable so I know where the BP is going, or if a structure is being supported by only a single egg.

[/dev/humancontroller]

u will be able to display any combination of: the surface of the range marker (as a semi-transparent sphere or spherical cone), the intersection between the world and the range marker (as a line on the map geometry), and the so-called outline of the range marker (as a line on the map geometry or in the air). u will be able to filter which buildable types u want to have ranges displayed for.

/dev/humancontroller: unless you have plans to release within the next month, please just lay off and leave this to people who actually have code to share.

problem?
in fact we do plan to release the range markers feature within the next month. it's time to lay on. nwhahahahaha!

[Plague Bringer]

As for merging power spheres, I think that's a bad idea. The main use I personally have for power spheres is to know which repeater(s) are likely to be powering a buildable so I know where the BP is going, or if a structure is being supported by only a single egg.

Just imagine a 4-egg alien base. It'd be hectic and probably obstruct the view (I can't say for sure, though, as I can't get on Brindus). Also, it can become hard to assimilate where power spheres are coming from when the screen is overpopulated with them.

[Nux]

I would also like to refer you to my post on page 3.

At least humans have the option of putting the ckit away (which stops them appearing), poor granger is blinded and can do nothing about it. 

[RAKninja-Decepticon]

I would also like to refer you to my post on page 3.

At least humans have the option of putting the ckit away (which stops them appearing), poor granger is blinded and can do nothing about it. 

question:  how hard would it be to add in a "toggle build spheres" bind?

[jm82792]

Have a line coming from each power source to the edge of the sphere?

[F50]

(I can't say for sure, though, as I can't get on Brindus).

What? If you're having trouble downloading the sounds (which is IMO most likely) try going to here and looking for the humongous zzz-sounds-alpha2.pk3

question:  how hard would it be to add in a "toggle build spheres" bind?

Code:

/bind KEY toggle cg_buildRanges

At least humans have the option of putting the ckit away (which stops them appearing), poor granger is blinded and can do nothing about it.

What? The spheres only appear when you have the ghost buildable in front of you.

[RAKninja-Decepticon]

question:  how hard would it be to add in a "toggle build spheres" bind?

Code:

/bind KEY toggle cg_buildRanges

just wondering, as that seems like a fine counter to aliens not being able to "turn it off" like the humans can by pulling out the blaster.  or perhaps toggling them to 50% or more transparency as a seperate, alien specific, bind.  it's no big deal if you have a toggle key, if you ask me.

[Nux]

At least humans have the option of putting the ckit away (which stops them appearing), poor granger is blinded and can do nothing about it.

What? The spheres only appear when you have the ghost buildable in front of you.

You're right. That's fine then.

[UniqPhoeniX]

Not drawing intersecting areas: not appropriate for anything IMO (even with eggs/om you may want to build something that is in range of more than 1 creep source), except repeaters *if* you additionally draw a plane exactly between the 2 repeaters, so you could see which is closer.
*Technically* it may be possible, tho I don't know yet. If it is, it's probably too inefficient on q3. I'm guessing it would be a piece of cake with full access to stencil and depth buffers.
I've thought about additionally drawing on all map geometry (not just at edges) inside any power area, and it should be easy, but it's not implemented yet. However that would also mean drawing on all players & buildables in power areas and that may look weird...

About precision: we already did get around the .md3 precision problem (tho we noticed the problem with cones) by using models with radius 100 that are scaled by range/100, so yes, that definitely works.
Another possible cause for the mismatch on Brindus is having the sphere centered above the center of the RC range.

The view is not nearly as obstructed when only displaying the lines on walls.

[Plague Bringer]

Lines would be my preferred method of rendering power. Perhaps it could be a choice, much like the crosshair. Lines, spheres, or none?

[/dev/humancontroller]

Lines would be my preferred method of rendering power. Perhaps it could be a choice, much like the crosshair. Lines, spheres, or none?

u will be able to display any combination of: the surface of the range marker (as a semi-transparent sphere or spherical cone), the intersection between the world and the range marker (as a line on the map geometry), and the so-called outline of the range marker (as a line on the map geometry or in the air).

[/dev/humancontroller]

we are proud to release the version 1.0 of our (Amsterdam Unlimited's) range marker feature.

i'll take the credit for coding. credits go to Uniq PhoeniX for creating the models, and devising a method (which we call "binary shaders") to draw lines on the map geometry and outlines of shapes. the development is tracked at the bugzilla range marker report.

provided is a demo package, which contains latest-revision modules with the added range marker feature. unfortunately, we do not provide a server with the feature atm, but other servers should install the feature soon.

[Nux]

MIGHTY ORBS



The command list:

    cg_rangeMarkerBuildableTypes
    cg_rangeMarkerForBlueprint
    cg_rangeMarkerLineThickness
    cg_rangeMarkerLineOpacity
    cg_rangeMarkerSurfaceOpacity
    cg_rangeMarkerDrawFrontline
    cg_rangeMarkerDrawIntersection
    cg_rangeMarkerDrawSurface

Why is it I can't see any intersection lines? (Yes, I have the options set correctly)

[Meisseli]

Blaster/spectators shouldn't be able to view the spheres.

Yeah, as I thought, starts to look more confusing than helpful when there are multiple power sources in play. Making a bind to toggle their visibility might just make it useful though.

woo rc hitting turrets, though

[/dev/humancontroller]

The command list:

    cg_rangeMarkerBuildableTypes
    cg_rangeMarkerForBlueprint
    cg_rangeMarkerLineThickness
    cg_rangeMarkerLineOpacity
    cg_rangeMarkerSurfaceOpacity
    cg_rangeMarkerDrawFrontline
    cg_rangeMarkerDrawIntersection
    cg_rangeMarkerDrawSurface

those are not commands.
btw, see Options -> System -> Range Markers

Why is it I can't see any intersection lines? (Yes, I have the options set correctly)

oh, crap. try setting r_showsky to 1, or going to an area isolated from the sky (ie., the Niveus plant room), and then doing a vid_restart. what happens then? this is just for my curiousity, but otherwise you should try setting r_fastsky to 1, and then doing a vid_restart.

[/dev/humancontroller]

Blaster/spectators shouldn't be able to view the spheres.

no u

[/dev/humancontroller]

just for the record, i've posted screenshots on how the range markers SHOULD(TM) show up with the default settings.