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

capabilities #24

Open
AEnterprise opened this issue Jun 3, 2017 · 14 comments
Open

capabilities #24

AEnterprise opened this issue Jun 3, 2017 · 14 comments

Comments

@AEnterprise
Copy link
Member

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

@asiekierka
Copy link
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.

@AEnterprise
Copy link
Member Author

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

@afdw
Copy link
Member

afdw commented Jun 3, 2017

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

@AEnterprise
Copy link
Member Author

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

@asiekierka
Copy link
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.

@AEnterprise
Copy link
Member Author

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

@asiekierka
Copy link
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!)

@AlexIIL
Copy link
Member

AlexIIL commented Jun 3, 2017

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...

@asiekierka
Copy link
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.

@AlexIIL
Copy link
Member

AlexIIL commented Jun 3, 2017

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

@asiekierka
Copy link
Member

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

@AlexIIL
Copy link
Member

AlexIIL commented Jun 3, 2017

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.

@afdw
Copy link
Member

afdw commented Jun 3, 2017

It's already 90° FoV:

@asiekierka
Copy link
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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants