   | |  | | ![]() I did say that the download should take place in the background. I highly doubt a single update would ever take a megabyte. I suppose there could be a low bandwidth option where it queries the server for an index of available information, but in most cases I doubt it would save bandwidth.
If each comment was the approximate size of a forum post, unless you're SL *cough*, that's typically not more than 1024 characters per post. With 50% compression rate (it's around that for text if I'm not mistaken), you can get 2048 characters in a single post for 1kb. 100 new comments would only be 100kb, which would be ~25 seconds on dialup.
Now if you want to include images, then that's a whole other story. It is an outright stupid idea, the very thought of including it in the guide (since I don't consider images to be part of the guide, but more of an optional supplement**) is I'll be nice terrible.
If you really want to save bandwidth, the background download can in theory be dropped to about 20-28 bytes per guide entry without compression (storage of location+entry# and possibly you could include size of text + size of extras for a couple bytes more). But the processing time on generating the index probably isn't worth it. You have to remember what needs to happen server-side as well as client-side.
From what you're saying, it sounds like for EVERY star (because I hope you don't mean planet) change you want to query the server for comments at that location. That, is going to be far worse than just a one-time update at the begining (imo, you should still be able to force an update to happen while you're playing), because there is the bandwidth required to make the query would be wasted essentially 100% of the time.
The average web host with say PHP scripts, I think time limits a script to 2 seconds, so all processing that the server needs to complete would have to happen within the 2 seconds.
The disabling GOES from people wanting to run a "clean" version, the time and bandwidth to convert a clean version of the game (with comments) to a sync'd version would be more work than it warrants.
I don't see your problem / your argument doesn't make sense to me.' | | | | I have another core principle (though it's more of a design principle):
| | | Assume any 3rd party library used is a security risk. | | | | | | This would be in addition to assuming our own code has a security hole, though if we use STL/Irrlicht's Containers it probably won't be too big of an issue, it'd just be using the containers in an unsafe way (i.e. write(&container[0], container.size()) is fast but unsafe). Stack corruption is mostly a non-issue now due to compilers being able to build stack checks/local buffer overflow checks into the code.
The justification for this design principle is that, the libraries we use would most likely be optimized to the point of near obfuscation. With that obfuscation, it's a whole lot harder to verify that there's no security holes. There's also the case where we use the library in an unexpected way thus causing a security hole to form. | | | | ** There's more than one reason why it should be optional, size is one; a security is the other remember the "recent" PNG bug? | |  | |  |
|
  | |  | | ![]()  | Hello!  said: | | Now if you want to include images, then that's a whole other story. It is an outright stupid idea, the very thought of including it in the guide (since I don't consider images to be part of the guide, but more of an optional supplement**) is I'll be nice terrible. |
Well, I was just giving an example of something that could require more bandwidth than typical guide comments. Also, note that I didn't suggest for photos to be included in the actual guide, but in individual 'travel logs' that would be separate from the guide comments, and looked up by the explorer who wrote them rather than by their location. It was just stated as a random idea of something that wouldn't work well if all updates occur at startup.
| Hello! said: | The disabling GOES from people wanting to run a "clean" version, the time and bandwidth to convert a clean version of the game (with comments) to a sync'd version would be more work than it warrants.
I don't see your problem / your argument doesn't make sense to me.' |
I still don't see any remote reason why someone shouldn't be able to write guide entries and name objects if their guide isn't syched with all the latest content from the primary database. Unsubmitted content can be stored in one cache, while downloaded data can go in another. Once the data is submitted, it can be removed from its cache, and be downloaded like any other submitted content when needed. | |  | |  |
|
| | | | ![]() | Cryoburner said: | | I still don't see any remote reason why someone shouldn't be able to write guide entries and name objects if their guide isn't syched with all the latest content from the primary database. Unsubmitted content can be stored in one cache, while downloaded data can go in another. Once the data is submitted, it can be removed from its cache, and be downloaded like any other submitted content when needed. |
The difference from being able to write guide entries into a recently updated game, and being able to write entries into a "clean" version is very different. They aren't even remotely the same. The difference is maybe ~50 entries on a delayed commit, versus synching against all ~1500 entries (which I think is the count for the NIV guide) from a "clean" version.
Also, I'd rather see the synching process be mostly client side to alleviate any possible server strain (the server will of course verify names don't get changed or overwritten).
Here's roughly the optimum data considering both client and server processing time/bandwidth used.
| | Star Name/Planet Name DB:
[command byte: 01]
[12 bytes: sector coordinates]
[1-2 bytes: star coordinates]
[1 or 2 bytes*: star name length]
[bytes making up star name]
[1 or 2 bytes*+: number of planet names]
{
[1-2 bytes: planet identifier]
[1 or 2 bytes*: planet name length]
[bytes making up planet name]
}[number of planet names]
[command byte: 02]
[12 bytes: sector coordinates]
[1 or 2 bytes*: how many named stars in sector]
[1-2 bytes: star coordinates]
[1 or 2 bytes*: star name length]
[bytes making up star name]
[1 or 2 bytes*+: number of planet names]
{
[1-2 bytes: planet identifier]
[1 or 2 bytes*: planet name length]
[bytes making up planet name]
}[number of planet names]
Guide DB:
[command byte: 01]
[12 bytes: sector coordinates]
[1-2 bytes: star coordinates]
[1 or 2 bytes*: planet/moon]
[1, 2, 3 or 4 bytes**: number of comments]
[1 or 2 bytes*: comment length]
[bytes making up comment: part of the comment]
[command byte: 02]
[12 bytes: sector coordinates]
[1-2 bytes: star coordinates]
[1 or 2 bytes*: number of planet/moons]
[1 or 2 bytes*: planet/moon]
[1, 2, 3 or 4 bytes**: number of comments]
[1 or 2 bytes*: comment length]
[bytes making up comment: part of the comment]
[command byte: 03]
[12 bytes: sector coordinates]
[1 or 2 bytes*: number of stars]
[1-2 bytes: star coordinates]
[1 or 2 bytes*: planet/moon]
[1, 2, 3 or 4 bytes**: number of comments]
[1 or 2 bytes*: comment length]
[bytes making up comment: part of the comment]
[command byte: 04]
[12 bytes: sector coordinates]
[1 or 2 bytes*: number of stars]
[1-2 bytes: star coordinates]
[1 or 2 bytes*: number of planets/moons]
[1 or 2 bytes*: planet/moon]
[1, 2, 3 or 4 bytes**: number of comments]
[1 or 2 bytes*: comment length]
[bytes making up comment: part of the comment] |
| | | | | * Unsigned integer. If first byte value is < 128, then it only takes one byte.
If first byte value >= 128 then it takes up two bytes granting 2^15 as the max value, if we assume a value of 0 == 2^15. Basically, using the high bit as a flag for 2nd byte extension.
*+ It would imply that a value of 0 would have to mean 0 not 2^15.
** Similar to the above, except it does it for the first 3 low order bytes.
For star coordinates / planet coordinates I'm saying 1-2 bytes due to it depending on how we store the coordinates/how big a sector is.
The Star/Planet Name DB has to downloaded in its entirety. So that targeting commands work.
For the guide, basically it's just a data container, thus allowing for any arbitrary storage in the guide. For a fast guide index download it can strip the contained bytes, and just download the header information. Then later it can request the contained bytes.
The server can further simplify client updates by tracking revisions. Only sending new revisions when updating (or a specific revision upon request).
Just to be as clear as possible, I have nothing against writing guide entries when not connected to the internet (in fact I'd prefer commits to be deferred until commanded to commit by the user). I am, however, against writing guide entries when using a "clean" copy of the game. Clean meaning that there is no local copy of the Star Name DB. | | | | |
|
| i haz title: speed-y-???-1 |
|
 | written by Speeder on Apr 05, 2008 17:10 |
 | |  | | ![]() I would like to have highly intelligent aliens, that have a highly low odd of being generated, a so low odd that probably noone will ever find, probably they will even be not generated, so we will never know if they exist or not | |  | |  |
|
| a title is a curious thing... |
|
 | | | | ![]() If I was a developer I wouldn't like coding highly intelligent aliens that are never seen or appreciated. Just a thought. That is a neat idea though. | | | | |
|
| written by Deanfrz on Apr 06, 2008 21:47 |
 | |  | | How highly intelligent are they? Covering much(read not most) of one planet with a few research bases on a moon or another nearby planet? More intelligent than humans already. | |  | |  |
|
 | |  | | ![]() If you want highly intelligent creatures, then you'd probably have to wait 20 years, or implement it yourself. The difficulties associated with maintaining a procedural universe with aliens spread across more than one sector (or star system) is anything but clean.
Also the thread you wanted was this one. Because this is a suggestion, not a design principle. | |  | |  |
|
 | |  | | ![]() Hehe, excuse me for chuckling at this little exchange. The idea is intriguing, but Granpire viking man has a point (and an ironic one at that).
Yes, much fun. Alright, I'll be quiet before we get railroaded. | |  | |  |
|
|
