It's pretty restrictive but hey why not? I can live with it. I'd reach out to Ionous if you decide to move forward with it. I think he has some upcoming plans for another jam. If I had known ahead of time dm4 jam may not have happened. 

It's pretty restrictive but hey why not? I can live with it. I'd reach out to Ionous if you decide to move forward with it. I think he has some upcoming plans for another jam. If I had known ahead of time dm4 jam may not have happened. 

It's pretty restrictive but hey why not? I can live with it. I'd reach out to Ionous if you decide to move forward with it. I think he has some upcoming plans for another jam. If I had known ahead of time dm4 jam may not have happened. 

Hey, wait a second! 

It's the server not me! 

it's probably happening at the browser level, it's submitting the form twice. I either need to block it on the server or disable the submit button on the client after you submit once. 

Blocking it on the server works better, because at least the server will have received it.

Unreliable mobile networks often fails to send data, forcing the user to re-send it. I've already had problems with websites doing the "disable button" approach, thus forcing me to reload the whole page and start everything over. 

I've pretty much finished a single player map (still looking for some people to playtest it though), and I'm wondering whether it's worth the trouble of making the necessary adjustments to make the map work in deathmatch. Does anybody of you still play dm, let alone on newly released maps?

I'm just frustrated, because I've spent about six hours working on dm modifications, and at some point, during my tests some func_doors/plats started glitching. I have a feeling it might have something to do with me placing simplified dm func_doors over more complicated single player doors that are killtargeted at some point, but at this moment, I can't be bothered trying to pinpoint the root of the problem.

Personally, I don't play deathmatch (although I probably would if I had family/friends here that wanted to play it too), but even if I don't play, I like to keep the possibility there on my maps, JUST in case somebody wanted to play dm. Also, I'm kind of perfectionist in that regard, feeling like the map's somehow broken/incomplete, if it can't be played on dm. 

The few people who still play deathmatch stick to a very limited set of maps, so don't expect any interest from that direction. Plus single player levels are often not favorable for dm because their layout and spaces are not as tightly focused as in dedicated dm maps. In this sense, it's not worth the effort.

However, you can still put some dm stuff in if you like! I support DM in most of my maps just for the heck of it. It's a fun bonus challenge to make things work on both modes. It shouldn't break the single player part of course. As for your doors, instead of killtargeting them you should probably make them spawn only on dm in the first place (combine not_easy + not_normal + not_hard spawnflags = only dm). 

Actually, I did what you suggested right from the get-go. Allow me to explain: My SP map consists of multiple partially exclusive branches, where some doors are openable only on one path and closed on the other. That's why I have this convoluted system of killtargeting the other paths' doors when the player chooses a path. It has nothing to do with killtargeting the doors for deathmatch mode. Sorry for not providing enough background.

Making this map had me learn the hard way, that you can't have other entities intersect killtargetable entities on the map file, lest you want them glitching out ingame. So on this map, instead of placing two versions of the same door (one for each path) inside each other, I had to clip the doors and make sure they didn't touch each other.

And unless I'm mistaken, the rule seems to apply even if the entities are set to spawn in mutually exclusive skill levels/deathmatch: My doors/platforms are broken because my DM doors (set to spawn only on dm) are intersecting the killtargetable SP doors (set to spawn only in sp). I haven't tested this conclusively, but based on today's fumblings of mine, that's my current hunch.

But yeah, I also do the dm adjustments for the heck of it. Maybe not because it's very fun for me, per say, but more like for the sake of completeness. I mean, the original id sp maps are playable in both modes, so unless my map's completely unsuitable for it, it should be made compatible, as well. Oh me and my stupid obsessions, right? :) 

I don't see why killtargeting intersecting doors should be a problem. And definitely not across skill levels/game modes. Maybe you didn't set doors_dont_link somewhere? 

 

Sounds good dumptruck! I've just got temp housing for a short time in Santa Monica, scrambling to find something else asap. I'll ping you when the dust settles.

SleepwalkR, nice to hear from you bro. I'm just over here for work. It was here or Berlin, but the wife doesn't like the cold... hah.

Sorry for the late reply! 

I did some testing, and it seems that doors DO work right, as long as they are not made to spawn at the same time, so negke's original suggestion was correct. So it looks like some other dm modification of mine broke my map causing some func_doors/plats to float in random places (they can't be touched and are visible at some points and then disappear at some other points; maybe the place-dependant visibility has something to do with vis, which dictates when to render them). Guess I gotta save and test my map more often, when doing the dm modifications next time.

My test map has four doors, or actually seven doors, where three of the doors have two doors overlapping each other. One of the doors in such a door set is a regular func_door with no triggers, while the other one is a door with the targetname "killable door".

The first door from the left is a door, which spawns both of the doors regardless of skill level or deathmatch flags. That door glitches out always when I play the map: When I press a button that killtargets the killable door, it also eats the other half of the regular triggerless door (a double door, which btw should be opening when I get close enough, but in this case won't budge).

The second door set is built in a way, that has both of the doors spawn only in easy skill level. In all other modes only one of the doors will spawn. That door works, as long as you don't play the map on easy, i.e. when only one of the doors spawn.

The third door set is a variation, where the other door spawns only in deathmatch and the other only in single player. No problems there, since there never is a situation where both of the doors spawn.

The fourth door is kind of unrelated to the whole dilemma. It's just a test on an alternative method on how to have the doors behave differently depending on skill level or deathmatch flag. I just put four trigger_multiples in front of the door, each opening the door in their respective play modes.

One final note: While writing this post and after already having uploaded the test map, I decided to fiddle around with the "don't link" flags, after remembering Qmaster's suggestion. Maybe the door linking causes the killable door to kill some of the triggerless door. I tried adding the "don't link" flag for both doors, which sure enough prevented the killtarget from killing any part of the triggerless door, but the triggerless door still refused to open upon approaching it. Only now did I discover that the "don't link" flag disables the func_door's ability to open automatically without a trigger. I was able to solve the problem though, by giving the door a triggername "regular door" and then putting a trigger_multiple in front of it.

So thank you, Qmaster! :) It seems that door linking was the root cause of this weird "killtarget door affecting other doors" behavior! Now only if knew just what it was that caused my doors and platforms glitch out in my main map... T_T 

Just as an addendum, I know that my previous post was heavily mapping stuff, but I didn't want to move the post to Mapping help, away from the discussion chain, which started with me asking about whether people still played deathmatch. Come to think, I should have probably posted that one in the mapping thread from the get-go, since that post had also mapping related stuff in it. So, apologies for the misplaced discussion! 

But the summers are super nice! If you ever make it here, let me know ;-) 

The week started at 34'c, cooled down briefly to 26'c for a day or two, then went back up to 35/36'c. It was not the cold I was looking for. 

Normally doors that touch (not necessarily only the brushes but also their bounding boxes) are linked. This means, for instance, on a door where one part moves to the left and the other part to the right, if the player approaches from one side, the other side opens as well, or if one side is blocked, the other one acts correspondingly (as opposed to one side opening while the other remains closed).
The "don't link" spawnflag makes each func_door an indivual entity independent of its surroundings and other doors it touches.

Unrelated to this is that a func_door with a targetname will not generate a trigger volume of its own so you must create a trigger_once or _multiple (or some other entity) to make it open. The "don't link" spawnflag has nothing to do with this. 

I tested just the "don't link" spawnflag again without any targetnames on a different simple test room, and it seems to me that the "don't link" flag on a func_door entity prevents the door from generating a trigger volume around itself; even if there is no other func_door touching the "don't link" door. It just doesn't budge. Perhaps you could try it out yourself, and if you can get the door to open itself with a "don't link" flag, I'd like to see the map. o: 

https://www.gearslutz.com/board/music-for-picture/911330-quake-soundtrack-charlie-clouser-any-info.html 

https://i.imgflip.com/269vo6.jpg 

Gaaahh! 

It uses polygons + game is dark and brown + 1996 = Quake