search

beyond-all-reason / spring

A powerful free cross-platform RTS game engine
https://beyond-all-reason.github.io/spring/
Other
182 stars 95 forks source link

Add ExitOnly Yardmap Type #1464

Closed marcushutchings closed 1 week ago

marcushutchings commented 2 months ago

Fixes https://github.com/beyond-all-reason/spring/issues/453

HAPFS raw move check hasn't been updated because the raw move code is rewritten in another PR, which calls the generic rawmove code, which has been updated to support exit-only zones.

I'm going to look to add building placemenet blocking for type 'c' as part of this change because I need the work here to do that. Note this doesn't impact the normal 'open' yardmap type as you would expect. Note, I'll also sort out 'w' since it will be minimal effort as well and it is something I wanted to offer for awhile.

marcushutchings commented 2 months ago

I had this crazy idea to have above water/below water separation of states; though, it seems to be causing problems. I'll abort that idea.

sprunk commented 2 weeks ago

It would be good to measure the perf cost at some point but I assume it's not worrying.

lostsquirrel1 commented 2 weeks ago

I'd like one of

* only force-align buildings with an exitonly tile in their yardmap

* have `constexpr bool HIGH_RES_EXITMAP = false` such that exitmaps are compiled as 2x2 by default but one can flip the bool and they would Just Work as 1x1 in such build without the need to adapt anything

* only align buildings to 1x1 instead of 2x2
  1. I worry that would cause buildings to place differently in a way that would not be obvious to the user why it is happening.
  2. Not sure I follow this suggestion. A yardmap is a series of 2x2 squares. I'm not going to make a mess of the yardmap by having parts of it defined in 1x1 increments. I don't know what that would help with.
  3. I don't see the benefit of this. Other parts of the engine are enforcing it - I'm not going to change that at the moment. All that's happening here is whether it is strictly enforced for performance improvements or it doesn't enforce it and keep current behaviour.
lostsquirrel1 commented 2 weeks ago

It would be good to measure the perf cost at some point but I assume it's not worrying.

There will be a cost; though, I've tried to limit it, it is difficult to gauge. I'll see if AKU can get some insight.

sprunk commented 2 weeks ago

1) builder placement UI for players is still 2x2 so it would only affect buildings spawned via Lua. 2) high resolution yardmaps (defined per 1x1 square, not 2x2) already exist. I assume (but haven't checked) that if you tag a 1x1 square as exit-only this way it would tag the entire containing 2x2 tile as exit-only. The reason I suggested that option is that I assume things could break if you used a 2x2 exitmap with 1x1 alignment, and I wouldn't want broken exitmaps to be an obstacle when working with alignment in the future. I generally want exit-only to be as un-intrusive as possible because I think the feature is of barely any use, for reasons I outlined in #453 (it doesn't solve the problems @WatchTheFort thinks it will solve). As long as it's cheap it's fine though, and I'm happy with 61d9152da1b401f8cc729713f05c6cdee84c7472. 3) which other parts of engine enforce alignment for Lua-spawned buildings?

lostsquirrel1 commented 1 week ago

  1. builder placement UI for players is still 2x2 so it would only affect buildings spawned via Lua.

    1. high resolution yardmaps (defined per 1x1 square, not 2x2) already exist. I assume (but haven't checked) that if you tag a 1x1 square as exit-only this way it would tag the entire containing 2x2 tile as exit-only. The reason I suggested that option is that I assume things could break if you used a 2x2 exitmap with 1x1 alignment, and I wouldn't want broken exitmaps to be an obstacle when working with alignment in the future. I generally want exit-only to be as un-intrusive as possible because I think the feature is of barely any use, for reasons I outlined in Exit-only yardmap types #453 (it doesn't solve the problems @WatchTheFort thinks it will solve). As long as it's cheap it's fine though, and I'm happy with 61d9152.

    2. which other parts of engine enforce alignment for Lua-spawned buildings?

Sorry, I misunderstood you there.

I'm happy to discard this if there is a better way to solve these problems.

I ran the BAR pathing performance test and I could not discern an obvious performance impact.

sprunk commented 1 week ago

I think it's cool as a minor feature and will still help BAR solve a decent chunk of their problems. Eventually BAR is going to discover the edge cases not covered by this and instate the gameside gadget anyway, but maybe this can happen organically instead of via zk trying to speedrun you through this.

lostsquirrel1 commented 1 week ago

  1. builder placement UI for players is still 2x2 so it would only affect buildings spawned via Lua.

    1. high resolution yardmaps (defined per 1x1 square, not 2x2) already exist. I assume (but haven't checked) that if you tag a 1x1 square as exit-only this way it would tag the entire containing 2x2 tile as exit-only. The reason I suggested that option is that I assume things could break if you used a 2x2 exitmap with 1x1 alignment, and I wouldn't want broken exitmaps to be an obstacle when working with alignment in the future. I generally want exit-only to be as un-intrusive as possible because I think the feature is of barely any use, for reasons I outlined in Exit-only yardmap types #453 (it doesn't solve the problems @WatchTheFort thinks it will solve). As long as it's cheap it's fine though, and I'm happy with 61d9152.

    2. which other parts of engine enforce alignment for Lua-spawned buildings?

Point 2 is a very good one. If yardmaps can be individually set to high res regardless, then the alignment effort is insufficient. It makes sense that exit-only tiling has to be at 1x1 resolution. I agree that it will be too disruptive to trying and force 2x2 size and alignment.