02 Aug, 2011, Vigud wrote in the 21st comment:
Votes: 0
I agree with Runter. I don't even have that much memory on my Atari 2600.
02 Aug, 2011, oenone wrote in the 22nd comment:
Votes: 0
Runter said:
640K ought to be enough for anybody.

Wait, this isn't 1981?


The one, who this quote is often attributed to, never actually said it.
02 Aug, 2011, Runter wrote in the 23rd comment:
Votes: 0
oenone said:
Runter said:
640K ought to be enough for anybody.

Wait, this isn't 1981?


The one, who this quote is often attributed to, never actually said it.


Quote
the move […] to 640k felt like something that would last a great deal of time

Quote
It [640K] was ten times what we had before. But to my surprise, we ran out of that address base for applications within oh five or six years


The sentiment is quite the same, and Bill Gates has denied that he said those things in the context of, you know, not feeling that 640k was "enough." But his other statements actually contradict that. It appears he did believe 640k was "something that would last a great deal of time."
02 Aug, 2011, Scandum wrote in the 24th comment:
Votes: 0
It helps if you have real experience with the topic you're talking about, or have to intelligence to run a virtual simulation, and come up with reasonable arguments rather than a vague 'it can't be!'.
02 Aug, 2011, melopene wrote in the 25th comment:
Votes: 0
I think my implementation for saving prog status to players will actually be similar to how I handle player info files and 'known' status (I use a short desc/intro system). That seems like a quick and dirty solution, and would let me store strings in addition to values.

Of course, if there ends up being a gazillion progs that use that functionality, it could lead to some large pfiles down the line. Of course, so could having a lot of very popular players, so I'm not too worried about it.
03 Aug, 2011, Hades_Kane wrote in the 26th comment:
Votes: 0
Rarva.Riendf said:
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)


I don't think it would be too difficult to expand our prog system to be capable of doing something like that. Generally speaking, anything that any of our builders has asked for, we've been able to expand our program system to be able to accomplish. I've probably done more coding on improving and adding to our OLC than almost anywhere else in the game. I agree that the bare bones mprog system is quite lacking and very limiting, but like anything in ROM or any other codebase, I think the key word there is -base-. No one should ever boot up a codebase and consider it anywhere near complete, it should be the base upon which everything else is built and added to. With a little bit of work, our program system has become quite versatile.
04 Aug, 2011, Rarva.Riendf wrote in the 27th comment:
Votes: 0
Quote
I think the key word there is -base-. No one should ever boot up a codebase and consider it anywhere near complete, it should be the base upon which everything else is built and added to. With a little bit of work, our program system has become quite versatile.

I totally agree you can expand the base system to whatever you want, but when you come from pretty much nothing (base ROM), you have to think:is it better to expand, or scrap the thing and use something more script oriented in the first place. Concerning mprogs I think you are better off offering a real scripting language than rewriting one that is not portable as well.
08 Aug, 2011, Fizban wrote in the 28th comment:
Votes: 0
Rarva.Riendf said:
Concerning mprogs I think you are better off offering a real scripting language than rewriting one that is not portable as well.


The problem there is that non-coders will likely find learning something like LUA very daunting. To a programmer learning a new language is trivial, to someone who has no programming experience at all though it isn't.
08 Aug, 2011, Tyche wrote in the 29th comment:
Votes: 0
Scandum said:
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]

Pardon the late reply as I've been on vacation. We didn't use it as a global quest bit completion thingamajig. If you look at the code it's an integer attached locally to the particular mobile instance. All it represents is the state of that particular mobile. That is the mobile has 4294967295 possible states. I don't think we had any progs that used more than 20 different states.

However, we did indeed use it to implement quests. When a mob got to a certain state via a combination of actions on the characters part, they were given a reward. But that's not at the same use case as storing quest results, we didn't even keep track of characters completing quests.

In our case, we also had roomprogs and objprogs that implemented the mpstatus code as well. You can find my roomprg/objprog code here.
Anyway for objects I added a 'use trigger' which would pass the name of the command one used with an object. I also created a buttload of dummy commands for players like do_use, do_push, do_pull, do_press, etc. which all called do_use() which in turn merely invoked the use_trigger or said "you can do that with this". :-)

Here's an example. This is an object, a blackboard, that sat in a room. If the player typed 'push blackboard', the blackboard objprog would send some messages to the player that they moved it, create an exit north to another room, and then issue a delay. The delay program would send a message to the room that it slid back in place, destroy the exit. The status variable is just used to store the state of the blackboard (it is slid to the side, or not yet slid to side).

#23028
blackboard~
`Dthe blackboard of Tyche`x~
`DA blackboard with many `wchalk`D scrawlings stands in the corner.`z~
stone~
trash R P
0 0 0 0 0
108 32767 10000 P
P 'use' 23028 push~
P 'delay' 23029 100~

#PROG
vnum 23028
code if status $i == 0
status 10
echoat $n You push aside the blackboard revealing an opening in the north wall.
echoaround $n $n pushes aside the blackboard revealing an opening in the north wall.
exit north room 3054
exit north name opening
delay 5
else
echoat $n The blackboard has already been pushed aside.
endif
end
~
#END

#PROG
vnum 23029
code if status $i == 10
status 0
echo The blackboard slides back to cover the opening in the north wall.
exit north delete simple
endif
end
~
#END


Note: The exit command above was also a homegrown command.
20.0/29