Readding eval()
 

eval( string )
... Serverside only AT THE LEAST. Please?

Dumb question, but what did eval do? Was it the standard strtofloat, or did it execute the command "string" (ie, eval (playerx=32))?

check out this thread, btw you could have tried too do an forum search for eval

Forum search for eval

This isn't the eval he is talking about.

The eval most likely is talking about is where you pass a string of code and it will execute the code. Which was disabled for security reasons.

Ah, didn't know that :)
btw, so an eval command could of been scripted by yourself?

That thread is talking about how the engine treats conditionals.

The function eval does:
And the evalFIX does
It's talking about optimization of returns that are inconsistent, because they present two different versions. But... Technically, if something isn't true, it's false... So, if it's not false, it's true. They are two different ways to write the same thing, but they yield different results.

That is NOT what I was asking for.

eval( string ) is a Graal v3 feature that was removed due to security reasons. It was useful because it would execute the code in the string.

It is disabled, but -- If we're on Serverside, this security risk isn't true. I could script my own eval, yes... But that would mean I would have to map out all the operators, set up a parser, and actually parse the information.

This can be done, but it's very prone to flaws. It's much easier to simply use the already created ( but disabled ) version.

By eval, he means something like..
eval(putexplosion,3,player.x,player.y);
or something?

well I thought by doing an forum search I could find out what eval was @ Tyhm
oh well, I tried ^^

It is always a security issue because there will always be people who don't properly secure their code. Not only that but there will be people who will hide eval() scripts in order to abuse scripting once they have left a staff team or so.
... or so.

No more dangerous that putnpc2.

NPC Code:

---

putnpc2(#c,playerx,playery);

---

=end of teh w0rld

I know... But -- Should the limitation be expressed by the current staff? I mean... People could potentially rescript the eval if they intended to do such... It doesn't pose any real security -- Only an articifial one.

But -- This is like:
It is there for a reason ( there is because too many people have done = instead of ==, and to remain consistent with GS1, GS2 loses the ability to )
HOWEVER... It diminishes the language unneededly.

Good programming practices should be honored and have their benefits. Bad programming should yield errors and unexpected results. It keeps the language universally understandable... and learning proper programming mechanics would be quite benificial for post-Graal work.

Genius.

Reviving a dead thread here but could eval() perhaps have a an option similar to clientrc in server options? eg.

restrictclientrctoweapons=-ScriptedRC
restrictevaltoweapons=-System

eval() would be useful. Especially for an upcoming project I have in mind.

Yes, having a serveroption for eval() would be best I believe.

I agree, even though I don't even script or have any idea what anything other than if () does.

Oh ho ho, I would love such a function. First add a serveroption that allows you to limit built in functions to certain npcs then reenable eval() :)

I'd love for eval() to come back. I have so many ideas for it :D

Ah examples please, there are several ideas of eval which seem to be quite different (some refer to eval as something that solves "1 + 2" or so). Also there was never an eval() function in Graal so I need some examples where you need it.

I think they are thinking along the lines of PHP's eval, where the passed string parameter is parsed as script commands or so. Here is a PHP example:
Return values are also passed through eval in PHP:
... would produce "foo".

Pseudo cause I can't remember it right:
if(startswith(#c,"setplayerprop")){
eval(#c);
}
Horribly dangerous, that one, but you get the idea. Should only be used for horribly complex scripts that are too long to Example, like a system NPC that dynamically displays thingies based on 3 other NPCs.

Hmmm Such an eval() would be bad design in my opinion, makes code looks less easy to understand, more unsecure and is not adding new functionality. So before adding something like that I would need to see some real application for it.
I initially though fo some thing that can compute stuff like "3 + 5 / 2", without the ability to access functions or similar.

I'll pm my use. It's still kinda secret ^^.

I'd say that eval() would make GS2 more complex, since it would then allow scripts to execute scripts. That is something I've always wanted to work with on Graal.

My opinion is the same, it would also be good for a quest system that I was thinking of, where you could store the script for each quest stage in a text file with quest data. But since thats not possible I have to make a weapon for each Quest so they can run their own scripts properly across clientside and serverside.

Seems like insecure design to rely on eval()-like functionality to do that. :|

Maybe, it was a passing thought. Don't see how its much different that placing something in scripts folder.
Quests will work much better as their own object that manipulates the mudlib rather than a part of it.

My current use for eval() would be in my Dialog System, when a response to a topic is evaluated from the conditions of the response, a number of functions are allowed to be executed. For now it is only able to execute one function per script line.
The functions AddItem and AddMsg are defined in the DialogControl as pfnAddItem() and pfnAddMsg(), the pfn meaning Parseable Function. And I have to translate all these functions to interact with the systems on Aeon, or whatever server will use the system.

Also there are the condition statements, which I would have loved if they could be evaluated, but since they're not I had to design the conditions object to load them into a format to be evaluated.

Meaning: resp#.cond#=atype,avalue,aparams,comparator,btype, bvalue,bparams,or

If a condition could be evaluated from a script form using a function it would be alot easier to perform.
But as it is now, each part of the condition array is loaded into the condition object, and when the time comes to get the correct topic response for a player, eval() is called on the condition by the response object and this is calculated.

I am not certain if you need such a system why you do not just use multidimensional arrays and the for (temp.foo: temp.bar) iterator to go through each of your actions, so that you do not have to restrict yourself like you have currently done.

I plan to release my NPC Dialog system for public use when I polish it more as it is complete for the most part. People will have to type the topic responses and conditions in a text file and there is no need to make it more complicated than it already is without a GUI to create the topics, something that I'm not going to waste my time on.

Also I don't really see how I've restricted myself as you have said. The current format makes it exactly clear how many conditions and scripts exist for each response, and I'm trying to make it as user-friendly as possible when typing it.

The potential complexity of topics is rather large which is why I trying to make it understandable with minimal space.
This is a simple topic that changes it text depending on if you've read the topic or not. Though when its implemented into the world, the response will differ from npc to npc based on a condition of the NPC's name that you're talking to.
Any comments on this would be appreciated.

Hmmm the use of eval() for that sounds quite tricky though, it might be better to add support for adding new functions to classes or remove functions. Then it would be easy to find the code that is responsible for something (may be should add support for sub-folders for classes?) instead of having some dynamic code hidden in some script variables.
Also this would work for clientside too since classes are sent to clientside (working much better with the next Graal version), while an eval() function would not work for clientside since the client cannot compile scripts.

*shudders* Um, I'll trust your judgement on the safety of this...

What do you mean?

Classes have always had a clientside part, how would making it more efficient change anything like the safety?

I guess Tyhm means that it could be a security problem when you make it possible for someone to enter script in a text field and then send it to all clients without checking if the script is ok. Making it possible to dynamically add scripts by scripts still requires some basic understand of scripters to prevent "security" problems. We have worked and are working a lot on making the scipt-engine un-abusable though, so that it is not possible to flood the hard drive with data or similar.

Make a function that at least calculates float operations (like you were talking about own()). Variable Functions can already be called so it wouldn't be such a loss if that wasn't included in eval() :)

I'm more concerned that "ZOMG SOMEONE STOLE MY SCRIPT! HAX HAX! STEFAN SHUT DOWN PW123889, THEY STOLED MY SCRIPTS!"

See also: Servers work against each other.

Oh, and the eternal "*download*...huh, so it just checks to see if that string's set...*hax*...okay, now the doors are opening...what's this? It reads a serverstring to see whether I should be sent to jail? *hax* *lolz*"