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 - quixadhal

Pages: 1 [2] 3 4 ... 43
Drivers / Re: Link for repository of fluffos-2
« on: September 12, 2017, 05:26:57 AM »
It's a change in the driver behavior... for good or bad, I don't judge.  However, I'm using the exact same mudlib on your driver that I'm using on the old 2.27.2 driver.  What Discworld uses to do its "queued command" logic, I don't know... but whatever it is, the driver is acting differently.

Drivers / Re: Link for repository of fluffos-2
« on: September 09, 2017, 06:27:30 PM »
Almost there!

Compiles fine, boots up, connects to I3, I can log in, however every command now shows up as a "queued command" and never actually executes.

I vaguely remember this being commented on elsewhere, perhaps in the discworld section of the forums even.  I'll try to poke around a bit later and see if I can find it, if you don't beat me to it.

Drivers / Re: Link for repository of fluffos-2
« on: September 09, 2017, 04:35:21 PM »
Just a quick bug report.  In trying to boot the ancient discworld mudlib, I get an "undefined function stringp" while loading the sefun object.

Code: [Select]
/secure/simul_efun/add_a.c line 40: Undefined function stringp before )
No error handler for error: *Error in loading object '/secure/simul_efun/add_a'
program: (none), object: (none), file: (none)
The simul_efun (/secure/simul_efun) and master (/secure/master) objects must be loadable.

The local options file used:

and the runtime config file:

The same options and config files worked on my older version of fluffos 2.x, so there's that. :)

Drivers / Re: A sad day in history - FluffOS-3
« on: September 05, 2017, 02:33:52 AM »
As I recall, the original reason FluffOS 3.x was forked from FluffOS 2.x was an unwillingness to allow the maintainer of Discworld to verify that the series of changes being worked into the driver wouldn't destroy a game with an active population in the thousands.

So, it's not so much that Discworld has no desire to migrate to a newer driver, it's that they had no desire to move to a rapidly moving target which showed no interest in maintaining compatibility with any game other than the one they, themselves, were running.

Now, there's no requirement to keep everything 100% backwards compatible.  FluffOS itself, when it was MudOS, broke things on a somewhat regular basis.  The difference is that during MudOS's evolution, compatibility issues were detected and described in the patch notes as each new revision was released, giving MUD admins the information they needed to fix their mudlibs, or decide to remain at the older version.

I'd like to think everyone has the same overall goals here... to try and improve the game driver for as many people as possible.  Since what's done is done, the only useful way forward now is to try and identify what things have been broken and determine if fixes will be simpler in the driver, or in the mudlib(s).

If I'm wrong, then perhaps a new name for the driver would be appropriate.  Afterall, MudOS became FluffOS because the maintainer of MudOS showed no interest in making the changes the Discworld people needed for their game to grow.

Open Chat / Re: Elder Scrolls Online
« on: September 05, 2017, 02:19:30 AM »
I have an xbox one, but won't play any games where a keyboard/mouse is superior.  Which rules out MMO's and FPS games.  Driving games, XCOM, Diablo... all better on the console, in the comfy chair!

Open Chat / Re: Elder Scrolls Online
« on: September 04, 2017, 07:36:45 AM »
If you ever wander to the side of the PC Master Race, I'm pondering a shiny new templar build to be able to slowly solo but never die. :)

Open Chat / Re: Elder Scrolls Online
« on: August 30, 2017, 02:22:57 PM »
I play on the PC version.  Since they can't do cross-platform, I'm not likely to do anything on the console versions since I already have time and money invested in the PC.

Drivers / Re: which driver would you use?
« on: August 09, 2017, 04:45:49 AM »
I would probably pick DGD, although LDMUD is a nice and well polished driver too.

It boils down to what kinds of features you want moving forward.  DGD puts a lot of effort into supporting persistence, with state dumps and atomic functions, so if that sounds like something you might want to use, it's a clear winner.  If not, it's still a nice fast and small driver.  Dworkin's philosophy has been to try to keep features that can be done in LPC out of the driver, so it can remain efficient and manageable.

LDMUD is far closer to LPMUD 3.1.2, and has a history leading back into the Amylaar driver.  It has lambda closures and seems pretty solid, although there aren't many mudlibs publicly available as examples.  I know BatMUD runs on it.

FluffOS is probably my last choice for the simple reason that it's currently not really maintained, and has some issues.  However, there are quite a few mudlibs available out there to use as comparisons to see what you'll need to change in your own.  If you do pick that one, the 2.x branch is the stable and not-really maintained version that you will likely want.  The 3.x branch was spunoff to try and convert to C++ and has evolved to be incompatible in many ways.

Open Chat / Re: Merry Christmas and a happy New Year!
« on: July 23, 2017, 11:39:40 PM »
Christmas in July?

*sounds of gunfire and explosions*

Hey... *cough*  to anyone reading this...


*cough*  It's almost too late for us.  Emperor Trumpu has declared martial law, because he thought it was marital law.  The Russians used our email servers against us, and the millions of Walmarts around the country turned out to be Chinese troop staging areas.

*whistling rocket sounds, then another big explosion*

We never stood a chance.  They offered us cheap NES classic emulators on Black Friday, and cut us down like grass beneath a lawn mower.

I'm sending this message back in time, from the future!  In 2019, it's too late to do anything... but there's still ONE chance for you to stop the apocalypse!  Release a new Discworld distribution lib before Christmas, 2017!

Save the mudlib, save the world!

Oh no... Education Secretary DeVoss, Crown Prince Pence, and Emperor Trump are starting to form Dumbtron!  It look like that's the...

*end of transmission*

Drivers / Re: FluffOS v2.27.2 (Unofficial)
« on: May 01, 2017, 12:57:55 PM »
Actually, you can see what changed via:

I generally force move the tag along as I commit things, so 2.27.2 should be the most recent commit, even though you'll have to check all 5 actual commits to see all the changes (including my typos, and whatnot). :)

General / Re: is back!
« on: April 25, 2017, 04:03:18 PM »
Always nice to see a new evil dictator rise to power.  Welcome Adam!

General / Re: wanting to loose this_player()
« on: February 28, 2016, 08:32:28 PM »
Well, if you're not using the built-in map code, but some custom stuff, that's even easier.

You put a general function in the reset() routine for every room that updates the player's map data.  reset() is called when something causes the room to be loaded, and if this_player() isn't set, that bit of code doesn't need to do anything.

Use the pre-exit hooks for your various security checking things, which shouldn't need to load the room itself, unless your check involves the contents of the room.  In any case, you can always ensure that you're only updating map data for environment(this_player()), even if they do trigger something.

As for finding all those things... assuming you used some kind of semi-standard thing like SetExit() or SetExits(), grep should find occasions where there's happy code nearby.  I forget the flags, but I know GNU grep has flags to check context so it can find things within N lines of the actual thing you look for.

General / Re: wanting to loose this_player()
« on: February 27, 2016, 05:33:12 PM »
Well, the mapper is just an NPC that walks around the rooms to map them.  So, of course it won't have a valid this_player(), but it does have a valid this_object(), and can certainly use enviornment() to see things about where it is.  So, to me, it seems like the solution is to not make your various exit checking routines rely on using this_player(), and if you want them to treat players and npc's differently, put the PC only code behind a check to see if this_player() is valid.

And you shouldn't be making 10,000 copies of almost identical functions.

Put your exit check functions into a small handful of objects (likely one for each domain), and have them inherited by the rooms, so the code isn't duplicated.  I seriously doubt you have 10K room exit functions that ALL do different things, they likely just do the same thing with different rooms and exits in their checks.

General / Re: wanting to loose this_player()
« on: February 27, 2016, 08:19:28 AM »
Make some_function() not use this_player(), but instead use this_object()?

Don't subvert the functionality of something that's used throughout the entire mudlib with a known and expected result to work around a local issue.  If your issue is with the way your exit check functions are working, change your exit check functions to be more predictable for your use case... don't change this_player() so it now doesn't perform its intended function.

Pages: 1 [2] 3 4 ... 43