special fields on the grid

[Z-Man]

A serious problem with gridlocking any map feature is the scaling. Maps can be scaled up or down by a factor of up to 32, a total scale variance of 1024 (more from the console). Things would need to align for the lowest scale without rearrangement, which severely restricts the placements. At the default scale, things need to be aligned to multiples of 32 tiles.
What's worse: the scaling factor is irrational for odd size settings, it's a multiple of sqrt(2). That would need to be changed, because there is no way to align something to the grid on all scales that way (unless we tilt the grid 45 degrees for odd sizes, or scale the grid texture.)

A better way to show the zones belong to the grid would be to make them half transparent so whatever is below them shines through. And to make it so that the zone texture and the grid texture are aligned.

For default arena sizes, things will automatically land on gridlines (umm, if we adapt the texture so the lines are actually centered...): map designers like integer coordinates.

[Lyx]

A serious problem with gridlocking any map feature is the scaling. Maps can be scaled up or down by a factor of up to 32, a total scale variance of 1024 (more from the console). Things would need to align for the lowest scale without rearrangement, which severely restricts the placements. At the default scale, things need to be aligned to multiples of 32 tiles.nd the grid texture are aligned.

Does the scale-feature actually make much sense anymore with the new map-system? For the current typical arenas, it does make sense, but for more detailed maps, problems may arise - some i could think of:

- the lane-example. If a map is designed at default-scale with a lane where a cycle barely squeezes through... and it is then scaled down, then we end up with an unusable lane.

- if the map-creator did place the special-fields in a strategical way(again, the lane-example plastered with turbo-fields), then the special-fields would need to be scaled as well, because else the scales of the various components(rim-walls, special-fields) will get out of sync.

So, wouldn't it possibly make sense to do it the following way:
- when maps are scaled, then everything on them gets scaled as well - walls, fields, grid-texture(from my observations, this is already done)
- only allow 5 scales: 0.25(grid texture scaled down), 0.50(gridtexture scaled down), 1.00(no grid-scaling), 2.00(no grid-scaling), 4.00(no grid-scaling)
- maps have to define how big they are when played unscaled
- maps have to define a list of scalefactors by which they may be scaled(that way, the map-creator can restrict scaling to factors which work with his map)
- remove the scale-feature from the menus
- instead, add a map-browser which allows to create a map-queue, where you can not just add maps to the queue but also define at which scale the maps should be played.

This would also make filtering easier: it would then be possible when listing available maps to only show maps which support a certain size.

[Z-Man]

Does the scale-feature actually make much sense anymore with the new map-system?

Yes. Of course, as you point out later, ALL map features need to be scaled (walls, spawn points, zones).

- the lane-example. If a map is designed at default-scale with a lane where a cycle barely squeezes through... and it is then scaled down, then we end up with an unusable lane.

Yes, but with different physics settings, the map will stay playable.

So, wouldn't it possibly make sense to do it the following way:
<snip>

I agree that the size selection belongs to the map selection menu once it is in place. And map designers should probably be allowed to specify a suggested range of sizes. But they should be viewed as a suggestion only; the system may warn you if you set an out of range scale, but not prevent it.

I don't like the idea of restricting the available scalings and hardcoding floor texture scaling just because it fits with the default grid floor; that's the form of hardcoding found everywhere in the current rendering code that makes maintenance hell. We'll have other, more general issues with texture alignment to face; it may be desirable in some art styles to align the floor and wall textures, for example.
What may work while still being flexible (and incidentally coincides in its effect with your floor scaling suggestion): By default, all textures are scaled with the map, i.e. the texture coordinates of a given point of the map stay the same when the map gets scaled. Some textures can have a scaledown property: when they are scaled up too much, they are shrunk down by an integer factor (probably even a power of two) by multiplying all texture coordinates using them by that factor. This would be coolest with "fractal" textures: Imagine a grid with thick lines. Between each two gridlines, place another, thinner line. Repeat with even thinner lines. Repeat. Repeat. You would not even notice when such a texture gets scaled by a factor of two.

[Lyx]

Okay, someway i have the feeling that we actually mean the same (or something similiar) and were just misunderstanding each other.

All the things which you point out, i completely agree to them. I just meant that for complex arenas, a map-editor would be useful which allows to easily align objects (i.e. walls, special-fields) with the grid. The easiest way to do this is with a toogleable gridlock-option. Or to make it easy to do this by hand: if my observations are right, then the default gridlines are spaced in units of 2. So the only thing one would need to do is only use even numbers for placement. But for this to work out, the floor-textures in moviepacks would need to be standardized on this scale(meaning that movie-pack creators should be strongly encouraged to stick to that scale, unless they intentionally want to make things misalign)

A better way to show the zones belong to the grid would be to make them half transparent so whatever is below them shines through. And to make it so that the zone texture and the grid texture are aligned.

I thought along the same ways as well... a PNG with an alpha-channel for the various fields. That way, one can also scale the fields and create "big" special fields covering 4x4 gridsquares, etc.

______________

Oh, by the way:

15.: "Teleport"-Field. Teleports cycles which drive over them to somewhere else. If walls can cover this field (maybe because the teleport is not instant but combined with a fast "fadeout" of entering cycles), then it may make sense to disable wall collisions on that field, and remove walls covering them after 30secs. The field is a one-way teleporter. Two-way teleports could simply be created by using two teleport-fields, with the target-positions adjusted to each other.

[Lucifer]

Well, as far as the map editor goes, I mentioned I was working on one. Right now it'll show the map, spawn points, a grid (to use for scaling) and the axes on the grid. I intend it to also have a square marked at 500x500 to show the standard grid map so map makers will be building with that as a reference. I'd also like to have a scale feature where you can scale the whole map, since I've built some maps that are only built to half scale compared to the default grid.

(Soon it should have a way to click buttons and draw walls, the I just need a drag'n'drop spawn point thing and the ability to save a map that's in memory and itll be ready to throw up for others to screw with)

[Lyx]

16.: "Magnet"-Field - makes cycles accelerate when driving towards it, and brake when driving away from it. Braking should be less than the acceleration-amount so that it can be used as a "catapult".

Edit: That sounds great, Lucifer :)