Open ByAlexius opened 5 months ago
we appreciate your proposal, can you please somewhat refactor eject
functions part? it would be impossible to differentiate between seat, player or ped ids
we appreciate your proposal, can you please somewhat refactor
eject
functions part? it would be impossible to differentiate between seat, player or ped ids
I have removed the function's that are impossible to implement and have added a ejectAll() method. Can you take a look again?
With kind regards Alexander
we appreciate your proposal, can you please somewhat refactor
eject
functions part? it would be impossible to differentiate between seat, player or ped idsI have removed the function's that are impossible to implement and have added a ejectAll() method. Can you take a look again?
With kind regards Alexander
it is possible to differentiate different types of arguments, i.e: eject(playerObject)
would be doable along with eject(int seatId)
we appreciate your proposal, can you please somewhat refactor
eject
functions part? it would be impossible to differentiate between seat, player or ped idsI have removed the function's that are impossible to implement and have added a ejectAll() method. Can you take a look again? With kind regards Alexander
it is possible to differentiate different types of arguments, i.e:
eject(playerObject)
would be doable along witheject(int seatId)
Ok, I added back eject(Player player)
, if i understood correctly this should work.
Are there any other problems or just this?
we appreciate your proposal, can you please somewhat refactor
eject
functions part? it would be impossible to differentiate between seat, player or ped idsI have removed the function's that are impossible to implement and have added a ejectAll() method. Can you take a look again? With kind regards Alexander
it is possible to differentiate different types of arguments, i.e:
eject(playerObject)
would be doable along witheject(int seatId)
Ok, I added back
eject(Player player)
, if i understood correctly this should work. Are there any other problems or just this?
yeah, sorry if it was gibberish, but that was exactly what I meant, other functions looks good
Quick Addition:
getPosition();
and
getDimension();
Quick Addition:
getPosition();
andgetDimension();
i think that has every entity later
Quick Addition:
getPosition();
andgetDimension();
i think that has every entity later
Yeah, probably but writing something that is already planned is better then not writing it down. If you understand what i mean.
In my opinion, a lot of these should be a getter/setter instead of methods, because they don't require more than 1 argument. So instead of .getDimension()
, a .dim
or .dimension
getter would be better.
In my opinion, a lot of these should be a getter/setter instead of methods, because they don't require more than 1 argument. So instead of
.getDimension()
, a.dim
or.dimension
getter would be better.
Every method that has a get and a set that only accepts / returns one value, should be a property.
Since you are probably talking about javascript/typescript i can't say much since i have very limited experience using it, sorry.
The same can be applied to any language that supports getters and setters
I based my original code example of java, where i generally use get and set methods (generated by lombok) for variables if it is used outside it's own class, i generally use the variable directly only if the method is in the same class. But that is more like a coding convention I and my coworkers use
Nothing about the API here should be discussed in regards to Java because that is a dying language that will never be available in YAMP
Nothing about the API here should be discussed in regards to Java because that is a dying language that will never be available in YAMP
Yeah fair enough (I used it for the example code since my main program language for work is java and I also didn't want to write wrong c++ or javascript code).
And this code is still just a suggestion, it's still the yamp developers decisions how or if they want to implement this.
destroyEngine( | Sets the engine health to zero (completely damaged).
repairEngine() | Sets the engine health to 100 (or the maximum value).
disableEngine() | Disables the engine, preventing it from starting until enableEngine() is called.
enableEngine() | Enables the engine, allowing it to start again (counterpart to disableEngine()
to ->
setEngineHealth(health: number);
setEngineState(state: bool)
Changes:
removed:
destroyEngine()
repairEngine()
disableEngine()
enableEngine()
added:
setEngineHealth(int health)
setEngineState(boolean state)
Thanks @kyro95 for the suggestion :)
What is the scope of the api ?
Propose an api design A clear and concise description of what you want to happen.
I have think these additions would be great and help developers while programming with the Vehicle API. The code examples use Java variable types for parameters.
Note: While I primarily described setter methods, getters are also required. However, including them might make the list to long.
I will update this list if i think of more methods.
If you have improvement idea's, don't hesitate to add comments.
Thanks for reading, have a nice day :)