Bunny83, on 29 April 2012 - 01:58 AM, said:
Well, i guess almost every real coder has already done this in a similar way (including myself)
/>
I figured as much - I was just looking for ideas on how I could improve and expand it.
Bunny83, on 29 April 2012 - 01:58 AM, said:
I don't really play MP. I just mess around in SP. However it looks quite solid, but i would hook all native move functions so you can still use the "go" program and others. You can use rawset to overwrite the functions with your own, but don't forget to backup the native ones
/>
Cool! I had no idea you could do that. Lua seems rather closed-minded when it comes to function overloading so I hadn't really considered the possibility. That would make daughter applications much less annoying to write.
Bunny83, on 29 April 2012 - 01:58 AM, said:
Also i just like to add that most game engines have this axis setup (at least all pure 3D engines). It's derived from the usual view direction which is along the ground. An unaltered transformation matrix (identity) will make you look along the z-axis since x and y belong to the screen coordinates. Depending on the mathematical system used (left or right handed) the z axis might be inverted. OpenGL uses usually the mathematically correct right-handed system, while DirectX usually uses a left-handed system, but both consider y as up and x as right.
Interesting! The only background I have in this sort of coding is in army simulations which are decidedly not 3D. My approach in mapping turtle coordinates was purely from a top-down perspective, where f=2 is north, f=0 is south, so x increases to the east, and y increases to the south the same way screen coordinates often do. Then Z as depth is sort of an abstract 'state' rather than position. That made it really easy to write my listener app because it just takes into account screen size to create a scale multiplier and then applies that to x and y with relation to their min/max reported state to display my turtle on a screen that can 'infinitely' scale to display turtle movement in relation to its home point, mining point and dropoff point. Unfortunately because i'm scaling the x and y axis independently, the ratio gets skewed, and I need to fix that. It's also severely limited by the maximum range of rednet. I've been trying to come up with a message rebroadcasting system that would allow me to monitor from farther away, but i hit limitations with textutils.unserialize with nested tables and haven't gone back to re-think it.