headers
Mark de Wever | 2 Dec 2007 11:22
Picon
Picon
Favicon

Re: Using compression for savegames and addons

On Thu, Nov 29, 2007 at 08:24:12PM +0000, Jens Seidel wrote:
> On Thu, Nov 29, 2007 at 07:30:11PM +0100, Mark de Wever wrote:
> > On Sun, Nov 25, 2007 at 07:02:38PM +0100, jeremy rosen wrote:
> > > I'll just reply about the boost part...
> > >
> > > yes it was discussed, and the idea of adding BOOST was accepted on principle
> 
> I do not remember any discussion on this list ...

It was [1]. Also we already use some boost stuff, but it has been copied
to the source tree. At least lexical_cast with some nice enhancements.

> As far as I know Boost has no stable API or ABI. Be prepared to depend
> on a single library version which may not be included in any distribution.
> 
> I also noticed that many Boost maintainers do not respond and others
> don't want to commit bug fixes for other libraries. Even many very simple
> patches for build errors are ignored.

Any references for these claims?

Regards,
Mark de Wever

[1] https://mail.gna.org/public/wesnoth-dev/2007-05/msg00110.html
Permalink | Reply | 2 comments |
headers
Jens Seidel | 2 Dec 2007 14:23

Re: Using compression for savegames and addons

On Sun, Dec 02, 2007 at 11:22:42AM +0100, Mark de Wever wrote:
> On Thu, Nov 29, 2007 at 08:24:12PM +0000, Jens Seidel wrote:
> > On Thu, Nov 29, 2007 at 07:30:11PM +0100, Mark de Wever wrote:
> > > On Sun, Nov 25, 2007 at 07:02:38PM +0100, jeremy rosen wrote:
> > > > I'll just reply about the boost part...
> > > >
> > > > yes it was discussed, and the idea of adding BOOST was accepted on principle
> > 
> > I do not remember any discussion on this list ...
> 
> It was [1]. Also we already use some boost stuff, but it has been copied
> to the source tree. At least lexical_cast with some nice enhancements.

Ah, thanks. Strange that I do not remember this.

> > As far as I know Boost has no stable API or ABI. Be prepared to depend
> > on a single library version which may not be included in any distribution.
> > 
> > I also noticed that many Boost maintainers do not respond and others
> > don't want to commit bug fixes for other libraries. Even many very simple
> > patches for build errors are ignored.
> 
> Any references for these claims?

The first is true for sure. I think I read this first on a Debian list
(debian-devel-games?) where the missing stable API was mentioned to be
the reason for not using Boost for a project.

Since some time I use Boost as well (tests and logging) and I'm
subscribed to the devel and user lists. There are I noticed as well that
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Philippi | 2 Dec 2007 15:02
Picon

Re: Using compression for savegames and addons

Am Sonntag 02 Dezember 2007 schrieb Jens Seidel:
> Now ask yourself: If trivial patches are not applied what happens with
> real errors?

They have much better chances to get solved I'd guess. People don't like to 
touch code maintained by others as this can lead to tension. If it's just a 
tiny improvement I'd wait much longer for the maintainer to take care of it 
then for important bugs.
In your case I'd suggest to simply ping patches older then 4 weeks.

Bye David
Permalink | Reply | 0 comments |
headers
Mark de Wever | 2 Dec 2007 17:04
Picon
Picon
Favicon

Asserts

Hi,

At the moment we use wassert which is mainly a wrapper to assert. But it
has an option to be used for platforms which don't support assert. Since
we also have code which uses the normal asserts I assume the code for
wassert to be obsolete. If there are no objections I'll remove
wassert.hpp and wassert.cpp and convert the code to use assert instead
of wassert.

Related to that we have quite some code that uses asserts on data
transferred from WML. For some reason our builds are compiled with
assertions still working, once we get a platform which doesn't we might
get some weird bug reports. I added WML_ASSERT [1] which can test a
condition but can also have a message to give hints to the user what
went wrong. When this assert is triggered it should be catch at game
level (or before) so we can show an error and go back to the
titlescreen. This avoids terminations due to asserts, which users see as
crashes. I'll look into converting the existing code to use this kind of
assert and also look at which asserts should be a runtime check.

Regards,

Mark de Wever aka Mordante/SkeletonCrew

[1] https://mail.gna.org/public/wesnoth-commits/2007-12/msg00024.html
Permalink | Reply | 2 comments |
headers
David Philippi | 2 Dec 2007 17:09
Picon

Re: Asserts

Am Sonntag 02 Dezember 2007 schrieb Mark de Wever:
> titlescreen. This avoids terminations due to asserts, which users see as
> crashes. I'll look into converting the existing code to use this kind of
> assert and also look at which asserts should be a runtime check.

I guess in 1.3.x / 1.5.x etc. assert in the build are ok but stable release 
series should be compiled with those turned off.

Bye David
Permalink | Reply | 0 comments |
headers
dave | 2 Dec 2007 18:19

Re: Asserts

Thank you for taking time to do this; I agree completely with your  
rationale and approach.

As a general note on asserts, I'd like to remind people that an assert  
should only be used for a condition that is NEVER logically able to  
happen, regardless of the program's input. A failed assertion always  
indicates that there is a bug in the engine. (Not in the WML or other  
input).

Also, it's okay for assert to be included in release builds, as long  
as the cost of the assert doesn't affect the performance of the build.  
We'd rather bugs be reported based on assertion failures rather than  
some weird abberant program behavior.

I tend to think that WML_ASSERT should actually throw an exception if  
it fails, and this exception should unwind things to some high level  
function where the error is reported.

The model we use for error handling is that errors internal to the  
engine (i.e. bugs) are handled by assertions. Errors external to the  
engine (i.e. bad input) are handled through exceptions.

David

Quoting Mark de Wever <koraq <at> xs4all.nl>:

> Hi,
>
> At the moment we use wassert which is mainly a wrapper to assert. But it
> has an option to be used for platforms which don't support assert. Since
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric S. Raymond | 2 Dec 2007 10:03
Picon

New bug in save/load

I'm seeing a new bug in save/load, possibly brought about by YogiHH's
recent bugfixes.

When I win ThoT::Fear, in my current test game, Aiglondur is L3.  If
I hit "End Scenario" to go to "Forbidden Forest" he is an L3 as he should be.

Hoever, if I then reload the scenbario start for "Forbidden Forest", 
Aiglondur is an L1.  Furthermore his start-event recalls do not occur.

Is anyone else seeing similar behavior in other scenarios?
--
					>>esr>>
Permalink | Reply | 0 comments |
headers
Lari Nieminen | 3 Dec 2007 14:56
Picon
Picon
Favicon

Fullheal AMLA for all

To allow max-level units to fullheal like all other units I'd propose 
giving them a fullheal AMLA in addition the the +3 HP one. So, when 
AMLAing you'd get to choose between fullhealing and +3 HP. Fullhealing 
wouldn't raise the XP limit for subsequent AMLAs, although it could be 
made to if that's wanted.

The reasoning behind it would be to let max-level units fullheal 
mid-scenario like every other unit. It gives you one more tactical 
option, and remedies what can be seen as a minor RIPLIB issue.

However, we'd need to change the necrophage's fullheal AMLA to something 
else, because the fullheal AMLA was supposed to be a specialty of the 
necrophage. Here's my suggestion:

An ability which grants +1 HP when killing a living unit (or any unit, 
if that seems better).

That's the same as what Ghast currently has in DiD, but it can be given 
something else instead (+1 per level of enemy killed, for instance). The 
unit seems to be commented out for the time being anyway.

I don't see any balancing issue in MP, as max-level units appear and can 
level only with silly settings or in special scenarios. In campaigns 
using max-level units to kill things would be slightly more useful to 
do, as you'd then get the ability to fullheal in the middle of a 
scenario at some point. It might make max-level units slightly more 
versatile in long campaigns, but not too much.

So, any arguments against such a change?
(Continue reading)

Permalink | Reply | 20 comments |
headers
jeremy rosen | 3 Dec 2007 15:13
Picon
Picon

Re: Fullheal AMLA for all

I'm not convinced the small riplib violation is worth the change. it makes units that don't have a lvl3 more powerfull in MP and makes the necrophage much less special...

I don't htink lvl3 units need to be healed mid-scenario, it's the player's job to protect them correctly..

On Dec 3, 2007 2:56 PM, Lari Nieminen <lari.nieminen <at> cs.helsinki.fi> wrote:
To allow max-level units to fullheal like all other units I'd propose
giving them a fullheal AMLA in addition the the +3 HP one. So, when
AMLAing you'd get to choose between fullhealing and +3 HP. Fullhealing
wouldn't raise the XP limit for subsequent AMLAs, although it could be
made to if that's wanted.

The reasoning behind it would be to let max-level units fullheal
mid-scenario like every other unit. It gives you one more tactical
option, and remedies what can be seen as a minor RIPLIB issue.

However, we'd need to change the necrophage's fullheal AMLA to something
else, because the fullheal AMLA was supposed to be a specialty of the
necrophage. Here's my suggestion:

An ability which grants +1 HP when killing a living unit (or any unit,
if that seems better).

That's the same as what Ghast currently has in DiD, but it can be given
something else instead (+1 per level of enemy killed, for instance). The
unit seems to be commented out for the time being anyway.

I don't see any balancing issue in MP, as max-level units appear and can
level only with silly settings or in special scenarios. In campaigns
using max-level units to kill things would be slightly more useful to
do, as you'd then get the ability to fullheal in the middle of a
scenario at some point. It might make max-level units slightly more
versatile in long campaigns, but not too much.

So, any arguments against such a change?


--
Lari Nieminen, a.k.a. zookeeper
lari.nieminen <at> cs.helsinki.fi
+358443758373

_______________________________________________
Wesnoth-dev mailing list
Wesnoth-dev <at> gna.org
https://mail.gna.org/listinfo/wesnoth-dev

_______________________________________________
Wesnoth-dev mailing list
Wesnoth-dev <at> gna.org
https://mail.gna.org/listinfo/wesnoth-dev
Permalink | Reply | 0 comments |
headers
Benoit Timbert | 3 Dec 2007 15:21
Picon
Favicon

Re: Fullheal AMLA for all

Selon Lari Nieminen <lari.nieminen <at> cs.helsinki.fi>:

> To allow max-level units to fullheal like all other units I'd propose
> giving them a fullheal AMLA in addition the the +3 HP one. So, when
> AMLAing you'd get to choose between fullhealing and +3 HP. Fullhealing
> wouldn't raise the XP limit for subsequent AMLAs, although it could be
> made to if that's wanted.
>
> The reasoning behind it would be to let max-level units fullheal
> mid-scenario like every other unit. It gives you one more tactical
> option, and remedies what can be seen as a minor RIPLIB issue.

But it would probably ruin some scenarios, making the game too easy.
Think about scenario liek the valley of death where a melee unit that too the
holy potion would probably stand forever alive against a horde of zombies...
Full healing when leveling is more or less necessary because we have a new unit
and handling the HP when leveling isn't complex that way, but still it doesn't
make a lot of sense to me.
Full healing on AMLA don't have any justification for me (except some special
units), it doesn't make sense.
I'd rather like to have not healing on levelup than full healing on general
AMLAs, but handling the HP on levelup would be a lot more complex (maybe this
will happen some day)...
Do you think it is nice that (not too much) badly hurt unit is hard to kill
because it's 1 xp to level ?
I do not.

> However, we'd need to change the necrophage's fullheal AMLA to something
> else, because the fullheal AMLA was supposed to be a specialty of the
> necrophage. Here's my suggestion:
>
> An ability which grants +1 HP when killing a living unit (or any unit,
> if that seems better).
>
> That's the same as what Ghast currently has in DiD, but it can be given
> something else instead (+1 per level of enemy killed, for instance). The
> unit seems to be commented out for the time being anyway.
>
> I don't see any balancing issue in MP, as max-level units appear and can
> level only with silly settings or in special scenarios. In campaigns
> using max-level units to kill things would be slightly more useful to
> do, as you'd then get the ability to fullheal in the middle of a
> scenario at some point. It might make max-level units slightly more
> versatile in long campaigns, but not too much.

Sure, such situations rarely happen in a typical 1 vs 1 or 2 vs 2 duel,
but it is more likely to happen in some other styles of MP games, survivals in
particular.
I don't like it.
Permalink | Reply | 6 comments |

Gmane