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

Update StaticBuilding methods to public #72

Open
MrTate opened this issue Sep 17, 2021 · 6 comments
Open

Update StaticBuilding methods to public #72

MrTate opened this issue Sep 17, 2021 · 6 comments
Labels
enhancement New feature or request

Comments

@MrTate
Copy link

MrTate commented Sep 17, 2021

https://github.com/JavaBWAPI/JBWAPI/blob/develop/src/main/java/bwem/StaticBuilding.java#L26

https://github.com/JavaBWAPI/JBWAPI/blob/develop/src/main/java/bwem/BWMap.java#L161

These are needed for pulling in the latest version (1.15) of BWEB into JBWEB

@JasperGeurtz
Copy link
Collaborator

JasperGeurtz commented Oct 29, 2021

Feel free to make a PR! Otherwise I will look into it when I have time

@JasperGeurtz
Copy link
Collaborator

After going through the code, can you not use: BWMap::onUnitDestroyed ? This method will call the respective onStaticBuildingDestroyed function:

onStaticBuildingDestroyed(u);

Although the reference BWEM-community implementation has them public and doesnt have this onUnitDestroyed function.
https://github.com/N00byEdge/BWEM-community/blob/9a63141f301f7830e9e09a2bae95c304fcc03cc5/BWEM/include/map.h#L162

I can make both of them public too, but as onUnitDestroy is already there and doing what it should do, maybe it's not needed. Any opinions @MrTate @dgant @Bytekeeper ?

Does the Constructor of StaticBuilding need to be public? Currently onStaticBuildingDestroyed takes a Unit and searches for the corresponding static building internally. If you could share how you'd like to use these changes, Ill make them public, but until then I think it's better to keep them like this.

@dgant
Copy link
Contributor

dgant commented Dec 3, 2021

If BWEM-Community has it public, I vote to match. Not a strongly held opinion.

@Bytekeeper
Copy link
Collaborator

Bytekeeper commented Dec 4, 2021

I think we should either leave it private, or make onUnitDestroyed not handle buildings. I'd vote for keeping it as is.

@JasperGeurtz JasperGeurtz added the enhancement New feature or request label Dec 4, 2021
@MrTate
Copy link
Author

MrTate commented Dec 5, 2021

I agree with Dan. If it's public in BWAPI we should maintain that across to JBWAPI

@JasperGeurtz
Copy link
Collaborator

JasperGeurtz commented Dec 5, 2021

I agree with Dan. If it's public in BWAPI we should maintain that across to JBWAPI

Sorry if it was unclear, this is not from (J)BWAPI interface, but the BWEM interface.

The original porters of BWEM to Java decided to add a public method onUnitDestroyed which does onStaticBuildingDestroyed and onMineralDestroyed at the same time (this method does not exist in the reference BWEM-community implementation), making it easier for users of (java) BWEM

For your JBWEB implementation, you probably want to just call onUnitDestroyed(unit), and it will handle it for you as you expect.

There seem to be 4 solutions:

    1. keeping everything like it is right now
    1. removing onUnitDestroyed and making the other 2 methods public so the interface is the same as BWEM-community.
    1. making all 3 of them public
    1. @Bytekeeper 's second suggestion make onUnitDestroyed not handle buildings

(1) is backwards compatible (maybe some people are already using onUnitDestroyed ) ?
(2) makes the interface the same as how BWEM-community currently is
(3) is also backward compatible, but maybe makes the interface confusing, a new user could be confused by what the difference is between onUnitDestroyed an onMineralDestroyed and maybe assume that BWEM also keeps track of workers or something?
(4) would make onStaticBuildingDestroyed public and keep onUnitDestroyed as a proxy for onMineralDestroyed but potentially silently break some logic of existing bots using onUnitDestroyed, so then I prefer (2), so at least the bot doesnt compile anymore.

I want to release a v2.0 with @dgant 's async support and @Bytekeeper linux support in the near future so I'm not afraid to break some small function calls, especially not if it's about improving/fixing the API .

Personally I favor towards (1) or (2), with a slight tilt towards (1) , as onUnitDestroyed is a nice addition in my opinion, and can just be used for onStaticBuildingDestroyed

I think the problem for most of us is that we dont have a strong opinion on this 😄

@MrTate can you see if just using onUnitDestroyed fulfills your purpose?

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

4 participants