#546: O(1) path-finding check
-----------------------------+----------------------------------------------
Reporter: Per | Owner: Per
Type: enhancement | Status: assigned
Priority: major | Milestone: 2.3
Component: other | Version: svn/trunk
Keywords: path-finding AI | Operating_system: All/Non-Specific
Blockedby: | Blocking:
-----------------------------+----------------------------------------------
Comment(by Kreuvf):
Replying to [comment:5 Zarel]:
> Replying to [comment:4 Kreuvf]:
> > 1. Doing this would mean trusting untrustworthy data (the
precalculated information in the map file/disk cache). So we would have to
check that data for validity. This adds complexity: If there is no
algorithm for checking the validity which is faster than doing the actual
calculation, checking for validity will take more time than calculating
only.
>
> ...um, why is that data untrustworthy? We trust all the ''other'' data
in the map file; why not the precalculated data? Especially since the
precalculated data saves millions of microseconds.
Trusting the other data is another topic and AFAIK there is at least some
validity checking somewhere (why else would I get an error message for
duplicate stuff?). Every data that comes from the outside is per se
untrustworthy. How can we be sure that the map and all the data have been
created by good users? And even if it was created by good users who
guarantees that the data has not been changed by something different? And
please stop counting microseconds, this does not change anything. If it's
a microsecond wasted or an hour wasted, sooner or later it'll sum up.
By the way: There are more trivial reasons for not saving stuff to
disk/map files and therefore not trusting what's in those files: We
changed internal formats often enough in the past (save-games, anyone?)
and as far as I understand it save-game format is a permanent headache.
Something very similar could happen to map-files, if you misuse them to
store unnecessary (=untrustworthy) data in them.
>
> > 2. Even the data saved to disk cannot be trusted and therefore must
be checked.
>
> ...why not? At most, we do a checksum or something, which is much faster
than ''several million microseconds''.
See above for the reason. Actually, you'd have to give reasons for
trustworthiness, as everything is untrustworthy by default. And if we did
a checksum we would just compare checksums? Checksums of what? And why
trust the checksum in that file ("outside data")?
>
> > 3. Saving additional data in map-files will lead to increased map
sizes. Larger map files in turn will need more time when distributing,
especially when distributing via WZ's built-in capabilities.
>
> It's negligible. Plus, I'm sure the data computes ''much'' slower than
than it transfers.
It's not negligible. (Back your claims or I'll just claim the opposite
~.~)
>
> > 4. Parsing map files will become more complex when "flooding
information" is included. This makes the corresponding code more error-
prone.
>
> ...oh, come on, that's ''really'' negligible. We do a lot more error-
prone changes for a lot less speed benefit all the time.
So at least you agree that it makes the corresponding code more error-
prone. And the speed benefit? There is enough benefit in having the
"flooding information" in the first place. If I understood everything
correctly, it'll speed up path-finding.
My conclusion still is: Not only there is no need for storing that
information _permanently_, doing so will give rise to further problems.
--
Ticket URL: <http://developer.wz2100.net/ticket/546#comment:7>
Warzone 2100 Trac <http://developer.wz2100.net/>
The Warzone 2100 Resurrection Project
_______________________________________________
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
