Addition of the SF_KARTLESS flag to S_SKIN lumps in character WADs to prevent kart & related gibs from spawning upon death
- May 19, 2024
-
-
Jack authored
added KARTLESS to the definition of the GETFLAG macro. This macro is used nowhere and so I'm pretty sure serves literally no purpose, but best to be prudent and proper and follow along with the rest of the flags.
-
Jack authored
Bandaid-removed the 'poof' on the ground of the kart landing even when supposedly kartless by making the kart have no gravity or momentum when kartless and therefore never landing, I feel like there's probably a render flag to do this, but all the same is it really a workaround to say that a kartless kart instance shouldn't need any motion? Also, I turned a lot of my kartless checks into ternary operators and removed the curly brackets from some one-line if statements, though I stopped myself after a little bit to not step on any toes.
-
Jack authored
-
Jack authored
It would seem as though removing only the MF_NOCLIP bit from flags and not also the MF_NOCLIPTHING bit (whatever that does) solves the problem of the kart drifting away in a cloud of white smoke. Pretty close to merge requesting here! : D
-
Jack authored
The SF_KARTLESS version of the kart moving with some random smoke effect seems to be directly correlated with the decision to KEEP the kNoClipFlags if the kart is an SF_KARTLESS (AKA MFE_KARTLESS). Making the decision to keep the collision re-enabling regardless of SF_KARTLESS fixed the issue entirely, however now of course the player can bump into something that isn't there. Getting close to figuring this out I hope!
-
Jack authored
From some more printing, I have determined that the smoke that appears when an SF_KARTLESS player explodes is NOT the same kind of smoke that gets disabled in fire(). The kind of smoke being disabled in fire() is indeed being disabled as I wanted, however that's the black soot sort of smoke and not the white bellowing sort of smoke that an SF_KARTLESS player produces. Additionally, whilst both an SF_KARTLESS player and everyone else WILL have the kart move after it has exploded, the former moves at a far greater rate than the latter, perhaps due to the state? not sure.
-
Jack authored
I added in a new flag to mobjeflag_t after changing the eflags data type from UINT16 to UINT32, I have no idea the repercussions of this but from skimming the entire codebase for the eflags variable it seems that nothing beyond getting/setting individual bits is being done so there's no reason to not expand the data type beyond losing maybe a byte or two of memory for every mobj. Anyway, by doing this I'm now able to cache the state of SF_KARTLESS and make the particles work even after an SF_KARTLESS player respawns.
-
Jack authored
Shifting around some console print lines has proven to me that isKartless is returning the wrong value past the immediate moment the player respawns because player() becomes a stale reference to the destroyed kart at that point, player() is set upon spawn() then never changed. Will continue to investigate options here, might be fine to just refresh the reference with some sort of listener?
-
Jack authored
I was wrong about fire() in the last commit, it IS being executed for the entire duration of the burning particle animation, it's just that the condition under which I was printing in the last commit fails immediately after the player starts to respawn for SOME reason. I don't know why this is, but this DID make me realize that if a player were to change skins in the long time between the kart exploding and the particle effect stopping (at least like a dozen seconds), then the kart would wrongly assume to un-kartless the particle animation since the check for kartless is performed every frame alongside the fire() execution. My first obvious idea to fix this was to cache the kartless value upon spawn(), however caching values for a Mobj isn't as simple as adding it to a class like Kart in the destroyed-kart.cpp file, it's got to be added as a variable to mobj_t inside of p_mobj.h presumably for networking purposes. I was going along just fine adding an 'extravalue3' to the already existing 'extravalue1' and 'extravalue2' variables, however THEN I realized that some enum called mobj_diff2_t needs definitions like MD_EXTVAL1 and MD_EXTVAL2 for bitwise operations and the upper limit to the entires for that enum to function as a set of values for bitwise operations is 32 entries which has already been reached. TL;DR I was wrong about fire() not executing every frame of the particle animation until the animation is over, however now I need to cache the state of SF_KARTLESS with nowhere to put it in mobj_t due to bitwise operation limitations I'm certainly not ready to be the person to solve. What can I do? not too sure.
-
Jack authored
Firstly, the issue with characters not animating when exploding from their kart seemingly happens even when I roll back before this branch began (or rather, roll back to the commit that this branch is based on), so I'm going to assume that's not my problem thankfully. Secondly, I thought I could disable most of the particle effects I didn't want with the check provided in this commit, however the method that I've applied the check to only seems to occur during the launch and not during the kart left behind thereafter, so I must be completely wrong on what I thought this method did despite little doubt otherwise.
-
Jack authored
I didn't want to have to make a whole new state for an invisible leftover kart that is identical to S_INVISIBLE, but checks in destroyed-kart.cpp for S_INVISIBLE lead me to eblieve this is the least destructive option. My only other idea was to add a new extravalue to p_mobj.h::mobj_t, but I'm concerned that modifying such a core struct could have huge impacts across the project were I to misunderstand even a little bit if modifying the parameters of the struct messes with, most notably, networking and sending packets. If I do some more investigation and find out its fine to add a new extravalue, then that'd work better. More importantly, I realized that the issue of non SF_KARTLESS skins not animating the player jumping out of the kart upon destruction goes back beyond the last commit which is concerning, so I'm making this commit and locally rolling back to find out where the problem began.
-
Jack authored
Presumably due to the age of the codebase combined with my extreme ignorance, whilst it is totally a no-op to remove the S_INVISIBLE check as prints from this commit will provde, for some reason removing that condition makes it so that ONLY S_SKINs without SF_KARTLESS set will no longer have the character animate when blasting from the kart husk. I don't know how or why, but I guess I'll put it back the way it was.
-
Jack authored
Hey so good news: I was going to make it less scuffed by making a whole new MT_ that actually has its thinker integrated into other loops in the software (which is where I went wrong with that idea a few commits ago), but turns out that the destroyed kart is already in the perfect state to remain hidden before destroy() is called, so all I have to do is NOT change the state. However, now the only issue left is that because the mobj is supposed to act like a destroyed kart, after the destroyed kart is supposed to visibly appear to the player the kart not only rolls away a bit (for no reason when invisible of course) but also it has kart sparks and smoke bellowing that should be hidden. Once these two issues of movement and particles are cleared up, I think a bit of reorganization is all I'll need to feel okay with submitting a merge request.
-
Jack authored
Got the concept of the branch KIND OF working, but it is incredibly scuffed and I'm not leaving it in this state for the merge request lest I do no merge request at all. I have an idea to do this slightly less scuffed, so we'll see.
-
Jack authored
I had the idea to spawn the destroyed kart as an MT_RAY rather than an MT_KART_LEFTOVER to make it a dummy entity for the particles to spawn off of, however it seems spawning as anything but the latter breaks the effect entirely. As such, this commit is merely here to help inform me as I continue to research.
-
Jack authored
Got the gibs to stop spawning and made the destroyed kart invisible on the condition of the SF_KARTLESS bit being set in S_SKIN in addition to just setting up the whole build process for this repo, however my inexperience has lead me to realize that simply setting the kart's sprite to nothing does not remove its collision or presence in the world as I should have guessed, so I'm using this commit as a baby step to roll back to in an effort to stop the kart from ever even spawning in the first place when SF_KARTLESS is set
-