Access every part of mob and player structure in 'if checks' If there's data, the mobs need to be able to discern it (maybe not outwardly, but it's always helpful in deciding how the mob should act).
As a builder, i'd like mudprogs to have more power… such as…
for mudprogs, i'd love for-loops, the ability to add variables into it, do high level mathematical functions. use any internal function from the mud. this could possibly be done with a 'function' table, or something equaly interesting.
Lets see what else.. I'd like to beable to make 'functions' so generic mudprog functions that could be called from other functions.
Access to all the structures, and have the ability todo simple comparison's, maybe even more advanced stuff.
thats just my basic opinion on some of the smaller ended things i'd like to see.
That's pretty much the reason I wrote my entire javascript system. Smaug's mprog system is great for simple tasks. In many ways it's simplicity is prefered to full featured language. But in others… it's sorely lacking. It's nice to see other people picking up on an embedded language. Heh, in truth I chose javascript because… most other embedded scripting languages are niche. JS is very common, with an abundance of tutorials. Most are related to client side web development, but that just uses the additional client-side libraries.
I prefer DG Script because it can do so much more than mobprogs, and can do most of the things listed above.
Skol said:
Access every part of mob and player structure in 'if checks' If there's data, the mobs need to be able to discern it (maybe not outwardly, but it's always helpful in deciding how the mob should act).
I believe DG can do what you're referring to, here's an example, albeit a very simplified one.
Name: 'Move Boulder', VNum: [57728], RNum: [ 3646] Trigger Intended Assignment: Objects Trigger Type: Command , Numeric Arg: 4, Arg list: move Commands: if %arg% == rock if %actor.str% > 16 %send% %actor% You manage to move a large boulder and reveal a tunnel leading into the ground. %echoaround% %actor% %actor.name% moves a large boulder revealing a tunnel leading into the ground. %door% 35711 down room 35735 else %send% %actor% You struggle to move the boulder, but alas you are not strong enough. %echoaround% %actor% %actor.name% pushes on a boulder with all %actor.hisher% might to no avail. end else %send% %actor% What would you like to move? end
Darien said:
for mudprogs, i'd love for-loops, the ability to add variables into it, do high level mathematical functions. use any internal function from the mud. this could possibly be done with a 'function' table, or something equaly interesting.
Something similar to this?
Name: 'Room While Teleport Example', VNum: [ 24], RNum: [ 24] Trigger Intended Assignment: Rooms Trigger Type: Random , Numeric Arg: 100, Arg list: None Commands: * By Rumble * Target the first person or mob in the room. eval person %self.people% wait 1 sec *While there are still mobs or people in the room. while %person% %send% %person% You are next! %echo% I am targetting %person.name%. %echoaround% %person% %person.name% is struck by a bolt of lightning. Leaving only a pile of ash. %teleport% %person% 3 %force% %person% look eval person %self.people% done
Darien said:
Lets see what else.. I'd like to beable to make 'functions' so generic mudprog functions that could be called from other functions.
Unfortunately DG Script can not do that, but LexiScript which were derived from DG Script can.
you should check out mudfiles.com fizban, download the old released version of leximud, its like, 10 years old, but its still full of really good things.
i as stated before, have a copy of one of the newer editions of it as i made a nice deal with fear to get it.
its a great system, i'm working on portin gover the features i like from it to work in the existing mudprogs, so that i don't have to rewrite the mudprogs ground-up (in mud) to the new system.
Trying to give the features of lexi without having to use the script itself.
As a builder, i'd like mudprogs to have more power… such as…
for mudprogs, i'd love for-loops, the ability to add variables into it, do high level mathematical functions. use any internal function from the mud. this could possibly be done with a 'function' table, or something equaly interesting.
More power unfortunately doesn't mean the builders will actually use it. Though variables are a must have there's little to gain by adding functionality that will only confuse most builders.
well, thats the thing, my mud rely's heavily on mudprog power, its how we run our quest system, so the more power it has, the more availability and variety of quests can be created. staving out of the norm.
And since i write most of the progs myself, they would be used quite nicely :)
As a builder, i'd like mudprogs to have more power… such as…
for mudprogs, i'd love for-loops, the ability to add variables into it, do high level mathematical functions. use any internal function from the mud. this could possibly be done with a 'function' table, or something equaly interesting.
More power unfortunately doesn't mean the builders will actually use it. Though variables are a must have there's little to gain by adding functionality that will only confuse most builders.
While I can understand you're point of view, but I wouldn't assume that builders would be confused. Many builders have asked about a way to run a prog for each character or object in a room, for varying reasons. Anyone with a high school level of education should be able to handle a little math.
i just want the high powered progs to make my life easier, because things that cannot be done in the progs, i have to code into the mud, this i want to change, as i'm trying to size down my 500,000 line monstrosity, things that can be done with progs, will be. Thats the goal.
As a builder, i'd like mudprogs to have more power… such as…
for mudprogs, i'd love for-loops, the ability to add variables into it, do high level mathematical functions. use any internal function from the mud. this could possibly be done with a 'function' table, or something equaly interesting.
More power unfortunately doesn't mean the builders will actually use it. Though variables are a must have there's little to gain by adding functionality that will only confuse most builders.
While I can understand you're point of view, but I wouldn't assume that builders would be confused. Many builders have asked about a way to run a prog for each character or object in a room, for varying reasons. Anyone with a high school level of education should be able to handle a little math.
On the flipside the speed with which vast amounts of high-level interactive material can be produced with a decent scriptengine means that you'd only need one or two people well versed with it for it to be effective. Most others can copy the functionality they don't understand and modify what they do to achieve their own goals, learning along the way.
I definately agree with that. With this in mind, and to reduce the amount of script that needs to be maintained, I've added the ability to store scripts on a vnum and include them into a prog. It's useful for common script tasks (ie… random speech) or atmosphere type scripts that are used repeatedly (ie… npc behavior). The final reason is that they're tied into the security model. While I haven't used security much, include scripts run in a separate security mode than the prog or script that they're included from. This allows higher level builders to provide functionality that a lower level builders cannot access.
I'm the same way I don't believe in the concept of spec-procs for the most part. I personally aim to do as much as humanly possible with DG Scripts/mobprogs and as little with spec-procs. The main reasoning behind this is that builders can add functionality easier using scripting than a ton of builders sending all their ideas to a single coder and having them add them in.