Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
baja blast rd.

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

Recommended Posts

Agentbromsnor said:

Just to get back to this, I have this DECORATE code for controlling the player's left and right movement:

TNT1 A 0 A_JumpIf(GetPlayerInput(INPUT_SIDEMOVE, AAPTR_PLAYER1) < 0, "MovingLeft")
Since I'm still learning DECORATE, how would I go about cancelling the "sidemove" inputs?

By not checking INPUT_SIDEMOVE at all and just doing what you did earlier with INPUT_BUTTONS:

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

bzzrak said:

If you make a DEH patch for Doom 1, can you use the Doom 2 codepointers?
Just curious.

Yes, you can.

Share this post


Link to post

I don't know what controller you are talking about and what input field(s) does that controller affect, but look here for the list of inputs available through GetPlayerInfo. You can choose to check any of them by calling GetPlayerInput with the respective parameter, and that's it. Feel free to test out if there's such an input that is affected by the controller and not by the mouse. If there is one, you're in luck, and if there isn't one, you probably can't do anything but to recommend your players to willingly disable or avoid using the mouse in your game.

Share this post


Link to post
RetroNova10 said:

Is there any custom 'monster' out there that is a Marine? Like a full representation of Doomguy, or at least who acts like a Marine would? (I can replace sprites)


I remember REELISM had a boss enemy Doomguy who acted the same and had all the same weapons as the player. Maybe ask the guys who made it for a copy of that enemy.

Share this post


Link to post
NEANDERTHAL said:

I remember REELISM had a boss enemy Doomguy who acted the same and had all the same weapons as the player.

I remember DTS-T had a boss enemy Doomguy exactly like that too.

Share this post


Link to post
scifista42 said:

I don't know what controller you are talking about and what input field(s) does that controller affect, but look here for the list of inputs available through GetPlayerInfo. You can choose to check any of them by calling GetPlayerInput with the respective parameter, and that's it. Feel free to test out if there's such an input that is affected by the controller and not by the mouse. If there is one, you're in luck, and if there isn't one, you probably can't do anything but to recommend your players to willingly disable or avoid using the mouse in your game.


As a last resort, do you think locking the player angle down using SetActorAngle in ACS would work? This would of course could complicate the left and right movement again though, since the hitbox would always be facing towards one angle. Though as long as I only change the direction of the sprites in DECORATE this shouldn't matter too much, I think.

Share this post


Link to post
Agentbromsnor said:

As a last resort, do you think locking the player angle down using SetActorAngle in ACS would work?

Yes. I actually thought you already did that. It's exactly as much "last resort" as locking the player on x axis is a "last resort".

Agentbromsnor said:

This would of course could complicate the left and right movement again though, since the hitbox would always be facing towards one angle.

I thought this "always be facing towards one angle" was also already in the core plan for your game.

Agentbromsnor said:

Though as long as I only change the direction of the sprites in DECORATE this shouldn't matter too much, I think.

Having the player face a constant direction enables your player-character to properly move left and right as the player-human presses strafe left and strafe right buttons, and also helps you to manage shooting and pressing use on switches. I wonder how you had wanted to do all that without restricting the player's angle.

EDIT: Last paragraph changed to avoid misinformation.

EDIT2: I've probably been misundestanding your several last posts. You've talked a lot about the mouse, but now it seems like you just wanted to prevent the player from turning left and right. In that case, locking his angle via SetActorAngle is the only way to do so, and you can forget everything I told you in my several previous posts.

Share this post


Link to post

Yeah... It does seem like a logical solution. I can't believe I just now thought of that, haha. It's one of those cases where I was completely overthinking matters.

Sorry for any miscommunication, I'm not always great at explaining things. :P

Share this post


Link to post

The player-character's body is affected by player-user's turning controls automatically (just like it is affected by his forward/backward movement controls and strafing left/right controls automatically), and player-user's turning controls can't be disabled (just like his forward/backward/strafing controls can't be disabled), so of course, "cancelling" their effects requires calling SetActorAngle (respectively SetActorPosition) every tic.

Also note that these virtual controls (forward movement, strafing, turning, anything available via GetPlayerInput) have nothing to do with input hardware (particular keyboard keys, mouse, controller). It's entirely in the player's own competence to assign his input hardware to virtual controls in the game as he wishes (in Customize Controls options). The modder has nothing to say into this, so the engine deliberately doesn't provide any modding features to do so (aside from defining default bindings for custom new controls, but the player will always be able to change those ones too).

GetPlayerInput doesn't care what kind of hardware the input comes from (press W, press A, move mouse to the right), but it can tell what the input virtually means (intention to move forward, intention to strafe left, intention to turn right), and it can distinguish between "numeric inputs" (intention to turn left/right by a given amount [as if mouse is being moved by a specific amount, but it doesn't matter if it really is a mouse or something else]) and "binary inputs" (intention to either turn left or not turn left [as if a key on a keyboard is either being pressed or not, but it doesn't matter if it really is a key on a keyboard or something else]). This is useful if you (as a modder) want to give your own meaning to various virtual controls, but useless if you want to give your own meaning to various hardware inputs - the latter is just impossible, and deliberately so.

Share this post


Link to post
Agentbromsnor said:

This would of course could complicate the left and right movement again though, since the hitbox would always be facing towards one angle.

Hitboxes don't have angles in Doom. They are static 2D squares, sometimes with an implied height depending on what mood the Z height calculations are in.

Share this post


Link to post

You're right. I meant to write the actor angle instead of hitbox. Derp! Disregard what I mentioned previously, I was completely overthinking everything.

Adding a simple line of SetActorAngle code to my "game loop" solved the problem though. I locked it down at an angle of 0.25, since the player-actor is already facing north to ensure natural left to right movement.

Thanks for the explanation Scifista!

Share this post


Link to post

I'm seeing this error message when I try to run my PK3 independently using GZDoom: "R_InstallSprite: Sprite TROO frame A is missing rotations".

I copied over these few imp sprites as PNG's, so I can use these for a placeholder enemy actor I can test my future weapon system on. Is there a specific reason why it's asking for rotations? I'm also using just four zombie-man frames as the player's placeholder sprite and it's not complaining about that, so I'm a bit puzzled about this.

Share this post


Link to post
Agentbromsnor said:

Is there a specific reason why it's asking for rotations?

Yes, you're not providing all eight rotations for TROOA.

You should have either:

  • TROOA0; or
  • TROOA1, TROOA2, TROOA2, TROOA3, TROOA4, TROOA5, TROOA6, TROOA7, TROOA8; or
  • TROOA1, TROOA2, TROOA2, TROOA3, TROOA4, TROOA5, TROOA6, TROOA7, TROOA8, TROOA9, TROOAA, TROOAB, TROOAC, TROOAD, TROOAE, TROOAF, TROOAG.

Share this post


Link to post

@Agentbromsnor: I suggest you to actually carefully read all of the respective wiki articles about sprites (naming conventions, rotations, mirroring) that I linked you previously. Please don't make me and Gez explaining the concepts to you by our own words in 10+ posts again when the zdoom wiki documentation is already perfect and anybody should understand it if only he wasn't unwilling to read through it and think about it.

Here is the post where I linked you the wiki articles and then spent way too many unnecessary posts explaining them.

Share this post


Link to post

If you're mapping for ZDoom, you define text screen's properties in cluster definitions and assign cluster numbers to particular maps in their map definitions. As far as I know, you can't have multiple text screens directly after each other, unless you define another cluster and use a dummy empty map that immediately ends itself just to display the text after it.

If you want vanilla/Boom compatibility, you can edit the text messages and background flats via DEHACKED (in Strings table), but you can't change the music and the map numbers in between which the text screens appear.

Share this post


Link to post
Gez said:

Yes, you're not providing all eight rotations for TROOA.

You should have either:

  • TROOA0; or
  • TROOA1, TROOA2, TROOA2, TROOA3, TROOA4, TROOA5, TROOA6, TROOA7, TROOA8; or
  • TROOA1, TROOA2, TROOA2, TROOA3, TROOA4, TROOA5, TROOA6, TROOA7, TROOA8, TROOA9, TROOAA, TROOAB, TROOAC, TROOAD, TROOAE, TROOAF, TROOAG.


Hmm, okay. I know about the naming conventions, but I think I didn't consider the importance of naming the sprite frames in order. Right now my PK3 also contains just TROOI0 to TROOM0, which actually should be named in alphabetical order, correct? So it should either follow up on the previous entry that started with A, or just start with A to begin with.

EDIT: I named them all in alphabetical order and that seemed to work.

Scifista, I'm sorry for asking things repeatedly. Like I said in the past, I do have a learning disability which unfortunately turned this into a habit for me. I'm totally fine with being referred to the ZDoom Wiki or anything else.

Share this post


Link to post
Agentbromsnor said:

Hmm, okay. I know about the naming conventions, but I think I didn't consider the importance of naming the sprite frames in order. Right now my PK3 also contains just TROOI0 to TROOM0, which actually should be named in alphabetical order, correct?

No. The problem isn't about frame letters at all. It's about the rotation numbers. For example, if you already provide a sprite named TROOA1, the engine requires you to also provide sprites named TROOA2, TROOA3 ... TROOA8. But if you provide neither TROOA1 nor TROOA2 nor ... TROOA8, it's OK. Even if you provide (all) TROOB* sprites but no TROOA* sprites, it's OK. Alphabetical order doesn't matter. You just have to provide either no rotations or all rotations per each letter. "No rotations" means no sprites with the respective prefix + letter at all, and "all rotations" can mean either one of the 3 situations that Gez mentioned.

Agentbromsnor said:

Scifista, I'm sorry for asking things repeatedly. Like I said in the past, I do have a learning disability which unfortunately turned this into a habit for me. I'm totally fine with being referred to the ZDoom Wiki or anything else.

Then I guess you won't be impressed by the suggestion that I gave you in the private message which I've sent you earlier today.

Share this post


Link to post

This might seem like a silly question but...

I noticed that a knocked back monster corpse can open a door if the door has "when monster bumps" checked. This happened when I killed a zombie man with the BFG and the gibbed corpse got knocked into the door. Is there any way to prevent a dead knocked back monster from opening a door?

Share this post


Link to post

Instead of giving the door linedef an actual door action, let it execute an ACS script, and write the script to contain the following commands:

if(GetActorProperty(0,APROP_Health)>0) { // Check if the script's activator has positive health
  Door_Raise(...); // Or any other ACS function or action special that will open the door
}
Alternatively, do not give the door a "when monster bumps" trigger, but a "when monster presses use" trigger instead.

Share this post


Link to post

You can't assign sounds to the textures themselves, but you can place Ambient Sound things near them.

Share this post


Link to post

I have set up a scene in a GZDoom themed map where the player's movement becomes really fast for a very short period of time. The speedup is done via ACS:

SetActorProperty(0, APROP_SPEED, 3.0);
They are then set back to normal with a linedef that triggers the below ACS:
SetActorProperty(0, APROP_SPEED, 1.0);
Issue I'm having is, sometimes a linedef skip happens when travelling this fast, meaning the player 'escapes' the designated area with 3x speed and can move around the rest of the map at lightning speeds. While entertaining, this is certainly not desirable. Aside from adding more linedefs which trigger the speed reset, is there a recommended way to negate linedef skips?

Share this post


Link to post
Dragonfly said:

Issue I'm having is, sometimes a linedef skip happens when travelling this fast, meaning the player 'escapes' the designated area with 3x speed and can move around the rest of the map at lightning speeds. While entertaining, this is certainly not desirable. Aside from adding more linedefs which trigger the speed reset, is there a recommended way to negate linedef skips?

You could use sector actions instead of line actions. If you don't make your sectors 1x1 squares, they should be harder to skip than lines.

http://zdoom.org/wiki/Classes:SecActEnter

Share this post


Link to post

Another solution would be to have a continually running ACS script checking the player's position and resetting his speed when reaching a certain position and then terminating itself, but unless all of your map's sectors need to be small, the sector enter actions should be a superior solution.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×