23 Dec, 2007, Avaeryn wrote in the 1st comment:
Votes: 0
Trying to get this prog working, which does NOT right now. I've tried several different variations and none work so far. Any help is appreciated.

The object is steam-powered boots of great striding. Wheels in the soles are powered by a miniature steam engine. Sometimes the wheels or engine malfunction with varying results. Here's the prog so far:


if rand(20)
and if iswearing($n,7316)
mpecho `GThe wheels in the soles of steam-powered boots of great striding roll smoothly with each step.`X
else
if rand(25)
and if iswearing($n,7316)
mpecho `GThe wheels in steam-powered boots of great striding suddenly lock up!`X
mpforce $n sit
else
if rand(33)
and if iswearing($n,7316)
mpecho `GSteam hisses from the engine attached to the steam-powered boots of great striding.`X
else
if rand(50)
and if iswearing($n,7316)
mpecho `GThe wheels in the soles of steam-powered boots of great striding fail to stop rolling!`X
mpforce $n rest
else
if iswearing($n,7316)
mpecho `GThe steam-powered engine begins to overheat and turn red!`X
mpecho `GSuddenly, the steam-powered boots of great striding explode into a thousand pieces!`X
mppurge
endif
endif
endif
endif
endif
23 Dec, 2007, Avaeryn wrote in the 2nd comment:
Votes: 0
The coder has just informed me that rand progs won't work in this instance since there is no trigger. Any ideas for pulling this off?
23 Dec, 2007, Zeno wrote in the 3rd comment:
Votes: 0
Correct, a rand prog on an object has nowhere to get $n from. And coding it in isn't simple either, because the obj wearer isn't passed into the supermob.

Although that's for Smaug. I don't know what codebase you're using.
24 Dec, 2007, Conner wrote in the 4th comment:
Votes: 0
Why not try just turning it around something like:
if iswearing($n,7316)
and if rand(20)
mpecho `GThe wheels in the soles of steam-powered boots of great striding roll smoothly with each step.`X
else
if iswearing($n,7316)
and if rand(25)
mpecho `GThe wheels in steam-powered boots of great striding suddenly lock up!`X
mpforce $n sit
else
if iswearing($n,7316)
and if rand(33)
mpecho `GSteam hisses from the engine attached to the steam-powered boots of great striding.`X
else
if iswearing($n,7316)
and if rand(50)
mpecho `GThe wheels in the soles of steam-powered boots of great striding fail to stop rolling!`X
mpforce $n rest
else
if iswearing($n,7316)
mpecho `GThe steam-powered engine begins to overheat and turn red!`X
mpecho `GSuddenly, the steam-powered boots of great striding explode into a thousand pieces!`X
mppurge
endif
endif
endif
endif
endif

Would that work instead? That way you're not asking the prog system to find a $n value within a rand but checking a rand within a iswearing. Just a thought, the alternative would seem to be a great deal of coding effort.
24 Dec, 2007, kiasyn wrote in the 5th comment:
Votes: 0
Conner said:
Why not try just turning it around something like:
if iswearing($n,7316)
and if rand(20)
mpecho `GThe wheels in the soles of steam-powered boots of great striding roll smoothly with each step.`X
else
if iswearing($n,7316)
and if rand(25)
mpecho `GThe wheels in steam-powered boots of great striding suddenly lock up!`X
mpforce $n sit
else
if iswearing($n,7316)
and if rand(33)
mpecho `GSteam hisses from the engine attached to the steam-powered boots of great striding.`X
else
if iswearing($n,7316)
and if rand(50)
mpecho `GThe wheels in the soles of steam-powered boots of great striding fail to stop rolling!`X
mpforce $n rest
else
if iswearing($n,7316)
mpecho `GThe steam-powered engine begins to overheat and turn red!`X
mpecho `GSuddenly, the steam-powered boots of great striding explode into a thousand pieces!`X
mppurge
endif
endif
endif
endif
endif

Would that work instead? That way you're not asking the prog system to find a $n value within a rand but checking a rand within a iswearing. Just a thought, the alternative would seem to be a great deal of coding effort.


same problem. he means a rand_prog, ie the trigger is random, as opposed to the rand() function
24 Dec, 2007, blueice wrote in the 6th comment:
Votes: 0
actually getting a rand_prog to pull the char from a worn/carried object is quite simple, tell your coder to view this:

open mud_prog.c and modify mprog_translate(), replace the two cases for n and N with the following:
case 'n':
if ( actor && !char_died(actor) )
{
if ( can_see( mob,actor, FALSE ) )
one_argument( actor->name, t );
if ( !IS_NPC( actor ) )
*t = UPPER( *t );
}
else if ( obj && obj->carried_by && !char_died(obj->carried_by) )
{
one_argument( obj->carried_by->name, t );
if ( !IS_NPC( obj->carried_by ) )
*t = UPPER( *t );
}
else
strcpy( t, "someone" );
break;

case 'N':
if ( actor && !char_died(actor) )
{
if ( can_see( mob, actor, FALSE ) )
if ( IS_NPC( actor ) )
strcpy( t, actor->short_descr );
else
{
strcpy( t, actor->name );
strcat( t, actor->pcdata->title );
}
else
strcpy( t, "someone" );
}
else if ( obj && obj->carried_by && !char_died(obj->carried_by) )
{
one_argument( obj->carried_by->name, t );
if ( !IS_NPC( obj->carried_by ) )
*t = UPPER( *t );
}
else
strcpy( t, "someone" );
break;
24 Dec, 2007, Avaeryn wrote in the 7th comment:
Votes: 0
Yes the prog was a rand triggered prog. Unfortunately I did not keep a copy of that particular prog since it didn't work and things could not be rectified before the area was complete. The players will still have fun trying to figure out how to put all the pieces for the boots together, that's about the extent of the excitement for them there :thinking:

I appreciate all the efforts here to give help. Altering the mud code for progs to do what I would like it to do is something that probably won't happen. I could ask, but you know how that goes. It would be great if the prog had worked, but it didn't. Sometimes you just have to go with a new idea.
24 Dec, 2007, Omega wrote in the 8th comment:
Votes: 0
modifying the code to make work…. Oh this is why i use Lua.. ;)
25 Dec, 2007, Conner wrote in the 9th comment:
Votes: 0
Darien said:
modifying the code to make work…. Oh this is why i use Lua.. ;)

And there's something wrong with a coder modifying the code to accommodate their builders? :ghostface:
25 Dec, 2007, Omega wrote in the 10th comment:
Votes: 0
Actualy conner, there is nothing wrong at all with that fact :) however, with the way I encorperated lua into my mud, i don't need to modify the code :) i can do most of my alterations in lua, only thing i really do to the source nowadays is just solidify it so it is more crash proof.

And luckily, if the lua bugs out, the prog just won't run :P anyways :P
26 Dec, 2007, Conner wrote in the 11th comment:
Votes: 0
That's certainly what David's been preaching, but for those of us who haven't removed all vestiges of mudprogs and replaced them with Lua or some other scripting language yet.. changing the code to make it more functional for the builders we work with is one of the best uses of our time available. :wink:
26 Dec, 2007, Omega wrote in the 12th comment:
Votes: 0
I still have normal mudprogs, but even those are greatly modified, including foreach loops, variables, the works.

can do everything from using $n to send name or character data, to using %actor.hp% or doing something like set victim mob 3323 %victim.hp% to grab data. its quite endowed, however, i found that the use of lua greatly aided my development, put lua in almost 8 months ago, created afew things, in the lua editor, you have options like, command, or load on startup, load on startup i use for global events, commands. Other options are mudprogs in-general.

Another tid-bit i did was modify the regular mudprogs to use a certain update, ie, if i do LUA <return> then lua code then /LUA it processes that lua code, within a standard mudprog. Sorta as a way to keep normal mudprogs running, (as they use less processing then loading lua all the time for simple things) and if i need it, i can simply just run lua within the prog.

another case/point of the matter is my internal webserver was written in lua :) and it runs on startup, all the options are there. but it can cost greatly on the VSZ..

Anyways, enough of that rant… my lame overbearing amount of code when it comes to developing mudprogs… (i've got the better half of 150,000 lines of code, all mudprog engine) everything from as i said before, %actor% style enhancements, to the normal $n stuff, to including lua, to doing complete lua enhancement. i've found that using all of them, is greatly helpful, my builders can work with standard mudprogs (with great enhancement.. ie, the variable system/forloops) and for the more advanced people (ie, how i hire coders nowadays) is hiring lua programmers. and while i do that, i'm slowly cutting out my hard-coded systems, and rewriting in progs/lua, its just how i go about things now. since sandstorm was over 500,000 lines of code, i've dropped it down to 350,000, and as stated above, 150,000(roughly) is the interpreted languages. and sooner or later, i'll have that all cut down aswell.

anyways, thats my rant.
26 Dec, 2007, Kjwah wrote in the 13th comment:
Votes: 0
Darien said:
I still have normal mudprogs, but even those are greatly modified, including foreach loops, variables, the works.

can do everything from using $n to send name or character data, to using %actor.hp% or doing something like set victim mob 3323 %victim.hp% to grab data. its quite endowed, however, i found that the use of lua greatly aided my development, put lua in almost 8 months ago, created afew things, in the lua editor, you have options like, command, or load on startup, load on startup i use for global events, commands. Other options are mudprogs in-general.

Another tid-bit i did was modify the regular mudprogs to use a certain update, ie, if i do LUA <return> then lua code then /LUA it processes that lua code, within a standard mudprog. Sorta as a way to keep normal mudprogs running, (as they use less processing then loading lua all the time for simple things) and if i need it, i can simply just run lua within the prog.

another case/point of the matter is my internal webserver was written in lua :) and it runs on startup, all the options are there. but it can cost greatly on the VSZ..

Anyways, enough of that rant… my lame overbearing amount of code when it comes to developing mudprogs… (i've got the better half of 150,000 lines of code, all mudprog engine) everything from as i said before, %actor% style enhancements, to the normal $n stuff, to including lua, to doing complete lua enhancement. i've found that using all of them, is greatly helpful, my builders can work with standard mudprogs (with great enhancement.. ie, the variable system/forloops) and for the more advanced people (ie, how i hire coders nowadays) is hiring lua programmers. and while i do that, i'm slowly cutting out my hard-coded systems, and rewriting in progs/lua, its just how i go about things now. since sandstorm was over 500,000 lines of code, i've dropped it down to 350,000, and as stated above, 150,000(roughly) is the interpreted languages. and sooner or later, i'll have that all cut down aswell.

anyways, thats my rant.


Couldn't you have done most of that a lot more simple though by providing builders a solid foundation to work off of that might have been something like LUA?
26 Dec, 2007, David Haley wrote in the 14th comment:
Votes: 0
Darien said:
(as they use less processing then loading lua all the time for simple things)

If that is true (have you empirically verified it?) you might be doing something wrong. Lua is very fast, shouldn't be loaded up every time you need to run something, and the mudprog engine reinterprets the whole script every time. How are you calling Lua scripts?

Kjwah said:
Couldn't you have done most of that a lot more simple though by providing builders a solid foundation to work off of that might have been something like LUA?

Well, that is what I would have done: set all the stuff up in Lua from the get-go and work from there.

Incidentally it is Lua, not LUA. (It's not an acronym; it means 'moon' in Portuguese.)
28 Dec, 2007, Omega wrote in the 15th comment:
Votes: 0
David, I'm very cpu/mem crazy, if it spikes, even a bit, I know about it. When Lua interprets a script, it bumps abit, much like the standard usage of mudprogs, however, i've noticed that it has more significant draw then the mudprogs. not enough to really care/worry about, however, I tend to look too much into things, it could of been the size of the scripts skewing the clock, so i cannot be 100% on the details.

Kjwah, I started out with Rom24, with Ivans OLC 1.81, 12 years ago, almost 13, (the OLC version upgraded over the years to 1.81, forgot what i started with) and the Lua addition is very recent. Meanwhile the mudprogs were there for ages, the upgrade to Lua greatly enhanced things for me personaly, because of how/why we were seeking to greatly advance the mudprogs. Thus why I am at the state I am now.

Though since I am writing sandstorm ground up right now (apposed to completely revamping my source any more then I already have) I intend to just go with Lua from the start.
28 Dec, 2007, Conner wrote in the 16th comment:
Votes: 0
It certainly sounds like it'll be a very interesting codebase once it's done, Darien.. as much as we know you tend to go nuts about security and memory..

BTW, speaking of OLC, any word on the progress with that new interface? :wink:
28 Dec, 2007, Omega wrote in the 17th comment:
Votes: 0
ROCS development has slowed greatly since my wife gave birth, sorta hit the back-burner, however, I do work on it when the kiddo isn't being a 7week old trouble maker :P its slow processing, but when its done, it'll be much worth it. I know its taking allot longer then originaly anticipated, but, what can one do when their life changes drastically.

as for security nuts, yeah, i am, and i'm sorta worried about the damage a builder could do in Lua if they knew what they were doing :P as i can't exactly stop them from going crazy. so with that being said, David, any suggestions?
28 Dec, 2007, kiasyn wrote in the 18th comment:
Votes: 0
trust
29 Dec, 2007, David Haley wrote in the 19th comment:
Votes: 0
Darien said:
so i cannot be 100% on the details.

Well, ok, but before doing anything about it I would do empirical testing, but not just watching the processor usage. By that I mean actually writing timing code and seeing how long comparable scripts take to execute in both systems; also, it would be worth verifying that you're using Lua correctly. (Well, correctly is the wrong term; perhaps "not wastefully" or "optimally" is better…)

Darien said:
as i can't exactly stop them from going crazy. so with that being said, David, any suggestions?

Actually you can stop them from doing pretty much whatever you want. :wink:

The idea is called sand-boxing: you can set symbols to nil, therefore preventing them from being accessed. Let's assume you don't want the scripter to be able to call anything from the os table (like os.exit). You can either set os.exit to nil when you create the Lua environment, or you can set the entire os variable to nil. Remember that in Lua none of these variables are special: you can set os.exit to be the same function as io.write if you wanted to.

So, you do that with all the tables or functions you would like to restrict. You typically do this when you create the Lua state. You can/should also do the following:

- execute every script (even trusted scripts) from a protected environment, so that if there is an error it is caught by your program and therefore doesn't cause the whole program to die.

- modify the environment of untrusted scripts so that they have read-only access to global variables (or read-only access to only some variables or write access to only some or …). You would typically do this using a meta-table that implements __index and __newindex.

- make sure that the functions with which you extend the Lua state (i.e. your own C functions) are perfectly safe and will never cause the program to crash. That means doing things like checking types (using Lua's built-in type checking). This way, any error in scripts will be caught normally by Lua and sent back to the error handler you set up above.

Of course, for scripts to be able to do interesting things, you will need to open up the environment somewhat. In the end of the day it is your decision and yours alone what you consider to be safe, and you will have to have some degree of trust eventually, as Kiasyn said.
30 Dec, 2007, Omega wrote in the 20th comment:
Votes: 0
David, thanks for the advice, i'm going to work on that, thankfuly at the moment, my system requires my authorization for the script to work at the moment until i can filter out things that i don't want people to use, though i may make them all work, and just detect if they are used within the script, there-for upon detection, the script would require authorization to be ran (once marked as authorized it would work from there anyways..) anywho, :) thanks again.
0.0/27