Scorpion Engine

[Mixel]

Originally Posted by earok

Update for the day:

Excellent update! Thanks for all the fixes! it certainly seems like most things are fixed now. I think i have one remaining bug, and that's my jumpy frogs (that detect actor_isonplatform) they just freeze up when on ramps now. i can maybe work around that, but its probably not supposed to be like that?

That's maybe connected to why my motorbike wont jump on ramps too, thinking about it..

- Partial revert of behavior for change actor type. By default, the actor's speed will reset when changing an actor type (as it was originally) but there's now a tickbox to disable this so an actor's current speed can carry through to the new type.

Best of both worlds, I like that.

- Fix for CPU path actors.

Snails are definitely working as intended.

@Mixel could set the camera scroll speed to 3? That's the "canon" way for auto scrolling games in the current Scorpion Engine. Otherwise you could do something like ...

Thankyou for both suggestions! I'll try tinkering with them.

And like Acidbottle said, merry xmas everyone! (though I'll probably post again before then anyway, haha)

[Pyromania]

Scorpion Engine keeps getting better and better!

[earok]

Cheers pyromania, mixel and acidbottle

---

Daily check in. Mostly fixes for manual jumps from slopes. Also slopes themselves have been reworked a little bit to support the different collision types (bounce, none etc) except for special_stayonplatform.

I may remove special_stayonplatform and replace with a new movement type (something like cpu_platform_patrol) that stays on platforms and -should- properly support staying on slopes. Could also come with other platform types that chase players, jump off platforms etc.

[earok]

Did a *second* update for today.

Support for the collision type "special_stayonplatform" is dropped. The new standard way of handling is setting "On Platform Edge Reached" to FlipXMove (this upgrade will be done automatically when you open the project).

The cool thing is you can use any other codeblock for handling what your character is meant to do for when it reaches the edge of a platform. You could use the new "Jump" function in standardfunctions to make it jump off the edge, or you could do some custom logic to make the enemy fall down on the player only if the player is underneath the enemy, for example.

[domkid]

thanks Earok for all these updates, merry xmas everyone

[UltraNarwhal]

That's fixed almost all the problems I had (unsure if flipXY works with vertical yet) It did break my ice sliding, but fixed by ignoring code if player was not moving.

Happy Christmas Have a break.

[Mixel]

I hope everyone is having a good xmas break. (and this is not in any way a call for people to stop being on said breaks, lol, I just have a spare minute before I’ll be super busy..)

Totally unimportant question: Does anyone here use a VM to run Scorpion, I’m going away for a bit so I’m running scorpion on my i7 MacBook Pro again, which I haven’t for a while.. is there any reason why imploder would complain about dlls when compiling in the vm when the same scorpion version ran from windows natively with no problems? Seems a bit odd. It’s the same experimental folder downloaded by GitHub Desktop, so I can’t see why it’s freaking out. (No big deal - I can just disable imploder when working on the Mac!)

If it’s relevant, I’m running it in Parallels.

Oh and I don’t think everything is right with slopes quite yet? If Actor_isonplatform == true still doesn’t seem to apply to actors standing on ramps? I might be misunderstanding how it works.

[earok]

I maybe need to add some examples but this should work

Actor_isonplatform != false (is on either a solid tile or a slope)
Actor_isonplatform == 1 (is on a slope but not a solid tile)

[Mixel]

Oooh that makes sense! of course! TY again! For setting different ramp speeds etc. I knew that recently and then forgot again, apparently.

[earok]

No worries

Check in for experimental. I'm working towards, so I'm going through all of the sample games (14 in the official repo and 6 in the unofficial one!) and ironing out the bugs that have propped up.

- Version is now "2021 Final". Once the public release is done, hopefully in the next few days, versions will be 2022 from now on.

- Sample games have been removed from experimental repo

- Added project folder name to project tab (useful if you work on a lot of different Scorpion projects and you're not 100% sure which one is open)

- Fixed bug with some auto upgrades (in particular, it was incorrectly setting "use projectile direction" (as opposed to actor direction))

- Minor fix for multiplayer games, the recycle modes for players 2-4 are "never" by default (which is to say, they never get deleted even when they're far outside of the playing area)

- Minor fix for multiplayer games, possibly an issue with the "Player" pointer in codeblocks being set incorrectly after a collision between players (might have only been a theoretical rather than an actual bug)

- Fixed minor bug that incorrectly assumed actors spawned with an "upward" direction were on a platform (caused some upwards facing "CPU platform" projectiles to immediately act like they had collided with the ground)

- More robust error checking, in particular failing a compile when an actor has an invalid animation.

- Made the actor movement reset much more like how it used to work, hopefully that should solve a few lingering bugs (tested on Amigo the Fox, without any manual code changes it seemed to work how it did previously).

- Also added "reset movement" as an option in "set lookdir" for manually resetting an actor's movement, not sure if that'll be useful at all but it's there!

[Mixel]

That’s incredible! 2021 has been a hell of a year for scorpion updates, it’s pretty crazy, congrats!

Feature request, just a pop up that says “this project was saved with a later version of scorpion engine [ver number] are you sure you want to open it?

Working on cmo across multiple machines I jumbled some stuff by loading it in an old version by mistake, haha. (No problem - I reverted it with GitHub) But I imagine the same happening to someone less backed up and it causing a bit of a headache.

Really happy you fixed the upward spawning bug, I assumed it was a me thing, not an engine thing and was going to circle back and do a work around.

[domkid]

hey guys, new Wip on Rick Dangerous, beginning of level 2...
[ Show youtube player ]

[malko]

Originally Posted by domkid

hey guys, new Wip on Rick Dangerous, beginning of level 2...
[ Show youtube player ]

GFX are beautiful. Looks like the level design has been changed a bit so it's not a 1:1 game. Is it intended that the enemies are not killed by the traps or is it the WIP status ?
Keep up the excellent work

[domkid]

Originally Posted by malko

GFX are beautiful. Looks like the level design has been changed a bit so it's not a 1:1 game. Is it intended that the enemies are not killed by the traps or is it the WIP status ?
Keep up the excellent work

Thanks, yes, still in progress...

[griffon]

Fist of all, wow. This piece of software is something else. Great job @earok!

I admit that I am only half thru this huge thread, and I've been messing with SE for only about three weeks now, but boy I do have a lot of questions, and the lack of a wiki/tutorial really hurts my brain even if the included demos have been helping.

I've been trying to find creative solutions to my problems, but there is one problem I can't find any example on. I'm working on a certain conversion, where one of the playable characters has a whip-like melee weapon. Let's say like Castlevania, either the arcade or home version where the MC has a whip that comes in different lengths. I was able to handle that as a projectile (the character can't move while using it anyway) and despawning it using the On Spawn Block code and basically just destroying the actor right after the end of the animation. That works fine if the character is walking, but alas, won't work when jumping attack, cause the character moves
While rummaging in the actor movement type option I found the "CPU Parent Lock, fixed to spawning actor" that sounded very promising but I can't find a way to make it work. Or is there another way to make it work? Also, I'd like to save some memory/disk space and instead of using a different set of animation frames for the weapon change (which is just the handle of the weapon, basically), I'd like to separate them to have one fixed animation set for the character (idle, walking, jumping, and attack), and to stick on top (or bottom, doesn't matter) of him/her the handle of the weapon and under the chacter the rest of the whip, to avoid using another set of animation if possible, and just having it "pop" horizontally from under that character. Suggestions on how that can be done in SE, or at least the first part of all that? Thanks to whoever will take the time to answer!

and to @mixel, I can't wait to see what you can pull off with your completed CMOHX game!

**Forgotten to mention I am using 2021 Final experimental at the moment, whoops.

[Mixel]

Hey! Thanks for the CMO comment! Earok will likely have a better solution than mine but..

It’s really funny you’re asking this now as I was trying to solve the exact same problem yesterday and ran through the same failed solutions you did.. (I don’t think child actors work for this) - I’ve been cleaning up my attack projectiles and animations (TY Tsak for your help!), so maaaybe we need a similar effect..

I have a timer on the projectile that changes the X/Y speed of that actor based on controller direction and player speed. It’s not exact in my case while jumping but it didn’t need to be as exact as a whip probably does, but that’s probably the sort of thing you’ll need to do. Maybe you can set its x/y coordinates every tick instead to player_x-something and player_y-something when joystick left and player_x+something/y-something when player is facing right? It’d be fiddly to set up but you could theoretically have it bonded to different positions based on the players animations if you rigged it up to the frames of the whip animation too (linking the codeblock into the whips individual frames instead of the timer, and setting the whip to have same number of frames as the attack animation? I didn’t get that exiaxt about it as mine’s just a swoosh animation that’s not technically attached to the player)

[griffon]

Originally Posted by Mixel

Hey! Thanks for the CMO comment!

They're well deserved, believe me, SE is impressive, but so is your work on it!

Originally Posted by Mixel

It’s really funny you’re asking this now as I was trying to solve the exact same problem yesterday and ran through the same failed solutions you did.. (I don’t think child actors work for this) - I’ve been cleaning up my attack projectiles and animations (TY Tsak for your help!), so maaaybe we need a similar effect..

Well, it's... good if it is a common problem, I think? More chances that earok will have a look at it

Originally Posted by Mixel

I have a timer on the projectile that changes the X/Y speed of that actor based on controller direction and player speed. It’s not exact in my case while jumping but it didn’t need to be as exact as a whip probably does, but that’s probably the sort of thing you’ll need to do. Maybe you can set its x/y coordinates every tick instead to player_x-something and player_y-something when joystick left and player_x+something/y-something when player is facing right? It’d be fiddly to set up but you could theoretically have it bonded to different positions based on the players animations if you rigged it up to the frames of the whip animation too (linking the codeblock into the whips individual frames instead of the timer, and setting the whip to have same number of frames as the attack animation? I didn’t get that exiaxt about it as mine’s just a swoosh animation that’s not technically attached to the player)

It's an interesting idea, I was thinking (and trying) something like that, but I didn't figure how to run some code every tick. How do you do that? I also am afraid that i will be very costly performance-wise. on the other hand, the alternative is to use a gigantic bob (player+weapon+whip-thing) which sounds just as costly, if not worse...


Thanks for taking some time to reply btw, very very appreciated

[acidbottle]

Happy new year scorpions!

Little issue has arisen. I have copied output folder to my CF card for some real amiga action. Unfortunately it now seems the exe no longer runs Should add i get no error and running, just executes and does nothing. Also in high res screen mode through an OSSC.

should be plenty of grunt in the expanded miggy to run it, works great on winuae wb.

[Mixel]

Originally Posted by griffon

It's an interesting idea, I was thinking (and trying) something like that, but I didn't figure how to run some code every tick. How do you do that? I also am afraid that i will be very costly performance-wise. on the other hand, the alternative is to use a gigantic bob (player+weapon+whip-thing) which sounds just as costly, if not worse..

Bottom right of the actor tab, i have my delay set to 2 because mine doesn't have to be that exact but if its set to 0 it'll be constant. That timer on my player actors is also where i put the hooks for ducking (technically a unique player actor with its own attack type) etc, which might be relevent if you're making a castlevania-like thing.

Thanks for taking some time to reply btw, very very appreciated

No problem! A bunch of the commenters here are super useful, i just got here first. Welcome aboard. You're likely to have your own workarounds for things that are totally different to mine, so its super cool seeing similar or adjacent genre'd stuff from a learning perpective, looking forward to seeing it!

Originally Posted by acidbottle

Happy new year scorpions!

Happy new year!

Little issue has arisen. I have copied output folder to my CF card for some real amiga action. Unfortunately it now seems the exe no longer runs Should add i get no error and running, just executes and does nothing. Also in high res screen mode through an OSSC.

should be plenty of grunt in the expanded miggy to run it, works great on winuae wb.

This also happens to me, I thought it's maybe what happens if you don't have enough Chip RAM to run it? CMO still runs if you boot with no startup sequence but doesnt boot at all from workbench currently. (it doesnt report errors, its just like nothing happens at all)

---
Feature request time! could it show the colour channels in the palette preview/project view somehow? Referring back to https://eab.abime.net/showpost.php?p...postcount=1249 for something so abstract isn't handy, and even then i don't really get it, sorry! lol (you say we use channel 2-1 - 8-1 based on how many of the thing we want w/multiplexing, in your example bullets.. But if it's something I only want to display one of.. If I want to use colours 25-27 do I have to pick "4 colours (channel 6-1)"? - i have a feeling im being dense here. Maybe i can use any 4 colours. I'll experiment! Edit: it just throws out an error regardless of which colours i use if i try to use 4 colour sprites?

[griffon]

Originally Posted by Mixel

Bottom right of the actor tab, i have my delay set to 2 because mine doesn't have to be that exact but if its set to 0 it'll be constant. That timer on my player actors is also where i put the hooks for ducking (technically a unique player actor with its own attack type) etc, which might be relevent if you're making a castlevania-like thing.

Oh my, hidden in plain sight! Being it right after "collision" type events I wasn't really sure how it worked... even if I used it to handle the main character!

...unfortunately, that won't cut it, alas. I mean, it kinda works, but it can't keep up with the character movement during jumps, even if works when crouching and standing (but that's easy! the character doesn't move during those attacks...), even with Timer Frames set to 0. It's sometimes too high, sometimes too low, even if the X asis seems to be OK at all times. It's so odd.

Maybe it can be improved by using sprites? Would probably need to use most of them tho. Not that I would be using them for much more anyway. Also, in that case, can different sprites use the same colors without expending more than 4 palette slots in SE?

I guess I gotta wait for earok's input on this.