Cicero Report post Posted June 28, 2007 (edited) Sounds like something you should send upstream. If support for it is as bad as you say, you could save someone else on amd64 a headache Now look what the cat dragged in... good to know you're still alive Cicero Yeah I guess I should make a post on the Pawn forums. After all I *am* part copyright holder of the current distribution I read the programming forum occasionally to see what you guys are up to. Pawn got my attention. I've been programming in Lua at work for a few weeks now Edited June 28, 2007 by Cicero Share this post Link to post Share on other sites
crusadingknight Report post Posted June 28, 2007 Sounds like something you should send upstream. If support for it is as bad as you say, you could save someone else on amd64 a headache Too bad the upstream seems to aggregate patches on the forums quickly enough, but actual releases (even bugfix) seem to have died off. Share this post Link to post Share on other sites
Entropy Report post Posted June 28, 2007 Well, so you did try the JIT There are two kind of JITs for pawn, one is a C one, and one is the ASM one. That's why I suggested trying the non JIt first (the switch way). But anyway, glad that you found it and fixed it. Now, the next step (which is optional, but would be very nice to have) is to have two independent Pawn machines. One machine would be for server stuff, such as the server sending instructions which script to run. The second machine would be for map based scripts. For example, it would be nice to add, in the map format, a section for scripts. The scripts would do stuff such as animate (move, rotate) objects, possibly cause various things to happen when the player is near some location (stuff without any importance, just things like make some leaves move, birds chirp, and so on). Now we might be able to squeeze both of those things in the same machine, but it might be easier and probably safer to have two different machines. P.S. Nice to see that you are still around, Cicero Share this post Link to post Share on other sites
Grum Report post Posted June 29, 2007 Ok, I added a second machine. At the moment they contains the same set of functions (well, actually, they both implement the only Pawn function there is so far), but that can easily be changed if so desired. Share this post Link to post Share on other sites
Entropy Report post Posted June 29, 2007 Great Ok, now one of the machines can be used soon, the other one (the one that needs server scripts) will not be used so soon. So let us focus on the machine that executs map scripts, and see what functions we could use. The first thing that comes to my mind is a function that rotates an object. So something like: rotate_object(object_id,x_rot,x_rot,z_rot) the x/y/z rotations should be in degrees. Then we can have: relative_rotate_object(object_id,x_rot,x_rot,z_rot) where the parameters are an increment (positive or negative) of the current values. The similar for moving an object.. So let's see what we cna come up with. Share this post Link to post Share on other sites
Grum Report post Posted July 1, 2007 Then we can have: relative_rotate_object(object_id,x_rot,x_rot,z_rot) where the parameters are an increment (positive or negative) of the current values. Do we really want those to be increments to the current angles, or do we want to take the objects current orientation, and rotate that over those difference angles? Rotations being the nasty non-commutative operations they are, there is a difference. Share this post Link to post Share on other sites
Entropy Report post Posted July 1, 2007 That's a good question. Having to do with the order of rotations and a lot of trigonometry :/ The problem with the current rotation over the angles difference is that we don't know what is the order of the rotations, which axis should it be rotated it around. So I guess we should just increment the angles. If we want to rotate the object over an axis where there are multiple axis rotations, we can do the math in pawn, and call the function with the proper arguments. Share this post Link to post Share on other sites
ttlanhil Report post Posted July 1, 2007 If I may suggest; why not simply send the new absolute rotation values from the server? If you only use this, then it's the same message sent to all clients; whether they were there to see some previous rotations or not (and hence there's no need to care which of the previous rotations a client has seen; a message missed when you increment it means one client can be out of sync. Not a big problem for rotation, but if other changes are coming, like object movement, it will matter more). Share this post Link to post Share on other sites
Grum Report post Posted July 2, 2007 Weel, the functions we're discussing here are for map events, local to the client, so I suppose it doesn't matter all that much if the clients are exactly in sync with each other. For server based events, you are probably right (but there are also functions for setting absolute orientation and position, so we're good on that too) Anyway, I've added the functions you proposed. There's still some stuff with the bboxes that I need to work out, but the basic functionality works (I've been cutting trees and moving rocks yesterday, much fun). If I find enough free time today I'll try to work out the math of combining two rotations and add an extra set of functions for those. We can add more fun functions of course, but the next two major things that I can see need to be done are: being able to call these functions repeatedly, in some timer based loop specifying how to integrate this with the map format. Specifying a function name is easy enough, but different functions need different numbers and different types of arguments, so we probably can't get away with a fixed size structure there. Share this post Link to post Share on other sites
Entropy Report post Posted July 2, 2007 What I was thinking is to have a timer callback that activates a pawn on timer function. And this function will take care of all the stuff needed. Integrating it with the map format... hmm, actually, we can have a file name like map_name.pwn and then the client tries to load that file with the map. Share this post Link to post Share on other sites
Florian Report post Posted July 6, 2007 from error_log [17:52:11] Unable to determine memory size for Pawn file pawn_scripts/pawn_test.amx Share this post Link to post Share on other sites
Grum Report post Posted July 6, 2007 from error_log [17:52:11] Unable to determine memory size for Pawn file pawn_scripts/pawn_test.amx Did you compile the script in the source tree, and put it in a directory pawn_scripts in your EL folder? (or in ferwer words: does pawn_scripts/pawn_test.amx exist?) Share this post Link to post Share on other sites
Florian Report post Posted July 6, 2007 does pawn_scripts/pawn_test.amx exist? No, it's not in CVS, so it's not in my data-dir. Share this post Link to post Share on other sites
Grum Report post Posted July 8, 2007 Ok, when Pawn is enabled, a map change will now also call the Pawn function change_map() with the name of the map, that can take care of map initialization. I'm not sure if we can dynamically load amx modules while the Pawn machine is already running, if this is possible the approach of having a per-map Pawn file loaded on map change might be cleaner. For now, the change_map() master function will have to do. I've also added the ability to add timer callbacks within Pawn. The current code is restricted to calling functions without arguments, if useful we might be able to change that. The example code makes the tree near beam turn every 2 seconds. Checking the Pawn timer queue is done in the high-res timer, perhaps we should use the misc_timer which is only called twice per second, or introduce a third timer for Pawn only. Share this post Link to post Share on other sites
Florian Report post Posted July 8, 2007 new message in log: [22:10:32] Unable to execute Pawn function: machine not initialized Share this post Link to post Share on other sites
Grum Report post Posted July 9, 2007 Florian, currently the Pawn scripts in the pawn_scripts directory are not compiled by the build system. To get them running, you should download the Pawn compiler from http://www.compuphase.com/pawn/pawn.htm , and create the pawn_test.amx file. One *nix this would go something like cd pawn_scripts pawncc -i. pawn_test.p Then create a folder pawn_scripts in your EL directory, can copy the amx file there so that EL is able to find it(*). Now, if there's enough interest I could perhaps include the compiler in the EL source tree, and build the amx files with the executable. I haven't done this yet, because it means adding extra code (which isn't ours) to the elc code base, and people can easily download the compiler from the original source. (*)Or create a link to the pawn_scripts directory in your source tree, as I did Share this post Link to post Share on other sites
Florian Report post Posted July 9, 2007 pawn does not compile out-of-the-box on OSX, so that'll have to wait until I figure out how to build it correctly. (I hate software w/o configure; make; make install ...) Share this post Link to post Share on other sites
Grum Report post Posted July 13, 2007 Florian, I've put up a small source code package for just the compiler on http://ghnet.nl/~ge/downloads/elpawncc.tar.gz . It includes a Makefile, which you'll have to edit to change the PLATFORM (it's currently set to LINUX). I'm not giving any guarantees that this will compile in one go on your system, but it's self-contained and should be simpler to use than the cmake build on the compuphase website. If you need to make changes to get it to run, please let me know so that I can incorporate them. Share this post Link to post Share on other sites
Florian Report post Posted July 13, 2007 (edited) Makefile: PLATFORM = MACOS FEATURES = X86_64 OSX CFLAGS = -D$(PLATFORM) -Wall -Wdeclaration-after-statement \ $(foreach FEATURE, $(FEATURES), -D$(FEATURE)) #LDFLAGS = -ldl -flat_namespace CC=/usr/local/bin/gcc EXE = elpawncc all: $(EXE) OBJS = getch.o lstring.o memfile.o sc1.o sc2.o sc3.o sc4.o sc5.o sc6.o \ sc7.o scexpand.o sci18n.o sclist.o scmemfil.o scstate.o scvars.o ifeq ($(PLATFORM),LINUX) OBJS += binreloc.o endif .depend $(OBJS): Makefile elpawncc: $(OBJS) $(CC) -o $@ $^ $(LDFLAGS) $(OBJS) : %.o : %.c $(CC) $(CFLAGS) -c -o $@ $< .depend: *.h *.scp $(CC) $(CFLAGS) -MM $(patsubst %.o, %.c, $(OBJS)) > $@ clean: \rm -f *.o $(EXE) .depend -include .depend lstring.c: #if !defined HAVE_SAFESTR #if !defined OSX <-- add this and a #endif at the end lstring.h: /* prototypes for strlcpy() and strlcat() */ #include <stddef.h> #if defined __WATCOMC__ && __WATCOMC__ >= 1240 /* OpenWatcom introduced BSD "safe string functions" with version 1.4 */ #define HAVE_SAFESTR #endif #if !defined HAVE_SAFESTR #if !defined OSX size_t strlcpy(char *dst, const char *src, size_t siz); size_t strlcat(char *dst, const char *src, size_t siz); #endif #endif #ifdef OSX #define stricmp(a,b) strcasecmp(a,b) #endif Dirty hacks, but hey ../elpawncc/elpawncc -i. pawn_test.p Pawn compiler 3.2.3664 Copyright © 1997-2006, ITB CompuPhase maps.p(1) : warning 235: public function lacks forward declaration (symbol "turn_tree") maps.p(33) : warning 235: public function lacks forward declaration (symbol "change_map") pawn_test.p(3) : warning 235: public function lacks forward declaration (symbol "pawn_test") pawn_test.p(12) : warning 235: public function lacks forward declaration (symbol "play_with_object_pos") 4 Warnings. ls -l -rw-r--r-- 1 lindner wheel 1036 Jul 13 17:39 pawn_test.amx Warnings when compiling pawncc: sc1.c: In function 'setopt': sc1.c:1262: warning: implicit declaration of function 'access' sc1.c: In function 'setconstants': sc1.c:1460: warning: left shift count >= width of type sc1.c: In function 'make_report': sc1.c:4159: warning: format '%ld' expects type 'long int', but argument 4 has type 'cell' sc1.c:4169: warning: format '%ld' expects type 'long int', but argument 4 has type 'cell' sc1.c:4205: warning: format '%ld' expects type 'long int', but argument 4 has type 'cell' sc3.c: In function 'hier14': sc3.c:823: warning: left shift count >= width of type /EDIT: bad news: el just exits without comments after parsing the actor XML files when I remove pawn_test.amx el start normally again Edited July 13, 2007 by Florian Share this post Link to post Share on other sites
Grum Report post Posted July 13, 2007 lstring.c: #if !defined HAVE_SAFESTR #if !defined OSX <-- add this and a #endif at the end lstring.h: #if !defined HAVE_SAFESTR #if !defined OSX .... #endif #endif I have instead changed the test in lstring.h to #if (defined __WATCOMC__ && __WATCOMC__ >= 1240) || defined OSX #ifdef OSX #define stricmp(a,b) strcasecmp(a,b) #endif Dirty hacks, but hey *shrug* if it works... ../elpawncc/elpawncc -i. pawn_test.p Pawn compiler 3.2.3664 Copyright © 1997-2006, ITB CompuPhase maps.p(1) : warning 235: public function lacks forward declaration (symbol "turn_tree") maps.p(33) : warning 235: public function lacks forward declaration (symbol "change_map") pawn_test.p(3) : warning 235: public function lacks forward declaration (symbol "pawn_test") pawn_test.p(12) : warning 235: public function lacks forward declaration (symbol "play_with_object_pos") 4 Warnings. Yeah, that's normal, I still have to figure out where and how to put those forward declarations. Should work just the same, though. Warnings when compiling pawncc: sc1.c: In function 'setopt': sc1.c:1262: warning: implicit declaration of function 'access' sc1.c: In function 'setconstants': sc1.c:1460: warning: left shift count >= width of type sc1.c: In function 'make_report': sc1.c:4159: warning: format '%ld' expects type 'long int', but argument 4 has type 'cell' sc1.c:4169: warning: format '%ld' expects type 'long int', but argument 4 has type 'cell' sc1.c:4205: warning: format '%ld' expects type 'long int', but argument 4 has type 'cell' sc3.c: In function 'hier14': sc3.c:823: warning: left shift count >= width of type /EDIT: bad news: el just exits without comments after parsing the actor XML files when I remove pawn_test.amx el start normally again Are you sure you have 64 bit machine? The warnings seem to indicate otherwise. You must've compiled EL itself with -DX86_64 too, though, otherwise Pawn would notice that the amx file has a different cell size (it inserts different magic bytes for 32 and 64 bit AMX code). If removing -DX86_64 from both EL and the compiler doesn't work, can you run EL from a debugger and generate a backtrace to see where it fails? Share this post Link to post Share on other sites
Florian Report post Posted July 13, 2007 (edited) Core2Duo CPU, OSX 10.4, gcc 4.2, so it's 64bit. no X86_64 for el and pawncc works (at least nothing in error_log) should the pawn_test.amx do something? /EDIT: yes it should, but does not ... Edited July 13, 2007 by Florian Share this post Link to post Share on other sites
Grum Report post Posted July 17, 2007 Core2Duo CPU, OSX 10.4, gcc 4.2, so it's 64bit. no X86_64 for el and pawncc works (at least nothing in error_log) Dunno what;s going on there, maybe your OSX build is 32 bit (don't laugh, I have no idea, didn't google before posting), or your gcc is set to build 32 bit executables by default. If so, you could try adding -m64 to your CFLAGS and CXXFLAGS when trying to build a 64bit executable. Not sure if OSX has the 'file' command, but on linux this gives some useful information about file types. Using it on my EL client shows something like grum@host:~/tmp/elc$ file ./el.x86.linux.bin ./el.x86.linux.bin: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.0, dynamically linked (uses shared libs), not stripped so you could try that to figure out just what exactly you've generated. should the pawn_test.amx do something? /EDIT: yes it should, but does not ... Yes, the tree near the campfire on IP should be turning around its z axis. Also when you press F8 while the mouse pointer is on a 3D object, it should rotate the object, if you're not on a 3D object it should spam your screen and play a sound. If all of this doesn't happen, *and* there's nothing in your error.log after trying, we should do some debugging. Share this post Link to post Share on other sites
Florian Report post Posted July 17, 2007 (edited) Oh well, I completely misinterpreted what the script would do. F8 is fun IP rotating tree works, but is very staccato. OSX and 64bit: http://www.apple.com/macosx/features/64bit/ With gcc -m64 my OpenGL seems to make some trouble, I'll play around with -DX86_64 and -m64. Edited July 17, 2007 by Florian Share this post Link to post Share on other sites
Florian Report post Posted July 29, 2007 (edited) Idea: can pawn scripts enable/disable EC effects? Background: starting fountains look absolutely great So I thought it would be nice if fountains could be stopped and started via pawn script. Waterplays hooray /EDIT: bug report: a rabbit just ran straight through the rotating tree on IP ... Edited July 29, 2007 by Florian Share this post Link to post Share on other sites
Entropy Report post Posted July 29, 2007 Yes, particle systems should be manipulated through the script as well. And why do you think the rabbit going through that tree is a bug? Share this post Link to post Share on other sites