scifista42 Posted September 4, 2016 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. 0 Share this post Link to post
Agentbromsnor Posted September 4, 2016 So there's no specific function for player turning I can use? I really wouldn't like to go back to INPUT_BUTTONS because of controller support. 0 Share this post Link to post
scifista42 Posted September 4, 2016 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. 0 Share this post Link to post
NEANDERTHAL Posted September 4, 2016 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. 0 Share this post Link to post
scifista42 Posted September 4, 2016 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. 0 Share this post Link to post
Agentbromsnor Posted September 4, 2016 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. 0 Share this post Link to post
scifista42 Posted September 4, 2016 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. 0 Share this post Link to post
Agentbromsnor Posted September 4, 2016 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 0 Share this post Link to post
scifista42 Posted September 4, 2016 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. 0 Share this post Link to post
Edward850 Posted September 4, 2016 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. 0 Share this post Link to post
Agentbromsnor Posted September 4, 2016 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! 0 Share this post Link to post
Agentbromsnor Posted September 5, 2016 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. 0 Share this post Link to post
Gez Posted September 5, 2016 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. 0 Share this post Link to post
scifista42 Posted September 5, 2016 @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. 0 Share this post Link to post
RetroNuva10 Posted September 5, 2016 How can I set up a custom Text Screen? (the one here: http://doom.wikia.com/wiki/Text_screen) I want to be able to edit the image behind it, the text shown, and the music playing. And between what maps it's displayed. And, can I have multiple? 0 Share this post Link to post
scifista42 Posted September 5, 2016 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. 0 Share this post Link to post
Agentbromsnor Posted September 5, 2016 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. 0 Share this post Link to post
scifista42 Posted September 5, 2016 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. 0 Share this post Link to post
Agentbromsnor Posted September 5, 2016 I get it now. I actually haven't read your private message yet, since I've had a rather busy day. 0 Share this post Link to post
Cosmic Grain Posted September 6, 2016 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? 0 Share this post Link to post
scifista42 Posted September 6, 2016 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. 0 Share this post Link to post
Matthias Posted September 6, 2016 is it possible to make a sound of a waterfall in a classic hexen? Like... you just walk around falling water and you can actually hear it?:) 0 Share this post Link to post
scifista42 Posted September 6, 2016 You can't assign sounds to the textures themselves, but you can place Ambient Sound things near them. 0 Share this post Link to post
Matthias Posted September 6, 2016 scifista42 said:You can't assign sounds to the textures themselves, but you can place Ambient Sound things near them. this? will it work? or does it need a script or something? 0 Share this post Link to post
scifista42 Posted September 6, 2016 http://zdoom.org/wiki/Ambient_sound 0 Share this post Link to post
Matthias Posted September 6, 2016 script 253 OPEN { delay(10); thingsound(19, "WaterMove", 100); restart; } did the trick and mapspot with tag 19 :) 0 Share this post Link to post
Dragonfly Posted September 6, 2016 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? 0 Share this post Link to post
Gez Posted September 6, 2016 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 0 Share this post Link to post
Dragonfly Posted September 6, 2016 Great suggestion! I'll give it a go later today to see if it works, but I can't think of a reason why it wouldn't. 0 Share this post Link to post
scifista42 Posted September 6, 2016 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. 0 Share this post Link to post