jeremy rosen | 1 May 2009 09:58
Picon
Picon

Re: automatic savegames and overwriting

seconded, that's what makes the most sense to me...

On Thu, Apr 30, 2009 at 10:23 PM, Eric S. Raymond <esr <at> thyrsus.com> wrote:
> Jörg Hinrichs <joerg.hinrichs <at> alice-dsl.de>:
>> through my last refactoring of the savegame code i stumbled upon the fact
>> that automatic replay saves still call the method save_game_interactive,
>> which looks kind of odd. They do that because they ask for overwrite
>> permission (and maybe a new filename) if the replay filename already exists.
>>
>> The other two automatic saves however don’t do that (start-of-scenario and
>> autosave), they just overwrite without asking.
>>
>>
>>
>> I would like to have a homogenous behaviour here, either such that replays
>> overwrite without asking, too, or that overwrite permissions are always
>> requested if the file already exists. Actually, I am indifferent which one
>> to prefer.
>>
>>
>>
>> What do you think about it?
>
> Overwrite without asking.  The UI is simpler, and it's what users probably
> expect anyway.
> --
>                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
>
> _______________________________________________
> Wesnoth-dev mailing list
(Continue reading)

Mark de Wever | 1 May 2009 11:43
Picon
Picon
Favicon

Re: automatic savegames and overwriting

On Thu, Apr 30, 2009 at 04:23:33PM -0400, Eric S. Raymond wrote:
> Jörg Hinrichs <joerg.hinrichs <at> alice-dsl.de>:
> > through my last refactoring of the savegame code i stumbled upon the fact
> > that automatic replay saves still call the method save_game_interactive,
> > which looks kind of odd. They do that because they ask for overwrite
> > permission (and maybe a new filename) if the replay filename already exists.
> > 
> > The other two automatic saves however don’t do that (start-of-scenario and
> > autosave), they just overwrite without asking.
> > 
> >  
> > 
> > I would like to have a homogenous behaviour here, either such that replays
> > overwrite without asking, too, or that overwrite permissions are always
> > requested if the file already exists. Actually, I am indifferent which one
> > to prefer.
> > 
> >  
> > 
> > What do you think about it?
> 
> Overwrite without asking.  The UI is simpler, and it's what users probably
> expect anyway.

In my opinion changing the behaviour with regards to automatically
overwriting replays sounds like a bad idea. I expect many users start to
complain once they lost a reply due to this change. Especially for MP
games I expect people to want to keep their replays around for quite a
while. I suggest to discuss this with the MP developers to get their
opinion as well.
(Continue reading)

Jörg Hinrichs | 1 May 2009 13:45
Picon

Re: automatic savegames and overwriting

Actually, from a coding point of view with revision 35365 i found a good
alternative by keeping the functionality the same as it is now. And it will
be very easy now to switch behaviour one way or the other. So there is no
design need to solve this anymore.

Mark wrote:

>In my opinion changing the behaviour with regards to automatically
>overwriting replays sounds like a bad idea. I expect many users start to
>complain once they lost a reply due to this change. Especially for MP
>games I expect people to want to keep their replays around for quite a
>while. I suggest to discuss this with the MP developers to get their
>opinion as well.
>
>-- 
>Regards,
>Mark de Wever aka Mordante/SkeletonCrew
Jörg Hinrichs | 1 May 2009 23:18
Picon
Favicon

Wiki developer resources

Hi all,

 

it always bugged me that the wiki developer information is splitted across several places, categories (and for some reason, the page you are looking for is the hardest to find).

 

So, here is “Developer’s Home”: http://www.wesnoth.org/wiki/DevelopersHome

 

Have fun and greetings

 

Yogi

_______________________________________________
Wesnoth-dev mailing list
Wesnoth-dev <at> gna.org
https://mail.gna.org/listinfo/wesnoth-dev
Nils Kneuper | 3 May 2009 11:11
Picon

Release plan for 1.6.2, stringfreeze on branches/1.6 and plans for 1.7.0


Hi everybody!
I just wanted to tell you that I currently plan to get 1.6.2 out next Sunday
(May, 10th). Because of this the strings in branches/1.6 are now frozen so that
translators can get some stuff done.
Beside the stable series it is probably time to get out the first development
release named 1.7.0 "soon". By now about 7 weeks have gone by since branching
off 1.6. I don't know the current shape of trunk too well, but what do you think
of trying to get 1.7.0 out in two weeks? From then on I would like to get a dev
release out every three to four weeks (if my time permits ;) ).
Comments about this? What do you have in your pipe that conflicts with these plans?
Cheers,
Nils Kneuper aka Ivanovic
Noy | 19 May 2009 22:58
Picon

Art Scholarship Proposal

Greetings

Over the past few weeks a proposal has been raised for the creation of  
a Wesnoth GSOC-like art scholarship. I've spoken to several developers  
including Dave, Jetryl and Ivanovic on this topic, and this email is  
really an compilation of those discussions.

I believe the reason behind the proposal is fairly simple; If wesnoth  
desires continued growth in the future, it is essential that we  
embrace a holistic approach to our development. While enhancing GUI,  
stats server or mp security are important issues, so is art  
development.  I doubt anybody can deny the exceptional contribution  
made by Kitty, Lord Bob and Jetryl to the game over the past year.  
This proposal intends to build on that by developing our young talent  
base. At the same time it is a philanthropic endevour, where we are  
offering a student the opportunity to enhance their art skills over  
the summer.

Wesnoth financial situation is well suited for such a proposal. With  
the completion of this year's GSOC in September we will have an  
operating reserve of between $5,000 and $7,000 dollars. Based on this  
and  some discussions, I believe there are two acceptable options;  a  
single $2,500 scholarship or two at $1,500 each. This would leave at  
minimum $2,000 for other contingencies.

The mechanics of the scholarship would closely resemble how we manage  
the GSOC process. We would retain the mentoring process the summer of  
code uses, with Jetryl as the lead person. However the nature of art  
as a medium in our project compared to coding requires some  
adjustments to the payment and oversight scheme. GSOC projects  
typically are end loaded; though there is constant interaction between  
the mentor and student, the project is typically finished at the end.  
As such the money is disbursed at the beginning and end of the  
project.  For an art project, we would expect a number of pieces to be  
completed over the project length. Therefore a progressive payment  
scheme seems more appropriate, where money is allocated when the  
student reaches certain milestones. This transfers some of the onus  
from the student to the mentor, as the latter would need to identify  
the development path of the student. I submit that a prospective  
student would identify some areas where he or she would like to  
improve, to which the mentor would design a program around. As an  
illustrative example, if this program was run from June 1st to  
September 1st, having four milestones  (one every three weeks  
consisting of a piece of art or two) might seem reasonable. Upon each  
assignment's completion funds would be disbursed. Again I'm not  
suggesting how it should be, just to illustrate how it might be  
organized.

While this system may seem to be somewhat onerous compared to GSOC,  
there are several good reasons for it. First is the fact that we are  
running this for the first time and don't have an adequate  
understanding of how this may turn out. By using a progressive scheme  
we can ensure the money is being used effectively throughout. I would  
rather this be run somewhat stringently the first time and then relax  
our procedures for subsequent attempts, if we decide to repeat it in  
the future. The second reason is the unique area for art. Unlike other  
gsoc programs which are widely critiqued by all the developers, we  
only have one individual in this area. Since Jetryl is the only art  
developer involved in day to day management of wesnoth, it would be  
difficult for our community to effectively assess the scholarship's  
outcome. Having clear milestones enables us to maintain an adequate  
level of oversight that is consistent with the GSOC program.

Obviously comments are welcome, but I would suggest that we move  
quickly on this proposal if it is approved.

Noy.
Mark de Wever | 19 May 2009 23:20
Picon
Picon
Favicon

Re: Art Scholarship Proposal

On Tue, May 19, 2009 at 01:58:31PM -0700, Noy wrote:
> Greetings
> 
> Over the past few weeks a proposal has been raised for the creation of  
> a Wesnoth GSOC-like art scholarship. I've spoken to several developers  
> including Dave, Jetryl and Ivanovic on this topic, and this email is  
> really an compilation of those discussions.

I also discussed it with Noy and already told him I'm also in favour to
try this. The motivation to do this is like one of the motivations
behind the GSoC project; allow students to work on their project in the
summer instead of doing a dull summer job, which doesn't learn them a
thing but only provides them with money.

> This transfers some of the onus  from the student to the mentor, as
> the latter would need to identify  the development path of the
> student. I submit that a prospective  student would identify some
> areas where he or she would like to  improve, to which the mentor
> would design a program around.

IMO the student should not only identify a development path, but also
come up with a proposal. This proposal can then be discussed with the
mentor(s) and turned into a final proposal.

--

-- 
Regards,
Mark de Wever aka Mordante/SkeletonCrew
jeremy rosen | 20 May 2009 00:23
Picon
Picon

Re: Art Scholarship Proposal

I second what mordante said...

the proposal period is a very important period in the GSoC process,
and it makes sense to try to have one for the summer of art.

would we have a limited area (portrait, terrain, units) or leave it
completely open to students ?

On Tue, May 19, 2009 at 11:20 PM, Mark de Wever <koraq <at> xs4all.nl> wrote:
> On Tue, May 19, 2009 at 01:58:31PM -0700, Noy wrote:
>> Greetings
>>
>> Over the past few weeks a proposal has been raised for the creation of
>> a Wesnoth GSOC-like art scholarship. I've spoken to several developers
>> including Dave, Jetryl and Ivanovic on this topic, and this email is
>> really an compilation of those discussions.
>
> I also discussed it with Noy and already told him I'm also in favour to
> try this. The motivation to do this is like one of the motivations
> behind the GSoC project; allow students to work on their project in the
> summer instead of doing a dull summer job, which doesn't learn them a
> thing but only provides them with money.
>
>> This transfers some of the onus  from the student to the mentor, as
>> the latter would need to identify  the development path of the
>> student. I submit that a prospective  student would identify some
>> areas where he or she would like to  improve, to which the mentor
>> would design a program around.
>
> IMO the student should not only identify a development path, but also
> come up with a proposal. This proposal can then be discussed with the
> mentor(s) and turned into a final proposal.
>
> --
> Regards,
> Mark de Wever aka Mordante/SkeletonCrew
>
> _______________________________________________
> Wesnoth-dev mailing list
> Wesnoth-dev <at> gna.org
> https://mail.gna.org/listinfo/wesnoth-dev
>
Eric S. Raymond | 20 May 2009 21:46
Picon

I'm ready to implement save threading in the load dialog

One of the flaws in Wesnoth's UI is that afyer you've been playing for
a while, the load-game dialog tends to list huge piles of autosaves
that are no longer really interesting; almost always you want to
reload the most recent save in a campaign.

About 18 months ago I floated a proposal to change the UI for loading
savegames so game saves are grouped into threads.  Typically a thread would
be a sequence of saves that are a continuous history of a campaign,
though deleting saves in the middle could break a campaign into any
number of disjoint threads.  

The UI would then turn into a two-level interface. Normally all you'd
see would be a list of the most recent saves in each thread; there
would be a way to descend into threads and see all saves in them in
the relatively unusual case that you want to go back in time within a
thread.

I am ready to implement this feature.  In fact, I already have the
machinery for the lower half working in trunk.  Thanks to YogiHH's
cleanup of the savegame code, I have been able to implement a "parent"
field in savefiles.  Code can use these to run back down the ancestry
chain from any given save.  Savefiles with no parent are thread roots,
usually the first autosave of a campaign - but as long as you have old
savefiles without a parent field in them, all of these will also be
treated as thread roots.

Furthermore, I have working code in dialogs.cpp::load_game_dialog()
that inverts the parent relation, creating a parent_to_child map.
Savefiles with no child are thread tips and usually the files users
will be interested in reloading.

This is all the infrastructure needed to support an improved,
thread-aware load-game dialog. The question, now, is what to do
with it at the presentation/UI level.

Here's the approach I favor:

Make the load dialog look something like a file manager, with
thread-tip saves behaving something like folders.  That is, each
save gets an icon to its left.  The icon may be 

1. Blank, indicating a non-tip savefile

2. "+" (or variant) indicating a tip save for which all the ancestors
   are visible in the list.

3. "-" (or variant) indicating a tip save for which ancestors are
   not shown.

The default presentation would be to show only tip saves, all marked "-".
If you clicked on a "-", it would change to "+" and all the ancestor
saves associated with this tip would be displayed.  If you clicked on
a "+", the ancestor-save lines corresponding to that that tip save
would be removed from the visible list and the icon would change to "-".
Clicking on a blank would have no effect.

Obviously this means the save list would have to be refreshed
whenever a - was toggled to + or vice-versa. 

Less obviously, I think this facility would make both the
sort-by-name/sort-by-date toggle and the filter box pretty much
pointless, and they should probably be removed to simplify the code
and the UI.

Comments?  Criticism?  Technical issues? Alternate proposals?  All
offers of help cheerfully accepted; I'd really rather not write more
C++ than I absolutely have to.
--

-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

The right of self-defense is the first law of nature: in most
governments it has been the study of rulers to confine this right
within the narrowest limits possible.  Wherever standing armies
are kept up, and when the right of the people to keep and bear
arms is, under any color or pretext whatsoever, prohibited,
liberty, if not already annihilated, is on the brink of
destruction." 
	-- Henry St. George Tucker (in Blackstone's Commentaries)
kpolikeit | 20 May 2009 23:35
Picon

Re: Art Scholarship Proposal

Hi,

that sounds like an interesting plan! Just one question:
If this works like GSoC - where and how do you plan to acquire students? 
Will we post ads on art forums? And which ones? As far as I know GSoC 
works because it is already well known and promoted and thus gets the 
attention of interesting/talented participants. How will we get the attention
of artists not already involved in open source games? 

Greetings, Kitty

> -----Ursprüngliche Nachricht-----
> Von: "Noy" <neuhausercova <at> gmail.com>
> Gesendet: 19.05.09 23:00:39
> An: dev-talk <wesnoth-dev <at> gna.org>
> Betreff: [Wesnoth-dev] Art Scholarship Proposal

> Greetings
> 
> Over the past few weeks a proposal has been raised for the creation of  
> a Wesnoth GSOC-like art scholarship. I've spoken to several developers  
> including Dave, Jetryl and Ivanovic on this topic, and this email is  
> really an compilation of those discussions.
> 
> I believe the reason behind the proposal is fairly simple; If wesnoth  
> desires continued growth in the future, it is essential that we  
> embrace a holistic approach to our development. While enhancing GUI,  
> stats server or mp security are important issues, so is art  
> development.  I doubt anybody can deny the exceptional contribution  
> made by Kitty, Lord Bob and Jetryl to the game over the past year.  
> This proposal intends to build on that by developing our young talent  
> base. At the same time it is a philanthropic endevour, where we are  
> offering a student the opportunity to enhance their art skills over  
> the summer.
> 
> Wesnoth financial situation is well suited for such a proposal. With  
> the completion of this year's GSOC in September we will have an  
> operating reserve of between $5,000 and $7,000 dollars. Based on this  
> and  some discussions, I believe there are two acceptable options;  a  
> single $2,500 scholarship or two at $1,500 each. This would leave at  
> minimum $2,000 for other contingencies.
> 
> The mechanics of the scholarship would closely resemble how we manage  
> the GSOC process. We would retain the mentoring process the summer of  
> code uses, with Jetryl as the lead person. However the nature of art  
> as a medium in our project compared to coding requires some  
> adjustments to the payment and oversight scheme. GSOC projects  
> typically are end loaded; though there is constant interaction between  
> the mentor and student, the project is typically finished at the end.  
> As such the money is disbursed at the beginning and end of the  
> project.  For an art project, we would expect a number of pieces to be  
> completed over the project length. Therefore a progressive payment  
> scheme seems more appropriate, where money is allocated when the  
> student reaches certain milestones. This transfers some of the onus  
> from the student to the mentor, as the latter would need to identify  
> the development path of the student. I submit that a prospective  
> student would identify some areas where he or she would like to  
> improve, to which the mentor would design a program around. As an  
> illustrative example, if this program was run from June 1st to  
> September 1st, having four milestones  (one every three weeks  
> consisting of a piece of art or two) might seem reasonable. Upon each  
> assignment's completion funds would be disbursed. Again I'm not  
> suggesting how it should be, just to illustrate how it might be  
> organized.
> 
> While this system may seem to be somewhat onerous compared to GSOC,  
> there are several good reasons for it. First is the fact that we are  
> running this for the first time and don't have an adequate  
> understanding of how this may turn out. By using a progressive scheme  
> we can ensure the money is being used effectively throughout. I would  
> rather this be run somewhat stringently the first time and then relax  
> our procedures for subsequent attempts, if we decide to repeat it in  
> the future. The second reason is the unique area for art. Unlike other  
> gsoc programs which are widely critiqued by all the developers, we  
> only have one individual in this area. Since Jetryl is the only art  
> developer involved in day to day management of wesnoth, it would be  
> difficult for our community to effectively assess the scholarship's  
> outcome. Having clear milestones enables us to maintain an adequate  
> level of oversight that is consistent with the GSOC program.
> 
> Obviously comments are welcome, but I would suggest that we move  
> quickly on this proposal if it is approved.
> 
> Noy.
> 
> _______________________________________________
> Wesnoth-dev mailing list
> Wesnoth-dev <at> gna.org
> https://mail.gna.org/listinfo/wesnoth-dev
> 

____________________________________________________________
Text: GRATIS für alle WEB.DE-Nutzer: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://movieflat.web.de

Gmane