[CF-Devel] new generator code

Thu Sep 4 06:32:06 CDT 2003

Le Jeudi 04 Septembre 2003 07:37, Mark Wedel a écrit :
>

      David Delbecq wrote:

     >

     >

        As a note, I have no problem with the idea itself - generators being able

     >

      to spawn inventory makes a lot of sense.  But I have some minor nits.

     >

     >

      > --

     >

      > There are 2 types of generators in crossfire since september 2003.

     >

      > both are identified as generators by setting the flag "generate" to 1.

     >

      > For the first type (the classical one) use "other_arch" to specify

     >

      > archetype of object to be spawned.

     >

      > The second type allow more fine tuning on what to generate. To activate

     >

      > second type, set the flag "use_content_on_gen" to 1. Then each

     >

      > time something must be generated, it will be a copy of a randomly

     >

      > choosen item in the generator's inventory.

     >

     >

        Why use such a flag at all?  It'd be much better to just have code like

     >

      'if generator->inv, use generator->inv for object, otherwise use

     >

      generator->other_arch'.

Cause, simply, someone may already have created a mouse with pearls in it's 
inventory or a key but mice are generators. I don't want on such map people 
asking 'why does my mouse drop pearls now and don't duplicate itself?'
I dunno if self-duplicating monster with randomitems in their inventory exists 
in arch or maps, but they would make sense, while stilling using the 
other_arch field (inventory way does not allow infinit list of generations 
unlike other_Arch way). So i implemented this the way which wouldn't have 
broke the existing.

>

     >

        I can't see any reason why that flag is needed.

     >

     >

        As an aside, this is a note to all developers, but things I definately

     >

      saw in your last two checkins:

     >

     >

      1) Please be careful about changing whitespace unecessary.  Eg, don't

     >

      change comments, }, or whatever else unecessarily.  If you're changing the

     >

      code in that area, fine, but there were several occasions in the last

     >

      checking in which whitespace changed in code not anywhere close/related to

     >

      other changes.  This may not seem like a big issue, until you realize that

     >

      other people working on the code with modified sources - it can cause

     >

      unnecessarily need to resolve conflicts that needs to be resolved if they

     >

      have modified the code.

sorry, simply seems all developpers are using differents characterisitcs for 
their 'tab' key, which most of time render code unreadable cause there is a 
mix of tabs and whitespace.
Most of the time when modifying a function, i redo tab indentation with <tab> 
indentation. Sorry for convenience, won't do i again.

>

     >

        I suggest that you should always run a cvs diff on the stuff before you

     >

      check in - make sure there are not unnecesarily changes.

ok

>

     >

      2) Make sure the program compiles without warnings with some reasonable

     >

      strict checking - -Wall with gcc for example.  There was an error in the

     >

      renaming code - was doing a cp==' ', when it should have been *cp - simple

     >

      error gcc caught. Also catches unused variables and other behaviour.

     >

Did i fail to notice it? I always check for gcc warning. Seems this one was 
hidding somewhere between two compilation lines.

>

     >

     >

     >

     >

      _______________________________________________

     >

      crossfire-devel mailing list

     >

      crossfire-devel at lists.real-time.com

     >

      https://mailman.real-time.com/mailman/listinfo/crossfire-devel

_______________________________________________
crossfire-devel mailing list

     crossfire-devel at lists.real-time.com

     https://mailman.real-time.com/mailman/listinfo/crossfire-devel