On Fri, 23 Jun 2017, Kevin Zheng wrote:
As much as possible I've been automating the world building. I hope it
offers different game play to keep people interested.
I think this could offer something to players who want to try something
new. Is the new world compatible with the standard
On 06/23/2017 07:56 PM, Rick Tanner wrote:
> On 6/23/17 10:02 AM, Matthew Giassa wrote:
>>
>> Also, has anyone tested how much bandwidth, disk space, etc; the latest
>> stable release uses under a test load (i.e. a few users/players)?
>
> Disk space needed for (trunk only) source content:
>
On 6/23/17 10:02 AM, Matthew Giassa wrote:
>
> Finally, who maintains the package currently available via `apt` on
> Ubuntu/Debian systems? The Ubuntu page notes that it is Kari Pahula [1].
> Is this person a CF dev?
*IF* it is someone else, I am not aware of it.
To my knowledge Kari Pahula has
On 06/25/2017 08:18 AM, Matthew Giassa wrote:
My guess is with meteor, let's assume 10 projectiles in rapid
succession, each generating a 15 tile radius (approx) effect, that's
about 10 * 700 = 7000 objects. How does the bandwidth shoot up to
10MB/s though? What is the minimal unit/"tick" of
My guess is with meteor, let's assume 10 projectiles in rapid
succession, each generating a 15 tile radius (approx) effect, that's
about 10 * 700 = 7000 objects. How does the bandwidth shoot up to
10MB/s though? What is the minimal unit/"tick" of time the server uses?
Finally, does the server
On 06/23/2017 04:56 PM, Rick Tanner wrote:
On 6/23/17 10:02 AM, Matthew Giassa wrote:
Also, has anyone tested how much bandwidth, disk space, etc; the latest
stable release uses under a test load (i.e. a few users/players)?
Disk space needed for (trunk only) source content:
arch = 124M
everytime someone has done something like that, they have regretted it.
FWIW, our class was considering writing a nueral network for crossfire
On Thu, Jun 22, 2017 at 10:01:20PM -0700, Mark Wedel wrote:
> On 06/22/2017 09:06 PM, Kevin Zheng wrote:
> >Hi there,
> >
> >It has now been 3 years
Hi, I'm currently using a 1.71 build of the gtk client on Windows 10. It
works well with only two issues.
1. The Meta server doesn't work
2. The default numpad key bindings don't work and have to be bound manually.
I'm happy to help bug test a gtk client (and the Java client) for this
release.
Would it be worth migrating the project to GitHub, along with a copy of
the HTML, assets, etc; for the real-time.com CF wiki? Issues wouldn't be
migrated, but a more modern VCS could be employed.
Also, has anyone tested how much bandwidth, disk space, etc; the latest
stable release uses under a
On 06/23/2017 05:37, Rick Tanner wrote:
> Would/could/will the planned release include an .exe version of the GTK
> client for Windows?
It's been a while since I've tried to build the GTK client on Windows,
but I'll remember to give it a shot.
--
Kevin Zheng
kevinz5...@gmail.com |
On 06/22/2017 22:30, Robert Brockway wrote:
> About 18 months ago I sparked a discussion about an expanded Crossfire
> world I was developing. Well I went away and did that but wasn't
> willing to host it on a VPS (Linode, Digital Ocean) as the size of the
> world made this quite expensive. So I
Sounds exciting.
About 18 months ago I sparked a discussion about an expanded Crossfire
world I was developing. Well I went away and did that but wasn't willing
to host it on a VPS (Linode, Digital Ocean) as the size of the world made
this quite expensive. So I decided to wait until until
On 06/22/2017 09:06 PM, Kevin Zheng wrote:
Hi there,
It has now been 3 years since the last release. Since then we've
accumulated a decent amount of fixes and improvements.
To make it easier on packagers, and so that more people might benefit
from these changes, I propose getting the ball
On 04/14/10 12:29 PM, Rick Tanner wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/31/10 2:01 AM, Mark Wedel wrote:
Just a heads up - I'm targeting weekend of April 10-11 to make a release,
since I should have time then (certainly won't this weekend)..
To recap or confirm..
On Wed, 14 Apr 2010 23:03:04 -0700
Mark Wedel mwe...@sonic.net wrote:
On 04/14/10 12:29 PM, Rick Tanner wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/31/10 2:01 AM, Mark Wedel wrote:
Just a heads up - I'm targeting weekend of April 10-11 to make a
release,
since I
On 04/15/10 08:47 PM, Kevin Bulgrien wrote:
Without countering Mark, I have build scripts that go all the way down to
making
RPMs... I'll support you in making a client release compatible with branch if
you
really want that. I can see part of the point of having branch for
stability,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/31/10 2:01 AM, Mark Wedel wrote:
Just a heads up - I'm targeting weekend of April 10-11 to make a release,
since I should have time then (certainly won't this weekend)..
To recap or confirm..
This will or would be called 1.5 and based on
Just a heads up - I'm targeting weekend of April 10-11 to make a release,
since I should have time then (certainly won't this weekend)..
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
Yes, in the past, usually for a week or two.
Of course, there is nothing that prevents one from making a branch from
something other than the latest version. So if tomorrow, someone made a
lot of big changes in which you think 'hmmm - I'd like more testing before
and don't want them in
On 03/20/10 12:55 AM, Nicolas Weeger wrote:
Hello.
Yes, that is the ideal case, especially if there is lots of active
development.
If there isn't, it is simpler to just freeze the trunk gate for anything
but bug fixes needed for the 1.50 release. That way quality can get
better,
Hello.
Call the release 1.50, to note it diverges a bit from the 1.11 release
(isn't a minor update) but at the same time isn't what we consider 2.0
Fine by me.
Target release for end of March or so. Are there any must fix bugs to be
dealt with? I hope to have the new account login
On 03/15/10 12:41 PM, Nicolas Weeger wrote:
snip
Target release for end of March or so. Are there any must fix bugs to be
dealt with? I hope to have the new account login stuff done soon, but I've
been saying that for months :(
The recent object_free2() and object_free_drop_inventory()
On 02/28/10 12:50 PM, Nicolas Weeger wrote:
Hello.
What about we just decide to do a release of trunk end of march?
Whatever it is called, 1.5, 2.0, 1.9, and such :)
Then let's kill branch, and work on trunk.
Does that sound ok?
Just to follow up on this some more and other ideas:
On 03/ 1/10 05:32 PM, Alex Schultz wrote:
I haven't been very active with things these days, but I'd be in
agreement with a release being made. My one reservation is that of
those options, I wouldn't want it numbered 2.0 since I don't think
enough has happened to justify that yet.
Making a
Hello.
What about we just decide to do a release of trunk end of march?
Whatever it is called, 1.5, 2.0, 1.9, and such :)
Then let's kill branch, and work on trunk.
Does that sound ok?
Sure - though perhaps my recent inactivity lowers the weight of the vote.
It has gotten to the
I haven't been very active with things these days, but I'd be in
agreement with a release being made. My one reservation is that of
those options, I wouldn't want it numbered 2.0 since I don't think
enough has happened to justify that yet.
Alex Schultz
On Sun, 28 Feb 2010 21:50:50 +0100
Nicolas
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lalo Martins wrote:
All right... with the help of crossfire traffic and svn, I compiled a
list of what's in the trunk and branch.
http://wiki.metalforge.net/doku.php/trunkbranchchangebreakdown
I've added about 10 new points of difference to the
quoth Rick Tanner as of Tue, 13 Jan 2009 13:55:12 -0600:
Lalo Martins wrote:
http://wiki.metalforge.net/doku.php/trunkbranchchangebreakdown
I've added about 10 new points of difference to the wiki page.
During the next couple of days, I will go through all the maps again and
post the any
Lalo Martins wrote:
quoth Mark Wedel as of Thu, 08 Jan 2009 22:08:38 -0800:
Lalo Martins wrote:
As far as I've seen, the only change that breaks character
compatibility is the combat rebalance. So until/unless we hear from
the code leadership, let's assume the rebalance won't be in the
All right... with the help of crossfire traffic and svn, I compiled a
list of what's in the trunk and branch.
http://wiki.metalforge.net/doku.php/trunkbranchchangebreakdown
Comments welcome.
As far as I've seen, the only change that breaks character compatibility
is the combat rebalance. So
quoth Mark Wedel as of Thu, 08 Jan 2009 22:08:38 -0800:
Lalo Martins wrote:
As far as I've seen, the only change that breaks character
compatibility is the combat rebalance. So until/unless we hear from
the code leadership, let's assume the rebalance won't be in the
release.
As far as
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lalo Martins wrote:
- As suggested earlier on this thread, current trunk will become
further 1.x releases. I remind you, that's for content; the
decision whether or not to do the same wrt server and clients
will be left to the people who
quoth Rick Tanner as of Tue, 06 Jan 2009 16:58:11 -0600:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lalo Martins wrote:
- As suggested earlier on this thread, current trunk will become
further 1.x releases. I remind you, that's for content; the decision
whether or not to do the
quoth Lalo Martins as of Wed, 07 Jan 2009 00:22:52 +:
Can you make a list, either here or the wiki, of known points where 1.12
would break backwards compatibility? I don't mind required that content
is updated in step, but breaking character compatibility I'd prefer not
to (last time that
quoth Rick Tanner as of Tue, 06 Jan 2009 20:35:13 -0600:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lalo Martins wrote:
Content changes that require trunk code are another matter. I'd like
to have a list of those if someone who knows about it has the time to
compile it; snip
One
Hello,
To throw my too cents:
I'm a long time user (since the pre-Mark-area; only debuged the code years ago).
So I would like to speak for those users, which are waiting of a new relase
since months.
Before making drastical changes to development (c++ implementation...) I would
like to see a
(Maybe there should be a vote on rolling back / not merging the rebalance
changes. Personally I love them. But I've seen some people claim
they're not finished enough for release.)
Given that we don't have anyone wishing to coordinate content and maps and
make them coherent and fun, I
quoth Nicolas Weeger as of Sat, 20 Dec 2008 13:22:50 +0100:
Given that we don't have anyone wishing to coordinate content and maps
and make them coherent and fun, I have no intention to do massive
changes to the code, so that question is probably rhetoric :) (unless
someone else feels like
Given that we don't have anyone wishing to coordinate content and maps
and make them coherent and fun, I have no intention to do massive
changes to the code, so that question is probably rhetoric :) (unless
someone else feels like doing such work, obviously)
That's not true... I thought
There is a difference of something being highly desirable and something
being strictly required.
I can think of some number of cases where people may not use the
metaserver2 for various reasons, and thus don't really want to bother
downloading what may be extra libraries.
*shrug*
We're
It shouldn't be. It's possible that a few things or other changes were
outside of #ifdefs. For both client server, having curl shouldn't be a
requirement.
What's the point of metaserver2, then? :)
I think curl is needed, so newer clients use newer servers.
Having pthread, at least for
Nicolas Weeger wrote:
It shouldn't be. It's possible that a few things or other changes were
outside of #ifdefs. For both client server, having curl shouldn't be a
requirement.
What's the point of metaserver2, then? :)
I think curl is needed, so newer clients use newer servers.
Kevin R. Bulgrien wrote:
I'll likely be packing up a release of 1.11 of server/client in a week or
two.
If you have fixes that you haven't committed yet, please do so.
Also, if there are any bugs that you see as critical that need to be fixed
before the release, please let me know.
Olivier Huet wrote:
Hello,
Something like a month ago, I did try some minor modifications on the
windows gtk1 client :
- make it compile on vs2005 (because I didn't have vs 6 installed anymore on
my current pc)
- activate back the sdl support (like it is in on gtk2 client, it's only a
[EMAIL PROTECTED] wrote:
Other thoughts: I'd say there is nothing prevent some micro releases of
some
components between now and then, if a change warrants it. For example, map
and archetype changes are quite quick to do and contain perhaps some of the
more noticable changes to the
Kevin R. Bulgrien wrote:
I also think that less than every 3 months is too long a gap - just
looking at
the client, there were lots of things changed since the last release, such
that
if there were 3 releases in that time period, each would still have enough
changes to be
On Sat, 2006-12-30 at 00:26 +0100, Yann Chachkoff wrote:
I do. I'd like to have enough time to solve at least the following
bugs before the next release:
- #1612838 : Problem with item_power code;
- #1539120 : Talisman of Evocation grants wrong skill;
- #1528525 : Sometimes bad initial
I'd like to make a 1.10 release of crossfire sometime soon. So if you have
bugs you're currently fixing, getting those fixes in now would be good.
Hrem, I don't think people keep fixes for ages in their local hard disks before
submitting them :).
If you are aware of any unreported bugs,
48 matches
Mail list logo