10 Oct, 2008, Runter wrote in the 21st comment:
Votes: 0
Eh, I don't keep any help files in memory until it is being accessed or changed. I've found it easy enough to thread the process of accessing help files.
10 Oct, 2008, David Haley wrote in the 22nd comment:
Votes: 0
I agree that (2) is probably the better solution in the long run. I don't picture (4) being viable because of the client dependency. I don't picture (1) being viable not only for the reason you mentioned, but also because you will need to talk to your MUD to signal the new file anyhow, so you might as well do (2). Option (3) suffers from the problem you mentioned, although I don't think copy/pasting is quite that bad. Still, I would hate to do any serious editing in anything other than an editor I like, such as vi. Anyhow, for good editing, you need a character by character mode, not line-by-line which is what most clients do.
10 Oct, 2008, Runter wrote in the 23rd comment:
Votes: 0
I couldn't live without vim. That being said and out of the way– I think that it's unfortunate that line by line editors are norm, but they are the most common types of editors for a reason. It's a mud. The type of input is line by line. There's a lot of things that are unfortunate about most muds. Like generally no mouse interface for direct interaction with the game. No graphics. Often poor implementation in general.

However, I think that web scripts and external upload forms in place of a standard line by line editor is more of a hassle than it's worth.

Personally, I don't believe that a good interface for a line by line editor is slow or that annoying once you learn it.

Something that passively accepts commands or the following is what I use:

+Any line to append to the end.
+#Any line to insert to a certain point in the existing file.
-Any text to be deleted.
-# (deletes a line by number)
+r#Replace any line with this line.
+r 'find this string' 'replace it with this one'

enter on a new line shows existing text to be edited.
Then I have a host of other commands like spellchecker by line, passage, format, format options. While I wish I had vim while editing, I've kinda learned to deal with it and it is quite functional for me for editing while dealing with other issues at the same time.
11 Oct, 2008, Vassi wrote in the 24th comment:
Votes: 0
Runter said:
I couldn't live without vim. That being said and out of the way– I think that it's unfortunate that line by line editors are norm, but they are the most common types of editors for a reason. It's a mud. The type of input is line by line. There's a lot of things that are unfortunate about most muds. Like generally no mouse interface for direct interaction with the game. No graphics. Often poor implementation in general.

However, I think that web scripts and external upload forms in place of a standard line by line editor is more of a hassle than it's worth.

Personally, I don't believe that a good interface for a line by line editor is slow or that annoying once you learn it.

Something that passively accepts commands or the following is what I use:

+Any line to append to the end.
+#Any line to insert to a certain point in the existing file.
-Any text to be deleted.
-# (deletes a line by number)
+r#Replace any line with this line.
+r 'find this string' 'replace it with this one'

enter on a new line shows existing text to be edited.
Then I have a host of other commands like spellchecker by line, passage, format, format options. While I wish I had vim while editing, I've kinda learned to deal with it and it is quite functional for me for editing while dealing with other issues at the same time.


Just to clarify, this is no longer really about help files and more-so about admin-created scripts.

Second, you think it's less of a hassle to write an entire interface for line-finding, sub-string replacement, spellchecking, formatting, buffering, etc than to write a simple upload handling and overwrite\create file command?

I'd say the former approach definately threatens to re-invent the wheel. Why would I develop anything in a line editor when I can use vi, np++ or whatever my lite script editor of choice is to write my script and then upload it with two button clicks? And if I already had such a simpler system in, why wouldn't I just go ahead and use it for help text files as well?


V
11 Oct, 2008, quixadhal wrote in the 25th comment:
Votes: 0
The problem with DikuMUD's is that they aren't really file based. They are string based. It happens that many of the strings involved are stored in files, but that's actually the problem. If I'm "editing" a room, I don't want to download and re-upload the entire area file.. in fact, I may allow builders to edit descriptions but not modify flag values and thus don't want them to be ABLE to access the whole file. So, what you really need to do is write the string they're about to modify out to a file, transfer it to the user's local system, and then let them re-upload the changed version.

That relies on the user having a client that can trigger on the download event to launch an editor, and then automatically issue an upload command when the editor exits. Not hard, but also not supported by the POT (Plain Old Telnet) we cling to.

Yes, you can do it by hand, but it's ugly to have to cut and paste filenames into another window to bring up your editor on the temp file, and then issue the upload command.

On the other extreme, you can refuse to cater to custom clients and force telnet into character-by-character mode, giving the user
a real editor. By doing so, you annoy every wizard who uses tinyfugue/MUSHclient/ZMUD, etc.

A line editor is most accessible of the three, even though it's also probably the most annoying to use in practice.
11 Oct, 2008, Vassi wrote in the 26th comment:
Votes: 0
quixadhal said:
The problem with DikuMUD's is that they aren't really file based. They are string based. It happens that many of the strings involved are stored in files, but that's actually the problem. If I'm "editing" a room, I don't want to download and re-upload the entire area file.. in fact, I may allow builders to edit descriptions but not modify flag values and thus don't want them to be ABLE to access the whole file. So, what you really need to do is write the string they're about to modify out to a file, transfer it to the user's local system, and then let them re-upload the changed version.

That relies on the user having a client that can trigger on the download event to launch an editor, and then automatically issue an upload command when the editor exits. Not hard, but also not supported by the POT (Plain Old Telnet) we cling to.

Yes, you can do it by hand, but it's ugly to have to cut and paste filenames into another window to bring up your editor on the temp file, and then issue the upload command.

On the other extreme, you can refuse to cater to custom clients and force telnet into character-by-character mode, giving the user
a real editor. By doing so, you annoy every wizard who uses tinyfugue/MUSHclient/ZMUD, etc.

A line editor is most accessible of the three, even though it's also probably the most annoying to use in practice.


I get that, and in that context it makes sense, but we're just talking about very different things. I don't think I fully stated the fact that I was using C# in the thread, so if you only skimmed it until now then that's probably all you need to know. (so forgive my rant from this point on)

Maybe if I was using a DIKU this would apply, my argument is that because I'm not - it doesn't, that's all. Line editing is fine for rooms and areas, because most of those are simple strings. Why would you need to let them download the file and re-upload it, if it's in memory why is it so difficult to write the description into the appropriate place and then only save to the file on shutdown or crash, to preserve the changes? I cannot express how trivial OLC is with languages that support Reflection, like C#.

It's occured to me lately that the reason I can't fully grok C (aside from the fact that I've never tried to sit down with it and learn) is because I'm so steeped in the OO approach that I see something and think 'that would be so much easier with a class", or whatever. My point is, unlike rooms or anything else, scripts are discrete envelopes of content and should be treated as such, hence the file approach.

What is so evil about requiring someone to use a browser, and how is that not accessible (to a wizard\admin, mind you)? You go to a website, you upload the file, it's now available in the game. Writing a moderately complex script, line by line, is the most unnatural thing in the world for me to do, because editing a typo is awkward, and time consuming, and how many times while you're coding do you forget a colon\curly brace\quote? I can't prototype complex things in the Python interpreter for that very reason. Perhaps I'm not hardcore enough, I don't know, but I do know that most of the people writing those quest scripts will definitely not be hardcore, nor will they be programmers, they will make mistakes - a lot of them.

I get why you guys are married to the line editor choice with the current options, but lets be honest, how many of you would even look at a C# codebase? How many seasoned DIKU\ROM\Circle\etc admins would throw all their skills away just because I have a line editor like they know and hate by all present indications. I don't see why I should conform in this scenario and I don't believe the arguments being presented here are taking in the context.

P.S. I don't mean to blow it all out of proportion even, I'm just a little confused by it.
11 Oct, 2008, Runter wrote in the 27th comment:
Votes: 0
Vassi said:
Runter said:
I couldn't live without vim. That being said and out of the way– I think that it's unfortunate that line by line editors are norm, but they are the most common types of editors for a reason. It's a mud. The type of input is line by line. There's a lot of things that are unfortunate about most muds. Like generally no mouse interface for direct interaction with the game. No graphics. Often poor implementation in general.

However, I think that web scripts and external upload forms in place of a standard line by line editor is more of a hassle than it's worth.

Personally, I don't believe that a good interface for a line by line editor is slow or that annoying once you learn it.

Something that passively accepts commands or the following is what I use:

+Any line to append to the end.
+#Any line to insert to a certain point in the existing file.
-Any text to be deleted.
-# (deletes a line by number)
+r#Replace any line with this line.
+r 'find this string' 'replace it with this one'

enter on a new line shows existing text to be edited.
Then I have a host of other commands like spellchecker by line, passage, format, format options. While I wish I had vim while editing, I've kinda learned to deal with it and it is quite functional for me for editing while dealing with other issues at the same time.


Just to clarify, this is no longer really about help files and more-so about admin-created scripts.

Second, you think it's less of a hassle to write an entire interface for line-finding, sub-string replacement, spellchecking, formatting, buffering, etc than to write a simple upload handling and overwrite\create file command?

I'd say the former approach definately threatens to re-invent the wheel. Why would I develop anything in a line editor when I can use vi, np++ or whatever my lite script editor of choice is to write my script and then upload it with two button clicks? And if I already had such a simpler system in, why wouldn't I just go ahead and use it for help text files as well?


V


I think it's more of a hassle to have to deal with web scripts, yes. It's "reinventing the wheel" when you decide to make a web editor interface that runs concurrent to your existing live line by line editor. You have to have a live editor regardless (most of us already have one), so if you want to talk about reinventing the wheel (the most over used term of 2008 @ mudbytes) then I guess the argument is moot considering the editor would already have to exist for other systems anyways.

Putting that aside, if someone wants to use and develop a web editor, go for it.
If someone wants to make the argument that *I* should be using a web based editor, I'll dispute you.

You like strawberry ice cream? Well, I like vanilla.
11 Oct, 2008, David Haley wrote in the 28th comment:
Votes: 0
Just to be clear, Vassi is talking about significantly large files here, not descriptions and so on. Editing long scripts, where, oh, long >= 100 lines, in a line-by-line editor is really not my idea of fun.
20.0/28