QuotePilgrim

If I understood what you're asking, what you're looking for is the StartConversation action special. You can place the actor a conversation is attached to out of bounds and apply that special to a line that can be activated by any means you like (player use, player cross, monster cross, etc) and it should start the conversation as if you walked up to the actor and pressed E. You can also use StartConversation in ACS scripts, naturally. Is there a better method? That depends on what you consider a better method as that is entirely subjective. There are different methods. You can use Print or HudMessage to show text (or graphics!) on screen. Print is simpler and easier to use, HudMessage is more flexible.

Hah, what a thing to be remembered for LOL. Yeah, I did do that, and most of the struggle was in terms of the usability. Getting them to work in and of itself was a non-issue to me, I suppose because I was already used to DOSBox from playing a lot of ancient games. And being Linux user who lives in the terminal has probably helped to some extent. I don't know of how much assistance I can be. I don't remember exactly how to use any of these editors, I mostly figured it out as I went. Plus I did it on a laptop. Without a keyboard and mouse plugged into your device I can't imagine you'll get very far. First things first, DETH is a an improved fork of DEU, so you should probably use that instead. You might need to get a node builder though; at least for me it didn't build the nodes automatically when saving a map even though I'm pretty sure it's supposed to. What worked for me is ZenNode v0.98a, with the 32RTM.EXE file that comes with v0.98. (And no, just getting v0.98 didn't work, why? that's beyond me). If using an external node builder is too complicated and DEU is in fact building the nodes for you then you can keep using it. Anyway the basic workflow with DEU/DETH is, in vertices mode, hover the mouse where you want to add vertices and press Insert. Then select the vertices in the order you want to draw the lines (you need to go clockwise around a room so all lines point inwards) and then press Insert again to add lines connecting the vertices, this will put you in lines mode, but will not fully enclose the room so go back to vertices mode (V) and select the two vertices that belong to the last line you need and press Insert again. Select all the lines that enclose the sector you want to create, then press insert. This should create a sector. Go to things mode (T), hover somewhere inside the sector and press insert to add a player 1 start thing. Save the map and check that it works. To add textures to a line, you need to select it in lines mode and press Enter, this will bring up a menu you can navigate to edit all of the properties of the line. If you want to know what shortcuts are available to you, press F1 for general shortcuts and F6 for shortcuts associated with the current mode you're in. You'll need do to that a lot before you actually learn all the shortcuts. Also, consider using DMapEdit instead. As far as I recall that one is by far the most user-friendly DOS Doom map editor. I should know, I have used all of them. (EDIT: Apparently I have severly misremembered my experience with DMapEdit, I hated it for some reason back then. The one I actually really liked was DCK. Kind of ironic if you ask me.) Also also, as someone who has used all of them: don't. And when I say this bear in mind I'm a weirdo who learned to map in ReDoomEd, a fork of the original DOOM level editor (with no changes made other than being able to run on Linux and Mac in modern hardware). My honest to god advice is get a cheap netbook or something and install UDB or SLADE or Eureka (that last one is Linux-only afaik). If you can't afford one, wait until you can. I'm on a 12 year old laptop and only now I'm getting a new machine because I can finally afford to. This laptop still servers me well though, even the latest version of GZDoom runs without any issues which is pretty impressive IMO. You are absolutely right, when it comes to making doom maps, Android sucks. Any smartphone/mobile device, running Android or otherwise, is completely unsuitable for the task. That's just the unfortunate reality. EDIT 2: HOM is happening either because you're in a sector whose ceiling and floor are both at 0 or you have missing textures in your lines. To solve the former select the sector in sectors mode and press Enter to edit its properties. To solve the latter select the offending line(s) and press Enter to edit its properties. You'll need to think about the changes in height between floors and ceilings in adjacent sectors to figure out if the missing texture is an upper or lower texture; in case it's one-sided line it's the middle texture. DEU/DETH might also show you what textures are missing when you hover over a line in lines mode. I know at least some editors do, maybe it's all of them.

These are not easy questions to answer. You have to create a class that inherits BaseStatusBar in ZScript and tell your game to use it by setting the StatusbarClass property in your GameInfo definition. Sort of? GZDoom goes through great lengths to prevent you from hiding existing options so you have to rely on workarounds and if a lot of people start using workarounds to limit the menu Graf Zahl will make sure those workarounds don't work in future versions. Anyway the documentation you want is on menudef; just create a simple ListMenu named "MainMenu" and copy the options from the default one except for the ones you don't want like saving and loading. If you want to make more extensive changes, you could recreate all the existing menus from scratch under different names while omitting options you don't need and then have your MainMenu point to them instead of the default ones, but do it at your own risk; Graf will show up to your house with a baseball bat. As for skipping the skill selection that is easy enough, just make sure your MAPINFO has exactly one skill definition and the game will not give players the option to choose the difficulty. SLADE, basically. Read this. Create one font named SmallFont and one named BigFont and your game will use them. There are multiple different ways to change what font any text uses depending on what is drawing the text. Your HUD class will not change its font the same way an ACS script that prints some text to the screen will. That depends on how much control you want. If you just want a default system that works, use ZSDF. Otherwise you probably just need to build your own. The one in my game is a weird hybrid ZSDF/ACS system. You can probably do something in ZScript. Anything I have not responded to I don't have an answer to. I only know what I know about GZDoom because I am making my own game that happens to be a Yume Nikki fan game of sorts. You can try to look at its internals and figure out what the heck it's doing and how it's doing it but it's very much in alpha stage and I do a lot of weird things that are frowned upon or strongly recommended against. The project is done 100% in SLADE. Also bear in mind all my level scripts are compiled with ZT-BCC and I hack my slade.pk3 file to make it recognize them as ACS files.

I can't believe this. Immediately after submitting this I've learned that there is a "HelpMenuClass" GameInfo definition that lets you specify a class defined in ZScript to be used to draw the help screen. That should probably work, I think. Still, if anyone else has any other ideas I would like to know -- I don't even know if the HelpMenuClass thing actually works yet. Gotta go write a ZScript class, I guess. It will take a while, object-oriented languages are the bane of my existence. EDIT: More amazingly, I can just add a menu named "ReadThisMenu" to menudef and it will show up as the help screen, so I could construct a help screen as an OptionMenu made out entirely of StaticText's. Creating a custom menu class might turn out to be a better idea, I dunno. Impressive how I manage to do this every time I have a question lol P.S.: This is still sort of a workaround though. The thing I said I suspected to be impossible is to display a different image in the help screen depending on the language chosen by the player, and I still have no idea how to do that thing specifically. There is probably a way to do it by creating a custom menu class as mentioned above, I just lack the ZScript required knowledge to do that.

I am like 99.99% it just isn't possible, and I've already added contextual help that the player can read by interacting with certain objects in the game but it doesn't hurt to ask just in case someone knows about some undocumented feature of GZDoom that would allow me to do that. I have some idea of how I could achieve it by messing with the contents of gzdoom.pk3 but that's the exact type of thing that I want to avoid. So as some of you may know I'm making a standalone GZDoom game. The thing is I'm making it in two languages and I would like it to show a different help screen when pressing F1 depending on which language is chosen. When trying to figure this out a year or so ago I stumbled upon a post by Rachael on the ZDoom forums stating that you can localize graphics by putting an image inside the localized namespace in the same directory structure as the pk3 root folder, and give it a name that ends with a dot followed by a language code, before the file extension. So if I have a file /graphics/infopic.png, I should be able to create another file /localized/graphics/infopic.pt.png and supposedly GZDoom would display the latter instead of the default one if the players sets their language to Portuguese Tried that, didn't work, and I can't for the life of me find Rachael's post again. So is there a way of accomplishing that I am unaware of or am I out of luck. Considering GZDoom pretty much lets you localize absolutely everything, the inability to localize the help screen seems like an odd arbitrary limitation. I would ask about this in the ZDoom forums but every single time I want to post something there I have to get my account verified again because of inactivity, which I find ridiculous and annoying, especially because it has to be looked at by a person rather than being reactivated automatically with a code sent to my email or something.

Y'all mostly talking about other FPS game so I'm going in a different direction. Apoplexy for Prince of Persia and Lunar Magic for Super Mario World.

First off, apologies for responding to a dormant thread, but considering that it's stickied thread I think this is fine. Also, this is a resource that really belongs here and more people should be aware of. BCS What Is It? BCS is an extension of ACS. BCS is mostly compatible with ACS and provides many interesting and useful features, including the following: Structures Enumerations Namespaces Preprocessor Strong types Block scoping Optional function parameters Object and function references && and || operators are short-circuited foreach loop ?: operator Knowledgebase ZT-BCC Wiki Tools ZT-BCC - The BCS compiler. It compiles BCS scripts to the same bytecode as the ACS compiler and should work fine with the vast majority of existing ACS scripts, so chances are you can use it as a drop-in replacement and start using it for your new scripts without worrying about updating the old ones. On a side note, since this isn't mentioned anywhere: if you use SLADE you can modify the contents of "slade.pk3" so it'll recognize files with the "bcs" extension as ACS scripts and automatically enable syntax highlighting for those files. The relevant file is config/entry_types/text.cfg; just look for the line that says «match_ext = "acs";» and change it to «match_ext = "acs", "bcs";».

You can probably tell from the fact that I'm a junior member despite being around for more than three years that I'm not a very active member. As a result whenever I come back and see a notification it comes as a big surprise. And of course in this instance it had to be someone quoting a post where I made a pretty egregious typing error I only notice upon rereading it LOL Anyway, always glad to hear someone other than myself likes one of my dumb ideas.

DavidXNewton. He does more than just DOOM and I actually found him through one of his Prince of Persia videos back when I was replaying the game for the billionth time; I didn't even know he made DOOM videos for quite a while after finding his channel. Which is to say, while I really enjoy his DOOM content, that is not necessarily what I care about the most. I just wanted to mention someone that wasn't already mentioned by everyone else. My favorite DOOM-specific content in all of YouTube is decino's analysis videos.

Tell them to go have intercourse with themself, problem solved.

UV, usually with a lot of quick-saving because I want to finish levels within a reasonable amount of time and I'm average player at best. I don't think I actually finished either DOOM or DOOM II in UV though; back when I played them through I would only play HMP because it's what is selected by default.

That is absolutely a valid way of thinking about it. It is also valid to think that the map is moving differently for each player. That is the thing about movement, it only exists relative to some frame of reference. The XKCD comic someone posted is a silly joke, but it is also true. In physics, from the frame of reference of a person standing inside the train, the train is stationary and Earth is moving, and from the frame of reference of someone standing somewhere else outside of the train, the train is moving. Both things are simultaneously true. As for what happens in the game, each player's computer is rendering a separate copy of the world, so there is no issue. Let's pretend the level doesn't exist for a second, and imagine there are two players standing in front of and looking at each other. If player A strafes left, what will both players see? Player B will obviously see the player A sprite moves towards the right side of their screen, but it is also true the Player A see's player B's sprite move towards the right of their own screen. Player A is moving from player B's point of view, and vice versa, in the very real sense that both computers are moving the other player's sprite across the screen. If you only looked at either screen, without knowing who is actually strafing, you would come to the same conclusion that the person see on the screen is the one moving. (Also, in case someone is about to bring up the fact that the strafing player's player would show a walking animation, I'll just point out that a walking animation doesn't have to be tied to movement. You could have neither sprite animate at all, or both animate constantly regardless of whether the player is doing anything, for instance.) It's more a matter of how to think about what is happening than what is being done in code. But one way in which the game actually move everything around is what I just described above, which you can see happening right in front your eyes. Just look at any object in the game and rotate your character a little bit with your mouse, and you see the object move on your screen. I think seeing this as moving the object relative to the player is a reasonable way of looking at it; if you don't, there's not much else I can say. Just think about this: the game has to calculate the position of everything relative to the position of the player in order to draw it on screen. It would be impossible to place anything on the screen without doing that. -- I hope this all makes any semblance of sense, it is very clear in my head but I often have trouble getting what is in my head out in a coherent way. Also, I think I have repeated myself enough, so I'll refrain from posting any further in this thread.

The point I'm making isn't that the map moves and the player doesn't. The point that I'm making is that both interpretations are valid. Thank for proving my point. So, let me state this a little more clearly. It is true that the player has a set of coordinates relative to the world origin, which change according to some user inputs and other things that happen in the game. You can think of those numbers changing as the player moving relative to the level. As a player it makes more sense to think of the player character moving, because that what's happening conceptually. It is also true that the way the level is rendered consists of calculating what parts of the level to draw on the screen relative to what the player coordinates are. You can think of this as the level moving relative to the screen/player. As a programmer it makes more sense to think of the level as moving, because it's the thing that you actually see move on the screen as the player coordinates change. The player moves relative to the level, the level moves relative to the player. Both statements are equally true. This exactly what I said from my very first comment.

Even in real life, if you move from your living room to the bathroom, it is perfectly valid to think of it as you being stationary as your house moves around you. That's what a frame of reference is. That is why I said both ways of looking at it are valid, and both are technically not the truth. There is no true interpretation, movement is relative. If you're just playing the game, it makes sense to think of it as the player is moving and the environment is not, but when you are programming movement in a game, what you are doing, usually, is making the environment move according to what the player's coordinates are. Look at the automap in DOOM, the little arrow that represents the player is always at the same spot on the screen as the map rotates and moves around. Or just look at gameplay in general, what is the thing that you actually see change position in the screen? Is it the player or the environment around the player?

That doesn't actually mean the player is moving though. I have next to no familiarity with DOOM's source code itself, but I have coded enough little game prototypes to know that what usually happens is the player coordinates are just some numbers that change with certain user inputs, and those numbers are used to calculate where to render the level relative to the player (and the player relative to the screen). You can interpret this to mean either the player or the level is moving, both are valid interpretations, neither is tecnhically true.