The Grand Mapedit Assistance Compendium

[Daedalus]

You've said quite a few things. I'll address it all in order.

It doesn't really make sense in Blood's logic to have a door require a key after it didn't previously. Unless you're deliberately looking to make something strange, I'd avoid this. What will probably better suit your needs will be having the door 'lock' upon the player entering the room. There are quite a few ways in which to approach this problem depending on your style and choices. You could simply have the door lock. You could have bars raise/lower that block the door from the inside. You could simply make it that the door doesn't open from the inside without the use of a button. As always, Mapedit can produce almost anything you can imagine, but some things are far more difficult than others to pull off. I think you should first decide on what you think would be the nicest way in which to manage this and then we can take it from there. What mechanism would you really like that indicates that the door no longer works? What means would you like the player to have to use to exit after the boss is dead?

So there are quite a few guidelines for implementing multiplayer modes. These are the hard rules you need to follow for individual modes.

For co-op:

• Keys must be specifically marked for respawn type when 3: permanent. That reads strangely in English, but basically just look for the respawn section in the key's properties after hitting ALT + F6 and make it 3: Permanent. This means you will need to duplicate all keys and have them differentiate between single player keys and co-op keys, which is a skill it sounds like you've already figured out. This means that the key will remain as an item that can be collected repeatedly and won't disappear. It's extremely important to always be mindful of the fact that in co-op players will die. Always expect them to die and accommodate that. If the key acts as it does in single player and the player carrying it dies, the area it is meant to unlock will be inaccessible and the game will be over, which is no fun.
• Be mindful of traps, environmental destruction and so on that might prevent the player from traversing parts of the map a second time. Again, if a player dies, they should be able to return to where they were upon death. A bridge which blows up, for example, will prevent a player who dies from reaching the same point and their game will be over. You need to establish a separate ruleset in co-op which allows players to not get stuck. A perfect example of this is your boss carriage on your train. If both players enter and die, and the door locks forever, they will be unable to try again and the map will be unable to be completed.
• Not so much a hard rule, but to set up the player starting points in co-op you need to place eight (or seven, but I'd advise against being lazy for player 1) starting points. Give them Type 1: Player Start. Data1 from 0-7 will allow you specify them for each of the players up to a maximum of 8, of course. Mapedit is zero-based, so 0 is player 1 and so on. This isn't critical, but if you don't create them, co-op players will start on top of each other, which feels amateurish and lazy. Mapedit is kind enough to give the little flags numbers for an easy visual reference in 3D mode.

For BloodBath and Teams:

• Player start locations for BloodBath and Teams are determined with sprites of Type 2: Bloodbath start. Again you will need 0-7. These are important to distribute sensibly around your map.
• Not a hard rule, but a bit of good hygiene, in BloodBath and Teams players always have all keys. Key door markers should not be present in this case, since they do not offer information of any value to the player.
• Red and blue bases need to be set up for Teams. For blue team's flag, you will use Type 145: Blue Team Base. This needs to be assigned the reserved RX ID of 80 and its STATE must be 1: ON. Red team's flag will use Type 146: Red Team Base. This needs to be assigned the reserved RX ID of 81 and its STATE must be 1:ON.

Secrets are actually quite easy to set up. You need to think of an event that will "count" as having found the secret. Perhaps it's collecting an item, or stepping into an area. Whatever the case, you will give the "sender" the attribute of TX ID: 2. This is a reserved flag which - you guessed it - marks it as a secret. The second part is a little weird. Don't dwell on it too much, but you also need to send CMD: 64: 0. This is another reserved number that informs Blood that it needs to convey that it's a secret. After those, it's just a case of triggering it, so for example, sending it at ON when picking something up, or stepping into a certain spot, etc. The only difference for a super secret is that you need to instead send CMD: 65: 1. That's it.

Phantom Express uses Blood's iconic train horn sound at its start. This is a SFX Generator which plays on the map's start. The sound ID is 276.

Unfortunately, Blood's monsters can see through any sprite configuration you make, no matter how difficult it might be for humans or Caleb to see through them. This is a limitation yet again when making sprite ceilings, and you will need to be careful with your placement or think of a solution you're happy with.

Blood's monsters can't interpret sprite constructions as paths either and they'll spin in circles when they can't find a path that they think is suitable. They can of course step on them, but they don't know how to traverse them instinctually as a player will. Yet again, there is no real solution to having monsters cross a sprite construction without solutions that basically defeat the purpose of having that sprite construction. This is a limitation to be aware of your future map creation.

I am pleased to hear that you are planning to make a full episode. That is a very bold decision which will require a tremendous amount of patience. I am eager to see what you come up with and will of course be around for whatever issues may arise.

[RoosterMange]

For the door, I'd simply like it to lock behind the player. A co-op solution to that may be tricky. Maybe I could add a sensor outside the room that unlocks it so the players may re-enter? The only issue is that the boss drops the key, and I'm not sure if I can make that respawn. I may just have to put a co-op key inside the room behind the boss, but that may allow players to skip the fight altogether.

The issue regarding my sprite ceilings is a major roadblock, as my initial intention was to have players battle monsters on the rooftops as they traverse the train and make their way to the boss car where they'd obtain the key, turn back around and go through the train they ran on top of, and end up fighting more enemies on the way back to get into the engine room. I suppose one solution could be to have the monsters inside the cars spawn only after the boss is defeated, which may cause issues for co-op but shouldn't be too major. The biggest problem is the enemies on top of the train. If their pathfinding is broken and there's absolutely no way to remedy this, it defeats the purpose of having enemies on top of the train to begin with. Is there any way I can still make this concept work? The best compromise I can think of is gargoyles, but too many of them is never really fun to fight. Let me know what you think and if there may be an alternative way around this.

For now, I'll go ahead and start marking secrets and adding that train horn, as well as the spawn flags and such.

[RoosterMange]

Upon testing with gargoyles, they see me from way too far away and they ruin the flow of the level. So they won't work here. They're incredibly boring to fight when dynamite falls through the roof for seemingly no reason. Is there a way to fix this so the dynamite properly collides with the roof and doesn't just fall through the floor? This not only causes frustration in singleplayer but it would be wildly unfair in bloodbath. I didn't realize so many issues would arise just from making the roof out of sprites.

Edit: I was replacing some of the sprite crates in the storage car with sectors so they wouldn't show through the roof as much, and for some reason the lighting effects are only applying to a single side of one of the sectors, meaning that part flickers while the other parts don't. I have no idea why it's behaving like this but I'd like the effect to actually apply to all walls like it says it will.

[Daedalus]

So for literally locking the door, your solution will work. A command would need to be sent to have the door close and lock when reaching a certain point in the room. The boss dying would then perhaps need to send the unlock command. The key indeed will not work for co-op play and you may need another solution in place, or to accept it. In general it feels to me like you're quite concerned about how co-op will play out. Unless you're specifically considering making a particularly strong co-op experience and are presenting your creation as such, I wouldn't stress about things too much. Co-op players will be happy as long as your map has a good enough flow and they don't get stuck by the map's design. Trying to optimise everything so that co-op is perfect isn't really worth it in light of the fact that fewer than 5% of your players will be playing in co-op mode. As long as you apply the 'core' rules to your design for co-op, co-op players will be satisfied running around and causing mayhem.

As I have said, making a "roof" out of sprites is problematic at the best of times and I'm sorry to hear you're struggling with it. I think your only real compromise in this case if you want to have some fighting on top of carriages is to either rethink and have some closed carriages which deliberately enable that, or to basically structure some of your carriages in such a way where substantial portions of them are "solid", after which you can use those segments to have monsters on. Zombies will probably not be good in this situation, but I can easily see cases where you could have cultists with a bit of an "island" that they can traverse. Picture this as a pillar when one is inside the carriage. This would then just be a raised floor that the cultist is perfectly comfortable shooting from. It's perhaps not so exciting assuming you specifically want the monsters to run to the player, but it's better than ineffective monsters. Your idea in this regard is cool, but it is very lofty for a new mapper and you're contending with something that Blood is quite weak with regarding its functionality.

Dynamite will be a bit annoying when it comes to 'passing through' sprites. This is yet another irritating problem. I can only suggest double checking that the sprites are hitscan sensitive and blocking. You can also try adding an invisible plane in the form of a large invisible sprite that can serve as a backup - basically another 'check' to try and stop the dynamite.

For your lighting problem, there are a few things that could cause this. Be sure that the lighting effect is applied to your sector as a whole. If so, are the walls that are unaffected 'red' or 'white'? Blood loves taking properties of previous sectors, walls and such and applying them to future ones, so check if perhaps the walls aren't attaching something weird such as your bottom-swap on the walls being applied in some way. Mouse-over them in 3D-mode and press '2' and see if that's not perhaps causing it?

[RoosterMange]

It's not so much that I'm particularly concerned with co-op mode, I'd just like my maps to be suitable for all gamemodes. Especially since I intend to play them with friends on different modes. I think having a motion sensor unlock the door from the outside would make it easily accessible again in case the players die in the boss car. I'll figure that part out later, right now I'm focused on making the map itself flow better.

How can I make the door slam closed and lock when the player enters the room? I assume I'd need an invisible floor sprite that sends a signal when it detects motion. That's about all I know.

Your pillar idea sounds brilliant. I could have tommy gun cultists on specific spots where they'd shoot from and the player can fire back with their own tommy gun. I may or may not have fixed the issue regarding dynamite. I still need to do further testing but it seems that making the sprites overlap more has helped.

When it comes down to enemies seeing the player from within the car while Caleb is on the roof, I've decided I want the enemies to just spawn in after the player is done with the roof segment. I'm unsure how to do this, but I'm thinking it could be motion activated so the monsters spawn at the appropriate point in the level.

The walls or rather crates that are supposed to be flickering are red sectors, no different than the walls of the car which flicker fine. For some reason, one side of one of these crates flickers while the rest don't. The whole sector is set to flicker as far as I can tell, so I'm unsure why only some parts are being affected. I'll try pressing 2 like you said to see if that affects it, otherwise I may need further assistance looking into this. There may be factors at play that I'm unaware of.

Edit: the walls were not bottom swapped and I can't tell if they have any different properties than the walls that do flicker. Very odd that one portion of the crates decided to flicker and the rest do not. I wonder if this weird phenomenon can somehow be applied to my doors to stop them from flickering. In any case, I'm really unsure how to get these crates to react to the lighting fx as intended

[Daedalus]

There are many ways to slice it up, but for your boss you could try have a "touchplate" for the floor. Basically just a sector that when the player enters, it sends a command to the door to lock. This would be CMD 6: Lock. Give it a try.

Your crate situation is perplexing. Please confirm that it behaves that way in actual gameplay and provide a 2D screenshot of its structure?

[RoosterMange]

In 3d mode and in game the behavior looks to be the same. Here's an image of the sector:

image_2024-03-15_042503383.png (10.34 KiB) Viewed 177 times

For the dynamite, I may just need to use that idea of making an invisible sprite layer to ensure no dynamite slips through. I want it to realistically interact with the roof so players have the option of using it without it being broken.

I'll try out that touchplate when I get a chance. Is there anything else about it I'll need to know? For example, how to have the door be unlocked initially and how to set the key for the door. I'm sure it'll be fairly straightforward. For now, I think I'll get some shuteye and work on the map tomorrow.

[Daedalus]

Depending on the scale of things, you may need to have a second door which closes which is the one that requires the key. There is no way in which to switch a door from requiring a key to not requiring a key in Blood. It is slightly unorthodox for Blood, but it should be fine for you to proceed with that plan. You would in that case only need to make a door with STATE 1: ON, which then receives an OFF command from stepping on a sector.

Going with this rather unusual approach, you'd do this:

Make a square on the ground, or at least identify part of the sector inside, but away from the door which then has a TX ID that transmits to the door, and have it send an OFF command on player ENTER. It should be away from the door because you want the door to completely close before the player can reach it. This is quite a nuisance in Blood because the player is very fast, but if ever you really want a player trapped, you need to make the door very quick to close to ensure the player is stuck. This door will need a key value assigned to it depending on whatever key you want the boss to drop.

The door itself will only then need to have its STATE be 1: ON, so that it starts the level open. This system should be suitable and work for what you're trying to produce in this way.

This then presents a logic problem in co-op. If the door closes, players will be trapped outside forever, so what do we do? We could forfeit the trigger for closing the door altogether, but this then thwarts your plans to have the players be trapped in co-op. However, we cannot 'reset' the boss position anyway, so if co-op players die endlessly, which you should always assume, there is more or less no way in which we can keep the boss from reaching the door and leaving the room. In this case, and depending on how you feel, you may want to consider doing away with trapping the players altogether in co-op, otherwise you will need to come up with an alternative solution.

For your image, please explain which sides of the boxes are working as expected and which are not. Also double check that the appropriate sectors are marked with "ShadeAlways" and for "Walls" to be affected. Basically, I need a little more context for this.

[RoosterMange]

The left side of the lowermost square is flickering as intended, and so are the walls of the room. The rest of the crates do not work. The sector that touches these walls and crates is set to "shadealways" and to affect walls, so theoretically it should apply to all of them. As you can see, the crates all touch the largest sector in the screenshot (the one with the lighting fx) aside from some sides which are meant to be casting shadows. The sides exposed to the light don't react to the lighting fx whatsoever.

[Daedalus]

My suspicion remains that the walls of the crates have bottom-swap on. Go to the ceiling/sky and unparallax the offending boxes, bring their 'ceilings' down, then mouse-over the corresponding walls and press '2'. See then if the 'bottoms' of the crate walls, i.e. those in the room are behaving afterwards. Hopefully that makes sense.

[RoosterMange]

I unparallaxed a portion of the cieling above a crate, lowered it, and bottom swapped it as you asked. It seems to have no effect on the lighting fx regardless of whether it's bottom swapped or not. I even tested it on the side that was flickering, and it still flickered either way.

[Daedalus]

Two more suggestions. Delete the boxes which aren't working correctly by mousing over them and hitting CTRL + DELETE to make them white and then "make them red" again. If after that they still aren't working correctly, assign the same lighting effect to the boxes themselves.

[RoosterMange]

I took one of the boxes and made it a white sector, then changed it back to red. It made the top of the box flicker, but the rest did not. I tried the same thing on the box that had one flickering side, and that side continued to flicker while the rest didn't. I checked the lighting fx for that sector and the settings appear to be the same as the lighting fx for the large sector that is supposed to be affecting the crates.

[RoosterMange]

I'm very proud to say I finally figured out what the issue was. The boxes actually were flickering, but because of the shading level they didn't visibly change. When I changed the shading level, I noticed it actually started to visibly flicker. Blood is very odd with its shading levels and sometimes there's no difference between levels. I'll keep this in mind if I run into this problem again, and I think I'll be able to stop the door from flickering by changing the shading value.

[RoosterMange]

For my door, the motion sector may be a problem. What I originally intended was for the player to fight a giant horde of zombies (significantly larger depending on the difficulty) and then when they're done, they would open the double doors which would very slowly swing open to reveal the priest standing all the way at the end of the room. When the player enters, the door would quickly shut and seal them inside so they're forced to fight the boss.

If the door was to start out opened, the priest would surely see the player prematurely and begin approaching. This would disrupt the flow of the level because there would likely still be zombies left to distract the player. There's also the risk that the priest leaves the room and even falls off the train.

In e1m2, there's a room where the doors close and you must fight all the zombies before you can leave. It seems as though the doors detect the enemies left alive and only open once they're all dead. Maybe something like this can be used instead?