Originally Posted by Sir Ementaler

I'm pretty sure that JJ2 doesn't contain onTrigger() itself, so to add it, JJ2+ would just have to check for those "too many conditionals every frame" on its own and it wouldn't be any faster. However, it's worth noting that there's no reason this would be slow at all, as all you have to do is check current trigger state (JJ2 array) and previous trigger state (custom array you should update manually) for every trigger. So, check state of two booleans in a for() loop that repeats 32 (or, in your "some day" scenario, 256) times. By my estimation, this won't slow the game down by more than 1.0*10^-20 fps. In other words: it's not cumbersome, it gives your script approximately up to 6 more lines, and you shouldn't worry about speed issues, there's no way this would slow the game down.

In fact I think we can do this roughly the same way as with the Text events: when they get activated, we call a specific AngelScript function. That wouldn't require checking all triggers every gametick. This is a planned feature, we just haven't gotten to the point of implementing it.

Originally Posted by plunK

the Abiltiy to create new coloured gems, with customizable gem values

I was testing in hope to find a variable that does it already. I failed, but to those curious what happens if you set var[0] to -4672:

Originally Posted by Jerrythabest

Weirdest. Bug. Ever. It doesn't really crash, it just hangs at the palette.apply() call.

For me sometimes it would outright close, actually (sometimes it would just hang, too). Should have mentioned that. Hey, it was 12 minutes after midnight.

And yeah, it's not game-breaking, not like palettes ever affect gameplay to my knowledge :P

Yea, I've seen it doing that too. It just disappears into nowhere.

I am so glad to see that Get Me R was finally implemented into JJ2+!, Good job and see you in the next one c:

^ there's a bug, like in GMR v4.0. If you jump on spring, and press type /ready while you are in the air, you will jump above the base. If you're in a sucker tube and type /ready, you will move from the base, like it's one tile sucker tube.

There's still one bug, like in previous versions. Not sure if it's possible to fix, and how, but do your best! If you put warp target above the vine, this will happen:

Both easy enough to fix, although I've always been attached to the second one, so I don't really want to...

Originally Posted by Violet CLM

I've always been attached to the second one

ditto, i hear ya bro

That should stay!

Add OBJECT::ENEMYBULLET=20.

Turns out it's used by all sorts of hazardous projectiles spawned by SP enemies. Dragons' breathe, Monkeys' bananas, Witch's spell, Devan's gun bullets, Devil Devan's fireball, etc.

Originally Posted by Violet CLM

Objects <= 20 are given special treatment as bullets, so it's on the list, but the problem is that it doesn't have any defined properties at _all_. And since you can't currently set an object's behavior function in AS, allowing people to create it wouldn't do any good.

(emphasis on "currently", probably)

Originally Posted by Sir Ementaler

Add OBJECT::ENEMYBULLET=20.

Turns out it's used by all sorts of hazardous projectiles spawned by SP enemies. Dragons' breathe, Monkeys' bananas, Witch's spell, Devan's gun bullets, Devil Devan's fireball, etc.

Object 20 is not only used by enemy projectiles, pepper spray bullets also use it, which would make it even more useful to get proper access to.
I assume the "behavior function" Violet mentioned refers to a function pointer inside the object structure that is called every tick. If that is the case, wouldn't it be sufficient to find all suitable functions from the various object types that use it and assign an enumerator to each of them? Then, just give the AS API a property of that enum with setter/getter functions that automatically convert from enum values to function pointers and back.

Originally Posted by GLaDOS

Object 20 is not only used by enemy projectiles, pepper spray bullets also use it, which would make it even more useful to get proper access to.

Oh, you're right. I had assumed pepper spray uses the same eventID as fireball.

But hey, that's not all! Object 20 is also used by the shock wave created by RF missiles. That'll cause trouble with naming it properly.

Originally Posted by GLaDOS

I assume the "behavior function" Violet mentioned refers to a function pointer inside the object structure that is called every tick. If that is the case, wouldn't it be sufficient to find all suitable functions from the various object types that use it and assign an enumerator to each of them? Then, just give the AS API a property of that enum with setter/getter functions that automatically convert from enum values to function pointers and back.

All correct, but there are a lot of them. We're figuring out how best to handle the behavior issue, floating around various approaches.


Out of curiosity -- what would people like to know about what we're doing? There was a while where we were posting teaser pictures on J2O, until people started complaining there were too many of them and other stuff like that. Now we're mostly silent except for occasional reassurances like "we know about this" or "we'll think of something." Are either of those options preferable? (With pictures presumably not on the J2O front page anymore.) Or full on development blogs? Keep in mind that I'm not saying we'll necessarily do what the majority support, but it would be nice to have some sense of where people stand on this issue.

So, I've been running into another problem... I need to set a bunch of tiles (the same pattern several times across the level, but independently controlled) in a foreground layer, but the "tile cache" is getting in the way. Is it technically possible to add the option to allocate additional tile cache entries that jjTileSet() will then use?
Perhaps adding a function like jjAddTileCacheEntry(uint8 layer, int xWord, int y) would be the most convenient way to do it. It would copy the cache entry into a newly allocated one and change the cache reference of the tile to the new entry. That is, if it is possible to increase the tile cache's size, either dynamically whenever the function is called, or, if that is not possible, by a predefined maximum number when loading the level.

EDIT in response to Violet:
A development blog with relatively condensed info about upcoming features would be nice (along with maybe a bug tracker and some place for suggesting stuff ), if it doesn't take away too much time from actual development.

This of JJ2 PLUS with AngelScript is a great occasion for unfinished episodes like "Jazz Unleashed", "Tomb Rabbit 2" and "Dreamscape" to REALLY amaze us when finished!

I don't think those will ever be finished

Well, Dreamscape might.

Quick question, does setting p.xOrg and p.yOrg have any effect in multiplayer at all? It doesn't seem like they work for me, the player just respawns at the MP Start / Jazz Start event.

And not the same spawn pos as the previous time?

The xOrg/yOrg variables seem to reset themselves to the usual start pos event on death. If you meant that I might have set the spawn point to the same position as the Start Pos event, that is not the case.

On an unrelated note, is the dev team considering adding access to the player input bitfield? (PlayerStruct + 0x584 if I recall correctly, at least for TSF)
It's one of these things that would allow for some very interesting gimmicks in scripted levels.

(on an even less related note, perhaps I should move my suggestion/implementation spam into a dedicated thread to make more space for bug reports/help requests/compliments in this thread, I have many more to make and I would really like to contribute to JJ2+'s script API)

Originally Posted by GLaDOS

Quick question, does setting p.xOrg and p.yOrg have any effect in multiplayer at all? It doesn't seem like they work for me, the player just respawns at the MP Start / Jazz Start event.

They were a pretty last-minute addition to the API, so I don't really know -- the description in the .html doc may not even be correct -- if that's the behavior you're getting, that's probably what happens.

Originally Posted by GLaDOS

On an unrelated note, is the dev team considering adding access to the player input bitfield? (PlayerStruct + 0x584 if I recall correctly, at least for TSF)
It's one of these things that would allow for some very interesting gimmicks in scripted levels.

Controller input is definitely something that should be exposed to AngelScript somehow; we just need to figure out the most helpful way of doing that, first.

(on an even less related note, perhaps I should move my suggestion/implementation spam into a dedicated thread to make more space for bug reports/help requests/compliments in this thread, I have many more to make and I would really like to contribute to JJ2+'s script API)

No, that's what this thread is for.

Originally Posted by Violet CLM

They were a pretty last-minute addition to the API, so I don't really know -- the description in the .html doc may not even be correct -- if that's the behavior you're getting, that's probably what happens.

I guess they only work with SP checkpoints, then. The reason I asked is because I thought I might have been doing something wrong (forgetting to call some function or w/e). Currently working around it using warping, it's not really an issue; it could at most be a bit confusing to newcomers to JJ2+ scripting.

Originally Posted by Violet CLM

Controller input is definitely something that should be exposed to AngelScript somehow; we just need to figure out the most helpful way of doing that, first.

An int/enum with bit values would give the most control/efficiency while a bitwise set/get function pair would be the easiest to use. Perhaps both could be implemented? There are already quite a few things that can be achieved in multiple ways using both properties and helper functions.

Originally Posted by Violet CLM

No, that's what this thread is for.

Okay then. It just sometimes felt like a few posts were left unread because all different kinds of posts are mixed into one thread, with different discussions going on at once.

------

Unrelated edit:
Is there any reason why the invincibility variable of jjPLAYER objects other than the local players cannot be read? It would be pretty useful to at least have read access to the blinktime of other players.

Originally Posted by GLaDOS

Is there any reason why the invincibility variable of jjPLAYER objects other than the local players cannot be read? It would be pretty useful to at least have read access to the blinktime of other players.

Two-part answer:
1) Invincibility and blinktime are separate properties, the one of which is exposed to AngelScript and the other of which is not.
2) Player objects have far, far more properties than you see in AngelScript, not all of which are of much use; the current collection was chosen somewhat haphazardly, and we're figuring out which ones shouldn't have been left out as we go along.

Originally Posted by Violet CLM

Two-part answer:
1) Invincibility and blinktime are separate properties, the one of which is exposed to AngelScript and the other of which is not.

That's interesting, I didn't know that was the case.

Originally Posted by Violet CLM

2) Player objects have far, far more properties than you see in AngelScript, not all of which are of much use; the current collection was chosen somewhat haphazardly, and we're figuring out which ones shouldn't have been left out as we go along.

With the enormous size of the player structure, having to leave out a lot of the properties is understandable. I just hope that the properties/functions that are being suggested will eventually be added to the API.

Edit:

Originally Posted by Anonymous Reputation (-8)

calm down and sit on your ass

Seriously? I asked about opening a separate thread for my suggestions in case this thread was spammed by me with suggestions too much, and I offered to help out with improving JJ2+'s AngelScript API (C++er here), but it does not seem like anyone of the dev team is interested in letting me help. Now the only way to contribute is for me to suggest features and their implementations in this thread, the reason I am posting so many in such a short time is because I am working on a relatively large multiplayer project using AS right now. So, instead of tolerating or at least ignoring the fact that someone here is trying to help the developer team make the AS API more feature-complete despite not being part of the team, this kind of complaint is the response I get?
Receiving random unbased hate from members who stay anonymous is easily one of the most demotivating things about posting on JCF; this is a case of complete anonymity just making things much worse.

Edit 2: Above rant on reputation is now invalid; reputation system has since been improved. Doesn't make the person who gave it to me less of an idiot though.

I've looked to the apple's objType property and i found some usefull stuff some of you might want to know and some of you might already know:

objType value: Behaviour
0: Hurt + Blocks Bullets
1: Hurt + Destroy
2: Hurt + Destroy
3: Untakable
4: Untakable (Goes here when eaten)
5: Eatable (Normal State)
6: Not able to change to this state
7: Untakable
8: Blocks bullets
9 - 14: Untakable

Untakable: The player can't take this and doesn't interact with it.
Hurt: The player get's hurt by the apple.
Blocks Bullets: Bullets are destroyed by the apple (all hail the mighty apple).
Destroy: Object gets destroyed when a player touches it.

Also, the apple can still be shot down with tnt (unless its in a masked tile) but not with normal blaster bullets (unless objType is 5).

I don't know if these changes in objType work with other objects (it probably will with other fruits). The use of this is to let the apple be a dummy object where you can change behaviour of it: i.e. make a throwable bomb that doesn't hurt the player when touched.

This does explain some of this stuff blur wrote:

typedef enum oooTYPES {
	oNORMAL, oPLAYERBULLET, oENEMYBULLET, oPARTICLE, oEXPLOSION, oPICKUP, oWAITPICKUP, oHURT, oSPECIAL, oDYING, oSPECIALDONE, oSELFCOLLISION, oTYPES=15, oENEMY=16, oTRIGGERTNT=32, oALWAYSACTIVE=64
} oooTYPES;

Originally Posted by Foly

I don't know if these changes in objType work with other objects (it probably will with other fruits).

Absolutely. For example, most enemies use

oNORMAL+oTRIGGERTNT+oENEMY

for their objType.

I know one of them -- possibly oSELFCOLLISION -- is what's used by turtle shells to determine whether an object should be bounced off of or not. oSPECIAL is a tricky one that means that the object has potentially unique behavior in response to a) being hit by a bullet or b) being collided with a player, behavior which must be defined separately for each oSPECIAL object. oTRIGGERTNT does what it sounds like; oALWAYSACTIVE means the object isn't deactivated when it's more than ~30 tiles away from the player in single player. oPARTICLE, oWAITPICKUP, oHURT, oDYING, and oSPECIALDONE I know less about.

Meanwhile, I know nothing at all about "doesHurt," and have only a limited understanding of "noHit."

Originally Posted by Violet CLM

oALWAYSACTIVE means the object isn't deactivated when it's more than ~30 tiles away from the player in single player.

Out of curiosity, are there any objects that actually have this?

for (uint8 i = 1; i < 255; ++i)
	if (jjObjectPresets[i].objType & 64 == 64)
		jjPrint(formatInt(i, "1"));

Rotating Rock, Bridge, and all the shootable pole events. Not sure why bridges mustn't get deactivated, but the others are pretty intuitive.

Also, Bees, for no reason at all.

Hahaha, is that why the Hocus levels had to leave Bees off of some of the spikes?

Too many objects, yea.

Here are my new suggestions for plus.

Ability to stand on walls, aka sideways gravity or sticky feet
Mute all, meaning both sound and music with one click

Going to go ahead and ask this here.

Could users be given access to at least some BASS functions? Not sure which ones are too big a security risk, but I'm particularly interested in BASS_ChannelSetPosition, BASS_ChannelSetAttribute, and BASS_SetConfig (only to set buffer length).

I ask because I'd like to have levels with "dynamic" sound or music. For example, smoothly switching to different music when overtime starts, or Sudden Death in the EGFP update (I SWEAR I AM DOING THIS).

Or, for an example that almost anyone can do, playing ambient noise depending on the player's location in a level - splashing waves that get louder as they get closer to the water, sparking noises near those electric...things in Tubelectric, etc. The Ambient Sound event can only handle so much.

Of course if it's too dangerous or not cool enough or BASS was incorporated into JJ2+ in a way that makes this non-trivial to add, I totally get that, no sweat

(you're sure you still want to allow feature requests in this thread? =P)

Originally Posted by JETT

Ability to stand on walls, aka sideways gravity or sticky feet

Complexity far outweighs utility, sorry. Reverse gravity is essentially finding a lot of values to change the signs of; sideways gravity takes a lot more thought and I don't see anyone ever using it.

Mute all, meaning both sound and music with one click

I really don't think two separate menu options (assuming that's what you're talking about) is an insurmountable hurdle to user enjoyment.

Originally Posted by minmay

Could users be given access to at least some BASS functions? Not sure which ones are too big a security risk, but I'm particularly interested in BASS_ChannelSetPosition, BASS_ChannelSetAttribute, and BASS_SetConfig (only to set buffer length).

Only replying to this because I'm posting anyway; I know absolutely nothing about BASS, but cooba and Torkell seem to know more, so hopefully we'll have some internal discussion of this.

Or, for an example that almost anyone can do, playing ambient noise depending on the player's location in a level - splashing waves that get louder as they get closer to the water, sparking noises near those electric...things in Tubelectric, etc. The Ambient Sound event can only handle so much.

The jjSample AngelScript function has parameters for position and volume, so I think that one's already covered, yes?

(you're sure you still want to allow feature requests in this thread? =P)

Of course! Keeping in mind we're not guaranteed not to ignore certain requests.

Originally Posted by Violet CLM

I really don't think two separate menu options (assuming that's what you're talking about) is an insurmountable hurdle to user enjoyment.

I did think this would be a pretty handy option to have, since I rarely mute only music/sound but not the other, and -nosound is impossible to turn off in-game.

Originally Posted by Violet CLM

The jjSample AngelScript function has parameters for position and volume, so I think that one's already covered, yes?

Well, I was thinking of using custom sound effects - the way I was thinking of using it, they'd each be a channel or two in a MO3, and I'd adjust the volume based on the player's position. (Definitely not thinking of using multiple files here - in fact one reason I wanted access to ChannelSetPosition was to switch between several similar themes in the same module and not need to store the samples multiple times by spreading those themes across several files.)

Of course, support for user-provided sound effects may not actually be desirable at all.

minmay, once I finish my current workings (to the Plus dev team known as the "hellfunction"), I will look into BASS. I've scrolled through its API already some week ago. Doesn't look all that difficult.

Info about noHit:
It appears to be a property used only by objects whose objType&oTYPES==oNORMAL (so in numbers, objType&15==0). It handles those objects' interactions with players' bullets. The way it works reminds objType.

0=on collision with a bullet decrease own energy and destroy the bullet unless it's fireball
1=ignore all bullets
2=destroy bullets except for pepper spray
3=destroy bullets except for pepper spray and fireball (it can also execute special actions if they're defined for the object)
+4=cause ricochet
+8=treat freezer bullets as regular bullets (if off, the object will always get frozen by freezer bullets)
+16=don't get pushed back by TNT

That's all there is to it, no object uses values higher than 31 and it doesn't seem they would cause any different effects.