[CF-Devel] Iso CF start phase

[Mark Wedel]

Michael Toennies wrote:
>
     
     
     
>
     
      ** PLEASE don't touch the CVS until i do the release today or next day**
     
     
 I strongly disagree that CVS should be frozen for other updates in pretty much
all cases.

 cvs provides automatic update and merging capabilities, so generally this
should not be a problem.

 If it ends up that the merge doesn't happen automatically, and needs to be done
by hand, this is effectively saying 'I can't be bothered to do the merges by
hand, so you should merge in your changes by hand instead'.  IMO this is not a
good thing for a community project, and if such freezes happen, I think it will
be detrimental to people coding (hmm..  I shouldn't do any coding this weekend
because I'll have to merge it in by hand.  Then next weekend, someone else may
do a 'freeze' for their own, same result, so I shouldn't do any coding then,
etc.)


>
     
      1.) the editor do the collect for the arches. It will write:
     
     >
     
      - bmaps.
     
     >
     
      - crossfire.png
     
     >
     
      - archetypes
     
     >
     
      - animations
     
     
 The current collection method must remain available.  If I'm just doing some
quick change for some arch, I don't want to have to load up the java editor just
to collect those.  Maybe the server doesn't even have java installed, or is set
up such a way that I can display back to my system.

 And really, it would probably make more sense for the java editor to just use
the existing collect scripts.  If the java editor creates the files in the same
form, no big deal, and I don't have a problem with the java editor having a
collection option, but that must not be the only way they can be collected.  I'm
also really suspect about having the editor actually create archs - yes, it may
allow for better checking on integretity, but at the same time may lead to a lot
of new archs being created when they in fact should not be.


>
     
      2.) transfering arches and maps
     
     >
     
     
     >
     
      I will setup the arch and maps in a way, we must touch every pieces to
     
     >
     
      transfer
     
     >
     
      it to iso. The editor will have some commands to automate this, for example
     
     >
     
      a
     
     >
     
      find & replace thing.
     
     
 I'm unclear what exactly this means.

 Non ISO support MUST REMAIN.  (or not, but if overhead view goes away, so might
I).  I really really really dislike iso views for most games.  Yes, it looks
nicer, but I find the playing of it a PITA.

 I'm going to send out another message about more large scale map updates.  But
IMO if every map needs to get touched up for ISO, in addition for every
archetype/image, this results in a ton of work.


>
     
      Let me say that this will give us the chance:
     
     >
     
      - to restyle some maps
     
     >
     
      - using more intelligence style sets!
     
     >
     
      - style sets will give the power to use mask, i will introduce this later
     
     >
     
      - rework the painful looking of some maps
     
     >
     
      - and so on
     
     
 Some maps need that.  But I'm fearful of this ever getting done.  Doing
something like updating every map will take a ton of time - I've seen this with
the images.


>
     
      But we have MANY unfinished maps!
     
     >
     
       - bad style
     
     >
     
       - unused exits
     
     >
     
       - unfinished quest
     
     >
     
       - broken maps!
     
     
 That of course has nothing to do with iso or map form.  It is just a matter of
resources - the person doing the map ran out of time, moved on to somethign
else, or may just ran out of ideas.  I don't see how having to rework all the
current maps is going to help that out at all, except to maybe get a more
conistent step.

>
     
      Ask AV about how long he needs to finds out the puplands map and how much
     
     >
     
      work it was.
     
     
 documentation about maps (and anything else) is a pure developer issue.  Rework
all the maps you want, but if the developers don't write the docs about the new
maps, you run into the same problem.  The reason of lack of docs is (either map
or programming/arch/whatever) is simply because people don't write them.  Unless
we force them somehow (don't accept anything without doc), I think we will get
into the same program again.  But if we get too anal about what we accept, then
you get into the problem of people saying 'I don't want to jump through those
hoops', and thus don't develope.


>
     
      3.) Scripting: Scriptfire
     
     >
     
     
     >
     
      Scripting is so great and gros scriptfire works fine.
     
     >
     
      This will give us the chance to include this from bottom up.
     
     >
     
      MW will put it in CVS, so we can use it in all versions.
     
     
 I said it should probably be put it, but didn't actually volunteer myself to do
it  Gros - do you think it is ready for inclusion?

>
     
     
     >
     
      4.) Client hacks for windows and linux
     
     >
     
     
     >
     
      I will do a fast patch so linux and dx client can show & play iso maps.
     
     
 Don't do fast patches, do proper patches.

 One of my pet peeves is the 'fast patch' which takes the easy approach and then
needs to get fixed up later to do the properly thing. 

 IMO, what proper means in this context is command line option to switch between
iso and non iso display.