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.

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:
[IMG]http://img836.imageshack.us/img836/5543/need1up.png[/IMG]

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:

[img]http://img195.imageshack.us/img195/5256/warpbc.png[/img]

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

ditto, i hear ya bro :lori:

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.

(emphasis on "currently", probably)

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.

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.

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 :p ), 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)

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.
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.
No, that's what this thread is for.

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.

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.

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.

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.

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

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:

Quote:

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:
Absolutely. For example, most enemies use 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."

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

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)

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.
I really don't think two separate menu options (assuming that's what you're talking about) is an insurmountable hurdle to user enjoyment.

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.
The jjSample AngelScript function has parameters for position and volume, so I think that one's already covered, yes?
Of course! Keeping in mind we're not guaranteed not to ignore certain requests.

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.

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.