Hi Ben.
This is a really good point. I'm tempted to rewrite the connection logic this way:
- a main configuration file that define connection types, main type and coupling (vector, rail or point)
- files for every part where connection aren't autodetected
- no special handling, but only one-to-one coupling
This allows to add new connection pairs (connector and receiver) only adding a row in main file.
I didn't know. Awesome, it will be really useful, thank you!
Ciao!
Mario
Ben Wrote:I understand. One of my design goals for Bricksmith is to avoid having any knowledge of the -actual- connection types in the actual implementation; I only want to code their 'classes' (e.g. rail, vector, point). That way we won't need code mods and a new app to extend the connectivity data.
This is a really good point. I'm tempted to rewrite the connection logic this way:
- a main configuration file that define connection types, main type and coupling (vector, rail or point)
- files for every part where connection aren't autodetected
- no special handling, but only one-to-one coupling
This allows to add new connection pairs (connector and receiver) only adding a row in main file.
Ben Wrote:For spatial sorting, I suggest my favorite pet spatial index: the R-Tree. :-)
http://en.wikipedia.org/wiki/R-tree
I didn't know. Awesome, it will be really useful, thank you!
Ciao!
Mario