why no scripting language yet?????

[FQuist]

Why??

Anyways, a quick rant here I didn't spend much time on. I (and probably many others) have had this idea for a long time: a scripting language would rock for JJ2. The idea seems rather farfetched, but I think with not THAT much effort at least something simple could be created.

(Edit:

What is a scripting language for JJ2?

Scripting programming languages (commonly called scripting languages or script languages) are computer programming languages designed for "scripting" the operation of a computer. Early script languages were often called batch languages or job control languages

A scripting language for a program can "steer" the program and it's functions. It would be a way to use programming to manipulate Jazz Jackrabbit and specifically playing situations in the game. Like you can use MIRC script to create bots, or make it easier to change a topic, a scripting language for JJ2 would mean you could change the amount of health/ammo a player has dynamically and similar things.)

(Edit: Here's a technical part, probably not interesting for people who don't have some experience with JJ2 utilities)

Since MP is the most used type of game in Jazz2, it's only reasonable that somehow when someone makes a program that has scripting abilities, that it supports multiplayer. There are (at the least) three challenges when taking this on. The problem you run into first is that of client-side and server-side variables. With variables that are set at the server side (I have no idea which ones these are, but I think health is an example) it's easy: a scripting client would just modify the serverside variable and it would change for all clients too. When you have client-side variables (like, I presume, player position), it becomes impossible to work with only one scripting program per server (at the host's computer). So that's probably the problem you run into most.. everyone would have to have the scripting program running for anything to work. That's a challenge, to make it so everyone is required to have one/or wants to have one.

A second challenge is how to command clients to give info on their variables, how to communicate this info between the scripting clients of various people and how to change things for everyone. It should be possible to somehow arrange this by changing certain variables that are sent to other clients, and the scripting programs at the client's computer would somehow understand this and reply (by doing something, or sending data back). What about sending something like a shot being fired at some unused location?

The third challenge is designing the scripting language and figuring out the methods to do everything.. even a very simple scripting language that can only check for a player's location and health and can only tweak triggers, health and location would already open up huge possibilities. And it probably would only take a good coder with good jj2 memory knowledge a short while to make. (you could just have a simple IF LOC=x,y TRIGGERID1=on statement structure thingie and it would already rock)

(Edit: Here comes the non-technical part! I added some more ideas to it, too[/b])

Some positive things having a scripting utility would possibly allow that I can think of at the top of my head:

<b>MP</b>

- Working team battle (without needing complex triggers)
- Adjusting people's score after events
- Lots of (new/improved) gametypes should be possible with this (Handicap CTF =))
- Making hurt events work in MP
- Giving gems/food/coins/other pickups more functions

<b>SP</b>

- Having levels with different next level possibilities (you choose to either go to planet 1, or planet 2, for example)
- Creating interactive stories (non-linear levels/storylines)
- Creating new hurt types

<b>MP/SP</b>
- Instant-killing people (iow: taking all their health at a time)
- Advanced time limit type levels (10 minutes to escape from the base!)
- Having a different 'default' health amount (5 hearts in CTF, or 2)
- Complex animations
- Trigger toggles/more advanced triggers (or more than the current limit, possibly)
- Changing layer properties on the fly
- Changing the level on the fly
- Multiple events on one tile
- Working fast feet
- Lots of stuff that may be possible, and may not be.

there's more.. but I am not really lucid right now. This rant doesn't seem that much understandable at all anyways.

Anyone have some input? I think this would be a good idea to talk about. We're not getting 1.25 anytime soon and this may be something to do until we get it.

edit I forgot there's also possibly the problem that when a memory value is changed serverside (for health for instance) you possibly have to get jj2 to realise that it changed so that it actually sends it to all clients.

[blurredd]

I'm hoping "Instant-killing people" refers to instant death by falling into pits, because that would own in MP. If only some programmers were up to the challenge. It's a bit annoying knowing that all of these things are possible—and without a 1.25 patch—but no one is willing to make them.

[Monolith]

This is a good idea. I've thought about it too, but I need to get used to programming the basics for JJ2 first. (And making interfaces ;|)

[LittleFreak]

To be honest, I have no idea what a scripting language is, but it sounds good so far.

I'm no coder of any sort, so I couldn't help though.

Should anybody be willing to make such a programm though, please keep in mind that some things which are helpful for MP games will ruin SP and backwards.

[ThunderPX]

Death pits = awesome. Play Metroid Prime Hunters to see what I mean ;p

[Olsen]

Really cool ideas. And as BlurredD said, the good thing yet still irritating is that it's possible but no one did it yet.

[R3ptile]

- Working team battle
There's already a working team battle.

Instant-kill wouldn't be useful in CTF maps unless you have a flag.

[cooba]

Instant-kill wouldn't be useful in CTF maps unless you have a flag.So what?

[R3ptile]

So what?
Oh and by the way, it wouldn't be useful in battle levels, too.

[LittleFreak]

There are more multiplayer modes than CTF. ;D

And in some it could be useful indeed.

[White Rabbit]

What exactly is stored in JJ2's 'memory' apart from ppl's positions, hearts, ammo?

[blurredd]

What isn't stored in JJ2's memory? I can't answer either question completely, but I could imagine most of the things that need to be modified by a program are already there in memory.

To R3ptile: Seeing how pits work in other multiplayer games, I don't see a problem with it in JJ2. You lose a roast when you fall into a pit (not to mention all your ammo and powerups), which means extra danger and more skill needed to pass through routes near the bottom of a level. It could make levels more interesting if done well.

As for Team Battle, besides the fact the scoring works in reverse, it doesn't work 100% of the time and levels have to be made to support TB. A Team Battle prog would mean anyone could easily make a TB level. Start positions might still be an issue though if a level uses mostly MP start positions--I know I'm guilty of doing this with my own levels--but hopefully this can be worked around.

[White Rabbit]

Heck, we could even put a warp in a lvl, with no warp target, and call it a trap. ;P

[R3ptile]

BlurredD: You should look at FireSworD's B1 team battle edition, he made a new, better system.

[FQuist]

What about being constructive and actually suggesting things, R3ptile, instead of just shooting down stuff?

[DoubleGJ]

This sounds like possible to do for one who already made a Jazz2 utility. Anyone of the J2HG still here?

[FQuist]

This is a good idea. I've thought about it too, but I need to get used to programming the basics for JJ2 first. (And making interfaces ;|)
Maybe you (and people in general) can work together. The J2HG crew has quite some experience with some aspects of manipulating JJ2. And some of them (like Link) know C++. The biggest problem is that most people use different programming languages here.. and in J2HG. I for example would make this stuff with others but I only know Delphi (excluding internet scripting languages).

This thing would never get off the ground without multiple people working on it, probably. Too much testing and designing work. Designing a sustainable scripting language that will be logical even after features get added isn't THAT easy.

[blurredd]

BlurredD: You should look at FireSworD's B1 team battle edition, he made a new, better system.I'm intrigued. What's different about it?

[R3ptile]

I'm intrigued. What's different about it?
Well, it scores for the right team. :rolleyes:

[blurredd]

Well, I wouldn't have assumed that was possible without an overcomplicated system because of the predicament where, for example, a blue player who passes through two red bases will score for red team but keep the second flag as well. Also, reversed scoring wasn't the main part of my argument albeit an important factor.

[White Rabbit]

Hey, if so much is in JJ2's memory, we should DEFINITELY expand the memory of JJ2 for SP. I mean, in multiplayer, everything's loaded. All the ammo, all the crates, triggers, springs, etc, but in SP, JJ2's memory seems to reach only a limited amount of tiles away from the player, like a box (afaik, it's around 20x20 tiles large). If we expand that 'memory box', you can do a lot of cool stuff in SP like timers (a la Bank Robbery), trigger effects (like those in GF lvls) and so much more. It would also prevent some bugs from being exploited because a regenerating event outside the 'memory box' will instantly appear again, when the player comes close. I multiplayer, this isn't the case. Would something like this be possible?

EDIT: Oh, and maybe you can edit JJ2's memory so that you can change pre-existing events, put in the lvl with JCS, into other events? For example, if JJ2 thinks there is a 3x seeker pick-up at pos 56, 70, then you could edit its memory and make it think that there is a 15x seeker-crate at pos 56, 64.

[Neobeo]

Sounds interesting. I would be more than glad to help. Btw, what happened to the J2HG?
(For those who don't remember me :p , I used to be in J2HG, with experience in x86 ASM and C++ (and visual basic, but not delphi)).

[Nitro]

I don't know how to program but I know this, to do death pits you got to define their position on the map on the level, like (23,70) or whatever, or certain Y hights. Anyway after that you make some program that whenever a player goes to that place (i.e coords) then his hearts value get set to zero.(/nerd) hehe [:

[R3ptile]

Well, I wouldn't have assumed that was possible without an overcomplicated system because of the predicament where, for example, a blue player who passes through two red bases will score for red team but keep the second flag as well. Also, reversed scoring wasn't the main part of my argument albeit an important factor.
The system doesn't seem to be complicated at all. Contact me if you want me to host it.

[n0]

Hrm... I see what you meant, Quist.

I think I could make a program that, for single player, turns area ID events into instant death events. Or, depending on the ID value, the events would be diffrent things. Like Area ID=0 is instant death, Area ID=1 is activate mini boss (been working on a way to do this), Area ID=2 is single player "No Fire Zone," ect.

I think I will work on this once I am done with school (One Week!)

Not really a scripting languge, but a start anyways.

[blurredd]

Hmm... Never thought of using the glitch where a player can score without actually passing through the base outside of classic CTF. This changes my stance on a Team Battle utility, but it still would be cool if TB could work without any level modifications.

[cooba]

Area ID=0 is instant deathUse ID=1 for that =|

[VashTheStampede]

you could try coding it in more than one scripting language, and have the different languages take on different functions

i.e. C++ for TB

or dephi for your smaller things like pits and instakill

it could work if you used the game engine just the right way.

[Link]

A second challenge is how to command clients to give info on their variables, how to communicate this info between the scripting clients of various people and how to change things for everyone. It should be possible to somehow arrange this by changing certain variables that are sent to other clients, and the scripting programs at the client's computer would somehow understand this and reply (by doing something, or sending data back). What about sending something like a shot being fired at some unused location?

The easiest way to do this would be to have parallel network communication. Using JJ2's networking (like a shot being fired) would be difficult and limited. The scripting program could run in client or server mode alongside JJ2, and send data separately.

Many of your suggestions can be done already with simple server-side programs (Project Controller for example), but I think they could be done more elegantly with extra server-client communication.

[FQuist]

Maybe that is the best solution, Link. You know more about network programming than me. A disadvantage of communicating outside of JJ2 is that people have another connection and port to worry about. A major disadvantage of using JJ2 for communications is that JJ2 has sloppy netcode and data might be lost more quickly that way, especially in laggy servers. I don't think using JJ2 would make things very limited, I'm sure using memory manipulation pretty much everything can be done if you design some protocol. If you really want it simple you could even work using bits by just turning something somewhere off and on.

I'm not sure that there are already programs that can do a lot what I suggested. Using PC4 you can skip games, and change some server settings and the level, but it's not influenced by any actions so it's pretty much useless and can't do what's the point of a scripting language - replying to actions, which would make new gametypes and more interactive single player experience possible.

Let's do some more thinking.. how should the scripting language work? It will need to be able to test for certain conditions like player position or health, or joining/leaving players. There would need to be a continuous loop somewhere checking for conditions to occur. You can either have the people themselves create this (a script someone would make that would check for certain conditions would have some sort of loop, like most GUI programs have for example, something like main() I think, not sure), or do it for people, and have something in the order of functions in the script that are called each time a movement changes, or some way of setting up "listeners" (a bit like setting up mIRC script timers, syntaxwise). What would be the best? I have no experience with any, although I could probably devise some syntax that work could with whatever thing is best.

[Monolith]

In terms of the networking, it would be much easier for the scripting program to use it's own connection and port than trying to ride on top of JJ2's connection. You could probably use something like port 10053 since I think a lot of people open that port even though it's not used for client-to-client communication.

And for the scripting language itself, it would be easiest to use a pre-existing language such as Lua or Python, and create an interface for that.

[White Rabbit]

From what I've gathered, a singleplayer script would be much more easier to do than a multiplayer script?

[Monolith]

From what I've gathered, a singleplayer script would be much more easier to do than a multiplayer script?
Yes. Because you wouldn't have to worry about multiple clients running the right script and being synced up and all.

[Baggers]

Just jumping into this convo so sorry if this has already been covered, but I see the main problem is integrating the scripts into the game, how would this be done, as far as i know youd need the jazz source code....wouldnt you ?

[FQuist]

Or about cheating, something I didn't think of until now. If you can manipulate individual player's positions, ammo, health, etc, it'd be pretty easy to make scripts that aid the player.. and maybe would even be hard to discover if done well. I will have to think about how to deal with that.

[Odin]

Or about cheating, something I didn't think of until now. If you can manipulate individual player's positions, ammo, health, etc, it'd be pretty easy to make scripts that aid the player.. and maybe would even be hard to discover if done well. I will have to think about how to deal with that.

Maybe the script used by the player would have to be also in the possession of all the other players in the server, or at least the server.

[Monolith]

To prevent cheating in a multiplayer environment the scripting client/engine will have to incorporate some way of checking to make sure all clients are running the same script. This sort of check would have to be made anyway, not just specifically to prevent cheating. Although if someone was joining an unscripted server, we might have to detect this and force that no scripts are used so they can't be running one while other people aren't. And if someone wants to cheat in single player, that's their choice.

[Torkell]

Server uploads script to clients, clients md5 it and send the hash back. Server maintains game state for all clients and does not trust clients - if server says client dies, and client then says "no, I shoot dave", server says "no, you're dead" (you'd have to allow for lag, but just ping the client every once in a while to measure lag).

[Odin]

Okay, I promised Quist that i'd post the syntax for the scripting language I came up with. Here you go.

/showspr XX posX posY Layer [XX refers to the number the sprite has assigned to it in anims.j2a. The command /showspr 35 15 18 4, for example, would show the sprite 35 at position 15, 18 in layer 4.]
/showani XX YY posX posY Layer FPS [XX and YY refer to the range of the sprites, according to the number assigned to it in anims.j2a. The command /showani 03 06 15 18 4 10, for example, would show sprites 03, 04, 05, and 06, in that order, at position 15, 18 in layer 4, animating at 10 frames per second.]
/stringwrite XX YY [XX refers to the string number, while YY refers to the value of the string. The command /stringwrite 01 "Jazz > Spaz" (With the quotation marks, mind you) would write the string "Jazz > Spaz" (without quotation marks) at string number 01.]
/musicplay XX [XX refers to the file name of the music module you wish to run. The command /musicplay diamond.j2b would change whatever music is playing to diamond.j2b.]
/musicsto [Stops current music.]
/musicrep [Starts music module from the beginning.]
/kick XX [XX can mean two things; either a name, or an IP. The command /kick Odin would kick any player named Odin in the server.]
/ban XX [Same as above.]
/print XX [XX is the player you wish the text to come from, while YY is the string you wish to print. The command /print 01 gg no re would show the host saying "gg no re."]
/spoofprint XX [XX is the string you wish to print. This is the same as above, but the text will be shown as if it were a game message (such as "Violet CLM roasted Orbitz CC").]
/eventcreate XXX posX posY A B C D G [XXX refers to the event number, while A, B, C, and D refer to the event variables. A G present creates a generator with the event. The command /eventcreate 164 15 18 31 G would create a soda pop event at position 15, 18, with a delay of 31 seconds, with a generator.]
/respawn posX posY XXX [XXX refers to the event number in the tile (with a scripting system, I assumed we'd find a way to create multiple events in one tile. However, you could not have two of the same event in the same tile.).]

I have lots more, but that's good enough for now, right?

[WaterRabbit]

Using Odin's script idea I came up with a few more options for a scripting language. Here they are:

Syntax: /choosemusic
This would automatically make a list appear in JJ2 that would let you choose from music files that you have in your JJ2 folder.
example: /choosemusic ChrisiLiz.it (You don't have to type this. The client will choose the music through JJ2)

Syntax: /levelvote [Levels for Voting]
This would automatically make a list full of different levels to vote on. The list would appear in JJ2.
example: /levelvote sfalls2.j2l xlmjrc.j2l olcunder.j2l

[EvilMike]

I vote the syntax is made it look more like a proper scripting language and less like a mangled mIRC script.

[Stijn]

I'd rather see something like choosemusic("filename.j2b", true). Or just
level.music.file = "filename.j2b"
level.music.loop = true

Which would work in the same way for objects:

player.position.x = 5
or
player.posx = 5

Though the event trigger system of mIRCscript might be useful:

trigger WARP_ENTER {
player.position.x = WARP_TARGET[0]
player.position.y = WARP_TARGET[1]
print(PLAYER_ID." warped to ".WARP_TARGET." via warp number ".WARP_ID)
}

Where WARP_TARGET and WARP_ID would be assigned a value automatically when WARP_ENTER would be triggered. PLAYER_ID would contain the id/name of the player that triggered the event (or maybe it should be called OBJECT_ID, if other sprites like enemies could also trigger this). The print() function would output text to the console/spy window.

Just some ideas.

[Stijn]

A special spawning function wouldn't be needed then, you could just do something like this:

create_object("foo")
foo.position.x = 5
foo.position.y = 9
foo.status.active = true
foo.status.visible = true
foo.gameplay.behaviour = BEHAVIOUR_TURTLE
foo.gameplay.friendly = false
foo.sprite = SPRITE_TURTLE

Would create an enemy turtle at position 5,9. This is a lot more flexible, as it could easily be extended by other properties (foo.gameplay.points for the points it could earn you, foo.gameplay.damage for the damage it takes before dying, etcetera)

[Grytolle]

Let's go for the IRC-commandish way instead, so they can be used in game like (*presses "T"* /kill Chiyu "Server killed you, becasue he wanted to.").

[Torkell]

I'd prefer a VB-style syntax as it's easy to pick up and use. And object-orientated sounds good, as that makes it easy to dynamically drop stuff in.

[n0]

And this is why there is no scripting language yet. We haven't settled on a script.

[Stijn]

Let's go for the IRC-commandish way instead, so they can be used in game like (*presses "T"* /kill Chiyu "Server killed you, becasue he wanted to.").
trigger KEY_PRESS {
if(KEY_ID==116) {
$allow_respawn = true
Chiyu.kill($allow_respawn)
Chiyu.send("Server killed you, because he wanted to")
}
}

[Link]

I support Monolith's idea of incorporating a scripting language designed for incorporation, such as Python, TCL, or Lua. This would be much easier than inventing (and parsing\interpreting\etc.) our own. However, it's still a good idea to brainstorm function and object ideas like Odin, Bloodrabbit, and sers have been doing.

Realize, though, that we don't have direct access to anything. All properties and actions would have to occur through memory hacking. There is currently no known way of spawning players or objects.

[Torkell]

You could always be fancy, and use the MS Scripting parser thing (and let people write in VBScript or JavaScript). That way all you have to do is provide a bunch of objects for use by the script. Whatever's used should be something designed for this, and not something like IRC syntax (which has its uses but not as a scripting language).

I'd suggest at a minumum Game, Player and Event classes. You could then add subclasses like Baddie, Boss, Weapon, Shield, Food and so on.

Game would be the grand-daddy of them all, and do things like manage game state and provide a method for accessing and adding Players and Events. Player would contain access to the state for a specific player, like health, ammo, gems, coins, etc. Event would contain the event params and location. Child classes of Event could have more specific details, like the current health and location of a baddie.

[ImportantGuy]

Completely unrealistic. Not going to happen. Just think about the synching problems between the game network sending a "shot fired" event, and your scripting network doing the same.

(On a side note, if you ARE going to try this, I suggest lua.)

[Newspaz]

I'm in favor of what Link says. I'm even considering making such a thing. I've been working with Python quite a bit lately and I like it a lot.