Scorpion Engine

[earok]

@acidbottle have you tried using "actor_y = actor_y + 1" to force falling through blocks? I think that should work even if a block is solid.

@mixel cheers for the much appreciated community support apologies, I know I've still gotta look at those issues you've reported, but I should be able to get to that soon.

---

Experimental update for the day, based on an issue reported by NEESO

Previously, "PlayMusic" would force the song to load from disk even if it was already in memory, which meant that there was unnecessary loading times if you were using PlayMusic for the same song at the start of every level. Now PlayMusic only loads from disk if the song wasn't already in memory, otherwise it plays the music instantly.

This should be particularly handy if you have every song in one mod file and use set music position to switch between them.

(Note that there isn't any option to "unload" music from memory, simply setting PlayMusic to none will stop the current song but it can be restarted instantly with PlayMusic)

[acidbottle]

Quickest reply in history that thanks earok, will try that later, sometimes its the most obvious simple things that fix an annoying issue.

Made even sweeter by fixing an another issue I had with the sounds to, awesome work.

[saimon69]

Hey Earok, still about Neeso, can you check if there are issues with mod files using the instruction F00? Those seems to crash the machine, thanks

[Mixel]

Originally Posted by earok

@mixel cheers for the much appreciated community support apologies, I know I've still gotta look at those issues you've reported, but I should be able to get to that soon.

No prob! I assumed you're busy and it does seem like the (maybe) leaky logic thing will be a total PITA to troubleshoot, haha! I mostly have CMOhn on the backburner for a week or two to work on art contest stuff, sprites etc so there's no rush!

What surprised me most - I've kind of been waiting for "the weirdness" to hit other people's games, but.. Doesn't seem like that's happening, and it's just CMO that's freaking out. Uselessly small sample size.

[acidbottle]

Dont know if its weirdness at my end but have some small freaky goings on since the past 2 updates, actor changes not as expected for example.

Setting actor_y +1 didnt work for me sadly .. or at least in the way my block setup works (have solid and slope) along with cpu_platform for most objects, bar floating things. Have to look at things closely as was warned that using slopes for everything may be buggy ha!

[Mixel]

Originally Posted by acidbottle

Dont know if its weirdness at my end but have some small freaky goings on since the past 2 updates, actor changes not as expected for example.

Setting actor_y +1 didnt work for me sadly .. or at least in the way my block setup works (have solid and slope) along with cpu_platform for most objects, bar floating things. Have to look at things closely as was warned that using slopes for everything may be buggy ha!

It'd have to be Y+a lot more to clear a ramp block as they're really sticky..

I've noticed its much easier to knock the player through platforms lately. I have to accomodate that somehow, my previously dangerous "time has ran out skull" is a lot more terrifying when it can smash you down through the floor. XD

The actors now indeed pass through blocks with no issue, which is fantastic. Alas the issue I had been left with is that I had to change the projectile from cpu_platform and thus losing the gravity aspect ...

I think you can keep the illusion of a gravity aspect, but its confusing.. Erik shows how here..

https://eab.abime.net/showpost.php?p...postcount=1288

Now.. IDK if what that would do with sideways motion, but for up/down might be good. You can then have it switch back to a platform actor near the bottom of its jump arc.. Theoretically?

[acidbottle]

Again you were spot on Mixel, upped to +50 and it did indeed bust through the block! Looks a little janky so perhaps some cunning actor swaps may be required to smooth the look, still its a start.

Problem I have with more actor switching is that my main character has a fair few switches already, am begining to lose count!

Had a visual moment of your "time is up" skull slamming you through the floors, seems a fantastic idea and certainly would up the sense of urgency haha!

[earok]

Experimental check in for the day:

1) One bug fix for NEESO - it wasn't possible for a CPU_Platform actor to return to an idle animation state after moving. This has been fixed.

2) One bug fix for Mixel. The bug where everything went haywire after picking up a save disk was an odd one indeed, it turned out to be a bug with the code that converts codeblocks into 68K instructions. I'm baffled it hasn't shown up before now since that code hasn't been modified in quite awhile, but in any case the bug has been fixed, and codeblocks should be *slightly* faster to boot.

Still other bugs to be fixed in CMOHX, I'll look again in a few days

[domkid]

Originally Posted by Mixel

That sounds like it could work similar to how I have crouching in CMO.. I have two actors, one for ducking and one for standing..

great , it works as I wanted, thank you

[Mixel]

Originally Posted by domkid

great , it works as I wanted, thank you

No problem, just make sure that the collision box stays the same width between states or you can end up with some unwanted behaviour (falling off platforms when you duck too close to the edge, or having the ability to wall jump by crouching by walls in mid-air, hehe)

Originally Posted by earok

2) One bug fix for Mixel. The bug where everything went haywire after picking up a save disk was an odd one indeed, it turned out to be a bug with the code that converts codeblocks into 68K instructions. I'm baffled it hasn't shown up before now since that code hasn't been modified in quite awhile, but in any case the bug has been fixed, and codeblocks should be *slightly* faster to boot.

Still other bugs to be fixed in CMOHX, I'll look again in a few days

Thankyou. That was the main one really, the others are comparitively minor, i was reluctant to start poking at things too much in case I'd done something big that I'd need to rescript, so it's mostly reassuring it was some eldrich combination of things causing it to happen.

[earok]

No worries @Mixel


Experimental update for the day. A short term project has popped up where I needed animated menu option icons, and so that's done.

It works in a very similar way to "number fonts", simply lay out all of the images in your animation in a horizontal strip, and then set the anim columns and anim frame delay settings. That's it.


I may extend this feature to the Counter function (eg, instead of having "image1" and "image2", you can have an arbitrary number of counters. This would mostly be useful for Zelda type games where you have a heart icon divided up into four parts)

[Mixel]

That is a very cool feature and I'll definitely make use of it!

..

As well as the fading screen on palette change bug I have another weird one that has me perplexed..

If I punch a rat, or a slime, it takes off some of the player's health. If I get hit by a spitting pipe it takes off way more health than it should. (it's set to make frhealth = frhealth-1) - Both Rats and Slimes use the Killmonster codeblock when hit by a projectile, but there's nothing in there about hurting the player, so it's getting that from somewhere else?

I've uploaded to Git a build that sends you straight to a place where you can make it happen (there are rats, slimes and a pipe spitter on screen..) i wonder what it is specifically about cmo that is making its logic fall apart.

[earok]

Daily experimental check in

I've fixed the reported bug with rat punching and seemingly the sea level framerate issues (it looks OK at my end but not totally sure?).

Without getting into too much detail, the bug seems to relate to the "inline" codeblock function. Simply put, collision events and such were essentially linking to the codeblocks that contained the inline, rather than codeblock itself.

---

Something I've been dwelling on for a next feature, thought I'd announce it before implementing it just incase there's any particular concerns about it.

I've been thinking about tying the yield and ontimer events to the vertical-blank rather than the game's logic update - essentially, ignoring any frame skips that might only happen on slower Amiga models.

The upside is that cutscenes driven by yield commands (eg, the Bad Apple demo) would run more consistently on different models of Amiga, which may be especially important when events need to sync with music and such.

The downside is this may have unexpected consequences in normal gameplay where the gameplay is spotty - eg:

- You've got a bullet that expires in "50 frames"
- But because of the game running on a slower Amiga than it was designed for, everything is running at half speed.
- The bullet will still be deleted in about a second, so it may have only travelled half the distance it normally would.


In theory this should only be a problem when a game is being played below the game's target Amiga configuration.

[acidbottle]

hey earok, keep the updates comming

want to get some quick advice though. I have solid blocks set for the walled areas in my project. They do not, however, prevent a player from waking through them by default, perhaps as intended design. I made a code block to push the character off the wall, depending on direction faced. This works nicely with my main character.

However, I have a powerup that changes the character completely (as in shape and size) it totally ignores my solid blocks and ploughs through them! Is there something I'm missing here?

[earok]

Originally Posted by acidbottle

hey earok, keep the updates comming

want to get some quick advice though. I have solid blocks set for the walled areas in my project. They do not, however, prevent a player from waking through them by default, perhaps as intended design. I made a code block to push the character off the wall, depending on direction faced. This works nicely with my main character.

However, I have a powerup that changes the character completely (as in shape and size) it totally ignores my solid blocks and ploughs through them! Is there something I'm missing here?

Cheers

I'm not quite sure why the player can move through a solid block at all - are they flagged as slopes? I might need to take a look at your latest project files to get a sense of what the issue is and how it can be fixed.

[Mixel]

I don't think i have any issues with timings being connected to VBL.. That's probably better.. I think.. Maybe?

Thanks for those fixes, the flashing/fading sky is fixed, as well as the enemies hurting. I'm getting close to bugless now i think. I have two big bugs i need to figure out, but it's possible they're the result of me trying to fix the inline codeblock thing and making it worse. Oops. More on those shortly if I can't figure it out.

Edit: It seems like long codeblocks just don't execute a lot of stuff near the end.. It gets distracted by something else.. Eg;


In this (kind of silly, but hopefully good) example it never gets as far as line 32, it just sort of.. Doesn't happen. Screen shakes/flashes a little but it never does the dialogue or the set variable at the end. If I comment out the "inline entire codeblock"s and the final yield before line 32 then it gets though the entire codeblock successfully, but maybe not always? (it also doesn't work if I use gosubs, if that's any help)

Edit: A new bug appeared? (Wackier than most! Sorry, hehe.)
If I start the game with the Start_Tunnels1 Codeblock I appear in the correct location..
If I use the Tunnels1a teleport from the Blue Barge.. I appear in the sky above where the player is placed on the map. I don't understand this one at all. [ Show youtube player ] Oddd..

[acidbottle]

CMOHX is going to be one epic game when its done Mixel, glad you are squishing those bugs quickly!

@ earok, thank you, will bundle it up and send over by tomorrow, fair warning its not the tidiest project you will have ever seen!

The blocks I used for the wall edges are just set as solid (and invisible) but some are connected to sloped tiles on the top edges, will have another look at it later to see if some fiddling can fix it.

[earok]

@Mixel:

Bug 1, it seems the problem is snap-to-screen is being called before the camera follow is set. Change the code to something like this:

unload level
follow player
load level

It's important follow player is set before a level is loaded, otherwise the camera will be in the wrong place and if you're using snap-to-screen, it'll shove the player within the incorrectly placed camera space.


Bug 2, I think the only thing that could be interrupting yield is another yield or ontimer on the same object. If you're not already, I'd try something like this:

* Create an object JUST for that codeblock (something like handler_boss_sequence). Probably worthwhile setting recycle to never and then having "destroy_actor" as the last line of your codeblock so that it doesn't get interrupted by the actor being offscreen
* handler_boss_sequence should have that codeblock set as the Spawn event
* spawn that actor from within code


---

Experimental check in for the day. I decided against making the suggested change to yield, ontimer etc (NEESO convinced me it could be potentially problematic), I worked out a better way of handling it.


There's a new "Frame_CountDown" variable that gets subtracted by one 50x times a second regardless of performance. So you could have a loop like this:


Frame_Countdown = 50
while Frame_Countdown > 0
yield
end condition


This codeblock should take one second to get through regardless of frame skips etc.

[Mixel]

Oooh! Thankyou! Idk why but I somehow convinced myself it works like html and everything that needs to happen within the level has to happen after calling the level. D’oh!

That frame countdown sounds great! Great to have both methods available.

That boss sequence rejigging method makes a ton of sense, too.

[Lemming880]

I've upgraded to version 2021.6.0 and the fist thing I noticed was that a boss starts with half health. I cannot find out why. After testing different variables it seems there's a problem with anything between 20 and 25. My boss happens to have 25 hit points but it starts with 12. I haven't tested a later experimental version though so maybe it's fixed already?

set variable / actual variable:
...
18 = 18
19 = 19
20 = 7
21 = 8
22 = 9
23 = 10
24 = 11
25 = 12
26 = 26
27 = 27
...