What is the deadline on this?
I might think about other workarounds on time.
Also thanks alot for your input total_newbie!; 

I can confirm that moving the Quad Damage an extra 16 units up from the floor solves the problem. Recompiled and tested, and the Quad appears. 

 

 

I got used to spending all my free time on that map.

I sent the map file last night, the time stamp on it was 11:48 pm. It took another 2 hours 21 minutes to compile the thing. I sent the final zip file a few minutes ago.

Unfortunately, I'm pretty sure I didn't supply enough ammo to finish it on the "hard" setting, but maybe someone will prove me wrong. Also, I spent the last few hours I had adding a secret. Bad thing is that if the player doesn't find it, they will have a very hard time finishing even on "normal". 

I wasn't making a map for this jam. The map I'm currently working on is kinda Retrojam3_dlc_dlc.

I felt an urge to map awhile ago, but there were no jams announced at that moment. I waited for some time and then started to make a proper map without jams. So you'll see my map soon but not that fast. 

Your first problem seems tied to using four separate triggers at the start. Players start touching all four, and one of them triggers one of the others (the one named 'start') with no delay. That trigger, in turn, has a sound style, target, and delay, but delay only affects the targetted object, while the sound always plays immediately. You could change the 'start' trigger to have no delay of its own, then add a four second delay to the trigger that targets 'start'.

The simpler thing to do might be to try using some trigger_relays instead of several trigger volumes. Make one trigger_relay for each thing you want to do. Set their targets and delays as you like, but give them all the same targetname. Then have one master trigger that targets that name.

Problem two seems like a naming issue. I see a button that fires 'st1' to teleport the enemies, but the stairs in the lava (if I'm looking at the right ones) are named st2, st3, and so on, and nothing in the map seems to target them. Give them the same name as those teleporters and they'll be activated at the same time.

Number five is I think because you have that large outer trigger meant to kill the 'jump' entities. Something I hadn't realized about Quake until starting my own map for this jam is that triggers are defined by their world-axis-aligned bounding boxes, not their actual brush volumes. The trigger you have set to kill 'jump' has a hole in it, but that doesn't matter because you're still inside the bounding box, so that one fires and kills the trigger_push before it's had a chance to toss the player. Split that large trigger into four separate ones, one brush each, and I think it'll work the way you want.

Finally, your last issue seems to stem from your silver key trigger having both a target and a killtarget, which won't work. Only one of them will fire, so if you want to target one thing and kill another, you'll as I suggested earlier need a few trigger_relay entities with the same name but different settings. 

Daya, I forgot to mention, if you go with my first suggestion of just changing the delays on those triggers at the start of the map, you'll also need to enable the 'start' trigger's "notouch" or "Entity only" spawnflag. I'm not sure what other editors might call that option. 

Re: Daya's second problem (untriggered stairs):

One of the func_door entities (i.e. one of the stairs) does have the targetname "st0" and is targeted by the Vore that's teleported in when you press the button. It then in turn targets s2, which targets s3 and so on. So as far as I can see, killing the Vore should activate the stairs, right? Yet I've tested it and they do not move at all when the Vore dies. 

Set the "door_dont_link" spawnflag on all of them. 

 

Tested linking the button directly with the stairs (giving the first func_door the same targetname as the teleporters), but that still did nothing -- so I don't think it's a naming issue.

Then I tested negke's suggestion and that crashes the engine with a stack overflow message. 

Ok, I got the stairs to work, using negke's advice and getting rid of the complex chain-of-targets: just gave all the func_door stairs the same targetname (st1).

They fall back into the lave almost immediately, though, so you need to change another one of the entity properties to get them to stay raised. I'm sure that's easy, though, and one of the experienced mappers here will know the answer. 

I'm an idiot, I didn't look closely enough at the connections shown in Jackhammer before deciding Daya hadn't actually connected them. Sorry.

The 'wait' key, or "Delay before close", sets the time to reset, change it to -1 to keep them open. I notice now poking around it's set to 0, which I thought might be a problem, but I don't get the stack overflow even with it set that way. It seems like enabling "Don't link" on the seventh stair is what does it. It's okay if I only enable the option on the first six stairs, but on st8 I get the error. I'm not sure why. 

Treating the whole bunch as a single entity (i.e. with a single targetname and "don't link" enabled on all of them) does work, though, so if I were Daya, that's what I would do. There does not seem to be anything to gain from having the stairs target one another; it just seems like an unnecessary multiplication of map entities... 

for problem 1., you can't switch a light off with killtarget, and if you mean it's a plusing style, then you can't switch it off with id1 progs.dat.
To make a non-pulsing red light that switches off, just give the light entity a color and targetname, it should switch off when triggered. 

At the collapsing bridge in your map, you have two messages, namely "The bridge will collapse shortly" (or something like that) and then "Woah!" (or something like that).*

At the moment, though, the first message appears for only a second or so before it is replaced by the "Woah" message (long before the bridge actually starts falling). The effect is that the player only really sees "Woah" on the screen and has no idea what is going on.

_____________
* The idea is obviously that the first message lets the player know of imminent danger (so they know they need to find a way off the bridge), and "woah!" is supposed to appear as the bridge finally collapses. 

Oh yeah, for this jam I ended up writing a bit of JavaScript to calculate the brush sizes I'd need to perfectly span the open spaces with repeating elements (like a fence, or series of windows). Specify the unit size of the space you want to fill and the unit size of the divider that goes between each section, and the script then lists feasible options that will repeat perfectly within that space. If anyone would find this script handy I could toss it on GitHub or something. It's kinda primitive tho - you just paste the functions into the JS console in your browser and call it from there. If enough ppl want it, I could just put this stuff in an HTML page with a simple web view or something. 

is that it's basically unplayably slow. I get around 10 fps on Quakepasm 0.90 on a not-too-old computer, where most maps run at around 70 fps.

I don't know nearly enough to diagnose why this happens, but I am guessing cleaning up the brushwork and sealing the map cannot hurt.

FWIW, when I compile the map without running light, it runs at around 20fps (and fullbright, of course), which is bad, but not unplayable. Don't know if this helps with troubleshooting. 

http://scampie.net/etc/mapshots/jam6_scampie1.jpg
http://scampie.net/etc/mapshots/jam6_scampie2.jpg
http://scampie.net/etc/mapshots/jam6_scampie3.jpg
http://scampie.net/etc/mapshots/jam6_scampie4.jpg 

That looks bloody great!

btw I wonder why doesn't necros tease us with some more screenshots. 

Not the quality of Scampie's shots, but for my first single player map ever in a game I haven't mapped for in over 15 years... I am pretty happy with the result despite having to restart and trashing half the rooms trying to fix errors 5 days before deadline. :-p

https://www.dropbox.com/s/yp20pcjhl4i5stg/Quake_MapJam666_WIP_11.jpg?dl=0

I will be fixing a few more things and updating Daz with new files tomorrow. I might have made it too easy trying to make it so you can beat it without ESP and only two shotgun shells remaining.

Beer time! 

Since Scampie decided to post screenshots of the finished map, I'll do some shots myself:

http://i.imgur.com/IZdEg7x.png
http://i.imgur.com/uggOy4x.png

I was getting pretty sick of working on this map to be quite honest. I guess I'll stick with doom mapping form now on, since it's a bit difficult to make a functional layout without getting confused on what to do or how the map would look like. I'm looking forward to seeing what Daz thinks of this map (It'll probably suck) and I am also looking forward to playing everyone else's maps. 

It's a shame you've been put off because those screenshots look really cool! It can be rough learning a game engine under a time limit for sure, maybe working on another small map but with a longer but self imposed time limit will feel much better? 

Bollocks, Doom mapping is for babies!

I'm happy you finally finished a Q1SP. I guess a deadline helped, since as far as I recall your projects would tend to run out of steam.