Doomery
#15880 posted by Kinn on 2016/01/26 19:29:06
Make the lift a secret. And there is an instant death pit under it.
DoomII.txt: the only way to complete the level is though the secret area.
Anyway this reminds me. I have just finished Doom II, Map 19 "The Citadel", by Sandy Peterson. Overall it's a pretty fun map, but the only way to the exit requires you to go through a secret area (like what da fuq does "secret" even mean at this point?), but anyway, whatever.
This map is notable however, for containing possibly the worst level design idea I've ever seen:
At a certain point in the level, there is a little alcove containing a powerup, a Soulsphere. Now I dunno about you, but when I find a powerup tucked away in a little corner like that, and there are no monsters around, and I don't need the powerup, I don't pick it up. I make a mental note that it is there, and go on my merry way. If I need it, I can quickly rush back and grab it.
So, I proceed to spend a sanity-destroying amount of time wandering around the entire map trying to figure out how the fuck to proceed. I give up after a while and consult a walkthough on the internet.
Turns out the way forward is via that powerup I found earlier. If you go to pick the powerup up, you don't actually pick it up, instead - nonsensically - you get teleported to a new bit of the map, which is the way to progress. (And no, before you ask, it's not sitting on a visible teleporter, it's just sitting in an ordinary, plain alcove).
Yeah, defend that, Doom level design apologists.
Doom 2 Levels Are Pretty Crap I Don't Think Anyone Will Disagree
#15881 posted by czg on 2016/01/26 19:31:04
Doom 2
Had some terrible maps.
E2m6 Is Pretty Much The Worst Doom Level Ever
#15883 posted by czg on 2016/01/26 20:51:13
Sac
Func_train
#15886 posted by Qmaster on 2016/01/26 22:32:54
When looping, please please use at least two or three. I hate falling off just to have to wait for it to go all the way around the loop. And falling into instadeath under it is not cool. Have fun DeeDoubleU.
Yes path_corners tell the train where to go, but remember that it is the location of the lower left corner of the bounding box.
Func_train
#15887 posted by Qmaster on 2016/01/26 22:32:56
When looping, please please use at least two or three. I hate falling off just to have to wait for it to go all the way around the loop. And falling into instadeath under it is not cool. Have fun DeeDoubleU.
Yes path_corners tell the train where to go, but remember that it is the location of the lower left corner of the bounding box.
Stupid Phone
#15888 posted by Qmaster on 2016/01/26 22:33:40
double posting! :(
#15889 posted by DeeDoubleU on 2016/01/26 23:17:35
Even if I will use an instadeath secret you would have to work your ass to get to it! 10 hidden switches and rampcirclejump at the very least.
Good idea to use two trains, will do.
Speaking Of Secrets
#15890 posted by Qmaster on 2016/01/27 01:54:20
The func_door_secret is limited in that it only goes in two directions when opening. One could use the func_train to make an elaborate secret door, but it can only open once when you set the last path corner wait to -1.
Func_door_secret
#15891 posted by mjb on 2016/01/27 12:01:59
Could you use the angles key to allow for more directions? I seem to recall a Preach blog:
https://tomeofpreach.wordpress.com/2014/06/26/unusual-func_door_secret-angles/
Quoth2 Fgd
#15892 posted by Bloughsburgh on 2016/02/05 22:48:55
Hi again,
Is there a link to acquire the most recent Quoth2.fgd file? The option I used was from Preach's Blog and while that is up to date, I don't see any mdl paths defined which causes just bounding boxes to display in the editor.
If I am expected to add the mdl paths myself I can do that but was just wondering if someone just had a quick link to the file.
Sorry if I am missing something!
#15894 posted by ericw on 2016/02/06 02:35:03
TrenchBroom includes a Quoth2 FGD that displays models in the editor
You have to make sure you point to the mod folder in preferences
#15896 posted by Bloughsburgh on 2016/02/06 03:13:40
Sorry should have stated more details.
Using latest release of Trenchbroom. It comes with a slightly outdated Quoth2 fgd file than the one hosted on Preach's blog.
The problem I found is that the Preach Quoth2 fgd seens to not have mdl paths defined as they are in the Trenchbroom one. Hopefully that makes more sense.
Everything works...I just can't see the models within the editor. This is only a problem if I opt to use the newest Quoth2 fgd and not the one that is packaged with Trenchbroom.
Thanks for the replies!
#15897 posted by mjb on 2016/02/06 15:56:54
Okay, so I believe I have everything sorted. I just opened the trenchbroom Quoth2 file and the Quoth2.2 file and manually copied the missing entries across. Everything seems to be working with models showing.
For reference here was the problem I was seeing:
Ex: Envirosuit--
TB file =
@PointClass base(Item, Appearflags) model(":progs/suit.mdl") =
item_artifact_envirosuit : "Environmental protection suit" []
2.2 Quoth file =
@PointClass base(Item, Appearflags) =
item_artifact_envirosuit : "Envirosuit" []
The "updated" file is missing the model path and this is the case for all entity models in the editor.
That was my initial issue but there were only a handful of missing definitions so I just inserted them into the file with models already defined!
Cheers everyone, until next time! >;)
Cool
#15898 posted by SleepwalkR on 2016/02/06 17:23:46
it would be great if you could create an issue report on github and attach your file so that I can include it in future releases.
Yeah, Cheers
#15899 posted by Preach on 2016/02/06 17:59:59
I really have been meaning to get around to that too! So if you've done it already, with your permission I'd love to grab a copy and post an updated version on the official site.
Do the model paths cause issues in other editors? Or are they safely ignored? I don't know if I need to keep a 2nd copy online for users of other editors...
Oh Wow
#15900 posted by mjb on 2016/02/06 19:56:16
It is great to hear I wasn't just missing something obvious!
I will be happy to assist with the updated file.
Here is the updated Quoth2 fgd:
https://copy.com/Q2AbvQX9DjQugqCj
There were only a few things missing (waterfall, effect pulse, etc). And this retains all of the model paths.
I do not know about other editors but I imagine if the path to the mdl files are completely absent from the definition file that it would have the same issue.
SleepWalkR, I will report the issue!
Trying To Make A Button Opening Two Rotating Doors
#15901 posted by aDaya on 2016/02/07 12:17:19
It's guessing work when it comes to Scourge's rotating doors, but I think there needs to be a func_rotating_doors as the center of rotation for a given brush, and then have a rotate_object brush being targeted by said func_rotating_doors, but I digress.
I want a button to open two doors (which is actually one, just like in Scourge's E2M1) but since we can only target one thing I'm completely lost on making it work. I tried a trigger_relay but no, I really need a way for a single func to target two things at once. How can I do it?
#15902 posted by mfx on 2016/02/07 13:30:27
The func_button targets one door and a trigger_relay, which targets the other door.
The way func_rotate_doors are set up prevents them having the same targetname i guess.
Check the ad_test3.map for details.
Checking Ad_test3
#15903 posted by aDaya on 2016/02/07 14:12:51
And I found that big circular door in 2 parts. One part is a func_door while the other in a rotate_object.
What's the difference between the twos if they're both assigned to a rotating entity? And what's the difference between info_rotate and func_rotate_door? Do their placement matters, as in the targeted brush's center of rotation, or no? And I'm getting a bit confused with the button targetting and all, can't we target more than two entities at once if they have the same target name?
#15904 posted by negke on 2016/02/07 14:14:02
This sounds odd. Why shouldn't multiple rotating doors be able to have the same targetname...
Apart from that, one door can target the other, so there's no need for a trigger_relay.
|