 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
It's worth noting that this was discussed around the community some years ago, and the described behaviour was a community consensus decision.
Hm, I see.
Well, "the community" was WRONG about this :D Where did this discussion take place? Got a link? I'd like to read over it and see how this "consensus" was arrived at.... This is bad behavior, altered from standard Quake, and uncontrollable by the user (specifically, I don't WANT to go to a custom map when I go to start a new single-player game -- and if I do want to, I will change to the specific map myself). If I have several maps in my mod folder, it just picks one seemingly at random? Or does it work by alphabetical order? I don't know, but you can almost guarantee that it's not going to pick the specific custom map I might want to play, meaning that I'll have to change it manually anyway. In a folder full of maps, it's not likely to select the correct starting map for a custom episode either. Testing that.... Yep. Looks like it's just grabbing the first map in alphabetical order... that is, unless there is any map that contains the word "start" in the name, in which case it prefers that. If you have 2 or more maps that contain the word "start" then it favors the one that's first alphabetically.... Of course, if there is a custom map named "start.bsp" for a custom episode (like with DOPA), then that will start automatically anyway.... that's standard Quake behavior. All that this functionality does is ensure that one single map -- whichever has the preferred name in your folder full of maps -- will the the one that starts up every time you go to start a new single-player game. So unless the end user is wanting to play the same map every time, there is no benefit, because he'll still have to change maps manually after starting up. The standard Start map is the starting map for various reasons, such as being small, without a lot of entities, so it loads up fast. This functionality could result in a larger map being selected as your single-player start map, which could take longer to load (ok, probably a barely noticeable delay in most cases, but still undesirable behavior). If I'm going to have to rename maps so that the the one I want will load up, that's no different than the standard behavior of having a custom "start.bsp" in your maps folder. Well, this isn't exactly a CRITICAL issue, but I will say that I absolutely hate it :D And this isn't just "in theory" -- It has been happening to me for a while, every time I want to do some testing, when I start up a single-player game, and I had no idea why it was happening, and it forced me to have to manually switch back to the Start map.... Now let's hear from all the people who are actually making use of this feature often, without any issues of having to change maps manually anyway, because it selects the correct map they want to play every time :D All I would really ask is an option to ENABLE this feature for those who might want it. Of course, I feel it should be DISABLED by default -- this is a pretty drastic change from standard Quake behavior. And it's a solution for a problem which doesn't exist -- you can already name a map start.bsp if you want that one to start by default. And it further seems unneeded, because I see that you have added the really NICE functionality of the console command "maps" to see a list of your custom maps, and "map XXX[tab]" to auto-complete a map name. Now that's some fine, elegant, helpful, non-intrusive functionality right there. Love stuff like that. ;) I suppose the ideal thing might be a map browser of some kind where you could scroll up and down the list and select the one you want. And quickly checking my old Quake.exe... nope, no macros in original Quake or GlQuake (they print literally "%c" instead of your cells value), but it is in Proquake. So it's just one of those things someone came up with, and everyone imitated. But it could be more optimal in various ways. Eh, not a major issue, but I don't care for it, since I don't use it. And the rare situation arises where it interferes with something I try to say. I find this particularly ironic.
You want a change from default Quake behaviour when that change suits you. You hate a change from default Quake behaviour when that change doesn't suit you. At this stage it's looking like you just want what suits you and to hell with anything else. loc support - How it works and how it was defined has nothing to do with me; is not subject to my whims. You used ProQuake for 10 years, it was always there. Nothing to discuss, move along
single player default map - This engine is oriented towards playing single player custom map releases just like func_msgboard! And it will be tomorrow and every day after that. map browser - Actually already has one. single player --> levels. Voila! And it's a solution for a problem which doesn't exist -- you can already name a map start.bsp if you want that one to start by default.
Except many modders are weirdos who like to name the start map of their mapset anything but start.bsp, even though their mod has its own directory. This feature is for players, not developers. It allows to launch such weird map packs without using the console. If you like to test on start.bsp - you're probably knowledgeable enough to organize it without using the new game menu. Except many modders are weirdos who like to name the start map of their mapset anything but start.bsp
Naming your start map "startsomething.bsp" is useful to avoid problems when you have a custom start.ent in \id1\maps. Otherwise you have to manually save the A problem that DarkPlaces can have -- but neither Quakespasm nor Mark V can ever have that problem.
The Quakespasm content protection system prevents id1 (start.ent) -> arcane dimensions (start.bsp) ^^ NO, that start.ent cannot know about model in gamedir Once I urged LordHavoc to add that system (I call it the "Quakespasm content protection system") to DarkPlaces. He didn't think that was a good idea. So DarkPlaces suffers greatly from that problem even today. mh, What specific issue are you talking about that I want to change from Quake's default behavior only because it suits me? That centerprint thing we were just discussing is a case where I WANT Quake's default behavior ;) And in that case it was you who was disagreeing when you thought it would be a change from Quake's default behavior, heh... soooo... aren't you doing the thing you accused me of?
What's ironic is that when people thought I was asking for a change to Quake's default, they seemed against it (ONLY for the reason that it was a "change"), but it turns out it was Quake's default all along (I only knew it was in ProQuake, which does stay pretty faithful to original Quake), and someone had changed it.... I'll quote Mugwump above, who said, "The point is the Fitz family of engines is more geared towards conservative Quakers. Therefore, changing things too much might not be a good idea." That nails the point PRECISELY, and that's the position I approach from. That doesn't mean NOTHING should be changed (certainly bugs should be fixed) -- and something like a more optimal positioning of centerprint is such an insignificant thing, and yeah, I would have advocated for that regardless of whether or not it was Quake's default. But I would NEVER push for something like, "centerprints should be in bright yellow text because I like it that way and it's more noticeable." Do you see the difference there? One thing is just a minor optimization of text position which doesn't change the look or behavior of Quake, while the other thing is a major change from Quake's default look based on my own preference. MINOR improvements and Behind-the-scenes-changes and options which CAN be enabled are great. FORCED changes from Quake's default, expected behavior are bad, especially when they cannot be disabled. It's as simple as that. And yeah, if you make a 4-sentence, pretty baseless attack on me, you get a multi-paragraph response fully describing my actual position ;) By the way, what is your position on the centerprint thing now? It should use Quake's nice default instead of, as you said, "ugly hacks," right? :D Come on people, don't be so serious. Then again, we're Quakers, and sometimes we just need to fire rocket launchers at each other ;) I just fire rockets...
@Baker We should petition LH to implement that protection system into DP. Let's show him how unnecessary it is! I get that the engine is geared toward single-player maps, but this feature is not good toward that end, except in limited situations. Yes, mappers use weird names, but if it's an actual "mod has its own directory" then there will already be a progs to send you to the right map. If that's not the case, there's no guarantee the intended map will be correctly named for this to find it.
"Weird map names" is a reason this function will often fail to do as intended. I'm not speaking hypothetically -- this is happening to me. I have the IIKKA and Terra map packs. They aren't "mods," just maps, so I have them all in the same folder, without their start maps (unneeded). I also have a modified DM6. So when I go to start a Single Player game I get put on DM6 because that's first by alphabet. There is seriously no reason this should ever happen when I try to start a single player game... Ok, so I don't have the IKstart or TerraStart maps, but even if I did, there would still be a problem -- I would always go to IKstart regardless of what I want, because it's first alphabetically and contains the word "start." I will never begin on the terra or orl start maps if I have those in there too, or any other map. How does this help me if I want to play single-player map episodes other than IIKKA? How does it ever help me if I want to play a selection of standalone maps? It would only work if I put one map at a time into my maps folder, otherwise I'm always starting on the same map. Seems most of the time this function is not helpful, unless you're using a lot of separate folders, and it even becomes a hindrance in some situations. Sure, it will work as intended if you only have one map, or only one map pack, assuming their is an auspiciously-named start map included. But that's the end of it -- if you add other maps, it breaks down and you gain nothing. What is the solution? It's already there! An excellent Map Browser! Now THAT is nice. I may have seen that before, but forgot about it.... But since we have that, and we can easily select whichever single map or starting map we actually want to play, why then do we even need an automatic forcing of a potentially unwanted map, especially if we are expecting a single-player game (of a mod) to put us on the standard Start map? So yeah, Map Browser: Beautiful, non-intrusive, allowing full player control. Forced Alphabetical Staring Map: Drastic change from Quake default behavior which is not controllable by the player. Options in order of preference: 1. Remove it! Heh, It just seems more negative than positive, and the user-controlled (important!) Map Browser is the IDEAL way to do this. Seriously. Love that. 2. Disable it by default, as it is far removed from Quake's default behavior. Allow it to be turned on if someone really wants it... 3. Even if it's left on as the default (*shudder*), give me a setting to disable it. Then you won't hear me mention it again, because it will stop annoying me, heh. 4. Have it be more selective and ONLY function if there IS a map that contains the word "start." TerraStart, IIKKAstart, ORLstart, whatever. At least you KNOW those are actually meant as starting maps. This wouldn't fix the problems I mentioned above (with many maps in the same folder you'd still be starting on the same map every time, regardless of what you want), but it would stop it from happening for those who don't want it by allowing some user control -- just make sure to remove maps with "start" in the name from the maps folder, and it stops sending you to some map (like DM6!) just based on alphabet. Heck, ya know what might be more useful than allowing the whims of the alphabet to select your starting map? Allow the user to select any map as the default starting map from within the map browser. "Press 'D' to set this as the default starting map." Throw me a bone and give me SOMETHING to allow me to make it stop happening! :D Don't get discouraged, Baker, heh. Even though I hate this feature, I still love the engine as a whole. But just because you CAN do something, and just because someone asks for it (... who asked for it anyway? was the idea really well-thought-out?) that doesn't necessarily mean it SHOULD be done. There should always be someone asking if there are truly good reasons to make changes, and pointing out the negative issues that can happen if those changes are implemented. Yeah, that includes any changes I might ask for. But I support my suggestions with solid reasoning, with consequences fully considered, and you'll never see me asking for anything that changes the look, feel, or function of Quake in a drastic way. It's the job of us modders to do that, not the engine coders ;) I'm just happy that you're actually making some updates now instead of later in 2017 :D loc file support -- is this not a separate issue from the macro format? I mean, it's not as if your hands are tied when you import something from another engine (just checked -- original Fitzquake didn't have this). Sure, maybe ProQuake chose to use %c as the macro, but you could choose to make it something like %c% instead (I mean, you changed "apropos" to "find" ;) ) It's just a matter of the user formatting their binds for the engine to access the loc files. But I guess all the other custom engines are using the %c format, so that's what players expect.... And anyway, this is a very minor thing, as I mentioned, which I don't care all that much about. But there's no reason to not talk about ways it might be improved....
No no no no no.
The centerprint positioning you want is not more optimal in the general case. It's more optimal for your mod. It's more optimal for what you want to do. And that's leading you to downplay the importance of it's actual intended purpose. A useful rule of thumb in cases like this is to ask yourself "what if two mods did this?" So please, try to look beyond your own requirement and think about what would happen if two mods had different centerprint positioning needs. That's why we have defaults and that's why defaults sometimes don't suit individual mods. There is a useful dialog to be had about making centerprint positioning more flexible - maybe keep the default but stuff some control characters to the start of the string to override. But right now you're being just as inflexible about it yourself. Next version: Coop players spawn partially transparent, get less transparent each second.
While transparent, they may walk through each other/cannot be telefragged. Maps without coop spawn points will be drastically less annoying for coop. Pure engine modification. Also in next version, Nehahra support is perfected and polished.
Includes fog support (yhe1, I think kept bringing it up) via non-standard commands that Nehahra uses and full fmod support. Mark V starts up fmod if you activate Nehahra, shuts it back down if you change the gamedir back to id1. Also during the fmod startup, it adds the Nehahra special commands in and then removes them on shutdown. /It has been discussed before that Nehahra tries hard and heavy to screw with your settings (fov, wateralpha, crosshair, viewsize, and on and on and on Next version: The built-in install single player releases from Quaddicted via typing "install" in the console has been enhanced some.
The install command will autocompete 538 Quaddicted single player releases. It can install the ones that don't auto-complete, but I didn't want the lower rated releases to autocomplete. And this subset is searchable similar to the "find" command, but I haven't been able to figure out a good name for it. Misc stuff: the OpenGL build may be able to work for, say, Gunter or Jonathan with touchy OpenGL drivers. Added -nomultisample (<-- I think this is the villain) and -nostencil command line params, hopefully one of those will solve the issue, particular for Gunter who can run Quakespasm ok with r_oldwater 0. Also bind 3 three keys in menu in customize controls. Shooting for a couple more things (and intentionally keeping something rather unusual a surprise) Probably will have international keyboard support. I've procrastinated on that because of more serious issues, but modern ProQuake has had international keyboard support for ages and ages (I worked with Vegetous and rudl as beta testers back at the time.). Also want it to be able to be turned off on a whim, like ProQuake does. I'm a bit confused about this centerprint argument right now. Gunter wants it to be returned to how the original engines and some custom ones do it, mostly because it serves his needs better (the argument can be made that it's also good to be more like the "real deal" anyway...), but mh doesn't want that because it's considered worse for a lot of other mods/use cases.
If i've summed it up well enough, I can't see where this discussion can go from here. And I mean, it hasn't really been going anywhere regardless. There are two elements to it.
Part one is that the original engine suppressed centerprints when the menus were up. Some engines changed this behaviour to retain centerprints. This should be reverted. Part one is not in dispute. Part two is that the default positioning of centerprints should be changed to suit Gunter's mod and that the original intended purpose of centerprints is not as important as Gunter's mod. Part two, and only part two, is in dispute. Now I don't know whether to use Mark V or QSS. I know it's too much to ask to make them a joint effort. This engine has x awesome feature and that engine has y awesome feature. And poor player doesn't know whether to get the camaro or the mustang, especially not when yall keep turbocharging them and adding cool features. To think I used my old beater WinQuake for so many years up until a couple years ago. Had to ditch DP since it didn't twist water right, plus it leaked oil all over my config file.
I'm tempted to compile a comparison chart so people can better pick the best engine. It'd be hard to keep up though. You have it right, Pritchard. mh is confused.... Maybe he didn't fully digest the post I made where I showed that the positioning I want is actually the default positioning of original Quake.
See for yourself. Start a single-player game in original Quake, GL, or Proquake (which uses the same positioning). As you walk through a hall you will get the one-line message about "this hall selects whatever skill." Note the position above your crosshair. Now enter the first episode area, and you get the 4-line message about the dimension of the doomed. Note that it still starts at the same place, but is still fully above your crosshair position (assuming you aren't in a tiny resolution). All good. Now enter the second episode area where there is a FIVE-line message about the realm of black magic... but look where it is positioned! It's way up near the top (again, resolution dependent)! Why? Probably for the same reasons I talk about: so that it doesn't actually start to extend to the crosshair area and block that important area of your view, when instead you can move it upward because you have all that extra screen space where it could go instead. This is NOT a case where I want to change the positioning JUST to suit my mod -- this positioning would be better for ANY mod that uses centerprints, and even for original Quake. So yeah, it IS more optimal for the general case. id, in all their wisdom, chose this positioning for good reasons. I, in all my wisdom, wanted this positioning too, for good reasons, before I actually realized it was the original positioning, haha. I didn't know at first that this positioning was from original Quake (I've been away from Quake for a couple years :p ) -- I just knew that it had changed from what I was used to in ProQuake, and the change had made things less optimal, and it ended up obscuring my view in an unpleasant way. So it turns out you actually agree with me, right mh? You think the default Quake behavior should be used, correct? Good, glad we have that settled. Or are you focusing too much on the idea that I am wanting to change the PURPOSE of centerprint messages, from when I said, "But I think at this point they are no longer 'always important,' sooo.... they don't really need to be inconveniently in the middle of your view anymore :D" Much like id's original statement, I was not being completely serious. id's original statement was a small joke (I thought it was funny anyway) -- it's simply not true that every centerprint in Quake is 'always important,' and they aren't even always inconveniently in the middle of your view, as I demonstrated above. Sure, I did talk about even changing it a bit beyond the original positioning, but that's the kind of ideas that should get thrown around in threads lie this. After some testing, I have found that I actually have a great deal of control with id's original centerprint positioning. If I want it to appear closer to the center of the view, I just make it 4 lines or fewer (that is the actual limit, now that I've checked for sure). If I want it to appear near the top (it's "7 lines" from the top), I just make sure to pad it with extra lines ("one line\\n\\n\\n\\n" will appear at the top). I can even move it below the crosshair area if I stuff in a bunch of extra lines above what I want to print.... I have lost this level of control in Mark V, so yeah, I would like it reverted to Quake's default behavior. And apparently you agree with me, right mh? You seem to pretty strongly advocate for using "defaults..." So we are in total agreement here! Now let me consider some of these other juicy changes Baker is adding in.... Yeah that's difficult since a lot of stuff is not well-documented, plus there's an avalanche of little things that someone may or may not care about.
One could try to do a chart comparing engine support for widescreen, rendering API, palettized rendering output, texture filtering, QW multiplayer, QW listen server, singleplayer, colored lighting, soundtrack music files (and in what formats), bsp2, map texture replacement, model texture replacement, alpha-masked textures, various fog behaviors, It might be a good thing to try to set up as a shared Google-docs spreadsheet that a few engine experts/aficionados would be interested in keeping up-to-date. I dunno. There's a chance it would just get dozens of feature-columns added for minor things which only apply to one specific Quake engine. "Coop players spawn partially transparent
Brilliant! We do have that problem in FvF! Unfortunately, I don't think this is going to help me, heh. That would be a server thing, right? Polarite runs some linux proquake for the server.... Further, FvF doesn't actually run in coop mode -- it runs in a special deathmatch mode (coop 0, deathmatch 3), so all the doors are already open and we don't have to go around collecting keys and things most of the time. We just get to killing the monsters. But this certainly give me the idea to try this change in the mod, instead of the standard 3-second spawn protection pent (which prevents telefragging, but causes people to sometimes be pushed into the floor). Hm, but what happens if the players are standing on top of each other when they became fully opaque? I'm hopeful about the gl issue workarounds.... That is pretty weird behaviour in WINQUAKE.EXE: set the res to 1024x768, walk up to the episode 2 entrance in start.bsp, and the 5-line message is near the top of the screen. The episode 4 message (4 lines) is just above the crosshair.
This feels like something where the code is fudged in a way that looks good at 320x240. (another is the weird left-aligned deathmatch hud) The episode ending messages use WriteString, not centerprint and that is why they are at the upper portion of the screen.
@Johnny Law: Might do...sounds tedious but I do like that sort of thing.
|
|
| This thread has been closed by a moderator. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |