*** The "ask a miscellaneous editing question" thread ***

GZDoom devbuilds can be found here and here.

Thank you! I'll be trying it out shortly. It's not a big deal by any means, seeing as I'm using GZDoom-GPL, but still.

Agentbromsnor said:

Question: how well implemented is the GetPlayerInput DECORATE function in GZDoom? Everything worked fine before, but for some reason it just now starts to crash upon start-up if I try to run my map from GZDoom Builder (after a fresh update, I should mention).

The start-up console very briefly reads "Script error: platformgame.pk3: DECORATE line 20. Call to unknown function 'GetPlayerInput'". I have to keep pressing the play button in GZDoom Builder because it keeps crashing before I have the chance to read it.

My game still runs fine from my custom GZDoom-GPL shortcut though.

I cant tell you why you cant in GZDoom Builder but you could try running it in DoomBuilder2 & since ive never seen DB2 crash unless I tried to edit sectors in "Make Sector Mode" OR try to put in over exactly 65,535 line defs; then I would say you got a pretty good chance of being able to open it in DB2.

How do you control which texture you get when using the Action 20 to raise the floor and change texture. It seems to be changing to the one on the floor near the switch.

rileymartin said:

How do you control which texture you get when using the Action 20 to raise the floor and change texture. It seems to be changing to the one on the floor near the switch.

That's exactly what it does; the one directly in front of the linedef's facing, to be exact. I'll usually go with little triangle sectors to house this effect. If it's something in the playable map area, making the triangle 1 pixel-long is a nice way to hide that a different flat is sitting there.

Kappes Buur said:
You have to construct a second control sector, giving the sector height to which to slope to, beside the real control sector which has to match the game sector alignment.

I still dont understand how to make a floating 3D floor ramp that you can also walk under AND walk on. I tried what I thought you meant in that description & it totally fucked me on the deal.

The dummy sector needs to be positioned so that the slope's plane will be exactly aligned with the intended slope plane of the intended 3D floor in the map. In other words, imagine that the dummy sector's sloped plane extends to an infinite horizontal area, and becomes visible and touchable only in the tagged sector where you want the 3D floor to be. The 3D floor's plane will indeed be at the very height where it would be if the dummy sector's plane extended infinitely - that is, it may be at the same absolute height as the dummy sector, or at a lower absolute height, or at a higher absolute height, depending on where the dummy sector is positioned relatively to the target sector inside the map.

If this is hard to understand, just check out some tutorials on making 3D floors.

scifista42 said:

The dummy sector needs to be positioned so that the slope's plane will be exactly aligned with the intended slope plane of the intended 3D floor in the map. In other words, imagine that the dummy sector's sloped plane extends to an infinite horizontal area, and becomes visible and touchable only in the tagged sector where you want the 3D floor to be. The 3D floor's plane will indeed be at the very height where it would be if the dummy sector's plane extended infinitely - that is, it may be at the same absolute height as the dummy sector, or at a lower absolute height, or at a higher absolute height, depending on where the dummy sector is positioned relatively to the target sector inside the map.

If this is hard to understand, just check out some tutorials on making 3D floors.

cool thanks, I know how to make a regular solid 3D floor but god dammit, the sloped 1 has been nothing but a kick to the nuts & fuck to the ass. Do you know of any links to tutorials on it? The picture I saw only showed the sectors but no explanation & I couldnt figure out what the 2 god dam triangles meant in the picture BUT I KNOW THEY WERE DOIN SOMETHIN!....BUT WHAT!!? = the son's uh bitches.

Byeblothingal 1024 said:

Do you know of any links to tutorials on it?

No, though I could Google them within 5 seconds, but so could you, so please do it yourself.

scifista42 said:

No, though I could Google them within 5 seconds, but so could you, so please do it yourself.

Sure man, didn't mean to try & put it on you. But just in case you just happened to have the link I figured it would be worth the ask. I appreciate you explaining it & I read it 3 times; but it just kicked my ass to understand it.

Erg, goddamnit. I just spent the better part of an hour bug fixing a complex monster-teleportation setup that I thought was working perfectly when I checked it last, only for certain teleportation triggers to now be failing.

Did the origin teleport linedefs have enough space? Were the destination sectors too small? Had the map corrupted in the 73 versions I've created since I finished this area? I moved the entire map a few weeks back 1000 units to the left - did something go wrong there? Perhaps I should rebuild the whole section, it was a little janky before after all?

Turns out half the teleport destination Things were only set to appear on Hard difficulty, and I'd been testing today on HMP.

*facepalm*

Bauul said:

Erg, goddamnit. I just spent the better part of an hour bug fixing a complex monster-teleportation setup that I thought was working perfectly when I checked it last, only for certain teleportation triggers to now be failing.

Did the origin teleport linedefs have enough space? Were the destination sectors too small? Had the map corrupted in the 73 versions I've created since I finished this area? I moved the entire map a few weeks back 1000 units to the left - did something go wrong there? Perhaps I should rebuild the whole section, it was a little janky before after all?

Turns out half the teleport destination Things were only set to appear on Hard difficulty, and I'd been testing today on HMP.

*facepalm*

OMG! LOL! FUCK THAT! hahaha F-U-C-K; THAT!! I can totally feel your frustration I have had shit like that happen to me when editing but never that exact bullfuck. I know I wouldn't be laughing if it happened to me & I hope not to piss you off by laughing. But I gotta admit THATS FUCKIN HILARIOUS!

How exactly would one go about ripping the music from a .wad file?

Open it up in Slade, right-click the music files and select "export."

I have a question, or rather a request to push me in the right direction on this. :P

For my game I want to have two weapons that the player can switch between, but whenever the player fires the weapon, because my game is a platform-game the player-sprite should animate as well. I was wondering how I can achieve this sort of thing in DECORATE. Is it possible for weapon-actors to reference player-actor states for example?

I think you'll have to have your weapon state call a script that will use SetActorState to change the player state.

Or another dummy inventory give/take/jumpif trickery.

I thought there was a weapon.preferredskin, but I can't find it in the ZDoom wiki.

It's a Skulltag feature.

That Skulltag feature would have been super handy for my game... But I suppose I'll have to do some research into what would be the best way of implementing this. Thanks for the ideas though!

I made a torch actor in DECORATE, consisting of nine frames of a flame animation. It's fairly basic, and I've gotten it to work in GZDoom, but a small problem I have is that the sprite keeps showing up a few blocks to the right and half-way into the ground compared to the actor position in GZDoom Builder. Is there some sort of flag I'm missing, I wonder?

Here's the associated DECORATE I quickly cobbled together:

actor Torch 1300
{
	Height 16
	Radius 8
	+NOGRAVITY + NOBLOCKMAP
	states
	{
		Spawn:
			TORC A 3
			TORC B 3
			TORC C 3
			TORC D 3
			TORC E 3
			TORC F 3
			TORC G 3
			TORC H 3
			TORC I 3
		loop
	}
}

Okay... I was just experimenting, and attached a dynamic light to my torch-actor using GLDEFS. When I ran my map again, I noticed that the light showed up to the left of the sprite's position. This means that the sprite's graphics are off-center. How can I fix this though?

Now I have another issue, this time related to GZDoom and controllers...

For some reason, the game is not animating my player-sprite if I use a controller. I put the controller configuration to "strafe", so that it matches the 2D platformer keyboard controls, but nothing. The player does move from left to right when I use the controller, but the actor doesn't animate at all. I have no idea what is going on here, and I would love to have somebody help me out with this.

Agentbromsnor said:

Now I have another issue, this time related to GZDoom and controllers...

For some reason, the game is not animating my player-sprite if I use a controller. I put the controller configuration to "strafe", so that it matches the 2D platformer keyboard controls, but nothing. The player does move from left to right when I use the controller, but the actor doesn't animate at all. I have no idea what is going on here, and I would love to have somebody help me out with this.

TNT1 A 0 A_JumpIf(GetPlayerInput(INPUT_BUTTONS, AAPTR_PLAYER1) & BT_MOVELEFT, "MovingLeft")
TNT1 A 0 A_JumpIf(GetPlayerInput(INPUT_BUTTONS, AAPTR_PLAYER1) & BT_MOVERIGHT, "MovingRight")

Because you're only checking to see if the player is pressing left or right buttons. Doom movement however is not done through buttons, but analogue input, which joystick controls a natively mapped to (since vanilla, so always). You need to check the actual analogue input (INPUT_FORWARDMOVE/INPUT_SIDEMOVE).

(The buttons are basically lies seeing as it doesn't reflect your movement at all, even when using a keyboard.)

Agentbromsnor said:

I made a torch actor in DECORATE, consisting of nine frames of a flame animation. It's fairly basic, and I've gotten it to work in GZDoom, but a small problem I have is that the sprite keeps showing up a few blocks to the right and half-way into the ground compared to the actor position in GZDoom Builder. [...] This means that the sprite's graphics are off-center. How can I fix this though?

Change the X/Y offsets of the sprite graphic lump itself within the wad.

Edward850 said:

TNT1 A 0 A_JumpIf(GetPlayerInput(INPUT_BUTTONS, AAPTR_PLAYER1) & BT_MOVELEFT, "MovingLeft")
TNT1 A 0 A_JumpIf(GetPlayerInput(INPUT_BUTTONS, AAPTR_PLAYER1) & BT_MOVERIGHT, "MovingRight")

Because you're only checking to see if the player is pressing left or right buttons. Doom movement however is not done through buttons, but analogue input, which joystick controls a natively mapped to (since vanilla, so always). You need to check the actual analogue input (INPUT_FORWARDMOVE/INPUT_SIDEMOVE).

(The buttons are basically lies seeing as it doesn't reflect your movement at all, even when using a keyboard.)

This makes a lot of sense! I can't believe I didn't think of it myself, but I suppose it's easy to overlook.

Thanks a ton!

@scifista42: through Google, I found a thread over on the ZDoom forums about one way to go about this, and it mentions using the Y value of the picture as the Y offset, and use half of the picture's X value as the X offset. Is there any truth to this, or should I just faf about until I get the right offset? :P

I fixed the frame coordinates of my torch-sprite just now, and I just noticed that whenever I go into visual mode in GZDoom Builder, the actor looks pretty funky...



Does anybody know what's up with this? It doesn't show up like this in game (thankfully), but I haven't experienced this before.

The torch actor has this pointlight attached to it in GLDEFS:

pointlight TorchLight
{
	color 250.0 250.0 70.0
	size 50
	offset 0 0 0
}

Agentbromsnor said:

@scifista42: through Google, I found a thread over on the ZDoom forums about one way to go about this, and it mentions using the Y value of the picture as the Y offset, and use half of the picture's X value as the X offset. Is there any truth to this, or should I just faf about until I get the right offset? :P

The offset is the coordinate of the "pivot point", the pixel that will be right at the base of the actor. So yes, usually for most standing actors it'll be a point in the center of the lower side, meaning half the X size and full Y size, give or take a few pixels depending on how the graphic is exactly.

In some cases it can be different. For a projectile, for example, you'll want the pivot point to be right in the middle, so half X and half Y.

Thanks for the explanation Gez!

Edward850 said:

TNT1 A 0 A_JumpIf(GetPlayerInput(INPUT_BUTTONS, AAPTR_PLAYER1) & BT_MOVELEFT, "MovingLeft")
TNT1 A 0 A_JumpIf(GetPlayerInput(INPUT_BUTTONS, AAPTR_PLAYER1) & BT_MOVERIGHT, "MovingRight")

Because you're only checking to see if the player is pressing left or right buttons. Doom movement however is not done through buttons, but analogue input, which joystick controls a natively mapped to (since vanilla, so always). You need to check the actual analogue input (INPUT_FORWARDMOVE/INPUT_SIDEMOVE).

(The buttons are basically lies seeing as it doesn't reflect your movement at all, even when using a keyboard.)

Getting back to this:

I changed the INPUT_BUTTONS command to INPUT_SIDEMOVE. It does work (you can still move left and right, but whenever I press any of the strafe keys, the sprite automatically starts to face left for some reason... Am I missing anything here?

Agentbromsnor said:

I changed the INPUT_BUTTONS command to INPUT_SIDEMOVE. It does work (you can still move left and right, but whenever I press any of the strafe keys, the sprite automatically starts to face left for some reason... Am I missing anything here?

So, does your code now look like this?

TNT1 A 0 A_JumpIf(GetPlayerInput(INPUT_SIDEMOVE, AAPTR_PLAYER1) & BT_MOVELEFT, "MovingLeft")
TNT1 A 0 A_JumpIf(GetPlayerInput(INPUT_SIDEMOVE, AAPTR_PLAYER1) & BT_MOVERIGHT, "MovingRight")

Or like this?

TNT1 A 0 A_JumpIf(GetPlayerInput(INPUT_SIDEMOVE, AAPTR_PLAYER1) < 0, "MovingLeft")
TNT1 A 0 A_JumpIf(GetPlayerInput(INPUT_SIDEMOVE, AAPTR_PLAYER1) > 0, "MovingRight")

The latter is the correct way. As you had it before.

Agentbromsnor said:

color 250.0 250.0 70.0

Color values must be in 0.0 - 1.0 range, not 0.0 - 255.0. Looks like GZDoom clamps them while GZDB doesn't.