FrozenMuncher's P-Switch Pack

[FrozenMuncher]

FrozenMuncher's P-Switch Pack (V1.1)

Introduction
This is my small pack to implement a few P-Switch related functions into SMBX2. It consists of 4 major components: a P-Switch replica, a blue P-Coin, a P-Door and a "Warp Fix".

The P-Switch
This is a replica of the vanilla P-Switch with an extra setting: It can be reusable! Once the P-event has ended the switch will pop
up again to be used once more!

The P-Coin
A simple coin that only appears when a P-Switch is active. It's a coin replica, however doesn't use the
coin AI as it would turn into blocks otherwise.

The P-Door
This door is toggled by a P-Switch. Both the default active door and default inactive door can be used.
If you use the Warp Fix script (which is recommended) you can simply place the door and an entrance. The
outline will not be enterable, but the door will be! No need for layer shenanigans.

The Warp Fix
WarpFix is a script you can load into your luna.lua file. This script prevents the player from entering doors
and pipes under certain conditions. For doors the player both needs to stand on ground (unless underwater) and
be infront of a valid door BGO (all vanilla doors are allowed aswell as the active P-Door). For horizontal pipes
the player has to stand on ground to enter them (unless underwater), and vertical pipes can, as usual, always be
entered.

Previews

Spoiler: show

Reusable P-Switch and P-Coins


P-Door


Warp Fix

Download (V1.1)


Changelog

Spoiler: show

V1.0 - Release
V1.1 - Bugfix in warpFix.lua

Credits
Me (FrozenMuncher)
Bulby_VR (noFloatingDoors) (thanks for correcting me lol)
Sprites ripped by RandomTalkingBush

Please give credit!

[Marioman2007]

Really cool stuff!
Though I noticed an error in the credits, noFloatingDoors.lua is made by Bulby_VR.

[Just_Thomas]

Awesome, I remember when Emral linked me to "noFloatingDoors" and even through it had some flaws, I was already happy.
I will definitely try out your work and will very likely upgrade.

BTW: Just an idea - would you consider upgrading your npc-751 with something like that?


Considering you know SMM(2) I think you know what I mean.

So, further options under "P-Switch Settings"?
"Upside down?" [as checkbox]
(Tooltip: Usually "placed" under the ceiling and can be activated from below but not taken or swallowed by yoshi)
This version would use "nogravity" or something like that I think

"Glued at block or ceiling?" [as checkbox]
(Tooltip: In combination of "Upside down": If checked, the P-switch will always stay on it`s position even if the ceiling is no more, otherwise it will fall down)

"Can not be taken" [as checkbox]
(Tooltip: Only possible if "Upside down" is NOT used. Refers to exactly THIS p-switch here, but not all of them, otherwise check the "NPC Config" on the wiki)

"Cool down timer" [default: 0.0]
(Tooltip: independent from the p-switch timer, this value defines when THIS p-switch is useable again)

"Cool down timer dependent from p-switch timer?" [as checkbox]
(Tooltip: If checked, the cool down value gets added to the p-switch timer on top, otherwise it will start from the moment the p-switch is active)

I have not tested the "warpfix" with water yet. Does it also work if the water level is lowered or rised, would it be updated, the moment the water is on the correct level or something among these lines? - ok it DOES work

Anyway: Just ideas, hints, thoughts, wishes, requests... the usual stuff
Also could you somehow change the priority of the npc, so it does not get displayed before the player?



Edit:
This is also selfish very likely, but would you consider adding the silver p-switch from SMW as well? Yes, it is already done ... but some of the features included were not working
viewtopic.php?t=25669
also author: "Last active: Thu Mar 24, 2022 7:19 pm"
Given your package is called "P-Switch Pack" I thought it would kinda fit.

Ok, or "gray p-switch":
Anyway, even the original in SMW has bugs as it seems:

https://www.mariowiki.com/Gray_P_Switch:
Due to a glitch, Gray P Switches act like normal P Switches after being taken through a pipe, though they retain their gray coloration.

Anyway, please keep in mind, it is your project and these are just wishes and requests.

Edit 2:
The door warp - here marked with 2 - always works and not only with p-switch active (yes, "local warpFix = require("warpFix")" is active)

[mariobrigade2018]

1.3 P-switch, your time has come.

But in all seriousness, could a developer check this out and see if this can be put in basegame?

[Just_Thomas]

1.3 P-switch, your time has come.

But in all seriousness, could a developer check this out and see if this can be put in basegame?

The developers always take a good look at what additional content is released here and are guaranteed to be thinking in a huge and poorly lit room about who will be given the honor of porting his or her content into the base game.

I don`t think it will be added. Very likely the same reason the Extended Koopas were not added (forgot who told me TBH), compatibility I bet with (other/older) episodes.

[mariobrigade2018]

1.3 P-switch, your time has come.

But in all seriousness, could a developer check this out and see if this can be put in basegame?

The developers always take a good look at what additional content is released here and are guaranteed to be thinking in a huge and poorly lit room about who will be given the honor of porting his or her content into the base game.

I was just talking about the P-switch and maybe the other stuff in the pack. Not the noFloatingDoors library. That would break every 1.3 and most X2 levels.

I don`t think it will be added. Very likely the same reason the Extended Koopas were not added (forgot who told me TBH), compatibility I bet with (other/older) episodes.

I said that.

[Just_Thomas]

1.3 P-switch, your time has come.

But in all seriousness, could a developer check this out and see if this can be put in basegame?

The developers always take a good look at what additional content is released here and are guaranteed to be thinking in a huge and poorly lit room about who will be given the honor of porting his or her content into the base game.

I was just talking about the P-switch and maybe the other stuff in the pack. Not the noFloatingDoors library. That would break every 1.3 and most X2 levels.

I don`t think it will be added. Very likely the same reason the Extended Koopas were not added (forgot who told me TBH), compatibility I bet with (other/older) episodes.

I said that.

1. I did not mean the floatingdoors thing either (even through I do not quite get it, why it can not be included as an extra option in the warp settings hmm).
I bet the way THIS p-switch is coded might cause problems in other episodes. Might,.... as I do not really know at all.
2. OIS.

[FrozenMuncher]

I bet the way THIS p-switch is coded might cause problems in other episodes. Might,.... as I do not really know at all.

The P-Switch has basically the same code as the X2 color switches, only with the option to be reused. Currently that means it spawns a new pressed P-Switch NPC. It should be compatible to replace the usual P-Switch, though I'm not exactly sure how it was implemented and if it behaves wildly different in some cases, as the standard P-Switch seems to use a different AI.

I'm currently working on a custom switch AI with all those settings (and some more) that will make it easy to add custom switches with custom functions. When it's finished I'll be posting it with the new P-Switch (and a silver P-Switch, thanks for the idea!) implemented.
I also fixed the bug with the door. It wasn't actually a problem with the water, but the fact that the P-Door was directly next to the warp. I also discovered you could duck-jump into horizontal pipes and enter, even if there was no ground directly under it, so that's patched as well.

The goal would be to be able to replace the current switch ai with this more versatile version, and that the behaviour of the current switches is equal to that of the new switches on standard settings.

[mariobrigade2018]

1. I did not mean the floatingdoors thing either (even through I do not quite get it, why it can not be included as an extra option in the warp settings hmm).
I bet the way THIS p-switch is coded might cause problems in other episodes. Might,.... as I do not really know at all.
2. OIS.

1. What I was referring to was this: the developers would deprecate the 1.3 P-switch and add this one, similar to what happened to the pow-block.

2. Hi again.

[Just_Thomas]

1. I did not mean the floatingdoors thing either (even through I do not quite get it, why it can not be included as an extra option in the warp settings hmm).
I bet the way THIS p-switch is coded might cause problems in other episodes. Might,.... as I do not really know at all.
2. OIS.

1. What I was referring to was this: the developers would deprecate the 1.3 P-switch and add this one, similar to what happened to the pow-block.

2. Hi again.

Aah, now I know what you mean. I misunderstood that, I thought npc-32 was supposed to be replaced directly by the code.
Yes, you can't really go wrong if you do it the way you recommend.

I bet the way THIS p-switch is coded might cause problems in other episodes. Might,.... as I do not really know at all.

The P-Switch has basically the same code as the X2 color switches, only with the option to be reused. Currently that means it spawns a new pressed P-Switch NPC. It should be compatible to replace the usual P-Switch, though I'm not exactly sure how it was implemented and if it behaves wildly different in some cases, as the standard P-Switch seems to use a different AI.

I'm currently working on a custom switch AI with all those settings (and some more) that will make it easy to add custom switches with custom functions. When it's finished I'll be posting it with the new P-Switch (and a silver P-Switch, thanks for the idea!) implemented.
I also fixed the bug with the door. It wasn't actually a problem with the water, but the fact that the P-Door was directly next to the warp. I also discovered you could duck-jump into horizontal pipes and enter, even if there was no ground directly under it, so that's patched as well.

The goal would be to be able to replace the current switch ai with this more versatile version, and that the behaviour of the current switches is equal to that of the new switches on standard settings.

Sounds amazing (I feel like I say that way too often through). Glad my ideas were not a nuisance for you.

[Jumper]

It's great seeing SMBX2 is slowly becoming more and more accurate to their original games (Chucks in SMW, Chain Chomps in SMB3, etc.), even if it's not included in the basegame.

This would definitely be useful for some of my projects I'm working on.

I'm currently working on a custom switch AI with all those settings (and some more) that will make it easy to add custom switches with custom functions. When it's finished I'll be posting it with the new P-Switch (and a silver P-Switch, thanks for the idea!) implemented.

Can't wait.

Could this also be used to create something like a ?-Switch, as an example?


Either way, I wish you the best of luck.

Edit: Link not working; meant to link to the Mario Wiki entry for the aforementioned switch.

[FrozenMuncher]

Could this also be used to create something like a ?-Switch, as an example?

Yeah that's the plan. Currently it will contain a premade P-Switch, Silver P-Switch, a ?-Switch where you can enter an event name to trigger it and a !-Switch which turns on some red blocks. And I plan it to be easy to add switches with custom functions, where you just need to write the "press"-function to have custom behaviour.

[Just_Thomas]

Could this also be used to create something like a ?-Switch, as an example?

While a ?-Switch has been done already
viewtopic.php?t=27285
(https://docs.google.com/spreadsheets/d/ ... 1014877093)
this one has the disadvantage that you can only place the switch within a map, but not put it in a block for example. At least back then I could only find the settings within a placed ?-switch. And anything in a block only uses default settings.

Could this also be used to create something like a ?-Switch, as an example?

Yeah that's the plan. Currently it will contain a premade P-Switch, Silver P-Switch, a ?-Switch where you can enter an event name to trigger it and a !-Switch which turns on some red blocks. And I plan it to be easy to add switches with custom functions, where you just need to write the "press"-function to have custom behaviour.

Do you use the function onNPCCollect? I do not know how to use it correctly. Most of the time I don't understand the syntax and I definitely need a real application example. However anything releated to math or calculations "kills" my brain anyway ... *caught*
This is how I understand it: Let's assume that a level has 3 different events (e.g. water rising, water lowering, all doors open at once etc.) that can be switched with ?-switches. But all these ?-switches are placed in blocks [and appear like a powerup} and not just anywhere in the level on the ground. You would then basically need three different ?-switches NPCs (e.g NPC-751, NPC-752, NPC-753 < all ?-Switches), each with its own fixed assigned event as a default setting, right?

[Jumper]

Could this also be used to create something like a ?-Switch, as an example?

Yeah that's the plan. Currently it will contain a premade P-Switch, Silver P-Switch, a ?-Switch where you can enter an event name to trigger it and a !-Switch which turns on some red blocks. And I plan it to be easy to add switches with custom functions, where you just need to write the "press"-function to have custom behaviour.

Okay, that's good to know.
Thanks for answering, and again I wish you good luck.

Could this also be used to create something like a ?-Switch, as an example?

While a ?-Switch has been done already
viewtopic.php?t=27285
(https://docs.google.com/spreadsheets/d/ ... 1014877093)
this one has the disadvantage that you can only place the switch within a map, but not put it in a block for example. At least back then I could only find the settings within a placed ?-switch. And anything in a block only uses default settings.

Thanks for the correction, I didn't realize this already existed until after I sent that post; I was just using it as an example to get a good idea of how the AI could work.

[Just_Thomas]

I have an other idea left for a P-Switch.
The idea has been pretty much realized already by deice (actually only happened because the YI blocks did not work properly with the P-Switch, so this happened before beta 5)
To put it simple: Only special blocks should be affected, so a p-switch without turning coins into blocks or blocks into coins.
This fellow would therefore act completely independently.
Maybe you can take the following code as base? The trigger would be a NON p-switch.

Code: Select all

--------------------------------------------------
-- Fix provided by: deice
-- Source: https://www.smbxgame.com/forums/viewtopic.php?t=28729
--------------------------------------------------

local pswitchable = {}
local blockutils = require("blocks/blockutils")

local sets = {}
local registeredIDs = {}

local psState = false

function pswitchable.registerSet(id1, id2)
    if registeredIDs[id1] or registeredIDs[id2] then return end
    table.insert(sets, {id1, id2})
    registeredIDs[id1] = true
    registeredIDs[id2] = true
end

function pswitchable.onEventDirect(obj, eventName)
    if (eventName == "P Switch - Start" and not psState) or (eventName == "P Switch - End" and psState) then
        if(eventName == "P Switch - Start") then
	    psState = true
        else
	    psState = false
	end
	
        for k,v in ipairs(sets) do
            blockutils.queueSwitch(v[1], v[2])
        end
    end
end

function pswitchable.onInitAPI()
    registerEvent(pswitchable, "onEventDirect")
end

return pswitchable

Code: Select all

local blockmanager = require("blockmanager")
local pswitch = require("pswitchableDeice")

local blockID = BLOCK_ID

local block = {}

blockmanager.setBlockSettings({
	id = blockID,
	frames = 1
})

pswitch.registerSet(blockID, blockID + 1)

return block

Code: Select all

local blockmanager = require("blockmanager")
local pswitch = require("pswitchableDeice")

local blockID = BLOCK_ID

local block = {}

blockmanager.setBlockSettings({
	id = blockID,
	frames = 1
})

pswitch.registerSet(blockID, blockID - 1)

return block