Gammon Forum : SMAUG : SMAUG coding : Python/Perl/C Interp for SmaugFUSS

Entire forum ➜ SMAUG ➜ SMAUG coding ➜ Python/Perl/C Interp for SmaugFUSS

Python/Perl/C Interp for SmaugFUSS

It is now over 60 days since the last post. This thread is closed. Refresh page

Posted by

Dralnu USA (277 posts) Bio

Date

Thu 23 Mar 2006 12:51 PM (UTC)

Message

Ok, this is an idea I have had for awhile, both to simplify some of the code (so that you don't have all your spells/skills hardcoded into the system), and to allow for fine-tuning on-the-fly of spells/skills. Anyways, how could one add in (either code in or refrence in) an interpreter to the code? I'm not exactly sure what kind of script to use (from my understanding, Lau might be a decent choice for this if possible), so that one could save the spells and skills to the normal file, and instead of dealing with spell_smaug, just use the script so that as things evolve, you can tweak them with a greater degree of control.
Anyways, any comments/suggestions?

Top

Posted by

David Haley USA (3,881 posts) Bio

Date

Reply #1 on Thu 23 Mar 2006 01:26 PM (UTC)

Message

I'll take Lua as an example since it's IMO the best choice here. In brief Lua is the best choice because its entire setup is very, very small, and it has very little overload and is very, very easy to interface back and forth with C.

Basically you have to write code that:
- sets up a Lua environment
- transitions from C to Lua
- adds functions to the Lua environment, so that it can interface to the C data -- this is probably where the bulk of the work is

The first two are easy; in fact they are really easy. The third is where you'll have to do the work, because you'll have to find a way to expose to Lua all the data you want it to be able to play with.

I'm not sure what distinction you draw between coding in and referencing in an interpreter, though.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Top

Posted by

Dralnu USA (277 posts) Bio

Date

Reply #2 on Thu 23 Mar 2006 01:38 PM (UTC)

Message

Well, my thought is this: Instead of hard coding something into the source, could save it to something like skills.dat or whatever, so that if you need to change something in a skill (lets say someone added in a flexible arm skill that paralysis the opponent for X number rounds), and they forgot a check, like vs. para, and you lack someone with access to the code itsef, you could basically:

sset (skill #) on [to put you into a buffer like for a desc.]
(add in check)
/s
sset save skill table

done

instead of

Wait for coder to log,
fix code
hotboot

and all that. Just a lazy feature, plus then you could work the same system into the prog system if you feel like it to open up more options in the way of programs (fights seem to be what would benifit most from this. Vary they're response based on classes fighting them, hitpoints, opponents stats, ect). Yeah that can prolly be done as is, but there is a distinct lack of refrences, and being able to get ahold of, say, an opponents weight to see if a mob could toss them into the next room would be interesting.

Top

Posted by

David Haley USA (3,881 posts) Bio

Date

Reply #3 on Thu 23 Mar 2006 01:55 PM (UTC)

Message

Oh, I'm not disputing the use of scripting at all, in fact I'm a big advocate of using it. For that matter, huge chunks if not all of BabbleMUD will be written in Lua.

If anything, having a real programming language instead of the nightmare that is mudprog would be very, very nice. Before I discovered Lua, I solved this by writing my own scripting language because I didn't feel like figuring out how to tie something like Perlscript in, and my original intention was to make it quick 'n dirty but working. But then I discovered Lua, and was so happy with it, and had discovered that I'd made some, well, "interesting" situations for myself, that I decided to just drop my own language and go with that.

I haven't finished the process yet, but I have written a new quest system that uses Lua to do most of its processing and data storage. Much nicer than text config files.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Top

Posted by

Nick Cash USA (626 posts) Bio

Date

Reply #4 on Thu 23 Mar 2006 05:12 PM (UTC)

Message

On another note, just about anything is better than text file storage. Its definitely worth looking into another storing medium if you plan to do any significant amounts of work and plan on being around a while. A lot of admins I know integrated MySQL with their muds, and the SWFOTE base is undergoing that process as a whole right now as well.

However, MySQL is not the only solution. If you want a real scripting language, Lua is probably the way to go.

~Nick Cash
http://www.nick-cash.com

Top

Posted by

Dralnu USA (277 posts) Bio

Date

Reply #5 on Thu 23 Mar 2006 09:43 PM (UTC)

Message

Well, one reason I mentioned using the more-or-less traditional text doc format is that is what I'm used to using. I don't know anything about the others. As is I was hoping there was a system to installing Lua (reason I didn't mention it is I havn't used it before), like somewhere someone had an faq for doing that.

Could you give me some info on other storage types, or a place with such info?

Top

Posted by

David Haley USA (3,881 posts) Bio

Date

Reply #6 on Thu 23 Mar 2006 09:55 PM (UTC)

Amended on Thu 23 Mar 2006 09:56 PM (UTC) by David Haley

Message

I'm not sure what you mean by 'system to install Lua'. AFAIK, very few people, and possibly nobody, has gone and fully implemented a Lua system in SMAUG. I'm some of the way there, but my goal thus far has been data storage, not scripting (although scripting will play a significant role later on).

The book Programming in Lua is very good, and is available for free at www.lua.org/pil/. It has a whole section on mixing C with Lua that is extremely helpful. (In fact the whole book is well-written and a good read. A new version just came out today for Lua 5.1.)

Whiteknight: I'm curious about the performance of database type storage. I implemented some time ago a vaults system, using BerkeleyDBXML and it was very slow. It took a number of seconds to load a player's vault information into memory. Of course, I might have been doing something wrong or stupid, and I didn't spend a lot of time optimizing queries etc. Still, there was so little data involved that it should have been very fast even for bad queries. You say that a number of people have been using e.g. MySQL -- how is that working performance-wise? Do you convert the database to memory, edit stuff in memory, and then convert back to database; or do you work directly with the database information? I'm curious what your experience with this is. Mine has been largely negative but I suspect that's more because I was doing something wrong (or chose the wrong tool) than because of inherent speed issues.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Top

Posted by

Nick Cash USA (626 posts) Bio

Date

Reply #7 on Thu 23 Mar 2006 11:59 PM (UTC)

Message

All of my experiences with databases have been quite positivie. While I've dabbled with some others, I almost exclusively use MySQL (MyISAM tables relating to my mud).

In my dealings with MySQL, queries have been and continue to be very fast. On my machine (which is old and not really good for anything but textual programming), query times seem to average in the .025 second range, and none of the test queries I did (medium sized queries) took longer than .055 seconds. On my host a similar size query doesnt even list a time usually (meaning less than 0.00 seconds). Under more heavy usage things would probably change a bit more.

Like SMAUG, I load all of the information into memory, where it is then manipulated and later updated in the DB if need be. There are several advantages to this. For example, if you change a skill in SMAUG, it needs to write the whole file. With MySQL, you merely send an update query with the information thats been changed and it updates the specified row. And of course I enjoy not having to write all of the code to load files and handle everything related to that. Loading is a lot simpler without it.

Overall, making a MUD hook up to MySQL is quite easy (especially with a single global connection). There is relatively little one must do in the ways of code beyond include the right files and link the correct library. If you've ever worked with MySQL and PHP its very much the same.

If you want to see a sample implementation of MySQL in a MUD you could grab Scratch, which was being discussed on this forum just a bit ago. It isnt the best system I think, but it works well enough for a time. Eventually you need to copy query data into a local variable so another query doesnt overwrite it, which I think defeats the purpose of the system.

~Nick Cash
http://www.nick-cash.com

Top

Posted by

David Haley USA (3,881 posts) Bio

Date

Reply #8 on Fri 24 Mar 2006 12:27 AM (UTC)

Message

Interesting, thanks for the info. It seems more and more likely that I was doing something wrong, then. When I would load a single vault, and process the text information into an in-game object, it would take a very noticeable handful of seconds.

I wonder if that has to do with the database being in XML, and therefore, several layers of parsing are needed. (The DBMS has to first parse the XML and then run my query over it.) Also I would run several queries, which was necessary by the nature of the beast -- inside the vault node was a series of object nodes, and this series had to be iterated over which meant more queries, etc.

Still, all this being said, I think that I'll be moving to Lua, not MySQL. The reason for that is that if I'm going to be scripting in Lua anyhow, why not just tie them together? If the scripting can talk natively to the data storage, that's good times all around; otherwise you would have to have communication between MySQL, the MUD, the Lua, back to the MUD and MySQL, etc.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Top

Posted by

Nick Cash USA (626 posts) Bio

Date

Reply #9 on Fri 24 Mar 2006 03:58 AM (UTC)

Message

It is likely that the multiple levels of parsing probably played more of a role in the lag time than the DB query, though its hard to say for sure.

And I agree with you, if you plan on using Lua you may as well make the best use of it you can. The less interfacing between multiple API's and what not the better. I still do not have much experience with Lua (which hopefully will change soon), so I work with MySQL. Learning the queries and various things that go along with DB's will probably be helpful in the future anyway.

~Nick Cash
http://www.nick-cash.com

Top

Posted by

David Haley USA (3,881 posts) Bio

Date

Reply #10 on Fri 24 Mar 2006 04:41 AM (UTC)

Message

Oh, yes, knowing how to use MySQL and understanding SQL databases in general is an incredibly important skill as a programmer. As soon as you start working with relatively large quantities of data, the database (as it were) makes your life much easier.

You're probably right about the multiple levels of parsing. If I weren't using Lua by this point, I would go back and actually time the stuff to see where it's taking so long. But since I'm using Lua, it's pretty much irrelevant.

<rant>
As a general comment on SMAUG, a lot of it works this way. It started out quite simple, and a simple solution worked. In this case, storing everything as plain text with a somewhat hackish parser worked. So why change it? But then things started growing, and you start having many, many players with thousands and thousands of rooms. Suddenly the old format becomes brittle, and very rigid with respect to change. Maybe it wasn't such a clever idea to hard-code in sequences of numbers for mob stats, such that if the sequences aren't printed in exactly the right order things break. But by this point, fixing it means a lot of work, and, well, most people are somewhat lazy in that respect. (After all, it still "works", right?)

There are many examples of this in the SMAUG code. Part of that is due to the fact that it was built on Merc and Diku, so we have three whole levels of accretion built in. Mind you the SMAUG code base is still very nice work, but they made some design choices out of laziness that came and bit them in the neck fairly seriously. Sure, it's convenient to store pointers to next and previous in the object itself, and not a proper list node. But, then if you want an object to be in multiple lists, you have to store next/prev for each possible list the object could be in!

Anyhow, ... :-) </rant>.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Top

Posted by Nick Gammon Australia (23,057 posts) Bio Forum Administrator

Date Reply #11 on Fri 24 Mar 2006 05:07 AM (UTC)

Message

Further to anyone that may want to add Lua code to SMAUG (or anything else), I have done a few posts about imbedding Lua into your own C application, at:

http://www.gammon.com.au/forum/bbshowpost.php?bbsubject_id=6400

As I have said earlier, using Lua as a configuration file processor is very easy (and indeed what it was originally designed to do, I believe). Effectively "loading" your configuration file imports everything into it into the script space, including calculations. Stuff like:



max_level = 65

max_mortal = max_level - 10

... could easily be done in the configuration file, rather than having the C code needing to do lots of arithmetic and work out relationships.

Also, re-saving your config would simply be a case or serializing the appropriate table (examples of which are included on this site), which again makes it very simple to do.

The Lua data structure, which includes tables (and nested tables if you want) can express almost any data you want (like containers of containers) without any trouble.

The problem with SQL is that it is (by design) "flat", and if you want things like containers of containers you must necessarily express them with either multiple related entries in one table, or multiple tables.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

30,815 views.

It is now over 60 days since the last post. This thread is closed. Refresh page

Go to topic: Search the forum

top