Shield rewrite

[Argh]

* ShieldHit lua-callin
* 2 new shield primitives: box & cone
* ability to add multiple shields to one unit
* ability to change the size of a shield via lua

+1 to all of that.

[Pxtl]

If we're going to talk about new shield-primitives, why not 2D primitives of circle and polyonal? This would allow you to assemble some complex shapes out of shields, and build shield-based perimeter walls. It also would let you construct bubble-barriers between overlapping circular shields (if you get the cut-sections-out-of-shields thing working).

*disclaimer, not actually a stakeholder

[Argh]

Doing semi-cheap volume searches requires a primitive that doesn't have any concave facets, and there are shortcuts for cubes and spheres and cones.

If we could use cuboids with arbitrary rotation, we could do things like walls that were very fancy at a reasonable cost.

[Agon]

It looks like most people want a new shieldHitCallin or if I rewrite shields a shield system based on Lua.

Since I want to write a new one, a wip proposal:
I think a shield part should be a model (s3o,...) this way you don't need any math to create a shield or any complex variables. Also a "shieldHit"-callin should exists for customized handling of collisions, effects, resource consumption and other gameplay related things.
A shield contain shield parts and each shield part should be modifiable like a normal unit is. To keep the old shields I would add the new shield system to the old one, so both can exist.

+ Shield hit callin

• * shieldID
  * shieldPartID
  * attackerID ?
  * damage
  * collisionPosition ?
  * weaponID

+ Unit collisions volumes aka models (s3o, 3do, obj)
+ Modification abilities for shield parts

• * disabling
  * resizing
  * position
  * direction
  * model ?
  * color (ARGB) ?
  * texture ?
  * shader ?

Some new Lua functions for shields (most likely not complete):

Code: Select all

+ getShield(int shieldID) : shield
+ Shield.getShieldPart(int partID) : shieldPart
+ Shield.hasParts() : bool // or shield.Parts() only?
+ Shield.parts() : int // amount of parts
+ Shield.owner() : unitID // to which unit is the shield attached
+ Shield.attach(int unitID)
+ ShieldPart.disabled
+ ShieldPart.model() : model // of course proper return value
+ ShieldPart.resize(float size)
+ ShieldPart.position
+ ShieldPart.direction
+ shieldPartHit(int shieldID, int shieldPartID, int attackerID, float damage, float3 position, int weaponID)

[Argh]

<looks at git>

Awesome.

[Agon]

<looks at git>

Awesome.

Yeah, great. So no requirement for a new shield system?

[Argh]

I can still see the need to write an efficient volume search for cuboids oriented arbitrarily (which, btw, is already present for Unit hit-tests, you just need to port it), myself, to allow for certain things. I certainly don't speak for anybody else.

[AF]

I can still see the need to write an efficient volume search for cuboids oriented arbitrarily (which, btw, is already present for Unit hit-tests, you just need to port it), myself, to allow for certain things. I certainly don't speak for anybody else.

Refactor != Optimization

You are talking about something that would be relevant to the internal implementation, the How.

This thread is not about the how to do it, it is about what 'it' will actually be.

[Argh]

Well, I haven't looked at most of that code, so to be perfectly honest, I don't know how much room there is for serious optimization of either the necessary logic or the ancillary bits (OpenGL setups, etc.), nor would I be a good judge.

I would presume that the performance of all of these is more than adequate, though. I've never heard of a game being brought to a crawl due to multiple Shields. Then again, we really haven't seen anybody do a game where Units with multiple Shields on certain facings were commonplace, etc. etc.

But it appears from the Git commits that Kloot's also put some work into rationalizing the structure as well as adding this functionality, so I think it's fair to say that it's an improvement in that sense.

The only major place where I think the OpenGL might be improved is by using culling so that multiple Shields that intersect remove the geometry under the overlap. I haven't personally tried to build such a system yet, but seems like if all visible Shields were rendered as a single pass, instead of Unit-by-Unit, as they appear to do now, that this behavior could be implemented with simple depth-test cull.

Oh, that, and maybe building the display lists at game-start, since most Shield sizes aren't changing (now that we can play with that, I plan to experiment with it in P.U.R.E.- having them simply shrink on each hit, instead of the stock 'weakening' code), and storing them somewhere, so that unless you've done something dynamic to the volume, it's a very cheap load. IDK if that's being done or not, but if yes, it would make the process of rendering Shields as a single pass to the buffer really easy and fast.

[AF]

eh i wasnt really prodding for a discussion on optimization.

Rather my point was that this isn't a thread about the optimization or implementation of XYZ, its rather more a case of defining exactly what XYZ actually is, aka what form it will take. So talking about optimization and implementation techniques as you've been doing is kind of offtopic and not really relevant at the moment.

[Argh]

<shrugs> There just isn't that much to discuss about the business case, tbh, other than the ideas that have been brought up, most of which are in the master branch already.

[AF]

Perhaps this is a sign or hint then that the thread is nearing the end of its life and you should move on?

[Argh]

Why, when I still had something constructive to say about things that might improve the implementation, and am pointing out that there is room for Agon to participate, albeit perhaps not in the direction he originally intended to?

IDK, seemed like a reasonable thing to do.

[AF]

I trust Agon and everybody else knows what they're doing, and if it turns out to be slow then we can suggest it as an improvement

[Argh]

What are you talking about? I haven't the foggiest where you're going with this. What's to trust? Most of what we actually want is already available, it's down to nuts and bolts, or the remaining business-case stuff, like conic / cuboid / cylindrical shield interception code (which, other than conic, is already available elsewhere in Spring).

[AF]

0_o you just undermined yourself, but yes no more derail