the groundplates have to be rescripted please!

[Optimus Prime]

That sucks...

If you want to make a long unit with a groundplatesize of for example 16x8 and this unit only fills this size, the groundplate dont turn with the unit.
What that means:
You have this nice long unit and when it turns 90° the groundplate should be now 8x16, but it is still 16x8 so the collision looks really odd and the unit can land on places where units are in their shiphull.

Or am i doing something wrong with the groundplates? Is it fixaple by myself in the scripts?

[FLOZi]

Groundplates are defined by the footprint in Spring.

Footprints have always had to be square for mobile units, but in TA the groundplate was rendered from a face on the model.

Make them square, and live with it.

[zwzsg]

Spring doesn't use the groundplate face defined in the 3do but the footprint defined in the FBI, for both selection square and ground occupation. And yes they don't turn, so you'd better make them square. And yes, long thin units with square footprints looks and behave odd, but there's not much you can do about it.

Topics about collision detection algorithm pop-up regularly, so it's not like dev are unaware of the issue. But apparently it isn't that easy to code a perfect collision system.

[Optimus Prime]

but wouldnt it be possible, to make the groundplate turn with the unit (i mean in the next spring version or so)? What would be the difference by doing that? I cant find a problem in this thought.

[FLOZi]

It is impossible to make the footprints turn. Atleast not without rewriting large portions of the engine, I imagine.

Live. With. It.

[Maelstrom]

I think Zaphod is actually rewriting the collision code to allow for rotatable collision boxes, as FF, GEM and SWIS really needed it, as their space ships are alot longer than they are wide, as OP has just found out. Im not sure where the thread has gone now, but I think it might have been in the Development forum.

[Caydr]

Collision boxes (ie, for weapon impacts) will rotate with the model eventually, but for the purposes of navigation, ie, going from point a to point b, Zaphod says it will always have to be sphere-based. I don't think this is really a problem and I can see the logic behind it. Picture this.

Code: Select all

==    S   ==
==    H   ==
==    I   ==
==    P   ==

It's flying through... let's say.... an asteroid field, or even just past a couple of ships, right? On both left and right there is blocking terrain but technically it can "sqeeze" through as long as it doesn't turn. Well what happens when you want it to turn? The code needs to be foolproof, and fools everywhere will start WTFing when their ship refuses to turn around, etc, etc, etc. Am I illustrating the problem?

Make your groundplate square.... there's just no way around it.

[Felix the Cat]

Well, you have four points corresponding to the four corners of a quadrilateral groundplate for your elongated ship (or other unit). It's simple to prove that if the object rotates around the geometric center of its groundplate, the extremes of the shape described by the rotation - the parts that will always collide with any obstruction which is at least as long as the unit in question. So you can always calculate where the corners of the object are and whether they've collided with an intervening object, and stop the turn if so.

This leaves you with two problems, illustrated below in my beautiful ASCII artwork:

Code: Select all

     S
     H
==== I ==
     P

Code: Select all

------------------------------
===============                
====     
====   ========
==== S ========
==== H ========
==== I ========
==== P ========

In the first example, the ship's corners can freely rotate - at least up to nearly 180 degrees. However, the ship's edges can't rotate as far as the corners. Solution: figure out if a line between the ship's corners intersects with a line between the obstruction's corners, which shouldn't be processor-intensive since it's solving a simple system of linear equations, which a graphing calculator has no problem doing.

The second example is a bit more tricky. The ship can go through the north/south passage fine, and the east-west passage fine, but can't make the turn between them. If it can't go in reverse, it will get stuck there forever if it goes in. The solution may be for Spring to parse all unit footprints and all map areas, and to figure out where "chokepoints" are where certain footprint size's can't pass, and not path ships through these chokepoints. However, that only solves problems with the map itself, and not dynamic problems such as those with other units and with wreckage. Those would have to be solved on demand, which would probably generate significant processor overhead. However, if we were to presuppose that all units big enough to justify a non-square footprint should be large enough to go through wreckage, and that situations where units are the culprits are generally only temporary as units can move, we're only left with buildings as problems - and as far as I'm concerned they can remain problems; if your buildings are so closely packed that your units get stuck, well, that's your problem.

It should be noted that I'm presuming that all groundplates are rectangular (as in, all angles between sides are 90 degrees). Irregular quadrilaterals present additional problems that probably aren't worth solving.

See, rectangular groundplates can be done and dealt with, at least in theoretical terms. I don't see how any of this poses a problem - it's all relatively simple math, and simple math is what computers do best. The attitude that a problem cannot possibly be solved and that we just have to live with it is an attitude that does not lead to creative problem solving and a better product, but rather to defeatism and a product that does not rise to the levels that it could rise to.

[HildemarDasce]

Well said Felix.

How about, as temporary solution, allow rectangular groundplates for air units?

The pathfinding code shouldn't be affected by this (right?), only where they can and cannot land.
This would benefit the space mods without putting to much load on the programmers.

Or maybe I'm wrong and it's just as hard to implement for air units?

Well, just my two cents.

[SinbadEV]

Perhaps allowing units to go backwards...

[smoth]

or perhaps... for long units... have them path for a square that equates to the longest side... I.E. 7X2 would path for 7X7... giving that ship ample room to mov around... little ships would follow their own box but the big ones would strictly adhere to a 7X7 square...?

[Caydr]

Perhaps not.

[smoth]

just a suggestion caydr... I do not see you posting any suggestion.

[Das Bruce]

I haven't been paying much attention but perhaps ground plates could be made into divisable parts.

Ie a straight unit.

Code: Select all

    ==
    ==
    ==
    ==

Same unit turned.

Code: Select all

==
 ==
  ==
   ==

Each '=' represents an element of the ground plate, it wouldn't be perfectly accurate but it would be a damn sight better than how it is, and it would seem to not be a huge change, I think...

[BvDorp]

Move to Dev forum?

[Optimus Prime]

one suggestiuon would be, to change a 7x3 box into a 3x7 box if the ship turns more than 90 degrees. Would that be possible? Its not the best solution, but better than nothing...

[Caydr]

But you're not paying attention, it would completely break the pathfinding engine and a dozen other things. Footprints must remain square.

[Optimus Prime]

but it works with rectangles now too. Atm a lot units arent squares and it works quite good. Else what sense would it have to give the groundplate 2 sizes X and Y?
Or are we talking about something different?
I m talking about the groundplates (the green rectangle under the units) and they are definitely not all squares in FF and i think in other mods too (geos for examples).

[Felix the Cat]

But you're not paying attention, it would completely break the pathfinding engine and a dozen other things. Footprints must remain square.

And of course we can't improve on the current pathfinding engine!

If everyone had your attitude problems, why, Spring 1.0 would have probably been out a long time ago. After all, no need to improve the engine! It's already perfect!

I have a proposal. If you are not going to offer at least somewhat constructive criticism, well, nobody wants to hear you. Take your overinflated ego and go away.

edit. Last bit is directed at everyone, not Caydr in particular.

[SwiftSpear]

Optimus, ground plates aren't used for pathfinding, they are usually way too small in comparison to the unit to properly pathfind a unit. [edit] groundplates and unit footprints are totally different things, the only thing the groundplate defines is where you can click on a unit for it to successfully be selected.

Felix: Honestly, the devs aren't just sitting on thier hands all day. There are dozens and dozens and dozens of feature requests that are being juggled constantly, but I think it's fair to say that the pathfinding engine isn't currently getting a total rehaul. So these kind of ideas, as great as they may be, are not simple implimentation changes, and aren't any more relevent to the current spring development then, say, asking for dynamic lights.