[Wesnoth-dev] Duplicate image files in trunk
Wiith the NR merge coming up, I decided to give macroscope the capability to find and detect cliques of duplicate files, so I can drop redundant copies of images in NR. You can generate this report by going to data/tools and typing make collisions My code uses MD5 hashing rather than byte-by-byte comparison, so this works pretty fast. Here's a copy of the current report. I deduce from this, for example, that it ought to be possible to remove the file data/campaigns/The_South_Guard/images/misc/cross.png. %% ../../images/terrain/castle/elven/keep-wall-0-ne.png ../../images/terrain/castle/elven/keep-inside-ne.png ../../images/terrain/castle/elven/keep-wall-1-ne.png ../../images/terrain/castle/elven/keep-wall-ne.png %% ../../images/terrain/cave/wall-rough-chasm-convex-nw.png ../../images/terrain/cave/wall-rough-convex-nw.png %% ../../images/projectiles/wailprojectile-n-6.png ../../images/projectiles/wailprojectile-s-6.png %% ../../images/terrain/castle/sunkenkeep-keep-e.png ../../images/terrain/castle/sunken-ruinkeep1-keep-e.png %% ../../images/terrain/castle/encampment-concave-w.png ../../images/terrain/castle/encampment-convex-w.png %% ../../images/projectiles/wailprojectile-n-4.png ../../images/projectiles/wailprojectile-s-4.png %% ../../data/tutorial/images/units/elder-mage-ranged1.png ../../data/campaigns/Heir_To_The_Throne/images/units/elder-mage-ranged1.png %% ../../data/tutorial/images/units/elder-mage-defend.png ../../data/campaigns/Heir_To_The_Throne/images/units/elder-mage-defend.png %% ../../images/terrain/castle/sunkenkeep-inside-sw.png ../../images/terrain/castle/sunkenkeep-wall-sw.png %% ../../data/tutorial/images/units/elder-mage-ranged3.png ../../data/campaigns/Heir_To_The_Throne/images/units/elder-mage-ranged3.png %% ../../data/tutorial/images/units/human-princess-attack-1.png ../../data/campaigns/Heir_To_The_Throne/images/units/human-princess-attack-1.png %% ../../images/terrain/castle/keep-wall-1-ne.png ../../images/terrain/castle/keep-wall-0-ne.png ../../images/terrain/castle/keep-inside-ne.png ../../images/terrain/castle/keep-wall-ne.png %% ../../data/campaigns/Under_the_Burning_Suns/external_binary_data/images/UtBS_campaign_icon.png ../../data/campaigns/Under_the_Burning_Suns/images/newelves/kaleh.png %% ../../data/campaigns/The_Rise_Of_Wesnoth/images/units/undead-vampirelady-defend.png ../../data/campaigns/The_Rise_Of_Wesnoth/images/units/undead-vampirelady-range.png %% ../../images/terrain/castle/sunkenkeep-wall-1-nw.png ../../images/terrain/castle/sunkenkeep-wall-nw.png ../../images/terrain/castle/sunkenkeep-wall-0-nw.png ../../images/terrain/castle/sunkenkeep-inside-nw.png %% ../../images/misc/bar-energy-enemy.png ../../images/misc/bar-energy.png %% ../../data/campaigns/Heir_To_The_Throne/images/story/story9.png ../../data/campaigns/The_Rise_Of_Wesnoth/images/story/rough_landing.png %% ../../images/terrain/castle/sunkenkeep-wall-0-ne.png ../../images/terrain/castle/sunkenkeep-inside-ne.png ../../images/terrain/castle/sunkenkeep-wall-1-ne.png ../../images/terrain/castle/sunkenkeep-wall-ne.png %% ../../images/buttons/paste_button_editor-active.png ../../images/buttons/paste_button_editor.png ../../images/buttons/paste_button_editor-pressed.png %% ../../data/campaigns/Eastern_Invasion/external_binary_data/images/EI_campaign_image.png ../../data/campaigns/Eastern_Invasion/images/portraits/gweddry.png %% ../../images/terrain/castle/encampment-convex-se.png ../../images/terrain/castle/encampment-concave-se.png %% ../../data/campaigns/Under_the_Burning_Suns/images/newelves/desert-elvish-archer+female-defend.png ../../data/campaigns/Under_the_Burning_Suns/images/newelves/desert-elvish-archer-defend.png %% ../../data/campaigns/Under_the_Burning_Suns/external_binary_data/images/UtBS_difficulty_hard.png ../../data/campaigns/Under_the_Burning_Suns/images/newelves/desert-elvish-prowler.png %% ../../images/terrain/lava-dcastle-ccw-nw.png ../../images/terrain/lava-dcastle-chasm-ccw-nw.png %% ../../images/units/human-magi/white-mage+female-die-4.png ../../images/units/human-magi/white-mage-die-4.png %% ../../images/buttons/group_castle-active.png ../../images/buttons/group_castle-active-pressed.png %% ../../data/campaigns/Under_the_Burning_Suns/images/newelves/desert-elvish-sharpshooter-defend.png ../../data/campaigns/Under_the_Burning_Suns/images/newelves/desert-elvish-sharpshooter+female-defend.png %% ../../data/tutorial/images/portraits/lisar.png ../../data/campaigns/Heir_To_The_Throne/images/portraits/lisar.png %% ../../images/items/bones.png ../../data/campaigns/Under_the_Burning_Suns/images/items/bones.png %% ../../data/tutorial/images/units/human-princess-defend.png ../../data/campaigns/Heir_To_The_Throne/images/units/human-princess-defend.png %% ../../images/terrain/castle/sunkenkeep-keep-se.png ../../images/terrain/castle/sunken-ruinkeep1-keep-se.png %% ../../data/campaigns/Under_the_Burning_Suns/external_binary_data/images/UtBS_difficulty_challenging.png ../../data/campaigns/Und
Re: [Wesnoth-dev] solidifying the Void
Mark de Wever <[EMAIL PROTECTED]>: > anybody against this idea? > http://www.wesnoth.org/forum/viewtopic.php?t=15849 No objection here. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] wesnoth and python
On Wed, Apr 25, 2007 at 20:28:22 +0200, Elias Pschernig <[EMAIL PROTECTED]> wrote: > > 1. We include the DLL - it comes with the official python installer, > so it can't be that problematic to re-distribute it with the Windows > installer, if otherwise it doesn't work. I don't think it is safe to draw that conclusion without examining what license the windows DLL is distributed under. It may not be compatible with the GPL. ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] wesnoth and python
> > Since nobody knows so far I walked the path of no risk and sticked to python > 2.3. However, for myself there is no problem at all since I own a legal copy > of Visual Studio.Net 2003. So for me, redistribution is not a problem at > all. I can't speak of anyone else that might be using python, though. > I wonder what other open source projects do. Also applications not using embedded python, but using py2exe to create a standalone executable from their python sources, likely will have the same problem. Anyway, I asked in #python about this before, but got no replies. (And writing to their mailing list will likely have no different answers than the links you gave.) > So if we come to an agreement that the windows package should be shipped > with a more up-to-date python DLL, just tell me and it will be done. But I > want it to be a matter of widespread agreement before I do that. I never > used python and I don't know which version is most appropriate. If we come > to a conclusion here just let me know and I will make it happen. > I can see five options how to proceed right now: 1. We include the DLL - it comes with the official python installer, so it can't be that problematic to re-distribute it with the Windows installer, if otherwise it doesn't work. 2. Stay with python 2.3. But I'd say, in the long term, staying with an outdated, unmaintained library always will lead to problems.. although, Mordante tested a recent trunk version with Python 2.3 and it does work. 3. Get Python to compile with mingw, or hack up the python sources themselves and redistribute a version compiled from that, or use another python version like stackless which does not depend on an extra Microsoft DLL under Windows. 4. A fourth option would be to ask users to separately download that DLL, in case it is not already present on their system. 5. Don't enable Python support in Windows builds, and in the long term, phase out the Python support in favor of Lua. Option 4 of course is very bad, even if the percentage of systems without that DLL is low. Unless maybe, it is a dll present on all XP and Vista systems, just not on older ones - but from what I've read so far that's not the case. Option 2 also is bad. If we can't use Python 2.4/2.5 or newer, then I think it's a strong argument for switching to Lua instead. Same for option 3 - getting the current Python-AI API working in Lua likely is an easier task than hacking up the Python sources. So, personally, I'd go with option 1 for now. And maybe over time some other project (or Python's windows devs) will do option 3 for us, or someone will write a Lua implementation, or maybe Vista ships that DLL by default.. either of them will make the problem solve itself eventually. -- Allefant ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
[Wesnoth-dev] solidifying the Void
Hi, anybody against this idea? http://www.wesnoth.org/forum/viewtopic.php?t=15849 If not I'm going to look at it soon. Regards, Mark de Wever aka Mordante/SkeletonCrew ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
[Wesnoth-dev] WML event bug
Hi, There an UtbS bug [1] which seems to expose some problems in the WML event handling. Cycholka posted a testcase[2] made by Zookeeper. There are 2 units both with a die event. * Unit 1, Jack, is stored * A third unit kills the second unit, Horsie * The death event of the Horsie runs, kills Horsie and unstores Jack at the same location. Jack death event is also played. What I think occurs is the game_event::fire finds both death events and tries to run them. The handler verifies the filter applies to the location where the event should occur and plays that event. First Hories event is found and played after that Jacks event is tested and Jack is at the wrong time at the wrong place and is presumed dying. So his event is also played. If the definition of the death events are in the opposite order in the scenario file the problem doesn't occur. I expect due to the fact that then Jacks event is tested first, there's no Jack to be found so no event. Can somebody with more knowledge tell me whether my conclusions are valid and also propose the best way to fix it. AFAIK it's allowed for a unit to have more than one death event, so limiting to 1 event being run won't fix the problem. Is what WML does really allowed or is this bending the rules too far and should it be documented on the wiki as not allowed? Regards, Mark de Wever aka Mordante/SkeletonCrew [1] https://gna.org/bugs/index.php?8981 [2] https://gna.org/bugs/download.php?file_id=2265 ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] UtBS rewrite
well, if a rewrite is needed, let's do a rewrite... that's what dev versions are for :) On 4/25/07, Mist <[EMAIL PROTECTED]> wrote: > As you probably (don't :) ) know I volunteered to do an WML rewrite of > UtBS. After doing some work on the first scenario and in depth analysis > of the rest, and surrounding utils there are two conclusions: > > 1) The present WML is rather unsalvageable, it's bloated, unprecise and > conceptualy ugly. That means almost complete overhaul. > > 2) Because of 1) I can't guarantee that campaign will remain in working > state all along. If keeping up compatibility with existing code will > mean writing uglier than could be done otherwise, I'll drop the > compatibility. > > I'll start after 1.3.2, that means campaign will be probably unplayable > in trunk before 1.3.3, and if not finished by then also further up. That > infomation should be included in changelog. > > cycholka > > > Rozlicz się sercem - przekaż 1% podatku. > 1% Twojego podatku może uratować życie dziecka! > Jak przekazać 1% podatku potrzebującym? Kliknij i zobacz: > http://klik.wp.pl/?adr=www.jedenprocent.wp.pl&sid= > > > > ___ > Wesnoth-dev mailing list > Wesnoth-dev@gna.org > https://mail.gna.org/listinfo/wesnoth-dev > ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
