[CF-Devel] new release: CFJavaEditor 0.971
dnh
dnh at hawthorn.csse.monash.edu.au
Wed Jun 20 03:51:02 CDT 2001
On Wed, 20 Jun 2001, Michael Toennies wrote:
>
Type information is a absolut unique identifier.
>
To advance it, we also talked about to make a second byte
>
which is then the under type typ.
>
>
like type x = weapon. x,1 = swords, x,2 = axes...
>
>
This is absolut enough information for the client.
Fair enough
>
Also, the color information submited with the magic map command is more
>
than worse. You will not have different colors... magic map is normally
>
build up by 13 or 16 colors ors so. Seems a relict from 16 colors days.
>
>
And, it its the xbm/xpm color system.
Indeed that is probably because it is.
>
Really, this is another discussion which blocks the game and make
>
much work in the future, only to safe yet some time.
Nobody is stopping you, I certainly am not. I know personally I don't have
copius amounts of time floating about and I lack the skills to do it
anyway. If you find something wrong and you want to fix it, go for it. I
don't see why we are wrong to express concern about the REMOVAL of a
feature because someone else thinks it isn't efficient. Would anyone be
happy id I decided I don't like any maps and deleted them all? would you
mind it if I decided I didn't like your client and deleted it? I some how
doubt it, if you want to work in a team project Mich, you might want to
consider other members positions. We are all happy to see new and exciting
things, and really glad when someone finally fixes that stupid bug here
etc etc. but when you start declaring that something is old and crappy,
but not providing a solution bar just removing it... obviously people are
going to question why.
I don't use magic map very often, probably because I know every map
already, but I don't like the idea of things just simply being removed.
You are complaining about creating work, would you like a list of current
bugs which no one has fixed?
*Monks wielding weapons
*Priest switching gods to gain all godly artifacts
*Speed problems concerning n^x spells calculations
*Server handling of entering and exiting...
I would consider alot of these more important than removing magic map blah
blah blah. I think you get my point.
Anyway, I never really liked the way magic mapping's interface was
handled, nor how it looked. Is anyone prepared to rework it? I am happy to
discuss how we can improve it so if anyone is interested gimme a bell =).
The new ISO set is looking very nice indeed, can anyone write out some
sort of way to install it all simply in debian. I really need some sort of
java .deb package and I was wondering which ones I should get.. mids?
food for thought
dnh
>
I had removed the visiblity and magicmap command from the iso arches and
>
i will not use it anymore. If no one build here a better magic map spell,
>
i hack in a short type to color transformation in the server.
>
>
I had remove it, when one miss it (what will not happens so fast) he can
>
build
>
something better.
>
>
>
>
>
>
> Hmm i tend to agree with mark here, while it may be silly to put face
>
> colour in there when we aready have the images. It seems both wasteful and
>
> very time consuming to create a new method. I don't really have a better
>
> suggestion for how to do it, though I would like to point out. There are
>
> some cases where certain tiles have been given strange colours to make
>
> sure if people use magic map it stands out. I can think of one classic
>
> example where there is a river, and they only way to get across is by dim
>
> dooring on the right angle. To help the player the correct path is a
>
> different colour on magic map. Now how else could map makers store this
>
> sort of information?
>
>
Using a different water arch.
>
>
>
> dnh
>
>
>
> On Tue, 19 Jun 2001, Mark Wedel wrote:
>
>
>
> > Michael Toennies wrote:
>
> >
>
> > > Also, as i add i copy&paste a false name, so i make a
>
> yoyodyme folder in CVS
>
> > > main tree.
>
> > > Can one remove it? Mark, Tanners?
>
> >
>
> > Since the CVS repository is hosted on sourceforge, everyone
>
> basically has the
>
> > same power to create/destroy.
>
> >
>
> > > The face file should be also removed, its nonsense to assign
>
> xpm/xbm color
>
> > > values to the faces.
>
> > > As i understand, this is used for the magic map command. This must be
>
> > > reworked for the png only
>
> > > set, so i drop it too.
>
> >
>
> > Do you have a better suggestion for what to do? Its easy to
>
> say what is
>
> > currently there is not ideal, but often harder to come up with
>
> a good solution.
>
> >
>
> > For png, if magic map is to be supported in the same form,
>
> that information is
>
> > needed. The server otherwise has no way of knowing what color
>
> the different
>
> > items are (and since as far as the server is concerned, the
>
> images are just a
>
> > bunch of bits which it does not understand, so it can't really
>
> look at the
>
> > images and generate what color it should be).
>
> >
>
> > Since the color/face data already exists, it makes keeping and
>
> using it the
>
> > easiest solution.
>
> >
>
> > Now magic mapping could of course get reworked to do something
>
> else, like send
>
> > the actual faces for all the spaces, and the client can then
>
> scale it down or
>
> > the like (which many other games do for the larger view). This
>
> would consume
>
> > much more bandwidth (at minimum, twice as much of only 1
>
> face/square is sent),
>
> > and may be much more useful (if all faces on a space are sent)
>
> or less useful
>
> > (if bottom space (typically terrain/floor/wall) is sent, or
>
> somewhere between
>
> > depending on what all gets sent.
>
> >
>
> >
>
> > >
>
> > > Michael
>
> > >
>
> > > _______________________________________________
>
> > > 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
>
> >
>
>
>
> _______________________________________________
>
> 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
>
More information about the crossfire
mailing list