This content may be freely modified and/or maintained by anyone.
Status
Not open for further replies.
Ah, I see the problem. I forgot that doing a proper exit resets all of the movement vars to normal itself, so the code intended to remove that flag never runs. This can be fixed by adding the following between lines 66 and 67:

Code:
player.pflags = $1&~PF_FORCESTRAFE

It was a simple lack of testing on my part, mostly because I don't use turn keys lololo

I'll add it to the base download once I figure out a good way to fix that other issue where Knuckles glides weirdly in analog mode, and maybe add a few other tweaks too, but for now, making that manual edit will fix that issue.
 
This worked, but I have another very strange problem: When going into Axis2D, a thing (type 800, GFZ flower) spawns in one random point of the map, always the same one to be exact. It doesn't show up in the editor and it is only visible while in the game. It also doesn't show up when I bypass the Axis2D trigger by noclipping, so Axis2D probably has got to do something with it.
 
That's probably because I used that object type as the camera. The code for handling cameras probably needs some major tweaking, not only to make sure they stay hidden but also so that the script works with cut-away views. It'll come once I update the script again.
 
Red, I'm really impressed how you made this lua! I wish I could make maps, maybe even with this lua, but I have a Windows 7, and I can't use the level editor. Still, great lua! Same for Clock Towers Zone by the way (Well, I used Version 2 as normal made the game crash).
 
I think it's broken. The same issue happens in the example wad included with Axis2D. Well, it's broken in a compiled version of the "gl-slopes" branch of the game, at least. I'm pretty sure it still works correctly in the released 2.1.14, though.
 
Last edited:
Stop right there, this is a release for 2.1.14 (or whatever the latest public release was by the last changes) in the first place you must remember.
I know that, but it's broken in the development versions, which is a huge shame when considering how amazing Axis2D is.
And besides that, the broken-ness seems really strange (see the video I linked to in the first sentence), and may be something worthwhile looking into (whether it be in the game's code or the Lua's code), as something seems seriously wrong.
...Although I may have worded it wrongly during the start of the post. My bad.
 
It's broken because development versions changed how Lua gets angles by bitshifting them down by 16. Most of the things I write abuse the fact that angles used to take the entire int range, which meant that 5 - 350 == 15. Since they don't in development builds, now 5 - 350 == -345, which throws off most of the angle comparisons I use in things like Axis2D.

It's not a bug with the script, and it's not a bug with the game. It's a change in the game that the script wasn't designed to handle. I'm not going to try to fix it at least until 2.2 comes out because I don't feel like chasing an unstable API.
 
So, am I right in that this (successfully) attempts to re-create SRB2's vanilla 2D mode in all dimensions? If so, there's something I feel is missing, and would appreciate seeing added.
In vanilla 2D, pressing down (player.cmd.forwardmove < -20)* makes you spin if you move fast enough (player.speed > FixedMul(5*FRACUNIT, player.mo.scale) ), however this doesn't seem to be the case for Axis2D.

Relevant SRB2 source code, at line 3771 of p_user.c (in the current "master" branch of the game):
Code:
    // If not moving up or down, and travelling faster than a speed of four while not holding
    // down the spin button and not spinning.
    // AKA Just go into a spin on the ground, you idiot. ;)
    else if ((cmd->buttons & BT_USE || ((twodlevel || (player->mo->flags2 & MF2_TWOD)) && cmd->forwardmove < -20))
        && !player->climbing && !player->mo->momz && onground && (player->speed > FixedMul(5<<FRACBITS, player->mo->scale)
#ifdef ESLOPE
        || (player->mo->standingslope && abs(player->mo->standingslope->zdelta) >= FRACUNIT/2)
#endif
        ) && !(player->pflags & PF_USEDOWN) && !(player->pflags & PF_SPINNING))
    {
        player->pflags |= PF_SPINNING;
        P_SetPlayerMobjState(player->mo, S_PLAY_ATK1);
        if (!player->spectator)
            S_StartSound(player->mo, sfx_spin);
        player->pflags |= PF_USEDOWN;
    }
* It's somewhat important to have it at "< -20" rather than "< 0", for the few people who use gamepads with analog sticks to play.
 
That function's worth consideration, but I think I'm going to leave it out mainly for this reason:

https://gfycat.com/CrispUncommonEmperorpenguin

These kinds of flips are fairly common in Clock Towers, and I'd hope they'll be fairly common in other Axis2D levels (they look really cool! especially once I release the update I've been working on that makes them nicer to control). It's not a stretch to picture someone following the turning radius with their inputs, particularly on an analog stick, and a down input getting registered as a spin in that case would be inconvenient. I don't want to try to special-case that because then you'd be dealing with down only working some of the time and being really inconsistent. (And besides, pressing the spin button yourself is ez)
 
Can you please elaborate on how they will be nicer to control? Because sadly I found them to be one of the most infuriating parts of that zone...
 
I found them to be one of the most infuriating parts of that zone...
Agreed. I quite hated these as well. They control terribly. I would be fully in support of removing all of them and allowing down for roll.
 
Last edited:
I'd bet your update is already on this track, but here's something you may have never noticed in S3&K: when you're running on the ceiling, your controls are flipped! The right button sends you left and the left button sends you right. In fact you might want to generalize it as right sends you counterclockwise and left sends you clockwise. This makes loops and things like this play seamlessly because you can just hold one direction to go "forward". (aside: this is also the reason these things suck) The game even hides the transition back to regular control orientation by temporarily ignoring all horizontal input when you fall off a wall or ceiling.

Obviously this isn't the same thing, because it's not like you're in a temporarily different orientation, but it's food for thought. Maybe left can continue sending you forward until the player lets go? Though the problem with that is a player might try to halt by pressing the opposite direction... and suddenly they keep moving forward instead of stopping.
 
Agreed. I quite hated these as well. They control terribly. I would be fully in support of removing all of them and allowing down for roll.
Well, what if what Red has planned is making so instead of pressing left or right depending on whether you're facing just 1 degree left or right or so, pressing backwards will pull you "towards" the screen and forwards the opposite? That would be a nice way to make them much better to control, and a very valid reasoning for not having down-spin.
 
Obviously this isn't the same thing, because it's not like you're in a temporarily different orientation, but it's food for thought. Maybe left can continue sending you forward until the player lets go? Though the problem with that is a player might try to halt by pressing the opposite direction... and suddenly they keep moving forward instead of stopping.
Actually, that was exactly what I did!
 
Can anyone help? I can't get this to work. I've even tried emulating the tags and range the axis is away from the player, but it didnt do a thing.
 
Can anyone help? I can't get this to work. I've even tried emulating the tags and range the axis is away from the player, but it didnt do a thing.
I'm having the same problem. I've set the axis and things up just as the example has them, but still nothing is working. Will someone please give advice?
 
Status
Not open for further replies.

Who is viewing this thread (Total: 1, Members: 0, Guests: 1)

Back
Top