Rim wall specific settings

[voodoo]

Hey all,

I'm trying to change a bit rim walls so that each rim wall can have different acceleration, boost and boost factor settings.
CYCLE_ACCEL_RIM, CYCLE_BOOST_RIM and CYCLE_BOOSTFACTOR_RIM are used as default but can be changed in the map file.
As this requires a change on both server and client side, and to give it more sense, I've added support to change rim wall textures in map file too the very same way cockpit does, allowing to customize walls with specific settings so players can "see" them.

Here's an example of wall definition in an aamap file:

Code: Select all

        <Wall acceleration="20">
          <Image scale_x=".3" scale_y=".3" repeat="both">
              <Graphic category="" author="voodoo" version="1" name="glowing_square" extension="jpeg" />
          </Image>
          <Point  x="200"  y="200"  />
          <Point  x="200"  y="300"  />
          <Point  x="300"  y="300"  />
          <Point  x="300"  y="200"  />
          <Point  x="200"  y="200"  />
        </Wall>

It's working fine so far but I have a few questions:
I've add a map dtd (map-0.2.8.0_advrim.dtd) but is there any official dtd for 0.3 and zones v2 ?
also, I've put it in resource/proto/AATeam but the client does not seems to be able find it after install (except if I set up a repo of course). Is it the right place to add it ?
finally, is there any reason there's separate Image and Graphic xml elements ? It might be better to merge them.

Here's the corresponding branch:
lp:~armagetronad-ct/armagetronad/armagetronad-advrim

[AI-team]

Great idea! I wonder why nobody has thought about that before

[voodoo]

I've added directional effect meaning settings apply only if you grind the wall from start to end:
<Wall acceleration="20" directional="1">
directional is a bool here.

Here's a ugly screenshot where the walls with arrow speed up your cycle if grinded following the arrow ...

[Tank Program]

This is most interesting. Someone who knows more about XML will have to comment on whether this is the direction we want to go for this. I was under the impression that textures as a resource would work slightly differently, but can't really explain how I think they should work.

[Z-Man]

The reason we haven't done anything like that is because we thought too much about it For example: I'd like to be able to override those custom textures on my client for whatever reason.

About the odd nesting, from the cockpit dtd:

Code: Select all

<!-- Graphic is a regular graphic file, like something.png.  ResourceGraphic is a resource xml
file that contains more information on the image and may be a case of YouMightNeedThis -->

So it's there for future flexibility. I don't know whether there is any good reason to do so in the code; if not, I'd think it would be better to just ditch it and make it a single tag without nesting. Call it GraphicImage or something so later we can have MaterialImage for more complex texturing or ResourceImage. Sure, the common attributes need to defined for each in the DTD, but they probably still can be handled by the same code.

A single tag would also be easier to later make customisable via CSS, I think. Which is the way I'd say we should go about server and client overrides and defaults for graphics styles.

About the DTD download problems: yeah, DTDs are a bit special. They can only be downloaded from the resource repository, not a custom server; we don't want rogue DTDs injected with future version numbers, plus it'd be hard to tell the system where to download them from in the first place.

I'd say: clean the thing up so it uses a single tag for the texture and no nesting, retrofit the same thing to the cockpit textures, have both cockpits and maps use the same base code (if that's not already what you're doing), and it's something I'd merge into trunk (not 0.4, we'd never get the customisation ready and good without delays).

Oh, one more thing, dunno whether you have thought about that (and again, I haven't looked at the actual code): it needs to be possible to put an offset to the texture coordinates so designers can align them at borders properly and you need a flag determining whether the texture should scale when the map gets scaled (so the whole map looks the same, just bigger) or not (what we do now, so the wall structures look the same but there's just more of it on bigger maps).

[voodoo]

So as requested, I've added GraphicImage in both map/cockpit code/dtd,
and fix a bug in texture start position so each time you set a new texture, it start from the very left again instead of keeping current position.

There's still an easy to fix bug with moviepack overriding texture position in gWallRim_helper (edit: I've just fixed it) but there's a few points to clarify about rendering anyway.

For example: I'd like to be able to override those custom textures on my client for whatever reason.

I was thinking the ability to change rim wall texture in maps as a way to highlight those walls with overridden physic settings. I can't see any good reason to let the client override those settings (except a not powerful enough machine but textures will be disabled anyway). While I'm thinking moviepack should not apply on those walls, is it a "whatever reason" requiring to disable rim wall specific textures ?

it needs to be possible to put an offset to the texture coordinates so designers can align them at borders properly and you need a flag determining whether the texture should scale when the map gets scaled

I've looked at the code and done some testing about size_factor. An issue is that wall height is not affected by size factor, which means that the map will not look the same anyway: walls will be longer, not higher (for those which have a specific height or if high walls are disabled). Default texture is not resized which is constant with this behavior. This said, I guess an horizontal offset makes sense but vertical offset or size factor flag requires to change the way height is affected by size_factor so far.

Edit: a screenshot with a moviepack and a cleaner specific texture (prev one was really ugly )

[Z-Man]

I was thinking the ability to change rim wall texture in maps as a way to highlight those walls with overridden physic settings. I can't see any good reason to let the client override those settings (except a not powerful enough machine but textures will be disabled anyway). While I'm thinking moviepack should not apply on those walls, is it a "whatever reason" requiring to disable rim wall specific textures ?

Ah. The way coustomization would work via CSS is that you give the walls a 'class' attribute, describing the type of wall. So you'd just say

Code: Select all

<Wall class="boost">
..points...
</wall>

And the CSS (defined inline in the xml elsewhere, or externally) would handle both giving it a different appearance and different physics. A clientside CSS could then override the appearance. It could also override the physics, of course, but that would only result in mispredictions, and who would want that? Anyway, don't worry about it. I think we can just magically make it happen later without changing the high level parsing code. Maps that should be fully customisable will need to be adapted later, of course, but not for the basic 'let the user pick a default wall texture' functionality.

I've looked at the code and done some testing about size_factor. An issue is that wall height is not affected by size factor, which means that the map will not look the same anyway: walls will be longer, not higher (for those which have a specific height or if high walls are disabled).

Observe feature creep, then It is obviously also required that you make it possible for walls to scale with size_factor. Optionally, of course, you still want to have chest high walls to take cover behind at all size factors.

[voodoo]

I finally spent time to add the offset and size factor things. Here's the thing :

Code: Select all

<Wall height="15" acceleration="30" directional="1" keep_size_factor="true">
          <GraphicImage category="" author="voodoo" version="1" name="arrow1" extension="jpeg" scale_x=".5" scale_y=".5" offset_x=".25" offset_y=".25" repeat="both"/>
          <Point  x="10"  y="250"  />
          <Point  x="60"  y="250"  />
        </Wall>

keep_size_factor is an attribute of walls so that wall height is affected by size_factor as other coordinates. Texture is scaled accordingly.
offset_x and offset_y allow to adjust texture assuming that new walls definition means texture coordinates restart to 0 (+ specified offset) at first wall's point.

I'm still not sure I've done it the way you were describing it.

I've updated cockpit.dtd, may be a new one should be better.
I've not included a zones v2 dtd as I don't know which one to use.
Apart from that, I hope all should be fine now...