Forum archive
EVALLIB query - code
- Ken, have you made any new modifications to your EVALLIB code?
In your wish list you mention that you want to implement more data types. The main one i'm interested in is LONG, why? well...
What i'm slowly working to is implementing most of VOXAPs cool features using your EVALLIB code. For example :
-colour functions for new exposed voxels
-insert/remove shapes (mostly for the editor)
-general scripting, AI, menu layout etc
Naturally most of VOXAP uses LONGs so this would be faster then casting from a double each time. Also the EVALLIB could do all the shifting itself. Fancy eh? ;)
I'm also gonna see how far I can push the language. In the process of writing my own "include" method... As well as some other more whacky ideas - I've fixed a few minor things in EVALDRAW .. nothing yet worth releasing. I haven't touched EVALLIB since my last release.
Those are impressive plans! I'm flattered that you've chosen EVAL_LIB over other scripting languages, such as TinyC or one of the LUA variants.
Yeah, I know. Integer support would certainly make EVAL more powerful. The reason I don't do it is because implementation would be a hell of a lot of work. I would have to write machine language primitives for all of the integer operations, not to mention adding automatic translation (double <-> long) to the parser. I haven't thought much about it before - I just know it'll be a ton of work. FYI, here's a list of ideas that I might actually have a chance of implementing over the next year:
EVAL lib:
* support subroutines; this would require {} around the function body
* implement switch statement syntax
EVALDRAW:
* call another KC file. Example: z = "gcd.kc"(x,y);
* add mouse control to menus
* use safety threads for all modes to protect from infinite loops (currently this only works in () mode)
* implement MoonEdit-style collaborative editing : )
* write 6dof height-mapped engine for (x,y[,t],&r,&g,&b); height is return value.
Subroutines would be a lot easier to implement than integers, and it would open up a whole new world to the language. So I'd rather work on that first. The integer stuff can all be emulated (albeit very slowly in some cases).
(P.S. Don't forget the 'L' in VOXLAP : ) - Fair point. Adding that support is gonna be hell!!! I haven't heard of TinyC or LUA stuff before... will have to investigate... The main reason I wanted to use EVAL lib was that I felt the community here would get a kick out of it and add there support (scripts!).
Subroutines and external files I like your idea for calling another KC file. Could do some really cool stuff like having muliple routines within a file like
z = "math.kc".sqr(n);
Couldn't think of a cool example there! HA!
In VOXLAP I think doing AI with EVAL lib would be a bit of a nightmare! However I think setting up and controlling menus as well as that editor stuff is still good... Well see. Haven't touched VOXLAP for a little while. You know how it is. UNI. Final projects. Coursework. - Well well well.... Where to begin?
Semester ended a couple of days ago, so now i'm free to try out my ideas over Christmas break (apart from this week, cos I'm spending it back home with mum and dad)! Any way...
What have I achieved so far?
Implemented a "Map Script", loading the "eval" script a FULL VXL can be generated with functions to insert/remove *ALL* the standard geometric shapes included in the VOXAP source!!! Of course with the other built in "eval" C style functions doing some funky stuff is well easy! For example my test level is a grassy field filled with about 400 trees! All randomly generated!!! YEAH BABY!!! The amazing thing is, it took about two hours to implement the whole system!
This is all great, but leads me to something I wonder if you are aware of... EVAL can be a bit flacky. Sometimes (for no apparent reason) a script file wont compile. It appears to be fine. The solution? Add/Remove commnets, line spaces... once it compiles it is fine and will ALWAYS compile, with that in mind its a problem most of us can live with.
My main concern is with one of the functions I link to the script... I'm using a linked list system to collect together all the functions and variables I want to have access to (this is the start of me having my own "#include" preprocessor...). This works perfectly, excpet for one instance. My cyclinder function, which is in the format "cylinder(x1,y1,z1,x2,y2,z3,rad);" causes problems...
The function is setup using evalextyp nam value as "cylinder(,,,,,,)" as standard. However when I pop the cyclinder function into a script it wont compile!? To get it to work I have to add a dummy value on the end of my script, for example
"cylinder(x,y,z,x1,y1,z1,r,0)"
This then works fine! Also if I add an additional comma to the evalextyp.nam it is still fine...
Tad confused about this as all other functions (About fifteen at the moment!!!) work fine.
One last thing, I can't access "kasm87err[256];". MSC++ Just wont let me! I'm sure if I could check this and tell you what it says the solution might present itself.
On the whole progress is going MUCH BETTER then I would have expected! I think that in a week or so (after getting back home!) I should have a pretty cool system for custructing VXL maps & SXL scripts! - That sounds like neat stuff, Maximus!
I have no idea why you can't access kasm87err. My best guess is forgetting to put extern "C", but I'm guessing you already tried that. It's defined like this in EVAL.C:
char kasm87err[256] = "";
Your function problems may be related to a bug with an optimization of pointer variables that are passed to the function. I fixed that recently. I'll try to get out a new release of EVALLIB soon... but first I want to finish preparing the release of some other demos : ) - EXCELLENT!!! New versions is always a joy ;)
Actually I will put my hands up and admit I didn't try extern C... :oops: WHOOPS! This will be quite a nice help!
One thing I didn't ask, but is on my mind...
With "evalextyp " is it possible to pass functions that take pointers? This would be handy... my thinking is, once, I have "#include" working a user could include ANY .kc script that is compatible with "evaldraw" (Well the ones for creating voxels). This means I will have to have the ability to pass values by reference for "x,y,z, &r,&g,&b".
I can't wait to be able to use your "rope.kc" to build funky columns that are built with a sin value applied to its horizontal scale. Of course all this can be easily controlled by other EVAL commands... create 3 for loops, 1 for each dimension. Loop through the coordinates of the "rope.kc" and plot! Oh the limitless possibilities!!! :D Sometimes (for no apparent reason) a script file wont compile. It appears to be fine. The solution? Add/Remove commnets, line spaces...
I don't know why this would happen. Is it possible for you to send me an example script that causes this? If you need to send me some code with your evalextyp definitions, I'll be happy to look at it.With "evalextyp " is it possible to pass functions that take pointers?
No, not yet. This one's high on my list though since I've been wanting a pic(x,y,&r,&g,&b) function for a while. Having to extract the RGB components from the return value is slow and painful!- OK, will send you a script in a week or so... after getting back to my own PC. Also, if I still have trouble with that darn "cylinder" func I'll send you the code! Its sooo tiny!
One last thing...
MERRY CHRISTMAS!!!