Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Aidil

Pages: [1] 2 3 4
1
Gurba Gathering / Gurbalib 0.43 beta available
« on: March 22, 2010, 03:13:57 PM »
Gurbalib 0.43 beta is a next step in the development of Gurbalib.

Compared to the previous release, it is much more robust, has enhanced security, and many smaller improvements and tweaks.
It is bundled with DGD 1.4.2, and optional sprintf and regexp packages.

You can download it from http://wotf.org/downloads/gurba

Also, see the Changelog file provided there for more information on what changed exactly.

Aidil

2
Drivers / DGD 1.4.2 released
« on: March 18, 2010, 07:52:02 PM »
On behalf of the DGD team, I have the pleasure to announce the availability of
DGD 1.4.2

It can be downloaded from:

http://sourceforge.net/projects/dgd-osr/files/dgd-1.4.2.tar.gz/download

New in this release:

  • Windows port is now a console application and builds with VS2010 (express edition)
  • Network extensions available on Windows
  • On Linux, Solaris and BSD variants, swap and dump files > 2GB are now supported
  • status() now returns large numbers as floats
  • The source code has been 'ansified', sorry, no more K&R, and, no more Amiga support.
  • Some changes and a bugfix to the extensions interface
  • Fixed the precompiler
  • Some documentation improvements
  • and more..

This is the work of a number of people, see the Changelog file in the
distribution for more information.

One contributor to 1.4.2 must be mentioned here:

The ansifying efford and improvements to the Windows version were
done by Stephen Spiller, many thanks for doing this rather back breaking job.

Enjoy the new release, and if you find any bugs or issues, report them to us
through the bug tracker on https://sourceforge.net/projects/dgd-osr/support

3
Drivers / DGD 1.4.1 released
« on: February 18, 2010, 05:50:23 PM »
DGD 1.4.1 has been released today, it can be downloaded from http://sourceforge.net/projects/dgd-osr/files/dgd-1.4.1.tar.gz/download

New in this version:

  • Support for // style comments
  • Integration of the network package (disabled by default)

4
Intermud / Re: Intermud-3 router status
« on: September 24, 2009, 08:07:43 AM »
Thursday September 24th starting at 10pm (timezone CEST) the *wpr router will be unavailable due to hardware maintenance. This maintenance is expected to last upto 2 hours.

5
Gurba Gathering / Re: The Gurbalib resurrection project
« on: August 17, 2009, 09:35:14 AM »
For the time being, when using the network package (as the line number suggests), you can comment out line 112 since it is not needed in case of the network package anyway. Next dgd update will probably solve this properly.

Aidil

Next update to dgd that fixes this compilation problem is avaible now, and has been merged into the gurbalib repository.

Aidil

6
Gurba Gathering / Re: The Gurbalib resurrection project
« on: August 16, 2009, 04:12:52 PM »
For the time being, when using the network package (as the line number suggests), you can comment out line 112 since it is not needed in case of the network package anyway. Next dgd update will probably solve this properly.

Aidil

7
Gurba Gathering / Re: The Gurbalib resurrection project
« on: August 15, 2009, 06:04:10 PM »
I don't have cygwin at hand here, so can't really look at it myself, but you may want to try the following

Code: [Select]
cd src/host
cp Makefile.sysv Makefile

And then try your compile again.

8
Intermud / Re: intermud.org
« on: August 12, 2009, 06:57:26 AM »
Rather a good idea, just got stuck when trying to decide if to add a dns record for the old router us-1.i3.intermud.org

9
Intermud / intermud.org
« on: August 12, 2009, 04:44:53 AM »
Last year, the intermud.org website dropped of the net, and the domain expired.

I picked up the domain, and created a new website with intermud related information.

http://www.intermud.org/

10
Promotions / Re: Visit the Dead Souls mud!
« on: August 06, 2009, 04:37:45 PM »
I still have my "Cubic Cube" mouse pad somewhere....

http://engrish.com/

Don't go there, you'll spend hours laughing, keep away! :)


You quite know posting that link is mean!

11
Intermud / Re: IRC to I3 gateway?
« on: August 04, 2009, 04:48:44 AM »
You need your mud to act as an irc client and bridge that with a local channel. This is very similar to what the I3 <--> IRC bridge does.

The I3 <--> IRC code allows you to bridge an intermud channel with an irc channel. Unless you run your own private I3 network, care should be taken when doing this, and you should understand both the technical and social implications really well, and discuss this with the i3 channel owner (if you are not creating a dedicated channel for this).

So you'll probably want to make sure you change or configure the I3 <--> IRC bridge to only use a local channel on your mud. How involved that is I don't know, but from a first glance, the code quite assumes it is being used with i3

Not to mention, connecting to irc may cause a lot of administrative hassle, including but not limited to dealing with some of the more abusive irc users (trying an udp flood or other ddos on people they don't like is rather the norm for some), but this depends in part on the irc network you connect to. Not much of a concern probably if your mud serves as a dedicated IRC gateway, but if you have a game with players then this is bound to make their game impossible at times due to lag.

In other words, I doubt its as simple as dropping the file somewhere, you'll likely have to change it to do the exact thing you want from it, and it likely needs to be adapted to your mudlib.


12
Drivers / Re: FluffOS cvs
« on: June 25, 2009, 05:44:19 AM »
I use mercurial for all my personal projects.
What I like:
  • Distributed. It really does make a difference even for single person projects. My local workspace is a full repository - I can do everything I want to do, even when I'm offline (which I frequently am). But yet I can still share my changes to other people (if/when I want to) by pushing to a public repo.
  • Distributed (2). I'm finally learning to break free from the mentality of "commit == publish". Now I commit when I want to create a revision in the repo. A single bug fix, a small step along the way to a feature, etc. When I get into the groove, I commit several times an hour. Then when I think what I've built makes sense, I publish (push).
  • Easy to install. It's a few python scripts + modules. I can put it on any machine I want, and get full client+server capabilities without compiling a mass of things like SVN usually requires.
  • Fast. It really is so much faster than any other tool I use.
  • Reliable. Compared to CVS, everything in Mercurial works simply and easily. Tags make sense. Commits make sense. Subversion delivers this too (more or less) so it's not an advantage in your case
  • Merging. Merging in mercurial is dead easy. Repeatedly merging from one branch onto another works like a charm.
  • Tags + Branches make sense. I find subversion's a tag is a branch is a directory approach to be painful.
  • Clean. One ".hg" directory, at the very top of your repository. Nothing else.

Part of your comments depend on your workflow, and say very little about which tool is better, more about which tool fits better with your desired workflow.

For example when working with multiple people on a single module, commit == publish may actually be desirable. Pushign this upstream with git or mercury means you can prevent interference, but the same can be achieved with branching. If having inclomplete features publicly available is desirable is an entirely seperate discussion, but I'd like to remind you of the publish early publish often idea that has worked very well for many succesful opensource projects. It strongly suggests that early public availability can quite help progress. (I'm aware of there being arguments against early public availability as well, I am just pointing out that not wanting such things published is a matter of preference)

With regards to merging, I maintain 3 forks of DGD now, with a lot of merging both from upstream and between the forks. 1 is public, 2 are not.

Beyond that, I maintain a public mudlib, which is a merger between 3 variant codebases (original Gurbalib 0.40, Nullinfinite's version, and a version by Cerihan and me). Merging those into the single public distribution we have now was a fun project, much of which could be done automatically with svn.

SVN can quite do this, but again, the way in which it works may not fit with your desired workflow.
Suggesting it can't do this or makes it difficult goes against what reality shows however since this is being done in practise, and not just by me.

That svn leaves .svn directories everywhere can be an advantage as well as a disadvantage. For one, it makes it very easy to use the data from within an LPC environment (if only because it is text based, and it is instantly obvious where you have to look for data concerning a specific file). Also, it allows having a local working copy that consists of modules coming from different repositories. It does also clutter your tree with things you may not want there.

At any rate, the point here is not to say that what you consider advantages are not there, I am absolutely sure they are there for you. The point is that much of this depends on personal preference for a specific workflow and application.

With regards to cvs, I'm glad I'm not using it anymore, but, for many projects it does provide all you need, and, if you have to invest time and efford into learning something else while the tool you have already does what you need, it is extremely likely you have better uses for your time.

On another note, if so desired, I can host the fluffos repository on the same server that hosts the dgd and gurbalib repositories, either with cvs (yuck) or svn. Contact me on i3 if this is desirable. The server is in a datacenter sitting on top of the Amsterdam Internet Exchange and has plenty of bandwidth available for this.


13
General / Re: Happy Birthday LPC!
« on: June 24, 2009, 02:40:10 PM »
And some more digging by Erwin Harte on the dgd mailinglist turns up that the first public availability was somewhere late april or may 1990 most likely, definitely not before that.

http://groups.google.com/group/alt.mud/msg/1d5874a3a7970481

http://groups.google.com/group/alt.mud/msg/08b6495323c9abb8

Then finally: http://groups.google.com/group/alt.mud/msg/0cc7ac65823daa99

14
General / Re: Happy Birthday LPC!
« on: June 24, 2009, 03:39:22 AM »
1988 sounds very unlikely to me, summer 1989 sounds correct.

doc/credits in the lpmud 3.1.2 source distribution says:

The program was written originally by

Lars Pensj, April 1989 (lars at cd.chalmers.se).

So a public release before that date sounds rather unlikely. Since development of an lpmud I have been arch on started in january 1990, I'm pretty sure there was a public release by that date.







15
Drivers / Re: Sub-second timers
« on: June 13, 2009, 12:40:46 PM »
Quote
If Dworkin was to announce that he was removing millisecond precision from DGD would it be hailed as a big step forward for muds or would we consider it to be imposing additional limitations on us as designers.

A step forward I don't see. It would impose a restriction, sure, question is how many muds would actually be limited by such a restriction (not too long ago I'd add that few muds use DGD anyway, but that has changed a bit again recently... and I'd have my own mud to counter that argument anyway.. btw, I do use sub-second timers there)

Iirc, Dworkin's motivation for adding milisecond callouts wasn't directly related to muds however.

Pages: [1] 2 3 4