Jump to content
Eternal Lands Official Forums
Grum

Pawn scripts

Recommended Posts

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 :P

 

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 :P

Edited by Cicero

Share this post


Link to post
Share on other sites

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 :P

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

Well, so you did try the JIT :icon13:

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 :pinch:

Share this post


Link to post
Share on other sites

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

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

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

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

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

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

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

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

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, 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

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

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

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 :D

 

../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 by Florian

Share this post


Link to post
Share on other sites

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 :P

*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

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) :P

 

should the pawn_test.amx do something?

/EDIT: yes it should, but does not ...

Edited by Florian

Share this post


Link to post
Share on other sites

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) :hug:

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

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 :P

 

/EDIT:

bug report:

a rabbit just ran straight through the rotating tree on IP ...

Edited by Florian

Share this post


Link to post
Share on other sites

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

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×