Pawn scripts

[Grum]

[ Starting a new thread for this topic, since it has nothing to do with the map editor ]

Well, there is something non OpenGL related that is sort of your 'old department'. Since last year, me and Learner (but mostly Learner) were working at implementing a server side/client side Small (now Pawn) scripting relationship, where the client will execute some predefined scripts sent by the server.

The idea is to have dynamic maps this way, basically the server will send a "execute script A at location X, Y with the following parameters: a,b,c,etc"

 

Now Learner is quite busy with his work, and he has a lot to do on the server side anyway, so if you can take the client side, that would be great. if you are interested, let me know, I'll give you more details.

Just getting the Pawn to run is a bit of a challenge, but I've managed to do that. I know we still have to discuss all of this, but since I already ran into some interesting 64bit issues, I thought I'd ask this now: in what form is the server going to send the scripts? Just script names, with the scripts defined locally on the client? Source code? Or amx code? In the latter case we're going to run into a hell of cell size and byte order problems.

 

EDIT: strike byte order pblms, looks like Pawn is little endian throughout.

Edited June 25, 2007 by Grum

[0ctane]

Fun. Now I have to figure out how to build Pawn for OS X. For those interested, here is a link to Pawn information.

 

EDIT: crusadingknight: Fixed a typo in your link.

Edited June 25, 2007 by crusadingknight

[Grum]

It may not be that bad, it's mostly a matter of selecting the correct #ifdef's. Anyway, I'm in the process of creating a Makefile and a small header file that maps EL config options to Small interpreter ifdefs. So no need for panick... yet.

 

BTW: your link's broken, looks like something went wrong pasting it. For the impatient among use, http://www.compuphase.com/pawn/pawn.htm is the correct link.

[crusadingknight]

I used to like Pawn, but after glancing at the internals of the core for the first time, I realized that I never want to have anything to do with it. There is way too much trusting to dirty hacks for my taste in there.

By the way, last time I checked there were still a few bugs in 3664, though the fixes are up on the forums.

 

EDIT: Sorry Grum, I think I beat you to it.

Edited June 25, 2007 by crusadingknight

[Florian]

Why Pawn/SMALL?

 

For example Lua is extremely extensible, easy to learn, it can do OOP and AOP, and it was developed to be integrated into C programs.

[Placid]

Why Pawn/SMALL?

 

For example Lua is extremely extensible, easy to learn, it can do OOP and AOP, and it was developed to be integrated into C programs.

Don't start that argument. You could say the same for Python and loads of other scripting languages. The server uses PAWN for its scripting too, so it makes sense to keep it the same.

[trollson]

Why Pawn/SMALL?

Indeed. It seems a very odd choice, given the range of scripting/portable code choices available -- as you say, Lua, Ruby, Python, or embed Java, with tools such as Swig to take away the pain of writing interface code. The state-machine modelling in Pawn was interesting, but that is something any OO language does quite happly.

 

I tried to build Pawn on Solaris/SPARC (32bit) about a year ago, to no avail (it all build, produced bytecode, which just crashed). I never got any support from the provider, and having spent some time poking around with it, I think I'd steer well clear. Given its age, it hasn't accumulated much of a user base, suggesting it doesn't compare well to the alternatives.

 

Personally, I'd use Java; invoke a Java VM from the code, define a class API to represent all the types of operation that the extensions will need to do (being derived from the core API). Most platforms have a JVM available now.

[crusadingknight]

Personally, I'd use Java; invoke a Java VM from the code, define a class API to represent all the types of operation that the extensions will need to do (being derived from the core API). Most platforms have a JVM available now.

Overkill, perhaps? The main advantage of languages like Lua/Pawn is their minimalism, and (usually) portability, which has very little increase in required libraries: For example, the Pawn VM itself is only one source file. In any case, radu is very fond of Pawn; Given that it's already deployed on the server, I sincerely doubt that it is open for debate anyway.

 

In any case, probably best to build using AMX_ANSIONLY to minimize the ugly hacks which may or may not cause portability problems.

EDIT: Scratch that, AMX_ANSIONLY is broken now and assumes that ANSI is actually ... not ANSI.

Edited June 25, 2007 by crusadingknight

[trollson]

Overkill, perhaps?

Depends what you want from the system. The hard part isn't invoking a JVM from C, but the design of a class library/framework to represent whatever is required (OOP is 90% design, 10% coding, usually done the other way around...). It does rely on a separate JRE installation, but thats pretty much a given now.

But no, I wasn't recommending it as an approach for EL; its just an example of else has been done (similar if larger system, infrequently a game).

Pawn:

• Is the intention to integrate Pawn into the CVS download/build, or will it be a separate dependancy?
  
• Last time I looked, the i386 JIT was assembler (NASM?). How does that affect people building with MSVC (MASM) or GCC (ATT) (I forget which). Does it disenfranchise non-IA32 users?
  
• How cross-platform is Pawn? What level of support is there? Does this limit the range of architectures ELC will be available on?
  
• What dependancy will there be on having Pawn integrated with the client? Will it be a requirement in order to play, or eye candy.
  

What sort of things will be run by scripts on the client side?

[Entropy]

Look, this thread is so that we talk about the implementation of a feature, not to talk about how much Pawn Sux0rz and Lua r0x0rz.

I like Pawn, and we are going to use pawn, and that's it. When you are going to make your own MMO, feel free to use whatever scripting language you want. If you still want to argue about the superiority of other scripting languages, make a new thread, but know that things will not change.

 

 

And now on topic.

The server will send an ID of the script. The idea is that the scripts will be sent similar to how the bags are sent now.

 

The name of the script will be in some file (xml or txt). The parameters will be x,y, and some other stuff we will talk about later on (we still need to decide how to do it).

[Florian]

May I suggest to also send an MD5 sum or something similar with the script? Otherwise everybody can change client-side scripts.

[Grum]

The server will send an ID of the script. The idea is that the scripts will be sent similar to how the bags are sent now.

 

The name of the script will be in some file (xml or txt). The parameters will be x,y, and some other stuff we will talk about later on (we still need to decide how to do it).

Ok, so the scripts themselves are entirely client side.

 

Not to be a PITA, but what's the advantage of having a scipting language over just implementing the desired functions in the client then? I suppose one advantage could be that scripts can be updated outside the regular client updates.

Is the intention to integrate Pawn into the CVS download/build, or will it be a separate dependancy?

Integrate.

Last time I looked, the i386 JIT was assembler (NASM?). How does that affect people building with MSVC (MASM) or GCC (ATT) (I forget which). Does it disenfranchise non-IA32 users?

The JIT is not necessary, but can be used to speed up running the AMX bytecode. Since these scripts aren't supposed to be CPU intensive, it probably shouldn't matter too much. There is already a MASM (or TASM, I frogot) version of the JIT, which I translated into NASM. But there's no way I'm going to translate it into gas again (though I do believe gas can also handle Intel syntax as well nowadays).

How cross-platform is Pawn? What level of support is there? Does this limit the range of architectures ELC will be available on?

Reasonably cross-platform, support is nearly non-existant though.

[crusadingknight]

May I suggest to also send an MD5 sum or something similar with the script? Otherwise everybody can change client-side scripts.

I'm not sure that would matter, as AUTO_UPDATE generally catches things with changed MD5s anyway, and messing up the scripts controlling pretty effects certainly wouldn't have much more of an effect than messing up the textures or meshes.

Edited June 25, 2007 by crusadingknight

[Entropy]

I don't care if people change the client side server scripts, it will be mainly to their dissadvantage to do so.

 

Anyway, the reason I want a script, and not just have the client side functions are:

1. Can be modified through auto update.

2. Changes can be made to a script that will affect both the client and server at once, no need to modify both the client and the server.

3. Once Pawn is integrated with the client, it can be used for other stuff as well, such as creating dynamic menus, etc., easier than it would be done by using C (and safer too)

 

Most of the stuff the server will send will be stuff like: Add a module, destroy a module, change module type from x to y.

A module will be basically a script that says: "place this object here and that obejct there". However, some scripts will be more complex than than, such as placing a road between two modules. That road needs to be placed dynamically, depending on the position and rotation of the modules it connects.

[Florian]

In file included from pawn/amx.c:57:

pawn/amx.h:64: error: conflicting types for 'uint32_t'

/usr/include/stdint.h:44: error: previous declaration of 'uint32_t' was here

[Grum]

In file included from pawn/amx.c:57:

pawn/amx.h:64: error: conflicting types for 'uint32_t'

/usr/include/stdint.h:44: error: previous declaration of 'uint32_t' was here

Should be fixed, but endianness issues may still exist.

[Florian]

fixed

 

/edit:

this shows up in the error log

 

[22:04:31] Unable to determine memory size for Pawn file pawn_scripts/pawn_test.amx

Edited June 27, 2007 by Florian

[Grum]

fixed

 

/edit:

this shows up in the error log

 

[22:04:31] Unable to determine memory size for Pawn file pawn_scripts/pawn_test.amx

I'm not surprised, please keep the comment in make.defaults in mind.

 

Now, if you actually want to try the script, you'll have to compile it using the pawns compiler, and copy it to a directory pawn_scripts in your EL installation folder. Bear in mind that on my machine it crashes the game if I call the script a second time.

 

I do have a source tree of the compiler with a Makefile that compiles cleanly. If there's enough interest for it, I can put it up for download.

[crusadingknight]

Bear in mind that on my machine it crashes the game if I call the script a second time.

That's odd, it would embed cleanly (without crashes) last year.

Edited June 27, 2007 by crusadingknight

[Grum]

Maybe I did something wrong, dunno. Took a quick look only so far, but it seems the AMX stack pointer isn't reset after the function exits.

 

EDIT: scratch that.

Edited June 27, 2007 by Grum

[Entropy]

BTW, are you trying the JIT? If so, let's not use it for now, until the code works.

[Grum]

BTW, are you trying the JIT? If so, let's not use it for now, until the code works.

No, I'm not using the JIT.

 

I have found where the problem lies. The first time AMX executes a function call, it will look up the function in its function table, and will then try to rewrite the program so that on the next call it can jump to the function directly. Somehow it manages to mess this up on my machine, maybe because it's 64bit based.

 

Investigating further...

[Grum]

Bug found and fixed.

 

For those that are interested:

The Pawn abstract machine can execute instructions in two different ways: indirectly via a gigantic switch statement over the opode, or for certain compilers by directly writing memory addresses for executable code in the AMX code. Gcc happens to be one of those compilers, and on 32 bit systems the code generation, execution, and function address rewriting was happily done with absolute addresses. However on amd64, an incorrect #ifdef led the rewriting code to insert AMX opcodes instead of the corresponding memory address into the AMX code, which resulted in a segfault when the script was executed for the second time and tried to jump to the rewritten address.

[Cicero]

Bug found and fixed.

 

For those that are interested:

The Pawn abstract machine can execute instructions in two different ways: indirectly via a gigantic switch statement over the opode, or for certain compilers by directly writing memory addresses for executable code in the AMX code. Gcc happens to be one of those compilers, and on 32 bit systems the code generation, execution, and function address rewriting was happily done with absolute addresses. However on amd64, an incorrect #ifdef led the rewriting code to insert AMX opcodes instead of the corresponding memory address into the AMX code, which resulted in a segfault when the script was executed for the second time and tried to jump to the rewritten address.

 

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

[Grum]

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