Having an issue with Capechase layering, and other misc subjects.

Status
Not open for further replies.

frozenLake

Member
So, I'm trying to make a little wad that places a copy of sonics shoes over him, (for color changing purposes), and I can't seem to be able to get it to work right, as the sprite refuses to display over the player whatever I do. Here is the pastebin to my code, in hopes that someone can help. Do mind the failed attempts in the comments. http://pastebin.com/VTDY5YX3
 
Last edited:
*S_SHOE_STND was miswritten as S_SHOE_STN in the FREESLOT block.

*You'll need to list DISPOFFSET = 1 as one of MT_ColorShoe's object properties if you want it to display in front of the player sprite at all times.

P_InstaThrust(player.mo.shoe, R_PointToAngle(player.mo.x, player.mo.y), 10000, player.mo.shoe)
*What's all this? If you want the shoes to follow the player at all times, just use P_TeleportMove to teleport them to the player's exact location every tic instead of messing around with P_InstaThrust.

player.mo.shoe.frame = player.mo.frame
*I'm not sure what this is here for, but you probably don't need it.

P_SetMobjStateNF(player.mo.hat, S_SHOE_STND)
*player.mo.hat isn't defined in your code. Instead, you should be using player.mo.shoe, which refers to the shoe object.
 
*I'm not sure what this is here for, but you probably don't need it.
I'm pretty sure what that is there for, and he definitely needs it. Unless he, like, wants the shoe to always be in the standing frame, regardless of the player's actual frame.

*You'll need to list DISPOFFSET = 1 as one of MT_ColorShoe's object properties if you want it to display in front of the player sprite at all times.
As far as I've heard, that doesn't work in OpenGL. You may want to add that. If I'm correct, Shields use the A_CapeChase action to stay slightly in front of the player relative to camera angle in OpenGL.


Anyway, why are there two ThinkFrame hooks? One MobjThinker hook would not only suffice, but also cause far less lag in large maps (as far as I've heard) (make sure to add a line of ", MT_PLAYER" at the end before the closing bracket). And why do you have both ObjectCfg and Lua freeslots for MT_COLORSHOE and S_SHOE_STND? (Well, if you fix the typo of STND in ObjectCfg, that is.)
 
I'm proud to say that Software mode support is working like a charm! (opengl is not supported ktnxbye) However, I still have a few bugs that I need to iron out, as can be seen in the gif linked here.

http://www.gfycat.com/PortlySaltyBull

Anyway, I have reuploaded my code to the pastebin here, so if anyone can spot what is going wrong, that would be good. http://pastebin.com/rbxc0qJj

(in all honesty, fixing the opengl bug would be nice too.)
 
Well, I know the custom Gravity Shield looks perfectly fine in OpenGL. You may want to take a look at what it does. (Though I don't remember whether the shield itself works or not in 2.1.9/2.1.10.)

Anyway, what is wrong is that you don't "reset" the shoe colour if no longer in Fire/FireFlower mode. Or what are the "few bugs"?
 
Well, presently the few bugs I see is that the shoes do not flash with the rest of the sprite when damaged, and the issue with me resetting the color is that the server variable causes the /entire thing to vanish/ when I attempt to implement it, which seems rather major. Also, uncommenting the area involving the check to see if you are using sonic causes a glitch where it prevents the shoes from animating. I suppose I'll look at the gravity shield though.

Edit: Update on the front of examining the gravity shield: I can't really find anything that seems to cause it.
Edit 2: After /actually/ using the gravity shield, I have discovered that it does not seem to overlay in opengl as well.

Edit the Third: I managed to fix the sprite switching to null! Now, just gotta find out a way to fix the secondcolor console variable, the flashing bug, and possibly the bug with OpenGL and this may get to the point of being releasable! New version of the pastebin, as always. http://pastebin.com/0gqBUYQV
 
Last edited:
Well, presently the few bugs I see is that the shoes do not flash with the rest of the sprite when damaged,
...Oh. Damn, I forgot firstly if it's the frame, the sprite, or the object that is invisible during such circumstances, and as a result also secondly how to check for it as well as thirdly apply it on something else.

and the issue with me resetting the color is that the server variable causes the /entire thing to vanish/ when I attempt to implement it, which seems rather major. Also, uncommenting the area involving the check to see if you are using sonic causes a glitch where it prevents the shoes from animating. I suppose I'll look at the gravity shield though.
...You don't have to reset something to a variable. You can reset it to a constant, like SKINCOLOR_RED or something.

Edit 2: After /actually/ using the gravity shield, I have discovered that it does not seem to overlay in opengl as well.
Hm. Well, it did work in 2.1.8, at least.

Edit the Third: I managed to fix the sprite switching to null! Now, just gotta find out a way to fix the secondcolor console variable, the flashing bug, and possibly the bug with OpenGL and this may get to the point of being releasable! New version of the pastebin, as always. http://pastebin.com/0gqBUYQV
I think I know exactly how to make the secondcolor console command work (you're better off using a console command and setting player.secondcolor with it than using a console variable, especially when it comes to netplay, I think), I just can't format it in English nor Lua (at least not without probably days of testing). Just remember, the SKINCOLOR_RED string (stuff with quotes around) is not the same as the SKINCOLOR_RED constant (stuff without quotes around), and console stuff returns either strings or numbers, I believe.
 
I'm pretty sure what that is there for, and he definitely needs it. Unless he, like, wants the shoe to always be in the standing frame, regardless of the player's actual frame.
An object's frame property is not the same as its state. As I said, I don't know what frame is, but it's pointless to use it. If Nomekop wants the shoe object to change its appearance based on the player's state while leaving the rest of the player's sprite visible beneath it, he'll have to create a separate set of sprites and states for all of Sonic's animations, but with everything except the shoes being transparent, and then change player.mo.shoe.state based on the value of player.mo.state. (That is, unless there's some Lua function that magically does all of that automatically, and I somehow haven't encountered it until now.)
 
An object's frame property is not the same as its state. As I said, I don't know what frame is, but it's pointless to use it. If Nomekop wants the shoe object to change its appearance based on the player's state while leaving the rest of the player's sprite visible beneath it, he'll have to create a separate set of sprites and states for all of Sonic's animations, but with everything except the shoes being transparent, and then change player.mo.shoe.state based on the value of player.mo.state. (That is, unless there's some Lua function that magically does all of that automatically, and I somehow haven't encountered it until now.)
That's true, but an object's frame property is its current frame. When an object changes state, the frame of the object gets changed to whatever is in the state definition. Setting the frame to the same as the player object is far far far more convenient and easier than setting if!player.shoe.state==(player.mo.state+S_PLAY_STND-S_SHOE_STND) player.shoe.state=player.mo.state+(S_PLAY_STND-S_SHOE_STND) end or something, while also defining each and every state of the vanilla player, but with the shoe sprite. Also, doing it that way will probably break the hook if used on (not-necessarily-)custom characters with custom states. Changing the frame property simply changes the rendered frame of the object.

TL;DR: Changing the frame works.
 
That's true, but an object's frame property is its current frame. When an object changes state, the frame of the object gets changed to whatever is in the state definition. Setting the frame to the same as the player object is far far far more convenient and easier than setting if!player.shoe.state==(player.mo.state+S_PLAY_STND-S_SHOE_STND) player.shoe.state=player.mo.state+(S_PLAY_STND-S_SHOE_STND) end or something, while also defining each and every state of the vanilla player, but with the shoe sprite. Also, doing it that way will probably break the hook if used on (not-necessarily-)custom characters with custom states. Changing the frame property simply changes the rendered frame of the object.

TL;DR: Changing the frame works.

You could've just called it "the state's subsprite" and be done with it.
 
Status
Not open for further replies.

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

Back
Top