Re: [Warzone-dev] List of things that are being removed for the 2.2 release
On Thu, May 28, 2009 at 3:56 AM, bugs buggy buginato...@gmail.com wrote: Does this sound good to everyone? Does to me. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] List of things that are being removed for the 2.2 release
On Wed, May 27, 2009 at 09:56:40PM -0400, bugs buggy wrote: Does this sound good to everyone? It all works for me. Any thoughts on what could be used for the external music player? -- Stephen Swaney sswa...@centurytel.net ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Savegame incompatibility rc1-rc2
2009/5/27 bugs buggy buginato...@gmail.com: That is why we should revert, and fix this error another way, like I explained before. Do you have a good way of fixing the error? If you do, I welcome it. Otherwise, I think this bugfix is more important than skirmish savegame compatibility (campaign savegames are fine). Another idea - when the script loader breaks like it does here, just restart the AIs? -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Savegame incompatibility rc1-rc2
On Thu, May 28, 2009 at 9:31 AM, Zarel zare...@gmail.com wrote: Another idea - when the script loader breaks like it does here, just restart the AIs? Won't work for campaign scripts. - Per ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Savegame incompatibility rc1-rc2
On Thursday, 28 May 2009 at 2:31, Zarel wrote: Do you have a good way of fixing the error? If you do, I welcome it. [Wed May 27 2009] [20:27:10] cybersphinx Hm. Making the truck template unchangeable (perhaps for player 0 only) should fix it as well, without compatibility problems. [Wed May 27 2009] [20:30:36] BuginatorI guess we could also make a hardcoded template for the AI, and don't copy it in the first place... New savegame revision, where the new scripts are saved in a new block. If that doesn't exist, adapt the old scripts to the new format. Otherwise, I think this bugfix is more important than skirmish savegame compatibility (campaign savegames are fine). See e.g. http://developer.wz2100.net/ticket/536 for a victim of this. I don't want to revert anything just to check if I can reproduce a bug (and this was the first time I encountered this issue, so I wouldn't have known even what to revert). ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Savegame incompatibility rc1-rc2
On Thursday, 28 May 2009 at 11:35, Per Inge Mathisen wrote: On Thu, May 28, 2009 at 9:31 AM, Zarel zare...@gmail.com wrote: Another idea - when the script loader breaks like it does here, just restart the AIs? Won't work for campaign scripts. Special case for skirmish? ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Savegame incompatibility rc1-rc2
2009/5/28 Per Inge Mathisen per.mathi...@gmail.com: Won't work for campaign scripts. Campaign scripts aren't broken, so that's not an issue. :P Besides, skirmish AI changes a lot more than campaign AI does. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] List of things that are being removed for the 2.2 release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 bugs buggy wrote: Since nobody has had time to update the docs/* to make them current, I think we should just scrub that directory, and instead have links to our web site wiki FAQ. Those are mostly up to date, and we wouldn't really need to do anything. Did you take a look at the current state of the docs? Last time I talked to you about it (~week ago?) the only thing mentioned was that some paths are not correct anymore. So, if those files are about to be excluded from distribution then at least make sure that all the information contained in them right now is available online as well. Additionally I strongly dislike the idea of not having offline help resources anymore. This is even worse considering that wz2100.net to the best of my knowledge is the only mirror for the aforementioned resources and down-times happen. So I propose adding the following to the doc-files instead of excluding them: This file has not been updated since the release of 2.1. Some information may not be correct any more. For current information visit the homepage of the Warzone 2100 Resurrection Project. - - Kreuvf -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKHsBi4y86f1GXLDwRAgWIAJ9dVRW2BEz73h40nwfdRTJ//nQUjgCgxDoL wdpw1r6sF2VFgTfzj1IBPgo= =72qo -END PGP SIGNATURE- ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] List of things that are being removed for the 2.2 release
On 5/28/09, Kreuvf kre...@warzone2100.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 bugs buggy wrote: Since nobody has had time to update the docs/* to make them current, I think we should just scrub that directory, and instead have links to our web site wiki FAQ. Those are mostly up to date, and we wouldn't really need to do anything. Did you take a look at the current state of the docs? Last time I talked to you about it (~week ago?) the only thing mentioned was that some paths are not correct anymore. New command line options, cheat warning, paths, default values for the new entries in the config file, and so on... So, if those files are about to be excluded from distribution then at least make sure that all the information contained in them right now is available online as well. All that information is on the wiki FAQ is it not? Additionally I strongly dislike the idea of not having offline help resources anymore. True, but this is only temporary, until we get a chance to update the docs. For what it is worth, I did take a crack at it, but I can only handle the English readme.en, the German xhtml versions still need fixing. It still is missing lots of the new command line / config options, and I don't got the time to fix it as it should be fixed. This is even worse considering that wz2100.net to the best of my knowledge is the only mirror for the aforementioned resources and down-times happen. So I propose adding the following to the doc-files instead of excluding them: This file has not been updated since the release of 2.1. Some information may not be correct any more. For current information visit the homepage of the Warzone 2100 Resurrection Project. - - Kreuvf I guess the disclaimer can work as well... either or works for me. And we always have google cache ;) ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone 2100 Trac] #546: O(1) path-finding check
#546: O(1) path-finding check -+-- Reporter: Per | Owner: Type: enhancement | Status: new Priority: major| Milestone: 2.3 Component: other|Version: svn/trunk Keywords: path-finding AI | Operating_system: All/Non-Specific Blockedby: | Blocking: -+-- Comment(by Kreuvf): so we may want to cache it on the disk, and later create it with a map editor. I object. Not doing this is easier, faster, allows for faster map distribution and wastes no disk space. 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. 1. Even the data saved to disk cannot be trusted and therefore must be checked. 1. 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. 1. Parsing map files will become more complex when flooding information is included. This makes the corresponding code more error-prone. Therefore I think that not saving any such data in a map file/disk cache and instead calculating it when needed is a superior way of doing it. -- Ticket URL: http://developer.wz2100.net/ticket/546#comment:4 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
Re: [Warzone-dev] Savegame incompatibility rc1-rc2
On 5/28/09, Zarel zarelxx...@gmail.com wrote: 2009/5/27 bugs buggy buginatxx...@gmail.com: That is why we should revert, and fix this error another way, like I explained before. Do you have a good way of fixing the error? If you do, I welcome it. Otherwise, I think this bugfix is more important than skirmish savegame compatibility (campaign savegames are fine). Another idea - when the script loader breaks like it does here, just restart the AIs? I still don't think you understand the issue, if we have 2 members for each struct, x1=10, x2=20, y1=5, y2 = 6, then it is fine. If one of the structs now has 3 entries, it doesn't match the data, so the first struct will now have 10,20,5 and the other struct will have 5,(whatever the next value is), and so on. We would have to reset all values, and that would mean the savegame is nothing like it was before. Not to mention actually coding that would be difficult, since as you may have noticed, the scripts aren't exactly easy to debug, to see what went wrong. I still think the bugfix is *very* minor, and isn't worth breaking the savegames at this point. Lots of the old savegames are used to debug issues as well. I know I have at least 30+ that I use for testing various things in the engine... Reverting is the correct choice, IMO, and it will save us from the numerous 'bug' reports and other issues involved with breaking a savegame. ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Savegame incompatibility rc1-rc2
2009/5/28 bugs buggy buginato...@gmail.com: I still don't think you understand the issue, if we have 2 members for each struct, x1=10, x2=20, y1=5, y2 = 6, then it is fine. If one of the structs now has 3 entries, it doesn't match the data, so the first struct will now have 10,20,5 and the other struct will have 5,(whatever the next value is), and so on. We would have to reset all values, and that would mean the savegame is nothing like it was before. ...why? I am indeed suggesting that we reset all values, and I don't see why the savegame would be affected. Remember, this is in skirmish, not campaign. The worst that happens is that the AI is disoriented for a few seconds while it recounts its units and structures. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] Savegame incompatibility rc1-rc2
2009/5/28 Zarel zare...@gmail.com: ...why? I am indeed suggesting that we reset all values, and I don't see why the savegame would be affected. Remember, this is in skirmish, not campaign. The worst that happens is that the AI is disoriented for a few seconds while it recounts its units and structures. Heck, I've suggested the exact same thing as a temporary solution to script crashes. -Zarel ___ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
Re: [Warzone-dev] [Warzone 2100 Trac] #546: O(1) path-finding check
#546: O(1) path-finding check -+-- Reporter: Per | Owner: Type: enhancement | Status: new Priority: major| Milestone: 2.3 Component: other|Version: svn/trunk Keywords: path-finding AI | Operating_system: All/Non-Specific Blockedby: | Blocking: -+-- Comment(by 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. 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''. 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. 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. -- Ticket URL: http://developer.wz2100.net/ticket/546#comment:5 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
Re: [Warzone-dev] [Warzone 2100 Trac] #546: O(1) path-finding check
#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: -+-- Changes (by Per): * owner: = Per * status: new = assigned Comment: Some ideas: The continent data can be saved in the map directory, so no consistency check needed. The size will be four bytes for each map node, ie a maximum of 256kb uncompressed. I think I would use two PNG images to store this info, say normalcontinent.png and hovercontinent.png, so it would be both compressed and easily viewed. We could precalculate this data for all default maps. -- Ticket URL: http://developer.wz2100.net/ticket/546#comment:6 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
Re: [Warzone-dev] [Warzone 2100 Trac] #546: O(1) path-finding check
#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
Re: [Warzone-dev] [Warzone 2100 Trac] #546: O(1) path-finding check
#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:6 Per]: Some ideas: The continent data can be saved in the map directory, so no consistency check needed. Why is no consistency check needed? Who/What guarantees that a map with the same name as before hasn't changed? Or the other way around: Who/What guarantees that the images have not been tampered with? Checksums of the map files could be used to verify that maps haven't changed, but then again you'd need to save the checksum somewhere. Somewhere nobody could have tampered with them. Replying to [comment:6 Per]: The size will be four bytes for each map node, ie a maximum of 256kb uncompressed. On slow connections (8 kb/s upload) this will add 32 s to the total map distribution time. And with compression you'd have to do additional calculations for decompressing. Replying to [comment:6 Per]: I think I would use two PNG images to store this info, say normalcontinent.png and hovercontinent.png, so it would be both compressed and easily viewed. We could precalculate this data for all default maps. How could the validity of the precalculated data be verified without rerunning the calculation on one's own machine? A checksum would probably be created from the precalculated data, but for comparison you'd need to have an own checksum which would require running the calculations on your own. Maybe I am missing some important point(s) here, so I'd be glad if somebody stepped up to explain to me how this is supposed to work in a reliable manner. -- Ticket URL: http://developer.wz2100.net/ticket/546#comment:8 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
Re: [Warzone-dev] [Warzone 2100 Trac] #546: O(1) path-finding check
#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 Per): I do not understand the concern for verification. Nobody is going to change maps stored on the disk. Even in savegames, the map files themselves do not change. A map editor that understands our map format would have to know about all the files in a map directory, of course, but such an editor does not yet exist. -- Ticket URL: http://developer.wz2100.net/ticket/546#comment:9 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
Re: [Warzone-dev] [Warzone 2100 Trac] #546: O(1) path-finding check
#546: O(1) path-finding check -+-- Reporter: Per | Owner: Per Type: enhancement | Status: closed Priority: major | Milestone: 2.3 Component: other | Version: svn/trunk Resolution: fixed |Keywords: path-finding AI Operating_system: All/Non-Specific | Blockedby: Blocking:| -+-- Comment(by Zarel): Replying to [comment:7 Kreuvf]: 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. Sure, we can't be sure that they've been created by good users, but why do we need to be? 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. Oh, not this. It's pretty easy to tell if a format is compatible. That can be as simple as adding a version number counter into the save game format. I mean, our map format isn't convoluted like our savegame format is; it'd be moderately simple just to add another file, and check for its presence. 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)? Why do we need to trust our map data? You still haven't established this. I proposed a checksum as a safeguard against accidental corruption. If someone wants to intentionally fiddle with our map files, ''let them''. We have an open-source philosophy - if someone wants to mess with stuff, ''great''. I don't see the problem here. 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. Yes, well, +2 seconds worth of map loading is pretty nontrivial. It should be avoided whenever possible. I meant that it's error-prone in the tautological sense: ''All'' code is error-prone. Even bugfixes. And yet we keep on writing it. My conclusion still is: Not only there is no need for storing that information _permanently_, doing so will give rise to further problems. What further problems? You've said nothing about any further problems except some vague commentary on trustworthiness. Replying to [comment:8 Kreuvf]: On slow connections (8 kb/s upload) this will add 32 s to the total map distribution time. And with compression you'd have to do additional calculations for decompressing. Decompressing a PNG takes a trivial amount of time (far less than two seconds). Maybe I am missing some important point(s) here, so I'd be glad if somebody stepped up to explain to me how this is supposed to work in a reliable manner. I think what you're not understanding is this: We don't need to be secure against attackers. You must realize, we are developing a game here, not, say, OpenSSL. What kind of attack are you afraid of? Here's a chart for you: || Attacker || '''Data regenerated''' || '''Data cached in map''' || || ''Malicious mapper/MitM'' || Warzone crashes || Warzone crashes || || ''Subtly malicious mapper/MitM'' || Warzone behaves strangely || Warzone behaves strangely || || ''Trustable mapper'' || Warzone works fine || Warzone works fine || Malicious mappers can already crash the game, or if they want to be more subtle, screw with gateways, features on top of buildings, etc, etc. And as a community, we are small enough that we don't have people bored enough to do that. And even if we did, we'd get around it by not downloading their maps. That's how every game works. Emphasis on malicious - a simply incompetent map maker would be fine, since it's the underlying map editor that takes care of the continent data cache. -- Ticket URL:
