31 Jul, 2011, melopene wrote in the 1st comment:
Votes: 0
A number of my builders are interested in learning how to write progs (I use the standard version with a few of my own additions), and the standard documentation and Mish's guide don't seem to be doing the trick. Do any of you have guides that you or your staff has written for the absolute novice, and if so, would you be willing to share?

Thankee :)
31 Jul, 2011, Scandum wrote in the 2nd comment:
Votes: 0
Lola has an in game hyperlinked helpfile system, though I'm not sure if that'll be much use for ROM systems. It also comes with a couple of 3rd and 4th generation quest areas which are a good resource if you're interested in examples and different approaches to quest design.

It was my experience back in the day that builders who never played my MUD, and as such weren't used to complex area based quests, were useless. It always felt like trying to teach your grandpa how to use a cellphone and I eventually stopped bothering altogether and hand picked the most qualified from the player base.
31 Jul, 2011, Elervan wrote in the 3rd comment:
Votes: 0
http://www.ansalonmud.com/building/

Has a lot of building information on it, might be slightly different but it is based on the ROM versions. I know it shows information for Mprogs, but I am not sure if they introduce oprogs/rprogs as well, but they are quite similar in function.
31 Jul, 2011, Rarva.Riendf wrote in the 4th comment:
Votes: 0
If yourself know how to code mobprogs in ROM , start by just asking what they want to do, and code it yourself. After while with enough example they can refer to, they can try by themselves. Most guides out there only refer to what is possible with basic ROM. That is, not much.
31 Jul, 2011, Ssolvarain wrote in the 5th comment:
Votes: 0
Rarva.Riendf said:
That is, not much.


Once you include the ability to use variables in mprogs, it's like the whole world shifts and the possibilities are just flying.
Alias goes right in there with it. I -love- the alias trigger.

The two make building a much less frustrating thing.


Forgot to mention, I'd be happy to help them with anything if they were to post to mudbytes.
31 Jul, 2011, melopene wrote in the 6th comment:
Votes: 0
Scandum said:
It was my experience back in the day that builders who never played my MUD, and as such weren't used to complex area based quests, were useless. It always felt like trying to teach your grandpa how to use a cellphone and I eventually stopped bothering altogether and hand picked the most qualified from the player base.


Two have a background with this type of game, one doesn't. Personally, I don't see what's so difficult since progs are just a series of conditional statements, but then I'm all giddy about tormenting grad students with statistics this semester, so I'm probably not the best point of reference.

Also, I can't find a listing here or on mudconnect for 'Lola'…



I've found that, and thought it provided some good examples, but
31 Jul, 2011, Rarva.Riendf wrote in the 7th comment:
Votes: 0
Ssolvarain said:
Rarva.Riendf said:
That is, not much.

Once you include the ability to use variables in mprogs, it's like the whole world shifts and the possibilities are just flying.
Alias goes right in there with it. I -love- the alias trigger.

You have variables already in default ROM, my point was more about the mpxxx methods. They are quite limited, and as Melopene says, you cannot du much but conditional statements and call to these methods.
As an example I have a mob that can recover all the corpses of a player wherever they are, even if the player disconnected in between etc. That is done through a spec in my mud, I doubt you could do it with a mprogs (you really need a full access to every mud variable to do that). I think mprogs were limited in order to limits builders access in the first place. I think mprogs should be limited as well, everything more complex should be either a spec, or be rebuild to accept a real scripting langage (usully LUA)
31 Jul, 2011, Tyche wrote in the 8th comment:
Votes: 0
Here's the mobprog help files from my old game.
It's pretty much as the original World's of Carnage documentation plus a few notes.
http://www.mudbytes.net/pastebin-48389
Having them online and in small readable pieces might help slightly.

Here's my snippet to add a single variable that can be saved and queried on whatever mobile the prog is attached too.
[link=file]707[/link]
Saving state is very useful. Some examples included.
31 Jul, 2011, Tyche wrote in the 9th comment:
Votes: 0
Rarva.Riendf said:
You have variables already in default ROM…

Just a historical note. No official release of ROM includes either mobprogs nor OLC.
IIRC, there was a patch file created by someone with the handle Thanatos(?) that patched moprogs and ILAB OLC into ROM.
A distribution with the patch already applied was released at some point and can be found here.
01 Aug, 2011, melopene wrote in the 10th comment:
Votes: 0
Tyche said:
Here's my snippet to add a single variable that can be saved and queried on whatever mobile the prog is attached too.
[link=file]707[/link]
Saving state is very useful. Some examples included.


Thanks for both of those! I was actually planning that kind of functionality but also saving variables like that into pc_data and onto pfiles, so that quests can be repeatable only once, or a handful of times - or even to store an individual's progress over a number of individual steps in a long, complex series of tasks. Your snip put me 85% of the way into having the latter done as well.

*gives Tyche a gold star*
01 Aug, 2011, Rarva.Riendf wrote in the 11th comment:
Votes: 0
Tyche said:
Rarva.Riendf said:
You have variables already in default ROM…

Just a historical note. No official release of ROM includes either mobprogs nor OLC.
IIRC, there was a patch file created by someone with the handle Thanatos(?) that patched moprogs and ILAB OLC into ROM.
A distribution with the patch already applied was released at some point and can be found here.

You are right, olc.c and merc.c are not in ROM as default, but are so quickly added I hardly see any ROM without it.
There is also a snippet that you should use Melopene, it is the event snippet
http://www.mudbytes.net/file-497
It will allow your mobs to start an action not right away but later (like only talking if someone stay in the room for more than xxx pulse instead of right away, or randomly every xxx pulse)
01 Aug, 2011, Scandum wrote in the 12th comment:
Votes: 0
melopene said:
Two have a background with this type of game, one doesn't. Personally, I don't see what's so difficult since progs are just a series of conditional statements, but then I'm all giddy about tormenting grad students with statistics this semester, so I'm probably not the best point of reference.

It's not so much the programming aspect as the quest design aspect. If you have person A) who lived in a house of sticks and mud his whole life, and person B) who lived in a cabin his whole life, next you ask both of them to build a house you'll obviously see some differences. What's worse, person A might be content to live in a house of sticks and mud.

An introduction to quest design might be helpful though.

melopene said:
Also, I can't find a listing here or on mudconnect for 'Lola'…

Lola is a codebase.


Tyche said:
Here's my snippet to add a single variable that can be saved and queried on whatever mobile the prog is attached too.
[link=file]707[/link]
Saving state is very useful. Some examples included.

A single 32 bit value is rather limiting. I'd suggest using my quest bit snippet which uses a 64 bit value that can be segmented into 64 booleans, or 16 quests each of 16 steps, 8 quests each of 256 steps, or any mixed combination.
[link=file]2562[/link]
01 Aug, 2011, David Haley wrote in the 13th comment:
Votes: 0
Don't use a fixed-size bit system. That might have been appropriate 20, 30 years ago. We're not in the 80s anymore. Use real data structures; no need to constrain yourself to entirely artificial limits on how you can segment your 64 bits.
01 Aug, 2011, Rarva.Riendf wrote in the 14th comment:
Votes: 0
David Haley said:
\We're not in the 80s anymore. Use real data structures\

Only if it is needed. No need to add complexity in a simple ROM code. Otherwise you could also say: Move to a real database for handling players/areas, a coding langage that does not make handling string a headache, and that used dynamically string buffer instead of fixed size….or rewrite the whole ROM code to move it to the 21 century.
01 Aug, 2011, David Haley wrote in the 15th comment:
Votes: 0
Sorry, but you should read what was being proposed…

And frankly, a good bitvector library is very easy to use, and causes far less confusion than people saying "why can't I add this one additional bit", etc.
01 Aug, 2011, Ssolvarain wrote in the 16th comment:
Votes: 0
Rarva.Riendf said:
You have variables already in default ROM


I'm talking about the ability to set, check and manipulate variables on mobs and players via mprogs.

Not the uses of $* characters.
01 Aug, 2011, Rarva.Riendf wrote in the 17th comment:
Votes: 0
David Haley said:
Sorry, but you should read what was being proposed…

And frankly, a good bitvector library is very easy to use, and causes far less confusion than people saying "why can't I add this one additional bit", etc.

For Melopene: David lib is here
http://www.mudbytes.net/file-2640
And for your remark. I just realized that they limit themselves to a verly low number of bit. (64 at max).
I kinda of do the same thing than you except I store my bits into chars.
01 Aug, 2011, Scandum wrote in the 18th comment:
Votes: 0
David Haley said:
Don't use a fixed-size bit system. That might have been appropriate 20, 30 years ago. We're not in the 80s anymore. Use real data structures; no need to constrain yourself to entirely artificial limits on how you can segment your 64 bits.

64 bits per area is more than enough. As I said earlier, that's enough for sixteen 16 step quests, with most areas having difficulty using more than 16 bits.

Typically you'd want to place a quest bit field on each area, object, mobile, as well as an array of quest bit fields on the player so each area has its own field unique to that player. Rooms can have a field as well, but being unique they can share the area field.
02 Aug, 2011, David Haley wrote in the 19th comment:
Votes: 0
I guess you're right. Who could need more than 64k cache?? Crazy talk.
02 Aug, 2011, Runter wrote in the 20th comment:
Votes: 0
640K ought to be enough for anybody.

Wait, this isn't 1981?
0.0/29