+- Hazeron Forums (https://hazeron.com/mybb)
+-- Forum: Shores of Hazeron (https://hazeron.com/mybb/forumdisplay.php?fid=1)
+--- Forum: Bug Reports (https://hazeron.com/mybb/forumdisplay.php?fid=17)
+---- Forum: Closed Bug Reports (https://hazeron.com/mybb/forumdisplay.php?fid=18)
+---- Thread: QOL: Hashcheck on the blueprints. (/showthread.php?tid=2429)
QOL: Hashcheck on the blueprints. - se5a - 09-03-2020
To save us downloading ~17mb of blueprints all the time, implement a hash check on them and only download blueprints that are not locally cashed/don't match the hash check.
This would be trivial to implement and likely save a fair amount of bandwidth.
RE: QOL: Hashcheck on the blueprints. - Mal - 09-04-2020
Agreed, but shouldn't these kinds of suggestions go in Arena of Ideas ? Don't want to actual bug reports to get buried now. : )
RE: QOL: Hashcheck on the blueprints. - AnrDaemon - 09-05-2020
This looks like a genuine bug/oversight.
RE: QOL: Hashcheck on the blueprints. - Celarious - 09-05-2020
This seems to happen every time you open the building blueprint exchange, even if you don't relog, so you keep downloading 18MB of designs. It's really inconvenient
RE: QOL: Hashcheck on the blueprints. - Raymoo - 09-17-2020
I don't think it is "trivial to implement", he would need to implement the mechanisms for sending the hash listing and storing them on the server and client. Also might need a add a way to request individual blueprint entries, which might not exist yet since currently everything is downloaded at once. And to be efficient you would want to be able to do a batch request for multiple entries so that SoH doesn't have to make many individual requests.
IMO none of that is hard, but it's also not "trivial". I think developers use that word too loosely and it should be reserved for cases where a change actually requires only minimal dev time.
RE: QOL: Hashcheck on the blueprints. - Celarious - 09-17-2020
(09-17-2020, 09:27 PM)Raymoo Wrote: I don't think it is "trivial to implement", he would need to implement the mechanisms for sending the hash listing and storing them on the server and client. Also might need a add a way to request individual blueprint entries, which might not exist yet since currently everything is downloaded at once. And to be efficient you would want to be able to do a batch request for multiple entries so that SoH doesn't have to make many individual requests.
IMO none of that is hard, but it's also not "trivial". I think developers use that word too loosely and it should be reserved for cases where a change actually requires only minimal dev time.
But he's already done this for the launcher and client files - so it's just a case of modifying the existing code for blueprints. On top of that, there's no need to worry about efficiency with multiple entries when every player has to currently redownload 19MB of designs on every login, and every time they open either exchange. Anything is more efficient than that by comparison
RE: QOL: Hashcheck on the blueprints. - Raymoo - 09-18-2020
Quote:But he's already done this for the launcher and client files - so it's just a case of modifying the existing code for blueprints.
Do you know the how the game is programmed so that you can make claims about the reusability of the current code, and how long it would take to adapt it? The launcher could just be getting some set of files configured statically on the server, which is a little bit different from arbitrary new files being added by players during gameplay (assuming they are stored on the server as separate files).
Quote:Anything is more efficient than that by comparison
I think this is true as long as "anything" excludes using the mechanism for partial updates for downloading the entire library. If there are several new designs, you have a good download speed, and you have a high latency to the server, though, it's possible an individual update might take longer than downloading the full update currently does, because the overhead of making all the requests might be larger than the download time saved. For example, a european with 100Mb/s download speed and 200ms ping would download the entire library in less than two seconds, but just the overhead from making requests to download 10 new ship designs would take up two seconds. In the common case this won't happen, and this cost gets spread out anyway so that the total amount of time spent downloading across all design listing updates will almost definitely be smaller. I'm not saying that he needs to implement batch requests to make caching designs an improvement, but it's needed to guarantee that it's a straight improvement always with no tradeoffs. And anyway the code changes required may not be trivial even without this feature.
RE: QOL: Hashcheck on the blueprints. - Celarious - 09-18-2020
Quote:Do you know the how the game is programmed so that you can make claims about the reusability of the current code, and how long it would take to adapt it? The launcher could just be getting some set of files configured statically on the server, which is a little bit different from arbitrary new files being added by players during gameplay (assuming they are stored on the server as separate files).
No, and neither do you. For all we know, how "hard" it could be to implement for Haxus depends entirely upon what already exists for such on the client and server. It could literally be a case of it already being implemented, and he forgot a bracket somewhere, or it could be almost impossible to adapt due to how the exchanges are setup.
Quote:I think this is true as long as "anything" excludes using the mechanism for partial updates for downloading the entire library. If there are several new designs, you have a good download speed, and you have a high latency to the server, though, it's possible an individual update might take longer than downloading the full update currently does, because the overhead of making all the requests might be larger than the download time saved. For example, a european with 100Mb/s download speed and 200ms ping would download the entire library in less than two seconds, but just the overhead from making requests to download 10 new ship designs would take up two seconds. In the common case this won't happen, and this cost gets spread out anyway so that the total amount of time spent downloading across all design listing updates will almost definitely be smaller. I'm not saying that he needs to implement batch requests to make caching designs an improvement, but it's needed to guarantee that it's a straight improvement always with no tradeoffs. And anyway the code changes required may not be trivial even without this feature.
Sure, but consider it's not only the user's download speed which affects the timing on this. The bandwidth available from the server-side would also matter, which already is fairly low and lowers even further during periods of high player count or just multiple people refreshing the libraries at once. I'm also speaking from experience on this with being in the UK and having a 200 down package. The entire library takes about 10 seconds to download currently. Consider also that your example of 10 new ships may not be entirely relevant, as unlike building designs, the average player wouldn't be refreshing the ship exchange every time they login, due to needing to store designs to local gear for manufacture. For buildings, at most, I've observed maybe 2 new buildings get added over the course of a week, so even given the 200ms latency in your example, you'd only have 400ms of download time per week. That's minutes of time saved compared to now.
RE: QOL: Hashcheck on the blueprints. - Raymoo - 09-18-2020
Quote:No, and neither do you. For all we know, how "hard" it could be to implement for Haxus depends entirely upon what already exists for such on the client and server. It could literally be a case of it already being implemented, and he forgot a bracket somewhere, or it could be almost impossible to adapt due to how the exchanges are setup.Yes, I know that I don't know. It may be trivial to implement on his end. My point is just that we shouldn't assert that it would be trivial to implement this in Shores of Hazeron, because we don't know. I wasn't trying to assert that it wouldn't be trivial, just provide a plausible scenario where it wouldn't be, so that I'm not just introducing uncertainty with no basis.