Closed eocron closed 7 years ago
There is no direct way of getting exact coordinates.
A robot may get its X and Z coordinates relative to a map (item)'s center using a navigation upgrade, at least up to the boundaries of the map (128x128 blocks by default, scalable up to 16x that).
Additionally, wireless network cards and access points provide a signal strength in blocks, which can be used to determine distances (with some noise from the hardness of blocks in the path of the signal). With four network cards/access points, any other wireless card/AP can have its position determined.
Lastly, with access to creative, (and being an operator if on a server), you may use a debug card to access your robot's position.
Well, this is bad cause it completely clutter the code and force users to make some bugged hacks =/ Is it hard to implement or is it done so for hardcore purpose? It will be useful if every block in system had the method such as getPosition() this will provide wide functionality to distinct different blocks or group them by sectors (making possible to do multiblock easy deployed systems) instead of typing a whole bunch of GUID's each particular time.
I'm not really a fan of the artificial limits placed on the navigation upgrade either. It's trivial for players to determine their absolute position (F3), so I don't see what the point is in making that so much more difficult for robots.
Because F3 is the debug screen used for debugging. You are not meant to use it for playing. Fortunately there are mods to turn it off.
Fortunately those mods are optional so elitists can't force them on others. Perhaps a config option?
That's what the debug card is for. Global positions are not something you will have in normal OC. You could always make a navigation upgrade with a big map at the centre of the world and use that. Or make a nav upgrade anywhere and program its centre's location into the robot. Or have the robot track its movement. There are many ways to do this.
I think that's rather heavy handed. I like the idea of having tiered components because it's immersive. F3 is a standard feature of Minecraft. It shouldn't require creative mode to get absolute position from a robot when it doesn't require creative mode to get it as a player.
vexatos tends to talk heavy handedly :)
This was an intentional design choice to only give relative coordinates data, with the option from setting a map-based origin.
Even if you use map as center you can't avoid main problem of fixing those map-binded coordinates each time you use them. For example, on the server where you can't possibly stand at this position. I mean, this will be almost always the first thing every programmer will do before using them, not counting overhead from using robot atop of charger with navigation card, this looks ridicilous, seriously =/
Best solution is to add getGlobalPosition() method to block components. This way programmer can place, for example, Turret and EntityDetector close to each other and make them work as multistructure porgrammaticaly without need for using hardcoded GUID's. This way it will be easy deployable even for none programmers: Ctrl+C, Insert, Run, and your turret is aimed at you. Or make some multiblock factory with single computer with single application which will determine this multistructure and will work according some factory alghorithm.
Keeping within the OC paradigm, what makes the most sense to me would be to have a "GPS card" as an upgrade to the "navigation card". That seems a whole lot less magical than the already existing internet card. If more realism is desired, they could be dependent upon being in range of one or more GPS transmitters to fill the thematic role of imitating GPS satellites/groundstations that exist in the real world.
Blocking the vanilla functionality of F3 (i.e. being able to use the numbers that basically all players are already familiar with in OC) just doesn't make sense to me as a default assumption.
Of course it's a deliberate design choice. We are questioning the wisdom of that choice.
GPS would imply there being a satellite or equivalent network in the Minecraft world; it would also remove the need for any custom GPS systems using things like wireless cards. Furthermore, nothing in the game except for the debug screen actually mentions coordinates at all. The centre of the universe is, if you ignore the programming and just go by game lore, not there; you do not even spawn on it, just somewhat near it. All the debug screen does is expose game-internal variables. They have nothing to do in the game itself.
Ground based GPS transmitters do exist in the real world and would be trivial to implement. Just return nil from getAbsolutePosition() if the computer isn't in range of one. (Or three if you want to be a stickler).
Does the real world internet exist in Minecraft? We have internet cards. Do chunks exist? We have chunkloaders.
This isn't really a realism issue, it's a standards issue. There is an existant and clearly understood standard in the form of the F3 menu, which like it or not, is a standard part of Minecraft (survival mode). By all means have an additional resource cost and/or config option to disable it. But blocking the functionality for people who consider F3 coordinates a standard and accepted part of (vanilla) Minecraft does not really make sense.
If I may suggest a compromise? Would it be a bad idea to offer a GPS loot disk? I don't currently have any code for this, never mind well-written code that I could upload to GitHub, but there are already loot disks for getting people started. It could include two programs; one that requests its own location, saves it, and broadcasts it for any device to listen to; the other program would be the receiver, taking the signals from the transmitter and returning either coordinates or an error (and potentially an accuracy value, if coordinates are obtained).
That would be an improvement, but I'm honestly just not seeing what the /point/ is in restricting this functionality.
Pros of a GPS type functionality: More straightforward Lower barrier of entry for new users Adherence to existing standards
Cons: ???
There is no existing standard. Right now there exists no computer mod using global coordinates in any way. And I don't recall there ever having been one.
F3 is vanilla functionality, and that information is freely available to all players by default. It's also used internally by the mod, is it not? I get that you personally don't like it, but just because I don't like that iOS runs on ObjectiveC doesn't mean that isn't the standard.
Players are going to want to be able to punch that information into their programs. This thread is already evidence of that. Why block such functionality?
Oh, trust me; if the OpenComputers devs say it doesn't fit the theme of the mod, or that it doesn't make sense, they won't change their minds. I'd appreciate a page of "These are reasons we will not add things", and examples of things like all-in-one/laptop computer blocks (a suggestion I recently made which was rejected). What I seem to have gathered is 1980's computers, don't hog too many resources from the host server, and allow access to all features of the computers while allowing realistic modularity. For all I know, such a page exists on the wiki, and I have missed it while browsing the majority of its other pages.
One of the first planned features.
Also, this issue elaborates on the question a bit.
The reasons are similar to why NBT data of items will not be exposed; it is game-internal data and should not be accessible; it ruins the game's immersion, just like the debug screen does. As I said, no computer mod I know of has ever exposed absolute world coordinates, and I think it should stay that way.
@NickNackGus: I totally get that it's their mod and their call. I just don't understand the reasoning behind making things needlessly difficult.
@Vexatos: NBT is not readily exposed to players to start with. Even if one rules out F3 specifically, a majority of modded players make use of JourneyMap or some other mapping plugin to keep track of locations in the gameworld. Absolute coordinates are widely used. "Other computer mods" may not expose them, but plenty of other mods do. I don't see how this is any more damaging to immersion than the internet card. Which is harder to imagine in Minecraft, a similar network of satellites as in the real world, or connecting to the actual real world internet transdimensionally? Of course the usefulness of pastebin and OPPM outweigh the holes in the fourth wall. That's precisely my point.
JourneyMap
That's the same as my argument with mods disabling the debug screen.
The internet card is there because it has to be there. The mod would be a lot less useful without an ability to easily share programs. A lack of exposure of absolute coordinate can be easily circumvented using software, and writing software to do things is the entire point of a computer mod.
Fair points. That's what I'll do, then.
Ok, if local coordinates around map is main course in navigation in OC, we should be able do deploy those upgrades not only inside robots, but in system blocks too. This will solve those problems and won,t destroy one of the main ideas even if some system block, for example EntityDetector in OpenSecurity, returns global coordinates, but not relative ones =/
I don't think the problem here is that we need a block / upgrade for this. the required information can be calculated by sending packets on wifi. IMO from that regard it's a lower barrier to entry as it provides many other useful functions.
You can find very functional results from https://github.com/OpenPrograms/ds84182-Programs/tree/master via (https://openprograms.github.io/)
In this solution, you need to establish and maintain a 'network' of GPS servers. You will also establish your own sense of 0,0,0 (in that you can set where ever you want, or establish it against the map's true origin) and the nodes can request coordinates to align.
So what's the problem here? Navigation and Location is hard, but I don't see building it into java/scala side is the wrong way forward. We do need to develop a more robust library for getting around. So I'd propose that we establish a openprograms repo to develop a standard library. Once it's matured a bit, we can talk about pulling it in as a loot disk or maybe push with openos
Given that this is unlikely to be implemented as part of the OC code, what are the chances of being able to implement an add-on mod for this? Would it even be possible to create a mod that, for example, gives all programmatically accessible OC blocks a readable coordinate?
Add-on's are completely up to their authors, OC won't do anything against someone adding over powered goo
Of course. However, I'm asking if the OC code itself is arranged such that an add-on mod would be able to manipulate OC data. How involved would it be to add additional data (such as block coordinates) to OC blocks?
This is starting to get off topic for this forum, at a high level the java system of course knows where everything is, you would end up creating a card or block component that exposes the data from java / scala to lua. How invloved is this? no clue I barely understand the way this is connected.
We don't plan to support this from the mod itself. the debug card is already available (a creative mode item) that gives you all this type of info - if you want to package the functionality of a global gps in an add-on, just look at how the debug card does it: https://github.com/payonel/OpenComputers/blob/master-MC1.7.10/src/main/scala/li/cil/oc/server/component/DebugCard.scala
I don't know anything else about the debug card myself [ i stay in the openos code base ] but I know that would be a good start.
Is there a way to know position of component block? For example place waypoint and use its position for configuration? Currently, I don't see a posibility to detect component global position and just hardcode it for each particular case. It is critical for systems what use navigation to not have its own positions in space. I have turrets which targets players and for it to navigate correctly I need to explicitly specify turret global position instead of placing blocks in some sequence.