Skip to content

capabilities #24

Open
Open

Description

@AEnterprise

There are alot of interfaces here ment for other mods to implement for compatibility. It would probably be best to convert most of them to capabilities

Activity

  1. asiekierka commented on Jun 3, 2017

    @asiekierka
    Member

    Isn't most of that work done, though? The tile and MJ interfaces are all capabilities, and ItemStack capabilities are wonky to say the least.

  2. AEnterprise commented on Jun 3, 2017

    @AEnterprise
    MemberAuthor

    It's mainly for itemstacks i mean yes, IToolWrench for example and such, the laser target interface and such could probably also be capabilities

  3. afdw commented on Jun 3, 2017

    @afdw
    Member

    @AEnterprise The problem of laser target (as you explained) is that there is also interface which block of this tile should implement.

  4. AEnterprise commented on Jun 3, 2017

    @AEnterprise
    MemberAuthor

    yes there is also the block interface but i don't think we really need it. The point of the interface on the block is for performance but if we have the lasers check the target area at one block per tick and that only every few seconds i don't think it'll be an issue

  5. asiekierka commented on Jun 3, 2017

    @asiekierka
    Member

    @AEnterprise Lasers are supposed to be spammed en masse. One laser won't, but a few hundred lasers times a few dozen users times a few hundred blocks per laser will add up really, really quickly.

  6. AEnterprise commented on Jun 3, 2017

    @AEnterprise
    MemberAuthor

    what if we add a cache? a global cache to see if a block is a target for a laser, if a laser asks a position that is not in the cache we add it, if something retreives from the cache we check if the TE is still valid, if it isn't or it's a position that was invalid but has not been checked in the past 10s or so we recheck

  7. asiekierka commented on Jun 3, 2017

    @asiekierka
    Member

    @AEnterprise Don't cache the TEs, that's very wasteful... use a Property (like robots do) to store whether or not a block is a laser target, then it's just querying booleans (even faster!) and can be done in a separate thread (yayyyyy!)

  8. AlexIIL commented on Jun 3, 2017

    @AlexIIL
    Member

    I'll worry about caching optimisations later... for now it works.

    Currently I've changed lasers to need a line of sight, and only look in a pyramid forwards, but I might have to introduce a separate way of spamming lasers...

  9. asiekierka commented on Jun 3, 2017

    @asiekierka
    Member

    Currently I've changed lasers to need a line of sight,

    YES

    and only look in a pyramid forwards,

    NOOOOOOOO

    but I might have to introduce a separate way of spamming lasers...

    Just don't make it too laggy.

  10. AlexIIL commented on Jun 3, 2017

    @AlexIIL
    Member

    NOOOOOOOO

    Its a of a strict pyramid at the moment, I'll push it out a bit more around the edges. Unless you really want lasers to be able to "bend backwards"? :P

  11. asiekierka commented on Jun 3, 2017

    @asiekierka
    Member

    @AlexIIL No, just have a nice 90 degree FoV like they used to?

  12. AlexIIL commented on Jun 3, 2017

    @AlexIIL
    Member

    Lasers might have been a little buggy earlier on in 8.0.x and had an FoV of 180, so I was comparing it to that.

    A 90 degree FoV would probably be fine.

  13. afdw commented on Jun 3, 2017

    @afdw
    Member

    It's already 90° FoV:

  14. asiekierka commented on Jun 3, 2017

    @asiekierka
    Member

    Oh, no, I was thinking of 180-degree FoV then. Like old BC lasers, anyway.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions