novakasa / brickrail Goto Github PK

this makes it possible to have blocks that are too short for some trains, when we set both can_stop and can_flip to false, so the train only ever passes. Should also be useful for gradient blocks.

right now the port gets set to none, but the controller field not, which makes it confusing why you can't select a port anymore. Switching controller to none and back again makes port selectable again.

e.g if blocks are right next to each other, if a switch follows a block directly, the edge that handles turning the train around

should be a pretty good fit and make it all much more readable

settings should be stored in user folder

probably use json again

also that's where layouts should be stored by default?

if track connecting to block is deleted, you currently can't connect it again because it doesn't allow new connections (to prevent a switch being created). Should probably check for that case so you can connect the block again

this is probably because I used TRACK_ARROW track type for switch rendering somehow but it shouldn't be needed anymore

in the ro-layout-umkehren if we set a one-way track where it makes sense, sometimes the route will ignore it

limitation to how shader is set up right now. need to distinguish the state properly in the different shape passes in fragment shader

this messes up sensor logic and stuff, so don't allow setting new route wile train isn't fully in a block

we don't really need control over which end of the block the train stays at anymore, flipping the heading at the end will be very short since the train only needs to go to the other end of the last marker it detected

for example if track belonging to layout_block is deleted

layer view mode that shows the separate layers next to each other instead of just showing the active layer

for this we need a "bounding box" for our layout.
should probably not allow layout editing in this view, as extending the bounding box dynamically might introduce a lot of headache
should the user be able to edit the positions of each layers? or should it be a grid pattern governed by the bounding box?
if the user can edit the positions, we should make only the tracks render,

Remove the buttons in layout section inspector for collecting a segment etc

Clean up UX regarding mixed usage of manual and automatic controls

Probably need to have some hard switch that won't allow manual controls of trains and switches when they are currently used automatically.
Also improve UX to ensure the real trains are in correct position when auto mode is engaged.

Should have a built-in way to flash pybricks onto a hub. With this we can give it a unique name, and already decide there what type of device it will be (train vs layout controller) and store the correct mpy program on it (future). The name will be stored with the layout.

Can also add a hub by its unique name, but it will only connect to a hub that has this name.

Should also add a button to add a device by connecting to a pybricks hub.

Add a button to connect all devices

This is probably because the state is not well defined at the border. Maybe state should be applied close to a given shape? Maybe we can "anti-alias" the state itself somehow?

something something next default turn is not defined for various functions in route planning and virtual train placement

should put the stop intention at the current leg and then set the route to null

probably no confirmation from ble switch

this is because it's next turn is decided when the "in" signal is triggered, so even when the switch changes position on a new route, the train is already committed to it's turn

when deleting block and creating shorter block on same segment again, error regarding sensor occurs. need to investigate further

a leg should have a check_greedy() func that returns True if the greedy flag is set in the target block or if it is a flip leg and the next leg exists.

We check for this func to make sure we lock this and the next leg at the same time, making sure that the train doesn't have to wait after this leg.

This helps with not executing a flip leg if the train can't continue after that anyway or with blocks that are not supposed to be stopped at but serve the purpose of freeing up previous blocks while the train is moving.

to make it easier to customize the colors. Research ways to generate a bunch of good looking colors based on a simple palette

To do this we could have the previous graph twice (one for each orientation of the train relative to its heading direction). This way path finding can find a path so that the train ends up facing the desired direction.
This facing direction flips each time the train heading is reversed (edge to the other graph)

need a signal that notifies the train that the intention of the current leg changed while the train had already reacted to the intention (after "enter" key)
Then the train will request a new behavior from the route, and execute it.
The route also needs to lock the next leg if the new intention == "pass".

This is probably required for multiple ble trains.

This is because when the controller is removed we try to select the current controller again in the new option list, but it doesn't exist anymore.

Probably should fix it by reacting already to the controller "removing" signal rather than controllers_changed signal. Probably use the same approach for trains as well where I applied a band aid fix earlier.

Have a class for an editor action that can sequentially store function calls and their respective undo functions (like in godot).

blocks are wiped first, when tracks are disconnected the state update needs to get the block references. superficial fix: change order of deleting tracks/blocks (tracks first).
But need to solve this more sustainably by removing any references to blocks once a block is deleted

right now the compositional relationship between Track and DirectedTrack is ambiguous. DirectedTrack has a track reference to check for connected DirectedTracks.
Connections should be refactored into DirectedTrack so no reference to Track is needed.

on the low level multiple layout instances and on a higher level just have "portals" between them. That would make it possible to introduce "portals" that don't necessarily correspond to the same coordinates.

or on a low level just have different layers assigned to each track and make it possible to filter the view. This would make it easy to have bridges on the same view. This would be harder to implement and might not be as flexible. This could be implemented on top of the previous paradigm as well.

probably happens when hovering on switch while deleting tracks which will also delete the switch. should probably connect a switch deletion signal to the track so the hover switch reference will be reset

this is because metadata entries are not deleted, and we iterate through metadata turns instead of connection turns

probably make some paths relative and have configurable python interpreter

this will be necessary for #39, since we want to communicate more complex instructions

this is already WIP, use single byte to tell type of data, and some kind of hash for the rpc function names, remove whitespace of repr before sending

in the layout that was added in e20219a the train doesn't take the shorter one by default. even when the longer one is blocked by crossings, it doesn't chose the other route.
This is because the edges of nodes are stored in dictionaries with keys corresponding to the targets. This means there will only be one edge collected.
This might be a low priority issue because if there are blocks on one of the routes, the problem doesn't occur (no same start and end nodes)

when connecting a hub, running a program or quitting the program (which waits for disconnects and stuff) we should have some kind of notification so that the user knows something is happening

most operations should have some timeout error

One should not be able to place blocks if it overlaps with existing block.
Also a block should probably not contain a switch.

generally loading layouts needs to be worked on quite a bit

need to handle hover_obj in layout_cell being reset if that object is deleted

on complex_layout_trains.brl, plan the train in block1 to arrive at the other logical block (without changing facing)

each node should be associated with a single directed_track.
Then a Segment should run from the first track after the previous node until including the next node.
A block is always associated with the last track on it's segment.

each hub should have a coroutine that cleanly stops hub programs and then disconnects the hub
one main cleanup coroutine manages the coroutines for each hub and at the end the ble server can be disconnected/killed

probably also happens with creating empty layout. need to properly invalidate currently selected layout section

Instead of just sending the next expected marker and the behavior, send the full list of markers until the next block, with markers tagged if they have a role in the block, and also send the expected behaviour (stop in block / pass the block)

That way, if something changes (can't pass anymore) we just have to send the new behavior and the train itself knows whether it should have slowed down by now and correct for it.

All other solutions are unreliable since we don't know for sure if the train already passed a specific marker or not.

highlight all cells used in the bresenham line algorithm in drag select mode

this is because drawing_last_track reference is not set to null when track is deleted

this is an issue because virtual train sets most mouse click and release events as handled. need to devise something smarter for that