Alex Schultz | 3 Jun 2005 01:04

Re: Spellcasting Swords progress

Andrew Fuchs wrote:

>On 6/2/05, Alex Schultz <alex_sch@...> wrote:
>
>>I tested it putting the sword on a map and that works except for the
>>above mentioned information loss. However when I tested it by using the
>>DM "create" command, the randomitems were not obeyed.
>>
>>I assume this information loss is because the treasurelists don't accept
>>such data and only use the defaults of the arch, so one solution would
>>be creating an arch for each rod that I want to use on the swords,
>>however I feel that would be a bit kludgy, and I am wondering if anybody
>>has any better solutions.
>>
>
>I the file "/lib/artifacts" in the server branch takes care of the
>modifiers for objects.
>Though, IMO this still is not very clean.
>
However the problem is that unless I'm missing something, there is no 
way to insert something made from the artifacts file into the inventory 
of an arch by default.  This doesn't prevent what I mentioned above 
about creating an arch for every rod that I want to make a spellcasting 
sword with, however IMO that's way too much of a dirty hack.
Unless somebody has a better solution, I might try and make it possible 
to nest objects inside others in arches just like one can already do in 
maps.

     Thanks,
          Alex Schultz
(Continue reading)

Brendan Lally | 3 Jun 2005 03:01
Picon
Picon

Re: new metaserver

>>> mwedel@... 06/02/05 08:23 AM >>>

> 1) Has someone agreed to run the metametaserver?  What about the slave 
> metaservers?

I can host one, maybe two, but this assumes the use of HTTP.

> 4) Has anyone considered the approach where all the servers talk to the 
> metametaserver (lets call it the master metaserver), and all the metaservers 
> just regularly pull updates from the master metaserver?  

That is pretty much what I have been doing, except with all metaservers being 'passive' and without the
metametaserver being protected.

>  Just some thoughts.  I'd probably still be good to rewrite the metaserver 
>logic, but IMO, having the servers talk to web servers is an extra complication 
>- pretty much all metaservers that are out there (certainly netrek at a minimum) 
> use their own protocol for the servers to update the metaserver.

I know that freeciv uses HTTP POSTs to send data to its metaserver.

As it is HTTP is simpler, there are libraries (libcurl) that make it easier than dealing with sockets
directly, and when there is a web server sitting in the middle then issues like threading, locking and
blocking are dealt with automagically. Web servers often can behefit from things like caching also, and
it may be possible to get compression for free too (I haven't looked into mod_gzip in detail yet).

It is also far easier to find places to host.
Mark Wedel | 3 Jun 2005 06:17
Favicon

Re: No autogen.sh for the client?

tchize wrote:

> 
> Speaking about automake.
> 
> Since a few week i noticed each time i do a commit, all the Makefile.in are 
> commited along. Did someone change the configure script to regenerate 
> automake.in file each time a ./configure is run? If that's the case, maybe 
> removing Makefile.in files from cvs would be a good think (if they became 
> machine dependent, there is no reason to keep them in CVS)

  Some file is out of sync, so it keeps re-running automake.  One would normally 
thing this should correct itself once the up to date ones are committed.  Maybe 
something that the makefiles depend on was committed with a bogus date.

  The rationale for having the Makefile.in's in CVS is to make it easier for 
users to grab snapshots and not need a large set of tools.  Ideally, this 
dependency should get fixed up somehow so that it doesn't re-run automake every 
time.
Mark Wedel | 3 Jun 2005 06:20
Favicon

Re: ingame music

Andrew Fuchs wrote:
> On 6/2/05, Mark Wedel <mwedel@...> wrote:
> 
>>  The obvious question for this is how to handle it.
>>
>>  Would it be sufficient to have map wide values of 'music' to play, such that
>>we just need to add a value to the map header?  Or do people see the need/desire
>>that they may want different music depending where on the map they are?
>>
>>  I'd separate this discussion from that of background or other noises, of which
>>those should be tied to objects.  But something like this music wouldn't seem to
>>be tied to any specific object.
> 
> 
> Yes, having the value in the map header is mainly what is needed,
> though hijacking the lighting code would be the way to go for
> connecting it to specific objects.

  Perhaps, but not positive if that will work.  Lighting is just a single value. 
  If you try to hijack that code for music, you will get cases of two sources 
overlapping, so that single value doesn't work - you then need to store both 
sources or figure out which is louder or something.

> 
> There is also the posibility of adding fields to triger sounds when
> items are applied (not hard coded like the current system).

  Yes, and that is on the TODO list.  But that is seperate from music, because 
those are mostly going to be things that get played as direct result of actions 
and not persist in the background for ever (although there are perhaps some 
(Continue reading)

Mitch Obrian | 3 Jun 2005 06:39
Picon
Favicon

Re: new metaserver

I can also host a slave metaserver.

--- Brendan Lally <B.T.Lally@...> wrote:

> >>> mwedel@... 06/02/05 08:23 AM >>>
> 
> > 1) Has someone agreed to run the metametaserver? 
> What about the slave 
> > metaservers?
> 
> I can host one, maybe two, but this assumes the use
> of HTTP.
> 
> > 4) Has anyone considered the approach where all
> the servers talk to the 
> > metametaserver (lets call it the master
> metaserver), and all the metaservers 
> > just regularly pull updates from the master
> metaserver?  
> 
> That is pretty much what I have been doing, except
> with all metaservers being 'passive' and without the
> metametaserver being protected.
> 
> >  Just some thoughts.  I'd probably still be good
> to rewrite the metaserver 
> >logic, but IMO, having the servers talk to web
> servers is an extra complication 
> >- pretty much all metaservers that are out there
> (certainly netrek at a minimum) 
(Continue reading)

ERACC | 3 Jun 2005 21:33

Re: Proposal to fix experience inflation due to random maps

On Tuesday 31 May 2005 09:32 pm
Todd Mitchell wrote:

> monster density - I think part of the problem with the monster density 
> is that terrain is either blocked or not. [...]

I am looking at the Valriel random map settings (within the map
/scorn/temples/valriel3) in anticipation of reducing the number of
levels, reducing monster density, adding some "new", tougher monsters
called "saints" using existing NPC arches and making the random maps
larger. One question I have but haven't been able to resolve: is
random map monster density determined by /styles/monsterstyles/* or
is it elsewhere? I asked this on IRC this morning (here) but
apparently everyone is dead there today. :-)

> Boss monsters - good idea

This would mean making a final map (like the one for Titan Quest) and
adding these boss monsters. Maybe for the Valriel one have one fight
the Avatar of Valriel (a customized Arch Angel perhaps). Should these
bosses drop or guard some sort of special treasure or is the
experience gained reward enough?

> One point - the random map styles are very ripe for development and 
> adjustment.  This alone would really improve the random maps and allow 
> more control - especially with the difficulty stepping code that was 
> recently added.

Well, I am looking in the map /styles directory for information on
how to work on these. Is there somewhere else I should be looking as
(Continue reading)

ERACC | 3 Jun 2005 23:33

Lone Town Permanent Apartment

Hello All,

I am working on ideas for the Permanent Apartments I am placing in
Lone Town. I am thinking of making it buildable of course. I am also
thinking of making an area in the main apartment that one can
purchase (for a LOT of diamonds) that is a "kitchen" and has a stove
one may use for "food" alchemy. I am also considering a basement area
that has side rooms for the other types of alchemy like jeweler,
bowyer and smithery with the proper "cauldron" for each. Each of
these would have to be purchased separately and would cost a great
deal to purchase. The cauldrons would be on regular tiles and would
return after a reset if they "got blowed up". The other areas in each
room would be unique.

Discussion please.

Gene
--

-- 
Linux era4.eracc.UUCP 2.6.8.1-12mdk i686
 16:17:53 up 16 days, 16:54,  8 users,  load average: 0.07, 0.02, 0.01
ERA Computer Consulting - http://www.eracc.com/
eCS, OS/2, Mandriva Linux, OpenServer & UnixWare resellers
Todd Mitchell | 4 Jun 2005 02:44
Picon
Favicon

Re: Proposal to fix experience inflation due to random maps

On Fri, 2005-03-06 at 14:33 -0500, ERACC wrote:
> On Tuesday 31 May 2005 09:32 pm
> Todd Mitchell wrote:
> 
> > monster density - I think part of the problem with the monster density 
> > is that terrain is either blocked or not. [...]
> 
> I am looking at the Valriel random map settings (within the map
> /scorn/temples/valriel3) in anticipation of reducing the number of
> levels, reducing monster density, adding some "new", tougher monsters
> called "saints" using existing NPC arches and making the random maps
> larger. One question I have but haven't been able to resolve: is
> random map monster density determined by /styles/monsterstyles/* or
> is it elsewhere? I asked this on IRC this morning (here) but
> apparently everyone is dead there today. :-)
> 

I believe it is determined by the monsterstyles but not sure how it
functions.

> > Boss monsters - good idea
> 
> This would mean making a final map (like the one for Titan Quest) and
> adding these boss monsters. Maybe for the Valriel one have one fight
> the Avatar of Valriel (a customized Arch Angel perhaps). Should these
> bosses drop or guard some sort of special treasure or is the
> experience gained reward enough?

Well the final map is one thing but Boss monsters would have to be done
in the code I think - something to figure out what monsters are being
(Continue reading)

Brendan Lally | 4 Jun 2005 04:52
Picon
Picon

Re: ingame music

>>> mwedel@... 06/03/05 05:24 AM >>>

>  Perhaps, but not positive if that will work.  Lighting is just a single value. 
>  If you try to hijack that code for music, you will get cases of two sources 
> overlapping, so that single value doesn't work - you then need to store both 
> sources or figure out which is louder or something.

This is a limitation the lighting code could do without also. If such a mechanism were used for the sound code
anyway, then it could usefully be extended to the lighting code to allow coloured lights. I don't know how
easy it would be to implement client side, but it would be a nice way to give feedback on some levels, or
create interesting optical effects.

The easist thing to do in that case then would be to store RGB values in the stats for the light object, and then
when they overlap have the resulting colour be the weighted mean in each value. (based on proximity and
strength of source).

Likewise with music, the resulting sound could be the songs all mixed together with volumes varing
depending on their source volume (glow radius) and the distance from the source.
Mitch Obrian | 4 Jun 2005 04:54
Picon
Favicon

Re: Lone Town Permanent Apartment

For the non-unique floors I suggest naming them nosave
or something similar. (tis what I do). That way users
won't leave stuff there.

Death To women's Rights.

--- ERACC <eracclists@...> wrote:

> Hello All,
> 
> I am working on ideas for the Permanent Apartments I
> am placing in
> Lone Town. I am thinking of making it buildable of
> course. I am also
> thinking of making an area in the main apartment
> that one can
> purchase (for a LOT of diamonds) that is a "kitchen"
> and has a stove
> one may use for "food" alchemy. I am also
> considering a basement area
> that has side rooms for the other types of alchemy
> like jeweler,
> bowyer and smithery with the proper "cauldron" for
> each. Each of
> these would have to be purchased separately and
> would cost a great
> deal to purchase. The cauldrons would be on regular
> tiles and would
> return after a reset if they "got blowed up". The
> other areas in each
(Continue reading)


Gmane