Closed TogarUshindi closed 3 years ago
I'm hoping that a lot of the MUFs from MUF archive are available in the fuzzball-muf repository on this account, but please let us know if there are any gaps you'd like to see filled.
The .m
extension has been for MUF programs for as long as I can remember, at least on the server side. I've seen names of the actual MUF object have a .muf
extension and/or a cmd-
prefix.
The repository I mentioned (and it looks like mufarchive.com does too) does use the .muf
extension to distinguish MUF scripts (that includes any pre- and post-installation commands) from the individual MUF programs. Oftentimes these can just be pasted in. but for larger programs some client interaction may be necessary to emit lines at a set speed.
An advanced option here is to run the script up to actually creating the MUF object (giving you a dbref #), create that #.m file on the server, and then continue with the script at the point after the program is created.
For the programs
list, it looks like it picks up any MUF that is set VIEWABLE.
I hope that helps, please reach out if you have more questions!
please let us know if there are any gaps you'd like to see filled.
coughs wixxx.muf
is an important one for "filling gaps"... coughs
In all seriousness, there are a couple others I'm discovering on MUF Archive's site, too. Some look interesting that I would like to try out.
to distinguish MUF scripts
Ah! So, *.muf
is more of a script than a "real" program?
Does this mean that they should be installed at lower Mucker levels? Perhaps that's why I never noticed the .m
extension in the past. In truth, I have only dabbled before, and that was with WinFuzz, not "LinuxFuzz." So, this is a new experience for me.
Oftentimes these can just be pasted in
Pasted into what? An in-game editor?
*.muf
scripts contain the program, but also any commands that need to surround it in order to "install" it, for lack of a better word. This should include any flags that need to be set to restrict the program to certain MUCKER levels.
Pasted directly into the client works for many programs. Depending on the length of the program and the underlying speed of the server it may not be able to "keep up", hence the other options.
but also any commands that need to surround it in order to "install" it, for lack of a better word.
Dependencies, in other words?
If I attempt to paste the MUF code into an in-game item, will it inform me if there are any missing dependencies?
Most of the time these commands include @program
, @propset
. @set
, and @action
steps, things that you would normally do if you're building it manually.
Dependencies usually come in with the program itself, if it tries to $include
another program you don't yet have registered, for example. Each line of this script - including the program compilation process - should generate output in your client, so you can see what has succeeded, and what may have failed.
Trying to copy/paste a muf into a script using @program
and it's saying:
Warning: Trying to send a very long command line. Perhaps a recursive alias definition?
So if I can't just copy/paste all lines of the program, what does it want me to do? Copy them one line after the other? Eww.
Searching around the ancient docs for a solution, and I ran across a page on "Porting Globals." Not sure if that applies.
But the one thing I notice about the ancient docs is that they're so ancient sometimes it refers to something FB7 on Github doesn't have.
To install them, uncompress and extract the files (`gunzip fbmuf.tar.gz', `tar -xvf fbmuf.tar')
Huh?
That's a problem.
fbmuf is an alternate name for the group of MUFs in the fuzzball-muf repo. If it's in the documentation we provide, we can modify the steps.
I think that Warning message may have been generated by your client. Could there be a way to suppress that?
Maybe a valid option at this point is to do it in parallel using the *.muf script:
@program
line.If you're still running into trouble, we can provide support directly through a character on your MUCK, if you'd like.
I think that Warning message may have been generated by your client.
I'm in-game using the @program
command, because it's my understanding that in order to script something and make it a program, that's the command to use. I've never used it and don't know if there's another way.
the *.muf script
Sorry, what's the *.muf script? Is that something included with fuzzball?
It looks like we were able to solve this in another setting. Feel free to re-open or create another issue if you have additional questions!
This feels like a silly question because I thought it was practically a drag-n-drop solution in the past, but...
How do we take MUF programs from places like mufarchive.com and get them to work in FB7?
Are any of the ancient help docs applicable and on point for FB7? They all seem to discuss programming MUF, not installing existing MUF programs.
I noticed that those in
/usr/local/game/muf
are given a*.m
file extension, but I remember the traditional extension is*.muf
, so I am wondering if there have been changes afoot with the new system.These are also all numbered, I see, rather than given names. Does this mean any new programs rolled in should also be changed to a numbered file with a
*.m
extension, or can they be kept as is?I assume that I would place newly retrieved files in
/usr/local/game/muf
with the rest. Once I do that, what steps do I take to get the game to see it so I can create an@action
? How do I get the program to be included in theprograms
list?