PaulicStudios
commented
1 week ago Soo, our goal for the library was never to really create a completely handholdey experience. Our goal is it to make it really easy to start and have a working bot (that's why the ft_distance function exists). On the other side we want to make it exponentially more difficult to not hit a skill ceiling so that even the best have always something to work on.
That the ft_create functions does not instantly return a pointer comes down to the architecture of how the server and client communicate. First the client receives a json with the complete state of the game. The connection library parses this json and fills all the array, etc. After that the ft_loop function from the bot gets called. There is no communication with the server. So all it's doing when you call ft_create, ft_attack and ft_travel is just append this action to an array that than gets send all at once to the server after ft_loop finished. Then the server tries to execute all these actions. So there is sadly no easy way other than to restructure and rewrite the whole architecture of the game to get a pointer and ID back in the loop.
I hope this gives you a better perspective on these decisions.
Should the focus be providing players with the fewest possible functions & then they have to build themselves a little lib, or to have them go right into strategizing? Because stuff like ft_distance exists (handholdey) but creating new units is super annoying because you don't get passed back the unit. I understand this is because you need to request a new unit from the server, which takes some time, longer than you can halt the function execution for. Can you reserve an id instead, and add an initialized boolean into t_obj? That way, we already have a reference to the new t_obj, even though we can't use it just yet. My larger point being, this library sometimes feels very handholdey and sometimes makes you do a lot of work to work around the limitations of the library to achieve simple things. Either way is fine, but i think being handholdey would be better as than you can fully focus on strategy. For another example of something really complicated which in my eyes wouldn't have had to be, please reference https://github.com/42core-team/public-wiki/issues/4.
Full Feedback -> https://github.com/42core-team/connection/issues/63