Scorpion Engine

[earok]

Yes. There's not a specific "powerup" feature in Scorpion but the engine is generic enough to support progressive powerups (eg, with Amigo the Fox, the character starts small, gets a big powerup, and then gets a shoot powerup, and all three of those levels can be used simultaneously with the invincible powerup) via the codeblocks visual scripting system.

[Kaizen35]

Thank you all for your welcome messages
A question concerns the projectile:
When I shoot my character (based on the Amigo game) is paralyzed a few seconds in the frame (but the direction arrows can always move him, it feels a little weird ) while the monkey in BadApple seems not.
I did not find where to reduce this delay? so that after each shoot, my character lowers his arm by finding the idle position for example.

[earok]

Originally Posted by Kaizen35

Thank you all for your welcome messages
A question concerns the projectile:
When I shoot my character (based on the Amigo game) is paralyzed a few seconds in the frame (but the direction arrows can always move him, it feels a little weird ) while the monkey in BadApple seems not.
I did not find where to reduce this delay? so that after each shoot, my character lowers his arm by finding the idle position for example.

Have a look in the actual animation, there's a tickbox for prevent movement that's used for determining whether your character can move while attacking.

If you wanted to have the actual shot on a specific frame rather than at the start of the attack animation, you can attach a codeblock event to the frame start.

[Mixel]

@earok - that seems to have fixed everything and it looks like the flashing portrait between lines of dialogue thing I mentioned is fixed too! ty!

I might not understand if you explained anyway, but those all seemed like completely unrelated bugs from an end user perspective.

[earok]

It all was the same bug (except the portrait flashing).

The bug was to do with reading player/actor/projectile variables, so if you did something like "type = actor_type", it'd return (for example) something like the "actor_x" value instead.

How it managed to mess up the screen so badly, well that's a total mystery to me!

[Mixel]

Aha that makes a bit of sense. I'll keep an eye out for further graphical glitches.

Did you change how ZOrder works? Some of my high Z-order stuff is appearing underneath my low Z-Order stuff now.

eg on the map, the blinky circles have ZOrder 0, the player and the yes/no popup have 600ish Zorder but appear under them. - (this doesn't seem to happen anywhere else I've noticed in game.. Could it be because I spawn them with codeblocks instead of placing them on the map?)

[Kaizen35]

Originally Posted by earok

Have a look in the actual animation, there's a tickbox for prevent movement that's used for determining whether your character can move while attacking.

If you wanted to have the actual shot on a specific frame rather than at the start of the attack animation, you can attach a codeblock event to the frame start.

Thank you ! that's right


other questions :

- What is the difference between "actor" and "player" in Scorpion Engine ?

- and I didn't understand what "Recycle" is for in the Actor section because it doesn't seem to change anything

[UltraNarwhal]

Originally Posted by Kaizen35

- What is the difference between "actor" and "player" in Scorpion Engine ?

- and I didn't understand what "Recycle" is for in the Actor section because it doesn't seem to change anything

Actor and Player seem same but using player makes sure events only affect the player (eg. level obstacles, items,etc).

Recycle changes how the actor behaves after going off screen. In my game enemies are projectiles, so I use recycle always, otherwise they'd never respawn after leaving screen. Recycle Respawn places actor back where it started level when off screen, handy for keeping sine wave actors in the correct place.

[Kaizen35]

Thank a lot UltraNarwhal !

[Mixel]

Narwhal covered everything perfectly.. (I’m still a bit fuzzy on some of the recycle rules!)

Another thing I think is worth mentioning about the relationship between player and actor - if your game codeblocks end up anything like mine you’re going to be frequently comparing actor_x and actor_y with player_x and player_y to get things to behave at certain times based on the player’s relative position to the actor. Like, if the player is within a certain distance, do a certain animation or attack.

[Kaizen35]

thank you Mixel, for this additional information

[earok]

@mixel Are the blinky circles sprites by chance..? I haven't touched the z-order logic in a long time, but sprites are always going to be on top of non-sprites regardless of z-order.

@Kaizen Yes, UltraNarwall and Mixel are absolutely correct. Some additional points:

- "Trash" recycle mode means delete when offscreen (mostly handy for things like projectiles where you never want to see it again)

- "Never" recycle mode means that the actor will never be deactivated, this is only really handy for things that you want to keep moving even when they're off screen (though too many of these actors will slow things down a lot of course)

- "Actor", "Player" and "Projectile" are context sensitive (eg, in an event with a collision between an Actor and a Projectile, they refer to that specific actor and that specific projectile)

---

Experimental check in for today, new "print" option in the dialogue menu. It's similar to "say", except:

- You can print to the top, bottom or fullscreen panel (Need to have a talkpad area configured)
- It doesn't interrupt the flow of the game (it's also an instant print rather than showing character by character like talkpad does). So you can print while the game is in motion, though there may be a frame skip depending on how many characters you're printing.

This might be handy for things like printing the name of the current room. Probably a whole lot of other things it'll be useful for too.

[Kaizen35]

Thanks Earok, I need to practice all of this now

[Mixel]

Originally Posted by earok

@mixel Are the blinky circles sprites by chance..? I haven't touched the z-order logic in a long time, but sprites are always going to be on top of non-sprites regardless of z-order.

That's what my initial thought was too but.. They aren't? unless the editor is misreporting. It's .. Very odd, usually I put this sort of thing down to misremembering but I was filming the map a couple of days ago and it was definitely right in that video. And now it isn't. So I'm fully stumped by that, hehe, It's not the end of the world and people would just think its intentional.

I just upped it to the Git in case it's a problem you want/need to look at..

Iconafran Anim / Iconfran Actor
redping anim / Mapredping Actor
greenping anim / Mapgreenping Actor
YesNoBox anim / YesNoSelector Actor

Its seemingly impossible to get the "pings" to appear below the other things with Z-Order now. I haven't noticed any issues anywhere else though outside of the map. (need to do some playthroughs though)

Experimental check in for today, new "print" option in the dialogue menu. It's similar to "say", except:

- You can print to the top, bottom or fullscreen panel (Need to have a talkpad area configured)
- It doesn't interrupt the flow of the game (it's also an instant print rather than showing character by character like talkpad does). So you can print while the game is in motion, though there may be a frame skip depending on how many characters you're printing.

This might be handy for things like printing the name of the current room. Probably a whole lot of other things it'll be useful for too.

Ohhh... very, very nice! I love this! That'll make part of my menus look nicer too.. That'll drastically change how I think about making some of the VN most likely. Not sure if I'll use it during gameplay in CMOhn, but.. maybe!

[UltraNarwhal]

I checked the latest experimental build and Z order does look to be broken (weird), I spawned the same egg and sometimes I go behind others I go in front.

Experimental build from 17 June works fine, spawning egg puts it behind player.

[acidbottle]

I'm still on a build from 26 May, Z order not working at all for me. My player disappears under all other actors. Thought it was something I had missed so dismissed the problem, but the above confirms it is a possible issue.

Well just to elaborate, all my sprites are in fact bobs, none have been set to sprite or auto sprite. I read above earok saying sprites appear above all bobs, which I didn't know, so changed player 1 to sprite, the colours are messed up but it is indeed above my bobs now! I believe sprites use colours from the the last 16 (or first i forgot!) of the palette.

[earok]

Eeep.

I think I've found the issue, checked in a new experimental but *not* tested yet (another flow on effect from adding the new tag and isonplatform variables)

[acidbottle]

That was a damn fast fix earok, cheers for that! Just tested and z order appears to be back in the groove

[Mixel]

Everything seems fixed here too.. TY for the speed again!

The only bugs I now know about are me bugs.

[earok]

No worries!

Today's experimental update is a relatively minor editor tweak - just like in the animation and actor tabs, the X/Y positions of talkpad, elements and options is displayed on screen in order to help with alignment.