1. question that might not have an answer

I have a question.  On the mud I am working on, I have a list of mudcommands
that can be done in a data file.  They read into a commands variable, which
looks like this..

commands={command,command,command...}
command={{name of command},{function command should run when typed},{level
player must be to use command}}


I would like for mud-"coders" to be able to add commands "on the fly" from
inside the mud.  I can handle the actual adding of the command easy
enough...on one line, they would simply type:

addcommand <command> <function> <levelreq>

But here's my question.  The functions are referenced by routine_id .  When
any command is typed, the program searches for the command in the data file,
then if found calls the procedure in the 2nd element of that command
sequence by using a routine_id.  So, the functions for the commands are of
course stored within a file..umm...something like commands.e

So, here's the problem.  Coders could physically add the command...but is
there a way to add the function into the .e file from inside the program?  I
THOUGHT about...reading in the entire commands.e file as regular data,
adding the new function to the end as regular data, then saving it again.
First of all, will this even work?  But, secondly, how would you force the
program to re-read that file while it's already running?  I already thought
of the "easy" fix and tried to make a "compile" command from inside the mud
that simply includes the file again.  But, apparently we can't put include
statements inside procedure/functions?  That seemed to be the error I was
getting.  Or, am I wrong about that and there was something else wrong?

Or, perhaps I just want to do the impossible?  But surely, there's some way?

Michelle Rogers

new topic     » topic index » view message » categorize

2. Re: question that might not have an answer

On Sat, 10 Jan 2004 09:15:20 -0500, Michelle Rogers
<michellerogers at bellsouth.net> wrote:

>I would like for mud-"coders" to be able to add commands "on the fly" from
>inside the mud.
If you want to make it easier to add Euphoria code snippets, provide
an include file expressly for this purpose. Following is a cut down
copy of userfunc.exw used both in my print preview and report
generator (which is part shrouded), and also in Expression Evaluator
(which is full source):

--- code starts ---
--
-- Examples of user/application functions that can be used in 
-- calculated fields.
-- Just add a function and update the table at the end.
--
include wildcard.e	-- upper()/lower()

function Capital(object charstring)
	if not sequence(charstring) then return ("Capital() error") end if
	if length(charstring)>1 then
		charstring=lower(charstring)
		charstring[1]=upper(charstring[1])
	end if
	return charstring
end function

function ufvrid(sequence name)
integer r
	r=routine_id(name)
	if r=-1 then ?9/0 end if
	return r
end function

if initialise_pprg(0,{},{},{
"Capital","(x)             %s    -- first character upper case, rest
lower",ufvrid("Capital")}) then end if
-- code ends --

NOTES:
1) obviously ignore 0,{},{} passed to initialise_pprg(); they are used
elsewhere. The main thing is "name","desc",routine_id.
2) ufvrid() illustrates another trick you may need: 'wrapping'
routine_id to ensure it is physically located in the source at the
right place. Otherwise you get -1's returned.
3) naturally, if userfunc.exw is modified, the application must be
restarted before any changes take effect.
> I can handle the actual adding of the command easy
>enough...on one line, they would simply type:
>
>addcommand <command> <function> <levelreq>
As you may have guessed, this is what initialise_pprg does. It just
appends the values passed to three existing tables. The functions can
then later be invoked by name.

Download Expression Evaluator from my page if you want to see the
above in action. However what I suspect you should really be doing is
allowing your mud-"coders" to invoke an existing routine, with
different parameters.

Regards,
Pete
http://palacebuilders.pwp.blueyonder.co.uk/euphoria.html

new topic     » goto parent     » topic index » view message » categorize

3. Re: question that might not have an answer

On 10 Jan 2004, at 9:15, Michelle Rogers wrote:

> 
> 
> I have a question.  On the mud I am working on, I have a list of mudcommands
> that can be done in a data file.  They read into a commands variable, which
> looks like this..
> 
> commands={command,command,command...}
> command={{name of command},{function command should run when typed},{level
> player must be to use command}}
> 
> 
> I would like for mud-"coders" to be able to add commands "on the fly" from
> inside the mud.  I can handle the actual adding of the command easy
> enough...on one line, they would simply type:
> 
> addcommand <command> <function> <levelreq>
> 
> But here's my question.  The functions are referenced by routine_id .  When
> any
> command is typed, the program searches for the command in the data file, then
> if
> found calls the procedure in the 2nd element of that command sequence by using
> a
> routine_id.  So, the functions for the commands are of course stored within a
> file..umm...something like commands.e
> 
> So, here's the problem.  Coders could physically add the command...but is
> there a way to add the function into the .e file from inside the program?  I
> THOUGHT about...reading in the entire commands.e file as regular data, adding
> the new function to the end as regular data, then saving it again. First of
> all,
> will this even work?  But, secondly, how would you force the program to
> re-read
> that file while it's already running?  I already thought of the "easy" fix and
> tried to make a "compile" command from inside the mud that simply includes the
> file again.  But, apparently we can't put include statements inside
> procedure/functions?  That seemed to be the error I was getting.  Or, am I
> wrong
> about that and there was something else wrong?
> 
> Or, perhaps I just want to do the impossible?  But surely, there's some way?

Yes, use eval() in Bach.
Or use mirc. (yes, you can MUD with mirc.)
Or the Eu interpreter written by David Cuny .. about 1999, in the archives.

Kat

new topic     » goto parent     » topic index » view message » categorize

4. Re: question that might not have an answer

Michelle Rogers wrote:

>
>
>I have a question.  On the mud I am working on, I have a list of mudcommands
>that can be done in a data file.  They read into a commands variable, which
>looks like this..
>
>commands={command,command,command...}
>command={{name of command},{function command should run when typed},{level
>player must be to use command}}
>
>
>I would like for mud-"coders" to be able to add commands "on the fly" from
>inside the mud.  I can handle the actual adding of the command easy
>enough...on one line, they would simply type:
>
>addcommand <command> <function> <levelreq>
>  
>
You need some sort of internal EU interpreter, because the code you add 
will be stored in variables or in a data file... it won't become a 
physical part of the program; it won't be additional lines of code.

David Cuny has an interpreter, I think, or Pete or somebody else. :)

new topic     » goto parent     » topic index » view message » categorize

5. Re: question that might not have an answer

Matt Lewis wrote:

>
>
>euphoric wrote:
>  
>
>>Michelle Rogers wrote:
>>    
>>
>>>I would like for mud-"coders" to be able to add commands "on the 
>>>fly" from inside the mud.  I can handle the actual adding of the 
>>>command easy enough...on one line, they would simply type:
>>>
>>>addcommand <command> <function> <levelreq>
>>>      
>>>
>>You need some sort of internal EU interpreter, because the code you 
>>add will be stored in variables or in a data file... it won't 
>>become a physical part of the program; it won't be additional lines 
>>of code.
>>
>>David Cuny has an interpreter, I think, or Pete or somebody else. :)
>>    
>>
>You might be interested in euscript, which is based on David's 
>interpreter.  You can get it from my web page:
>
>http://www14.brinkster.com/matthewlewis/projects.html
>
>IIRC, someone (Greg Haberek?) was improving euscript.  To see it in 
>action, you can check out EDB (also on my page).  I use euscript to 
>allow user defined event handling in database forms.
>  
>
Hey, Matt! Sorry 'bout that. I knew somebody had something like that; 
bein' Monday 'n' all, I just couldn't get my brain to respond properly.

new topic     » goto parent     » topic index » view message » categorize

6. Re: question that might not have an answer

> IIRC, someone (Greg Haberek?) was improving euscript.  To see it in
> action, you can check out EDB (also on my page).  I use euscript to
> allow user defined event handling in database forms.

I wrote a front end for it. Go to www.finalphasesoftware.com to download it.

I was slowly developing an interpreter dll based off the existing C source,
but since Robert announced that the new version will be mostly
Euphoria-based, I'm going to wait and get that source, since it should be
easier to make a dll if there's less code to change. I think a dll would be
the best route, since it will be just as fast as the original interpreter.
This will of course limit it to Windows. I just think that having an
interpreter inside and interpreter is like making a copy of a copy, it's not
quite as sharp as, well.. the original. (ever seen Multiplicity?)

Or maybe one day Rob will implement scripting inside the interpreter....

~Greg
www.finalphasesoftware.com

new topic     » goto parent     » topic index » view message » categorize

7. Re: question that might not have an answer

I don't know that Euphoria is the best language to use internally in a 
MUD. MUDs are very heavily object (but not necessarily class) oriented, 
and MUD programmers are accustomed to address a property of an object 
and not an index in a sequence, etc.

Euphoria is a good language, don't get me wrong, but also I'm afraid 
that it might not be the best fit for world building.

Oh, and by the way, I was one of those who was interested in helping 
out. Email: isaac at blueapples dot org

~ Isaac




Michelle Rogers wrote:

>
>
>I have a question.  On the mud I am working on, I have a list of mudcommands
>that can be done in a data file.  They read into a commands variable, which
>looks like this..
>
>commands={command,command,command...}
>command={{name of command},{function command should run when typed},{level
>player must be to use command}}
>
>
>I would like for mud-"coders" to be able to add commands "on the fly" from
>inside the mud.  I can handle the actual adding of the command easy
>enough...on one line, they would simply type:
>
>addcommand <command> <function> <levelreq>
>
>But here's my question.  The functions are referenced by routine_id .  When
>any command is typed, the program searches for the command in the data file,
>then if found calls the procedure in the 2nd element of that command
>sequence by using a routine_id.  So, the functions for the commands are of
>course stored within a file..umm...something like commands.e
>
>So, here's the problem.  Coders could physically add the command...but is
>there a way to add the function into the .e file from inside the program?  I
>THOUGHT about...reading in the entire commands.e file as regular data,
>adding the new function to the end as regular data, then saving it again.
>First of all, will this even work?  But, secondly, how would you force the
>program to re-read that file while it's already running?  I already thought
>of the "easy" fix and tried to make a "compile" command from inside the mud
>that simply includes the file again.  But, apparently we can't put include
>statements inside procedure/functions?  That seemed to be the error I was
>getting.  Or, am I wrong about that and there was something else wrong?
>
>Or, perhaps I just want to do the impossible?  But surely, there's some way?
>
>Michelle Rogers
>
>
>
>TOPICA - Start your own email discussion group. FREE!
>
>

new topic     » goto parent     » topic index » view message » categorize

8. Re: question that might not have an answer

This won't quite work, because he's writing a MUD server. It can't 
reboot very often.


Philip Deets wrote:

>
>
>Michelle Rogers wrote:
>  
>
>>I have a question.  On the mud I am working on, I have a list of 
>>mudcommands
>>that can be done in a data file.  They read into a commands variable, 
>>which
>>looks like this..
>>
>>commands={command,command,command...}
>>command={{name of command},{function command should run when 
>>typed},{level
>>player must be to use command}}
>>
>>
>>I would like for mud-"coders" to be able to add commands "on the fly" 
>>from
>>inside the mud.  I can handle the actual adding of the command easy
>>enough...on one line, they would simply type:
>>
>>addcommand <command> <function> <levelreq>
>>
>>But here's my question.  The functions are referenced by routine_id .  
>>When
>>any command is typed, the program searches for the command in the data 
>>file,
>>then if found calls the procedure in the 2nd element of that command
>>sequence by using a routine_id.  So, the functions for the commands are 
>>of
>>course stored within a file..umm...something like commands.e
>>
>>So, here's the problem.  Coders could physically add the command...but 
>>is
>>there a way to add the function into the .e file from inside the 
>>program?  I
>>THOUGHT about...reading in the entire commands.e file as regular data,
>>adding the new function to the end as regular data, then saving it 
>>again.
>>First of all, will this even work?  But, secondly, how would you force 
>>the
>>program to re-read that file while it's already running?  I already 
>>thought
>>of the "easy" fix and tried to make a "compile" command from inside the 
>>mud
>>that simply includes the file again.  But, apparently we can't put 
>>include
>>statements inside procedure/functions?  That seemed to be the error I 
>>was
>>getting.  Or, am I wrong about that and there was something else wrong?
>>
>>Or, perhaps I just want to do the impossible?  But surely, there's some 
>>way?
>>
>>Michelle Rogers
>>
>>
>Maybe, when a new command is entered, the program could do the 
>following:
>
>1. Write the new command in commands.e
>2. Save the state of the game.
>3. Restart the game automatically and abort the original one.
>4. Load the previous version of the game.
>
>That way maybe the new command would be registered.
>
>Don't know if it would work ok for you, but that's my idea.  Hope it 
>helps.
>
>Phil
>
>
>
>TOPICA - Start your own email discussion group. FREE!
>
>

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu