Re: [Freeciv-Dev] (PR#39798) cheat using goto to explore
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39798 No. I've already explained your error, and there are explicit references. I've proposed a solution. I just haven't had time to write the code to fix the several reports. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39798) cheat using goto to explore
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39798 [wsimpson - Sat Nov 17 15:47:54 2007]: As I reported, folks are trying to use goto to explore. That is, they *want* to cheat. I included specific references. Please read and think before pontificating. Okay, although you specifically said in effect, this is really a cheat. But since cheating this way is not possible, can we close this ticket? (resolved/not-a-bug) -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39798) cheat using goto to explore
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39798 [wsimpson - Sat Oct 27 09:22:54 2007]: I'm trying to understand the goto problem reports, and one common thread seems to be that folks are trying to use goto to explore. Then, they complain that it won't goto an unknown location (PR#15629), or the trireme sinks, or the unit doesn't handle dangerous paths (PR#39697), or the unit chooses suboptimal paths as they change during the goto (PR#13348), or problems flying across unknown territory, or whatever. In effect, this is really a cheat! They are trying to get the server to confirm information about places they don't know, or select good paths to places that are obscured by fog-of-war. No it's not. Client-side goto (which is what the user uses that shows the path to be taken) knows only what the client knows and this does not include anything more than what is shown. Unless there's a specific bug cheating is not possible; your words show you clearly don't understand how client-side goto works. What actually happens is that client-side goto assumes unknown tiles are generic, non-dangerous, base-move-level tiles. This means your triremes and airplanes will happily goto over them and sink or whatever. I propose that whenever the goto is destined to an unknown location, the cursor change to explore (or X or something) and the turns disappear. The explore action should have a direction, and a destination. Hiding the estimated number of turns in such situations is an option. But it's not a perfect fix as there are many instances where you want to do goto with ships or goto just one tile into the unknown and you really would want to see the number of turns. It could zig-zag for optimal exploration coverage (which it should be doing for AI units, anyway). Doing a goto into/through the unknown is not actually an explore. Zig-zag is an option (previous versions of goto/pf have tricked the search routine into taking diagonals) but again it's not a perfect solution as many times you will want to take the shortest/safest route possible. And of course you can always zig-zag yourself using waypoints. The server would have to select a new path every turn (which it should be doing for AI units, anyway). That is server goto. Quite the opposite of client goto. And yes that is what's used for AI units. Changing over from server to client goto was quite a step forward (only with client goto can the path to be taken be shown) and this isn't something that should be reverted. Also server goto is potentially buggy and tends to cheat. The orders list would be simplified, using the technique currently used for multi-part path selection. (What, you didn't know that the current code allows a goto, followed by a road, followed by another goto, etc? Seems overly complicated, and undocumented, but it's in there) Undocumented, yes. Incomplete, yes. But if you want more complex client goto (such as connect) that shows the path to be taken (highly desirable for road-building and one of the most oft-requested features before we implemented it) then this is the way it has to be done. It's also not overly complicated; the code was actually simplified to make orders work that way. -jason ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39798) cheat using goto to explore
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39798 [jdorje - Ven. Nov. 16 20:11:57 2007]: That is server goto. Quite the opposite of client goto. And yes that is what's used for AI units. Changing over from server to client goto was quite a step forward (only with client goto can the path to be taken be shown) and this isn't something that should be reverted. Also server goto is potentially buggy and tends to cheat. As I could see in the code, since 2.1, the client cannot use server goto anymore. Anyway, the goto order of an unit is not updated at the start of the new turn. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
[Freeciv-Dev] (PR#39798) cheat using goto to explore
URL: http://bugs.freeciv.org/Ticket/Display.html?id=39798 I'm trying to understand the goto problem reports, and one common thread seems to be that folks are trying to use goto to explore. Then, they complain that it won't goto an unknown location (PR#15629), or the trireme sinks, or the unit doesn't handle dangerous paths (PR#39697), or the unit chooses suboptimal paths as they change during the goto (PR#13348), or problems flying across unknown territory, or whatever. In effect, this is really a cheat! They are trying to get the server to confirm information about places they don't know, or select good paths to places that are obscured by fog-of-war. I propose that whenever the goto is destined to an unknown location, the cursor change to explore (or X or something) and the turns disappear. The explore action should have a direction, and a destination. It could zig-zag for optimal exploration coverage (which it should be doing for AI units, anyway). The server would have to select a new path every turn (which it should be doing for AI units, anyway). It would stop when the destination is confirmed unreachable (in that direction), or an unfriendly unit is encountered. The orders list would be simplified, using the technique currently used for multi-part path selection. (What, you didn't know that the current code allows a goto, followed by a road, followed by another goto, etc? Seems overly complicated, and undocumented, but it's in there) This is probably best done for 2.2, but it might be retrofitted to 2.1, replacing the problematic patches proposed in PR#20772. ___ Freeciv-dev mailing list Freeciv-dev@gna.org https://mail.gna.org/listinfo/freeciv-dev
