|
|
Vassi
Conjurer
Group: Members
Posts: 182
Joined: Sep 24, 2008
|
#17 Posted Oct 8, 2008, 2:19 pm
|
DavidHaley said:It sounds like your approach of using "blocks" is basically another way of looking at the AI-distance I was talking about. It sounds good to me. Keeping a global list of exceptions seems like a reasonable way to shortcut the block handling.
I assumed that most muds had the concept of blocks in the implementation of areas, area files, etc. I keep three sets of references (whether that's bad practice or not, I don't know, but it's might convenient) I keep a master list of everything, the block keeps a list of each item, player, or mob inside of it, and so does the room. So each room hands off the reference to the next, when moving around, and if the new room is in a different block the block will hand off to the other (all of these hand-offs also having event\scripting hooks ;))
It makes more sense to query the lands to see if they're unfolded and active before doing anything with the stuff inside.
Quote:
In Lua, you can precompile the Lua text into Lua bytecode. There's no optimization, so the only savings are when you load the script. What kind of benchmarks were you using when you got a 9-10 factor increase? Incidentally, there is a LuaJIT for x86 architectures that gets you massive performance increases because it compiles the Lua bytecode into assembly.
I guess it depends what you mean by loading, and if it's one time. The way the IPY interpreter works you can either interpret the file every time, or compile it and run the compiled module. Loading time for the whole system is attrocious on a first run (thankfully, first-run literally means only the very first script you interpret) but the compiling is very helpful. The test is nothing special, only a simple script that adds a couple of things together and prints a message. This test is wrapped inside of a for loop to simulate calling it various number of times.
Honestly, even interpreted, I don't think performance would be that big of an issue at < 100 or so players, but precompiling was easy to do so it seemed like a no-brainer. Most scripts do not change on a regular basis once they've been tested and debugged.
|
......................... Vassi no Diem et Tharin
< ramble/>
|
|
David Haley
Wizard
Group: Members
Posts: 5,727
Joined: Jun 30, 2007
|
#18 Posted Oct 8, 2008, 3:22 pm
|
I don't think that SMAUG has a list of players per area; it does have a count, and a list of players per room, but data doesn't get aggregated upwards in the hierarchical division.
Vassi said:The way the IPY interpreter works you can either interpret the file every time, or compile it and run the compiled module.
By compiling, do you mean compile the text to bytecode, or compile to assembly language like what a JIT would do? If you mean the former, Lua does that by default and you only read the actual strings once (upon load). If you mean the latter, you need LuaJIT to get to the machine code level.
|
|
|
Vassi
Conjurer
Group: Members
Posts: 182
Joined: Sep 24, 2008
|
#19 Posted Oct 8, 2008, 3:32 pm
|
DavidHaley said:
By compiling, do you mean compile the text to bytecode, or compile to assembly language like what a JIT would do? If you mean the former, Lua does that by default and you only read the actual strings once (upon load). If you mean the latter, you need LuaJIT to get to the machine code level.
From what I understand, IPY compiling is equivalent to LuaJIT. It doesn't hold on to any byte-code it generates for interpreted scripts unless you load a script into the runtime as an include, which does not help you for scripts you need to run more than once. In those cases, if you're not compiling, the file is read - turned into byte-code - then JITed by the VM every time you run the script, which is pretty standard fare(? I think cPython does 'optimize' by keeping the byte-code as pyc files? But it still has to JIT them)
Hence the large performance improvement. Still, IPy runs, on average, as fast or slightly faster than cPython in most scenarious except for heavy loop-based ones where things get instantiated a lot. Then you start to see some degradation, which is slightly more noteable in Mono.
|
......................... Vassi no Diem et Tharin
< ramble/>
|
|
Vassi
Conjurer
Group: Members
Posts: 182
Joined: Sep 24, 2008
|
#20 Posted Oct 10, 2008, 10:18 am
|
DavidHaley said:
Couldn't you in principle use an editor-buffer approach like what most OLCs currently do? It's not nearly as nice, but it works..
After thinking about this I can really only think of four ways to do it, and I'm not sure which one I prefer. In some ways I like 2 the best, because of how simple it would be to setup in my own situation and the fact that it's codebase dependent, rather than 4 - which is client dependent.
1) A simple web-script(PHP, Python, Whatever) to handle user uploads to whatever directory you want. You'd have to log-in users based on your account\character files (easy enough, if you use a database for those bits, but not much harder if you use flatfile). This fails if your MUD and webhost are not on the same server.
2) Again a web-script, but this time have it communicate directly with the server via a 'service socket'. This lets you do the script processing from inside the MUD server. The easiest way to authenticate this is to make sure the connection is from the local loopback or some pre-authorized IP. This would work even if your webhost is not on the same server - but relies on you being able to easily check incoming connections and treat them differently. The command would essentially be a byte-blast of the contents of the file and the username who is requesting the file be saved, this one allows you to provide more intelligent feedback like "Authorization Failed" or "File Already Exists" or even the chance to detect Syntax errors.
3) A line-buffer editor, as we discussed, but IMO this is a very awkward way to write a script, and copying and pasting seems error-prone. Getting a more robust buffer mode is client dependent for reasons bemoaned by everyone who wants a better OLC.
4) A client-specific way of sending data in such a manner that it is not 'cleaned up' and can be treated in a special manner. This would allow something like an in-client editor that can then send the data through.
|
......................... Vassi no Diem et Tharin
< ramble/>
|
|
Runter
Wizard
Group: Members
Posts: 1,074
Joined: Jun 1, 2006
|
#21 Posted Oct 10, 2008, 10:38 am
|
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.
|
|
.........................
-Heath
For once you have tasted flight Ruby you will walk the earth with your eyes turned skywards,
for there you have been and there you will long to return. --
Leonardo Da Vinci Yukihiro Matsumoto
|
|
David Haley
Wizard
Group: Members
Posts: 5,727
Joined: Jun 30, 2007
|
#22 Posted Oct 10, 2008, 11:47 am
|
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.
|
|
|
Runter
Wizard
Group: Members
Posts: 1,074
Joined: Jun 1, 2006
|
#23 Posted Oct 10, 2008, 7:16 pm
|
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.
|
|
.........................
-Heath
For once you have tasted flight Ruby you will walk the earth with your eyes turned skywards,
for there you have been and there you will long to return. --
Leonardo Da Vinci Yukihiro Matsumoto
|
|
Vassi
Conjurer
Group: Members
Posts: 182
Joined: Sep 24, 2008
|
#24 Posted Oct 10, 2008, 8:35 pm
|
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
|
......................... Vassi no Diem et Tharin
< ramble/>
Last edited Oct 10, 2008, 8:36 pm by Vassi
|
|
quixadhal
Wizard
Group: Members
Posts: 1,256
Joined: Oct 17, 2007
|
#25 Posted Oct 10, 2008, 11:15 pm
|
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.
|
......................... 
|
|
Vassi
Conjurer
Group: Members
Posts: 182
Joined: Sep 24, 2008
|
#26 Posted Oct 11, 2008, 12:01 am
|
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.
|
......................... Vassi no Diem et Tharin
< ramble/>
|
|
Runter
Wizard
Group: Members
Posts: 1,074
Joined: Jun 1, 2006
|
#27 Posted Oct 11, 2008, 7:40 am
|
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.
|
|
.........................
-Heath
For once you have tasted flight Ruby you will walk the earth with your eyes turned skywards,
for there you have been and there you will long to return. --
Leonardo Da Vinci Yukihiro Matsumoto
|
|
David Haley
Wizard
Group: Members
Posts: 5,727
Joined: Jun 30, 2007
|
#28 Posted Oct 11, 2008, 12:25 pm
|
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.
|
|
|
