[Wesnoth-dev] SotBE description a bit racy
I noticed the description for the SotBE campaign uses the term tree-shagger to refer to elves. For a mailine campaign it might be better to use a more family friendly term such as tree-hugger. ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Directory objects -- proposed change in preprocessor behavior
On Fri, May 11, 2007 at 21:14:36 +0200, Nils Kneuper <[EMAIL PROTECTED]> wrote: > Bruno Wolff III schrieb: > > I have thought of something else that might be nice to do after each > > campaign is in its own directory. If references were only allowed within > > a campaign or to main line stuff and not cross campaign, we could make sure > > that removing a campaign will not break another campaign because of > > dependencies. This could enforce the rule that you are supposed to copy > > non main line objects rather than make references to them. > > > Ehm, we are already using this policy. It will be enforced for all new > content to add mainline and it is eg needed for the split debian > packages. So in this matter it does not make a real difference, since we > already do handle things this way. I knew we had a policy of that is how things are supposed to work. What I was suggesting was that this policy be enforced in code. It might be that there is a relatively new feature doing this. I know Eric has been doing all sorts of clean up checks and of his tools may catch campaigns that do this when they are run, but that isn't the same as having wesnoth do it. Having the check in wesnoth will let campaign developers notice the problem before they try to submit their campaign (or changes to an existing campaign). ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Directory objects -- proposed change in preprocessor behavior
Bruno Wolff III schrieb: > I have thought of something else that might be nice to do after each > campaign is in its own directory. If references were only allowed within > a campaign or to main line stuff and not cross campaign, we could make sure > that removing a campaign will not break another campaign because of > dependencies. This could enforce the rule that you are supposed to copy > non main line objects rather than make references to them. > Ehm, we are already using this policy. It will be enforced for all new content to add mainline and it is eg needed for the split debian packages. So in this matter it does not make a real difference, since we already do handle things this way. Btw, I do completely agree to restructuring things. One short proposal to work together with the soon to come campaign server changes: Devide data in some "groups" like campaigns_singleplayer and multiplayer where under multiplayer all the factions stuff, mp maps/scenarios and (once they come) mp campaigns reside. The same structure should be used inside the userdata dir to make it in the end easier to see what the installed content is. So a new faction (with all needed for it) would go to userdata/multiplayer/factions/newfaction, where a normal campaign would do to userdata/campaign_singleplayer/newcampaign and so on. I think some structure like this would help users that "only want to get rid of the mp content but keep the usercampaigns" and makes it easier to see what which UMC is meant to be. Cheers, Nils Kneuper aka Ivanovic ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Directory objects -- proposed change in preprocessor behavior
I have thought of something else that might be nice to do after each campaign is in its own directory. If references were only allowed within a campaign or to main line stuff and not cross campaign, we could make sure that removing a campaign will not break another campaign because of dependencies. This could enforce the rule that you are supposed to copy non main line objects rather than make references to them. ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Directory objects -- proposed change in preprocessor behavior
On Fri, May 11, 2007 at 13:34:31 -0400,
"Eric S. Raymond" <[EMAIL PROTECTED]> wrote:
>
> After staring at the layout for a while, I think one source of
> grubbiness is that we've used directories to create a sort of
> half-baked package structure without making them package objects.
> The way capaigns are laid out is representative; for a campaign
> named "Battle of Foobar" there will be a Battle_of_Foobar.cfg
> and a Battle_of_Foobar directory, with the directory sort of
> accidentally a package by virtue of {}-inclusions in the .cfg.
I think it makes a lot more sense for campaigns to be under a single
directory. Previously there was no automated process forcing the names
to match up. I remember worrying about this issue in the past when
working with the campaign server.
___
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Directory objects -- proposed change in preprocessor behavior
yes, this sounds good
Eric, you might want to discuss your project specifically with the
guys from Spacenoth/SoS since they try to redo the whole directory
structure and might be interested to provide their input in such a
project...
On 5/11/07, John McNabb <[EMAIL PROTECTED]> wrote:
> Sounds reasonable to me.
>
> On 5/11/07, Eric S. Raymond <[EMAIL PROTECTED]> wrote:
> > Some of you know that, with encouragement from other devs, I'm doing a
> > cleanup and reorganization of the Wesnoth directory layout. The immediate
> > motivation is to make correct behavior easier for tools like wmlscope
> > and wmllint, but there are long-standing issues about our data layout
> > beneath these symptoms.
> >
> > After staring at the layout for a while, I think one source of
> > grubbiness is that we've used directories to create a sort of
> > half-baked package structure without making them package objects.
> > The way capaigns are laid out is representative; for a campaign
> > named "Battle of Foobar" there will be a Battle_of_Foobar.cfg
> > and a Battle_of_Foobar directory, with the directory sort of
> > accidentally a package by virtue of {}-inclusions in the .cfg.
> >
> > I have a proposal for a small extension of preprocessor behavior to
> > make things cleaner.
> >
> > New rule: When a directory reference like {foodir/} resolves
> > to a directory containing a file named "%main.cfg", it is treated
> > as though the reference had been {foodir/%main.cfg}.
> >
> > With this rule, Battle_of_Foobar.cfg can move to Battle_of_Foobar/%main.cfg.
> > The directory Battle_of_Foobar becomes a self-contained package. Including
> > it processes %main.cfg and whatever files %main.cfg chooses to include.
> > --
> > >>esr>>
> >
> > ___
> > Wesnoth-dev mailing list
> > Wesnoth-dev@gna.org
> > https://mail.gna.org/listinfo/wesnoth-dev
> >
>
>
> --
> ---
> "In theory, theory and practice are the same,
> but in practice they're different."
> ---
> John W. C. McNabb
> ---
>
> ___
> 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
Re: [Wesnoth-dev] Directory objects -- proposed change in preprocessor behavior
Sounds reasonable to me.
On 5/11/07, Eric S. Raymond <[EMAIL PROTECTED]> wrote:
> Some of you know that, with encouragement from other devs, I'm doing a
> cleanup and reorganization of the Wesnoth directory layout. The immediate
> motivation is to make correct behavior easier for tools like wmlscope
> and wmllint, but there are long-standing issues about our data layout
> beneath these symptoms.
>
> After staring at the layout for a while, I think one source of
> grubbiness is that we've used directories to create a sort of
> half-baked package structure without making them package objects.
> The way capaigns are laid out is representative; for a campaign
> named "Battle of Foobar" there will be a Battle_of_Foobar.cfg
> and a Battle_of_Foobar directory, with the directory sort of
> accidentally a package by virtue of {}-inclusions in the .cfg.
>
> I have a proposal for a small extension of preprocessor behavior to
> make things cleaner.
>
> New rule: When a directory reference like {foodir/} resolves
> to a directory containing a file named "%main.cfg", it is treated
> as though the reference had been {foodir/%main.cfg}.
>
> With this rule, Battle_of_Foobar.cfg can move to Battle_of_Foobar/%main.cfg.
> The directory Battle_of_Foobar becomes a self-contained package. Including
> it processes %main.cfg and whatever files %main.cfg chooses to include.
> --
> >>esr>>
>
> ___
> Wesnoth-dev mailing list
> Wesnoth-dev@gna.org
> https://mail.gna.org/listinfo/wesnoth-dev
>
--
---
"In theory, theory and practice are the same,
but in practice they're different."
---
John W. C. McNabb
---
___
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
[Wesnoth-dev] Directory objects -- proposed change in preprocessor behavior
Some of you know that, with encouragement from other devs, I'm doing a
cleanup and reorganization of the Wesnoth directory layout. The immediate
motivation is to make correct behavior easier for tools like wmlscope
and wmllint, but there are long-standing issues about our data layout
beneath these symptoms.
After staring at the layout for a while, I think one source of
grubbiness is that we've used directories to create a sort of
half-baked package structure without making them package objects.
The way capaigns are laid out is representative; for a campaign
named "Battle of Foobar" there will be a Battle_of_Foobar.cfg
and a Battle_of_Foobar directory, with the directory sort of
accidentally a package by virtue of {}-inclusions in the .cfg.
I have a proposal for a small extension of preprocessor behavior to
make things cleaner.
New rule: When a directory reference like {foodir/} resolves
to a directory containing a file named "%main.cfg", it is treated
as though the reference had been {foodir/%main.cfg}.
With this rule, Battle_of_Foobar.cfg can move to Battle_of_Foobar/%main.cfg.
The directory Battle_of_Foobar becomes a self-contained package. Including
it processes %main.cfg and whatever files %main.cfg chooses to include.
--
>>esr>>
___
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
