[CF-Devel] Iso CF start phase

[Michael Toennies]

Only a shot note to this (i am hard on work on iso).

true to booth here:

- Overlook will not go away as long people support it.
  Ther will be differences in map sets, thats the worst
  one, but perhaps this can be reworked (that the iso maps
  will be used for flat).

  this is needed, because from (ok my) technical point it is better
  to see flat as downcasted iso and not iso as a boosted flat perspective.
  Iso has more tricks in it.

  But the discussion goes in a worng way: We don't talk about Diablo gfx.
  Ok, from some points, it is same, but our CF iso is more a hybrid, a not
  so die hard iso style with not so extreme views.

  Think more about it in a boosted flat mode, which will hopefully be
  liked from most people - hopefully Mark too. :)

- There will be no game play change or server differences
  I strongly look in this. Changing the dx client to iso is done in 12 lines
different code.

- the CVS freeze: i do some strong cuts in maps, arches and clients. Its
hard to make this
  without mistakes and so on. Also, i must rework the windows server (is
broken trough some
  changes to source) and include the scripts in it (need much libs) and drop
out a binary.
  I really only want a "hold on folks, here comes a bunch of code and work".

>
     
     
     >
     
       A few clarifications/thoughts.
     
     >
     
     
     >
     
       I realized after I sent my last message it may be taken in the
     
     >
     
      wrong way (ie,
     
     >
     
      my leaving crossfire).  What I really meant to say in that is
     
     >
     
      that if crossfire
     
     >
     
      evolves into a game that I don't want to play (only isomorphic
     
     >
     
      view), then its a
     
     >
     
      pretty sure bet that I won't develope for it anymore.
     
     >
     
     
     >
     
       I also just wanted to make it clear that IMO non isomorphic view should
     
     >
     
      continue to be supported.  If nothing else because I think it is
     
     >
     
      going to take
     
     >
     
      quite a while for the isomorphic view to get completed (in terms
     
     >
     
      of maps and
     
     >
     
      images).  This is from prior experience on crossfire.  Now I may
     
     >
     
      be wrong about
     
     >
     
      this - it wouldn't be the first time I am wrong about something.
     
     >
     
     
     >
     
       Note that MT never said that the overhead view was going away.
     
     >
     
      I just want to
     
     >
     
      hopefully be clear that his changes do not remove that support
     
     >
     
      for 'traditional'
     
     >
     
      play.
     
     >
     
     
     >
     
       Re CVS freeze (or non checkin - amounts to the same thing):
     
     >
     
      Now its only my opinion, but IMO I just don't think its good for
     
     >
     
      development.
     
     >
     
      Part of CVS is anyone being able to do updates at most any time.
     
     >
     
     
     >
     
       And that said, the normal cvs process is:
     
     >
     
     
     >
     
      1) cvs update
     
     >
     
      2) make changes
     
     >
     
      3) cvs commit - if you have modified files that are not current
     
     >
     
      in CVS, cvs
     
     >
     
      won't let you commit them, so continue on to step 4 below - if
     
     >
     
      other people have
     
     >
     
      modified files that you have no modified, no problem
     
     >
     
      4) cvs update old files
     
     >
     
      5) may or may not need to do hand merging
     
     >
     
      6) compile, run quick test (quick test may not be much more than
     
     >
     
      verify it does
     
     >
     
      compile and runs, presuming that more thorough testing was done before)
     
     >
     
      7) cvs commit again.
     
     >
     
     
     >
     
       Now to me, the idea of making a 'non commit except for me' phase
     
     >
     
      is that its
     
     >
     
      basically saying the other guy should do steps 4-7 and not me.  I
     
     >
     
      just don't
     
     >
     
      think thats good for a community project.  As a coder, it
     
     >
     
      basically says to me
     
     >
     
      that perhaps I should wait before starting any changes, otherwise
     
     >
     
      I'll most
     
     >
     
      definately have to do step 4-7 because someone else is doing a
     
     >
     
      big check in,
     
     >
     
      even if my changes may be smaller and I could get them done
     
     >
     
      before that other
     
     >
     
      checkin is done.
     
     >
     
     
     >
     
      But if we agree its OK (which it sounds like we do), then I'll
     
     >
     
      start using it in
     
     >
     
      the future also (like when I start on the map tiling).  Not
     
     >
     
      having to do steps
     
     >
     
      4-7 will probably save me some amount of work.
     
     >
     
     
     >
     
       Now perhaps MT overstated the amount of freeze really needed,
     
     >
     
      but from the
     
     >
     
      message:
     
     >
     
      ** PLEASE don't touch the CVS until i do the release today or next day**
     
     >
     
     
     >
     
       This suggest to me that no change no matter how small should be
     
     >
     
      made to CVS.
     
     >
     
     
     >
     
       As said, if we agree that developers can 'freeze' cvs for times
     
     >
     
      while they work
     
     >
     
      on big projects, I can live with that.  I just wanted to state
     
     >
     
      that I think that
     
     >
     
      will be bad for development in the long run - especially if it
     
     >
     
      starts to get
     
     >
     
      overused.
     
     >
     
      _______________________________________________
     
     >
     
      crossfire-devel mailing list
     
     >
     
     
      crossfire-devel at lists.real-time.com
      
      
     >
     
     
      https://mailman.real-time.com/mailman/listinfo/crossfire-devel
      
      
     >