[guru]

I am looking at paths currently and have noticed some things that kinda suck for developers.

• Brehesman path cannot be extended as it is final, what is the point in it being final it could be useful to extend this path to do extra stuff while pathing.
• The .step() method should respond something other than true/false, its current form does not give enough information to us a developer.
  • .step() should return an ENUM of STEPPED/FAILED/IDLE
  • I assume the enum is self explanatory.

Thanks! .

@Cloud @Party @SlashnHax

 

[savior]

The .step() method should respond something other than true/false, its current form does not give enough information to us a developer.

• .step() should return an ENUM of STEPPED/FAILED/IDLE
• I assume the enum is self explanatory.

Been preaching this for a while now

 

[wet rag]

Been preaching this for a while now

2/5 prime team members, so far.

We're going to need a full majority in order for this API update to happen.

 

[cloud]

I am looking at paths currently and have noticed some things that kinda suck for developers.

• Brehesman path cannot be extended as it is final, what is the point in it being final it could be useful to extend this path to do extra stuff while pathing.
• The .step() method should respond something other than true/false, its current form does not give enough information to us a developer.
  • .step() should return an ENUM of STEPPED/FAILED/IDLE
  • I assume the enum is self explanatory.

Thanks! .

@Cloud @Party @SlashnHax

1. If it wasn't final and you were able to extend it, what exactly would you change? It's literally a straight path and all CoordinatePath's use the same logic to determine when to step.
2. I agree that it would be useful, but I can't simply make it return an enum value instead of a boolean. It would break compatibility with almost every bot on the store.

 

[guru]

1. If it wasn't final and you were able to extend it, what exactly would you change? It's literally a straight path and all CoordinatePath's use the same logic to determine when to step.
2. I agree that it would be useful, but I can't simply make it return an enum value instead of a boolean. It would break compatibility with almost every bot on the store.

Admittedly I cannot do much extending it but who knows what people want to do.

As for it breaking every bot on the store, that leaves one additional choice. Add getLastAction() which is the result of the last call to step() as a enum. That would not break compatability then .

 

[savior]

1. If it wasn't final and you were able to extend it, what exactly would you change? It's literally a straight path and all CoordinatePath's use the same logic to determine when to step.
2. I agree that it would be useful, but I can't simply make it return an enum value instead of a boolean. It would break compatibility with almost every bot on the store.

How about making a new method, and letting the existing step() method call it, returning true or false based on the new mathod's result?

 

[cloud]

Admittedly I cannot do much extending it but who knows what people want to do.

As for it breaking every bot on the store, that leaves one additional choice. Add getLastAction() which is the result of the last call to step() as a enum. That would not break compatability then .

True, but that would be sub-optimal.

How about making a new method, and letting the existing step() method call it, returning true or false based on the new mathod's result?

Would confuse authors.

 

[savior]

True, but that would be sub-optimal.


Would confuse authors.

Why? You are basically just adding one new method which authors can use. What exactly the existing step() method does is hidden anyway.

 

[cloud]

Why? You are basically just adding one new method which authors can use. What exactly the existing step() method does is hidden anyway.

Why is regards to which statement?

 

[savior]

Why is regards to which statement?

The confusation of bot authors.
The existing step() method would not change at all (only internally)

 

[cloud]

The problem is that the new method would either have to be called something different than step or it would have to accept different method arguments. Otherwise there would be a descriptor collision with the step methods that return booleans.
@Savior

 

[savior]

The problem is that the new method would either have to be called something different than step or it would have to accept different method arguments. Otherwise there would be a descriptor collision with the step methods that return booleans.
@Savior

Yeah I know that, I just didn't come up with a good name for a new method yet.

 

[guru]

Yeah I know that, I just didn't come up with a good name for a new method yet.

.stride()

 

[savior]

.stride()

It shouldn't just be any synonym for "step" tbh, this would confuse the developers. It should be clear that it basically does the same thing as step(), just with a more detailed return value range.

 

[aria]

How about .run()?

goddamn that would be a terrible idea

 

[guru]

The problem is that the new method would either have to be called something different than step or it would have to accept different method arguments. Otherwise there would be a descriptor collision with the step methods that return booleans.
@Savior

I feel like newStep() or something like that would suffice or even just name it stepWithInfo(). Too be honest the name doesn't matter too much what matters is that this method is added, it adds a huge amount of control authors can have between steps aswell as tons of useful debug information.

Additionally naming it something like "run()" isn't too bad, because when eventually you come to remove step() it will be seemless integration rather than having yet another change to make whatever its named too to something valid.

We have compiler messages for a reason, you must be able to specify a method to WARN a user rather than to completely block them (Deprecated).
 
Would really like to see this happen @Cloud. Would add much more flexibility compared to the current pathing.