Crossfire Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CF: Re: Crossfire 0.94.2 released

On May 20,  3:58pm, Christian Stieber wrote:
> Subject: CF: Re: Crossfire 0.94.2 released
> Mark Wedel (mark@pyramid.com) wrote:

> Still, some objects are not merged yet. Is there some sort of informal
> "list" telling what objects should not be merged, or is this just
> because nobody has fixed the archetypes/maps?

 Likely because nobody has fixed the archetypes/maps.  If nrof=0 on an object,
it will not be merged.  Note that removing that fixing such objects may require
changes in the apply code (ie, if gauntlets are mergable, and you merge 2
gauntlets of strength +3, the apply code needs to break them apart before
applying).  However, you can't break apart all items that are applied - I
believe there are some things that need to be kept together when applied.


> I guess this means you people are pretty confident that the new cs code
> is actually usable now. Which brings me to my question: is there a way
> to let players keep their keybindings? Some way of letting players copy
> the bindings from a character into their private keybinding file? Or
> do I have to tell the players "sorry, you'll have to redo your keybindings"
> once the X code is removed from the server?

 I use the client exclusively for play, and have not found any real problems
with it.

 To preserve keys from characters:

 Take the 'key' entries out of the save file, remove the 'key ' at the start of
each line, and put the remainder in ~/.crossfire/keys

 Granted, this requires that the players can either access their save files, or
you send them too them.  However, the advantage here is teh keys are now set of
the player, even with different characters (I suppose this could be a
disadvantage if you have several characters and what radically different
bindings between them however).

>
> Other than that, the client seems still quite experimental, considering
> that it prints all sorts of stuff that players are not interested in :-(

 Its a lot of harmless debugging information.  Compile ther server with the
DEBUG option, and see how much output you get there.  Does that make the server
less playable?  Granted, that isn't especially cosmetic for the client - I'll
have to look at cleaning it up, or at least only get that much output if
running with a debug flag or something.

>
> > have a new archetypes file.  The second reason is that there were a lot of
> > formatting changes made, which would make for a fairly large and/or a
fairly
> > messy patch.
>
> Hm... Ignore whitespace option?

 Lots of lines also changed from things like

 if (...)
 {

 to

 if (...) {

 And ignore whitespace doesn't handle those.

>
> > Added hitback code (looks like it was missing from the NEW_HIT_PLAYER
> > code)
>
> Does this mean I just have to stand there to kill monsters? I've always
> missed that...

 I don't think so.  I belive the hitback code is only for certain monsters,
like teh acidsphere - stuff with FLAG_HITBACK set.  Now if you manage to get
that set in a character, you have an interesting situation.


> Finally :-) You can still get exp multiple times, of course, but it is much
> more complicated now, and requires a fair amount of crossfire knowledge.
> I'll probably get killed for disclosing this, esp. since nobody else seems
> to be interested in disclosing such information :-)

 Some sections of the code need to be cleaned up.  Experience going to the
right skill category is still a problem (I wonder if doing a get owner to the
skill category might work better than setting it to the player).  However, that
requires a bit of rewriting.  Maybe not - maybe set_owner can be changed such
that if the new owner is a player, we set the owner to that players current exp
object, otherwise set it to the object itself.  However, add_exp and other
stuff would also be modified.  Such a change is likely to fix some bugs, and
introducte new ones.

 However, skills and objects has always been a little problematic.  You want to
limit the use of a skill once to prevent a player from getting repeated exp,
but we probably don't want to add a flag for each skill.


>
> Too bad that the fun is decreasing... finding new ways of getting exp
> after some ways have been removed; but it now seems that things get rather
> complicated, so we can't afford to post details to the list :-) We don't
> know enough ways to get exp to afford loosing one :-)

 If you just wants gobs of experience by using loopholes, why not just add a
couple zero's to the experience total in the save file?  Or for that matter,
create a map which has every artifact (or maybe new super powerful ones), with
a bunch of orcs work 1,000,000,000 exp each on it.

 If your goal is to find loopholes to get exp, fine.  But that type of goal
seems a bit odd when there is open source, and in fact you ahve actually
contributed source to it.  Should I take no source from you on the basis you
might try to work in a new loophole to gain exp from it?

>
> How about _adding_ some new ways to gain exp fast? That way people could
> report some way, you remove them, and add another one so people can still
> have fun finding and using it :-)

 See my comments above.


> Hm... suddenly Dark Angel Hanuk (Ithe one with the meteor swarm spellbook
> in Lake Country) is casting meteor swarm... he never did that before :-(
> Seems one has to get the meteor swarm spellbook from pupland, and get the
> golden unicorn horn later on. :-(

 I think he did get beefed up some.

>
> I don't see any references to the show invisible bug :-( Seems I still
> have to tell people that certain parts of pupland are inaccessible in
> crossfire 0.94.x, instead of "crossfire <0.94.2" :-(

 I would have to look at the function in question to be sure.  However, I
thought a couple more items were added to the list of things to make visible,
but not positive.


-- 

-- Mark Wedel
mark@pyramid.com
[to unsubscribe etc., send mail to crossfire-request@ifi.uio.no]
References: