Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Specify bounds instead of radius #68

Open
crabctrl opened this issue Mar 17, 2020 · 3 comments
Open

Specify bounds instead of radius #68

crabctrl opened this issue Mar 17, 2020 · 3 comments
Labels
enhancement New feature or request

Comments

@crabctrl
Copy link

It would be handy to be able to specify the exact area of the ship in XYZ instead of just the radius, as this would allow you to fit oblong ships together or against docking ports much more nicely.

@crabctrl crabctrl changed the title Specifty bounds instead of radius Specify bounds instead of radius Mar 17, 2020
@BuckarooBanzay
Copy link
Member

BuckarooBanzay commented Mar 17, 2020

Hmm, i thought there was already an issue open about this... 😕

Yes, this would be nice, the ground-work is already there:

jumpdrive/move.lua

Lines 6 to 8 in a8bf7ad

-- moves the source to the target area
-- no protection- or overlap checking is done here
jumpdrive.move = function(source_pos1, source_pos2, target_pos1, target_pos2)

The api already supports this but the interface is just not there yet...

I wasn't sure if i would mutilatemodify the existing jumpdrive:engine node or create another one with the additional functionality but i guess multiple engines with various shapes would be the sane option here.

Optimally it would look like this:

  • jumpdrive:engine default engine, can jump an area with given radius
  • jumpdrive:engine_custom customized cubic jump-area configurable with 2 coordinates
  • jumpdrive:area_engine can be linked to an area, if the areas mod is available
  • ... others?

The linking with the jumdrive:backbone to a fleet should still be possible then (given there are no overlaps)

@S-S-X
Copy link
Member

S-S-X commented Jun 24, 2021

Linked issue with few comments about what could be done to make this work nicely, proposed solution requires breaking changes to public functions jumpdrive.execute_jump and jumpdrive.simulate_jump.
Goal for these changes is to make jumpdrive API more generic and allow a lot more use cases while still providing a lot of similar consistency checks and other validation stuff hidden behind API functions.

It is possible to keep backwards compatibility for those but probably not really required, any known mods actually using those 2 functions?

@BuckarooBanzay
Copy link
Member

It is possible to keep backwards compatibility for those but probably not really required, any known mods actually using those 2 functions?

I don't think they are used outside the mod, they were never "official" (and there is no documented api 😋)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants