mcrfpy.Vector - support more convenience #109

New Issue

john · 2025-07-11T15:36:08Z

john commented

2025-07-11 15:36:08 +00:00

Some refactoring caused mcrfpy functions to return mcrfpy.Vector objects; this broke a lot of Crypt of Sokoban, which was relying on tuples being returned. Instantiating vectors shouldn't be required to do these convenient tasks:

vector.int - return an integer vector (floor) - should compare with int tuples for convenience; much better than mcrfpy.Vector(int(vector.x), int(vector.y))

this is the sf::vector2f vs sf::vector2i problem; can we create a lightweight solution that permits

vector[0], vector[1] - indexes for .x, .y

vector == (5, 6) - tuple value comparison

do (0, 0) or (0.0f, 0.0f) compare as falsey?

Some refactoring caused `mcrfpy` functions to return `mcrfpy.Vector` objects; this broke a lot of Crypt of Sokoban, which was relying on tuples being returned. Instantiating vectors shouldn't be required to do these convenient tasks: `vector.int` - return an integer vector (floor) - should compare with int tuples for convenience; much better than `mcrfpy.Vector(int(vector.x), int(vector.y))` - this is the `sf::vector2f` vs `sf::vector2i` problem; can we create a lightweight solution that permits `vector[0]`, `vector[1]` - indexes for `.x`, `.y` `vector == (5, 6)` - tuple value comparison do `(0, 0)` or `(0.0f, 0.0f)` compare as falsey?

john added the

Minor Feature

label 2025-07-11 17:18:23 +00:00

john referenced this issue

2025-07-12 19:58:59 +00:00

Generate perfectly consistent and complete Python interface #126

john referenced this issue from a commit

2025-07-14 05:39:08 +00:00

Update ROADMAP with GitHub issue numbers (#111-#125)

john referenced this issue from a commit

2025-07-16 01:42:02 +00:00

Squashed commit of the following: [alpha_presentable]