(10-09-2016, 05:47 AM)RaptorParkowsky Wrote: @krzys_h & @tomangelo : Ok, I can see now what you're talking. But still I have mixed feelings about this. No crashspheres for such a small objects I would also consider to technology/time limitation of development original Colobot. And that would be fixed in the future development. I think any kind of holograms or augmented reality isn't compatible technology element to the EPSITEC games design (even in BlupiMania or BuzzingCars there was no such a thing). This would fit to Colobot 2 instead. If those objects would be some kind of hologram, they could be rendered in a specific way, transparent a little bit or so. But they're not, they are rendering just like other objects in the game world.
And if they would be some kind of virtual markings, where would you store informations about them? SpaceShip's central computer, ExchangePosts? Or maybe SatCom? IMHO then they should be at least visible even on map and other places, but they're not. And why then I need to use radar to detect them just like other objects instead to just read a data about their locations and types from the colonization database? They are an object and have their own category... but they are not object. This is more complicated than it should be, especially if in Colobot's universe simplicity always was in the first place.
For me they're indeed an object. Some kind of silly plastic gadget that would you even give your dog as a toy, but with some special abilities like levitation with some sparkles while disappearing (just like other "magical" objects in EPSITEC games). They simply don't need this kind of explanation in this game's design and plot.
Even platforms from exercises have their own crashpheres, adding them for WayPoints would be even easier. Still, Epsitec didn't implemented it, so I'm still certain it's virtual object. Also there is no sacred rule that every hologram must be blue, half-transparent, with noise and such. For breaking it there is no penalty, no one will throw you into some hole of shame for making such thing in other way. Remember that it's game aimed for children, with it's own child-friendly design. Probably Epsitec stated that childs will be more for monocolor, big marker, instead of holographical one (that could be also harder to implement in original engine. Maybe they even wanted to make it like that, but again - engine limitations?), or flat texture on ground (that's also less visible than current ones).
Comparing to Blupi and BC - they aren't space exploring game. I didn't played them so much, but do they even have a searching for minerals and mining it theme?
Storing information about them - probably in similar way there are stored public class and functions.
About their abilities - what kind of weird plastic it is, that would deny basic physic laws, like gravitation, because someone touched them? With such kind of materials why does FlyingBots even need an engine, because it could fly itself? It just make no sense. I find it as some special effects aimed for kids, that runs their programs to drive through WayPoints and they're like "woah, it's flying, sparkling, blinking, moving, because I coded. I want moar."
And again, I find it as a virtual objects, that exists, but don't exist. Again it's simplicity for exercises mentioned above, where you simply need to radar closest one and go there, instead of searching in array and comparing every single point if it's closest to bot or not. Also it might be "under the hood", that radar function detect if someone passed WayPoint as argument and then instead of radaring it, simply browse array in search of closest point.