[the_f0qer]

That can be fixed in the progs

[RocketGuy]

Originally Posted by Zop

BNT2.BSP
- needs sps's
- Interesting problem with keys: They are on movers that slide back into the ceiling when touched. Although keys are kept in packs when you die, it's still possible to lose a pack in the lava or on disconnection.

I'm fairly certain movers can be reconfigured by the progs, if not I'm completely certain they can be removed.

Originally Posted by Zop

CARNAGE.BSP
- Platform up to gold key cannot be brought down without almost dying in lava or rj'ing.

Same as above, if I'm right it can be reconfigured to come back down automatically by the qc.

Originally Posted by Zop

chain3.bsp
- needs sp's
- monsters fall off the level easily. RG needs to fix bug with trigger_pain, monsters that trigger effects can end up somewhat lost to players.

More details on this please, I don't think there even exists a trigger_pain (perhaps you mean trigger_hurt?) and I need to know exactly what happens.

Originally Posted by Zop

cjhsp1.bsp
- crashes rquake, but not vanilla: too many model precaches.

Can't really do anything about this without switching protocols.

Originally Posted by Zop

corpus.bsp
- needs sp's
- The last mover above water moves only once, and it's possible to activate prematurely. I didn't see how foq got to it. Normally you teleport from water on bottom to its entrance, and then it takes you across. Hookshot solves this problem, but is there a better way?

Again a qc reconfiguration may be possible.

[Zop]

We have to find locations where it's safe to spawn, and get the exact origin. RG can use the origin to make spawnpoints for the mod. Quake doesn't normally have a method to display your current origin in-game, but it's way easy to code.

[RocketGuy]

Originally Posted by Zop

it's way easy to code.

It would also be redundant as RQuake can already do this, as well as some engines.

show-pos is the command in RQuake.

[metchsteekle]

dosent qrack display your origin when you dont have a loc file and you give the %l command?

[spooker]

so out of the 13 you evaluated, 6 of them had problems that need to be fixed if we're going to use them (not counting the spawn point problem). Yikes, that's not a very good record, looks like this is going to take longer than I thought. How is it coming Zop? I can't connect to Foq's server now

[Zop]

Oops, RocketGuy, yes, trigger_hurt is the name. This bug happens in intro.bsp, as well. If you keep jumping off the level, eventually the trigger will stop working. I think it's an old problem from vanilla.

What else do you want to know about the movers to make an assessment? For BNT2, I think we could remove the targetname from the keys to keep their movers in the down, key-grabbable position.

spooker, I don't know what's up with foq, I've been away from the computer lately... If you see him on, do some testing with him, if possible. Also, the levels can be saved, even with the limitation of not editing the .bsp file, but some might be too complicated to fix. It depends on how much work RG wants to put into it or how messy he will likes his code to be. Though, in regard to cjhsp1, we may already have to consider it scrapped.

[spooker]

Don't hesitate at all to conclude that a map would require too much work to fix. There are over a thousand other maps we could use, the ones I picked for this first batch were just the highest rated on the injector. Besides, the first time through I didn't really know what to look for, besides fun maps that didn't have any custom coding or progs.dat.

[Lardarse]

Originally Posted by spooker

How do we solve the problem of most of the maps only having 1 spawn point?

To give a more in-depth answer: There is a file in the RQuake source (I forget which file it is, as I don't have the source code handy) that is dedicated to adding the spawn points for maps that need it. There is a function in that file that, based on the map name, will add the required spawn points. We also have the ability to "ignore" the spawn points that are in the map and define replacements, should it be required (we use this for a3 and ikspq5, and possibly some others).

We tried to make sure that there are 5 info_player_coop in the map, as well as the info_player_start. For many maps that only have 4 coop starts, we just added one (although in some maps, such as one of the other ikblue maps, they are too close to each other, so we use new ones only). The mod will try to make sure that the spawnpoint isn't occupied when it tries to use it (so if there is a coop start overlapping the single start, then effectively only one of them is useful), but it will telefrag at info_player_start if all else fails.

When providing additional locations, you'll need to tell us the location (x/y/z), and also the angle that you want the player spawning there to face. Looking at the exit to the room that they are in is good, otherwise facing the same way as everyone else works as well. All of the spawns that I made have co-ordinates rounded to the nearest 8, and angle to the nearest 15, but you don't have to be that anal if you don't want to. The only other thing that I would recommend is that you try not to put someone directly infront of someone else, otherwise they'll get a rocket up the arse. Out of sight of monsters is also a good idea if possible, as some of the monsters are a lot more powerful than in id1.

I can look at a few maps for spawnpoints. I'll start at the bottom and work up the list. I likely won't be checking for other issues though.

[Lardarse]

Small addendum: coagula2 and coagula3 are in already, coagula isn't. I'll look at the coag2 pack maps (tyrcoag, pushcoag, etc) first, as I downloaded them earlier.

Edit:

tyrcoag: Not suitable. There is very little room in the starting area. The existing coop spawns are the only available places to put them, which are all too close to the start point, which will cause telefragging on map load.

pushcoag: Probably not suitable. The starting area is a large platform which moves up, and never moves back down again. Could work if we abandon the existing spawn locations, and create new ones that are 1000 units higher (from a Z of -1322 to -320), and have the players fall onto the platform. Do you think this could work?

discoag2: Might work. No existing coop spawns, enough space to put a few. But the readme file for this map states that there are issues in coop. There is 1 lift that's a tight squeeze, but there's only a key at the top so it's not a major issue.

nesp10: Probably not suitable. Plenty of space in the starting area (although the existing spawn points face the wrong way, which isn't worth is fixing), but the early part of the map is full of narrow paths with no passing space and parts that make traveling across them in groups very difficult. If you do include it, there's a door that needs removing (the one with a shambler behind).

jesus: Suitable, if you can find a way of dealing with the 2 blue bastards that are right next to the spawning area. They can be made to just jump straight off, but I'd rather not rely on that happening. It should be possible to selectively remove them, somehow. Needs spawnpoints, but there's plenty of room for them.