The Grand Mapedit Assistance Compendium

[RoosterMange]

I finally got around to finishing up that bar car. Things have been busier for me lately but I'm still planning to finish this map. I noticed that in some retail Blood maps, lighting fixtures can be destroyed and cause the room to be darker as a result. I wanted to do something like this on my train where chandeliers or lamps can be broken and make the room dark. How would I go about this? On a similar note, how could I make light switches to toggle the lights in a room?

[Daedalus]

A light switch and destroying a light source have quite similar functionality. Let's start with destroying a source of light.
As you may be familiar with by now, this will of course be using the same trigger system as we've used before. You will set up a sprite which will send the command and a sector, or multiple sectors, which will receive the command.
Mapedit is incredibly flexible and powerful, so you can try accomplish basically anything you can imagine. You could make anything change the lighting in a sector, really, but in this example you would make a sprite which would logically emit light. After you've found one that you're happy with, mouseover it and hit ALT + F6. All you would need to do here is set it to type 416: Gib Object. Then set up a unique TX ID for it. By default, the command (Cmd) will be set to 0: OFF, which is what we want. The last thing you'll have to do, then, is set it to send when going OFF, so check that box. Remember that this reflects the internal state of the object itself. In this case, what we're saying is "when this sprite is destroyed (shifts to an OFF state), send a command to change something else to an OFF state". You'll probably want to set up the gibs and sound for the gib object so that it feels a little more natural when you destroy it, which I've covered above.

Now you have a sprite which you can destroy which sends an OFF command, but we still need to set up a sector to actually receive that command. What I would suggest in this case is that you build your area you want the light to cover as if the light is off, so, basically, create it in the darkened state as if the light was off. Once you're happy with it, for each sector that you want affected by the light source being destroyed, mouseover it and press ALT + F5. Assign the sector an RX ID that matches the TX ID of the sprite you created. Next, just below that, set the State to 1: ON. This sets the default state of the object. In this case, by default we have the light on. Now we're almost done. The last thing you need to do is go to the "FX . . ." section and press enter. This will take us to a new page filled with effects we can apply to a sector, with some interesting options. In this case we're trying to do something fairly simple. On the left side, where you start, you will already be in the "Lighting" section. You need to set the amplitude to a negative number. A positive number indicates increased darkness, while a negative number increases brightness. As a general rule in Blood, you want reasonably strong contrast between light and dark. For this example, set the amplitude to -30. Why are we increasing the brightness when we want things to get darker, you might wonder? Remember that we set the sector's state to ON. We are suggesting that the sector's default ON state is to have "-30" brightness. When the sector goes to an OFF state, that "-30" no longer applies, and so the sector is darker! The last thing you need to do is set this to apply to either the walls, ceiling and/or floor with the checkboxes. Usually you will want to make all three apply, so that's probably safe for now, depending on your case.

When you run the map, you should see that destroying your sprite increases the darkness of the sector you chose, and it should then match how it appeared in Mapedit before you applied the increased light to it.

Something interesting now is that I have actually empowered you with enough knowledge to build a light switch yourself. I will provide some guidance and let's see if you can pull it all together.

To start with, in 3D mode, press ALT + S to bring up the "Insert" menu. From this menu, select "Misc". You will see tile 1078 as an option, which is the light switch visual. Place this in your map as you like.

This will default to type 20: Toggle Switch, but it will have no other properties attached to it. A "Toggle Switch" is a powerful type of sprite which can alternate between ON and OFF states while sending commands. A "Toggle Switch" will also by default change its visual between the current art tile and the art tile which follows when it changes states, meaning that in the case of the light switch, it will change between looking on and looking off.

Let's see how you fare with this. As a hint, what you will want to do with this is sort of a hybrid between the properties we assigned to the walls for your sliding doors and what I have just presented above regarding lighting. Set Data1 and Data2 to 207 to have it produce a light switch flicking sound when turning it both on and off.

Let me know how it goes.

[RoosterMange]

I realized the sprite roof might make the lighting effect look odd when viewed from the top, so I've decided to wait until I make a white sector car to try making a light switch and breakable lamps. Until then, I'm now trying to make a luggage car and wanted to know if it's possible to make a suitcase with a lid that flips open to reveal some items inside. I want to reward players who interact with all the random suitcases and give them a cool secret if they find the one that opens. I'd have to find textures for the suitcase for starters, but the actual opening and closing part is more tricky than that.

[Daedalus]

A traditional suitcase on the floor which has its lid flip open in an arc is impossible to do in Build, since you'd have a true 3D sector performing a rotation on its own axis which you can observe from all sides. The closest you'd find to that structurally already exists in Blood - the Beast Vision secret in the storage compartment in Phantom Express! Ion Fury would likely go the route of a voxel which transitions instantly to an open state when being used. We don't have that luxury.

Your compromises are the following: a container which mirrors the one found in Phantom Express, a chest voxel (which is present in the game) which is destructible and which drops something or a lid which slides in a direction, which would probably look a bit weird.

[RoosterMange]

The Phantom Express box would work well in this situation, but it would also be useful to know how to make a destructible sprite drop an item.

[Daedalus]

For a change you have asked for something with a simple solution. You can make any monster or gib object drop items. All you need to do is modify the properties of the object via the usual ALT + F6 method and look for the "Drop item" parameter at the bottom right of the menu. This is expecting a value that corresponds to the numbering of item in TYPE (the first category when you edit items. For example, if you place a Life Essence, that will be an object of Type 109: Life Essence). You would in this example enter 109 in the "Drop item" section, after which the object would drop a life essence when destroyed.

[RoosterMange]

Thank you, I'll definitely incorporate this somewhere on the train. Maybe not as a secret, but just random breakables to encourage more exploration. As for the box, how could I make something similar to Phantom Express where the box swings open to reveal an item? I wanted to make a suitcase as a reference to Priest containing a Tommy gun and sawed-off, or at least some ammo.

[Daedalus]

There are a few ways in which to achieve this. In this case I'd strongly recommend looking at Phantom Express' example, since it is quite tidy but here's the basic flow of it:
Build a sector that you want to serve as the parent or container for the cabinet that opens. Within that sector, build the cabinet in an open position. We are going to make it rotate. 99% of the time you'll want to make rotating objects in their "open" position in Mapedit. So basically, you're going to in this case make two separate diagonal halves of the cabinet, which you can imagine in this case to act sort of like Pac-Man's mouth:

14.PNG (7.67 KiB) Viewed 571 times

The example above is comically large, but I'm using it just to illustrate the concept. You will repeat the structure and flip it to act as the other half of the cabinet.

Exactly as you did with the original sliding doors we made, you will have to mark appropriate walls to send a command to open it. You can decide on exactly how easy you want to make it for the player. Perhaps pushing the use key from any side opens it - or perhaps just from the 'front', but the decision is yours. Give the walls you decide on the exact same properties as you did for the sliding doors, except with a different TX ID, of course.

Now the secret here is that there will actually be three independent sectors which are having some kind of rotation performed. The parent sector will control the rotation of the exterior walls of the cabinet, and then each of the interior sectors of the cabinet (left and right, or top and bottom) will need to rotate as well. If we only rotated the exterior or interior, we would get glaring visual bugs.

Starting with the exterior, hit ALT + F5 on your parent or 'container' sector. We'll be giving this a new type "615: Rotate Marked". This is almost identical to the Slide Marked sectors you've set up before, except it commands marked elements to rotate rather than simply move in a direction. Give it an RX ID that matches what you set up on your walls.

Now this parent sector is going to control the rotation of the inner cabinet components as well. It is generally a good idea when making complex motion in Blood to connect elements rather than attempt to make multiple independent elements move in unison. So we're going to modify things further and give the parent container itself, which receives an RX ID from the player pushing the walls of the cabinet its own TX ID. This means that we'll be forming a little chain of commands: Walls of cabinet -> Parent sector -> Interior sectors of cabinet. Now we're going to issue a new command within the parent sector. This will be Cmd 5: Link. This is a powerful and complex command which guarantees that whichever objects we issue commands to will mirror the parent sector timings exactly. Don't worry too much now if that sounds a bit complicated. For now all it means is that it will control timing for the cabinet interiors. Check the boxes for send at ON and send at OFF, and give both the opening and closing of the cabinet busytimes. 10 is probably a decent choice.

Once done, there is another new step to be taken. An 'axis' will have been generated, similar to the arrows which appeared for the slide marked sectors you made before. It will be a yellow marker with a little tail. This is used to control the angle of motion which the object will perform. In Mapedit, 512 "units" of rotation equal to 90 degrees. In the case of the cabinet, we'll need 256 "units", since it will be opening at an angle, like Pac-Man's mouth. To do this, you'll mouseover the axis and push either the left or right square bracket to alter its angle. This angle will depend on your use case, but as I say, you will probably want either +256 or -256. Positive indicates clockwise, while negative indicates anti-clockwise. After setting the value, you will need to also place the axis. This is because while the sector knows that something within it needs to rotate, and we've told it how much it needs to rotate by, it doesn't know from which point we want the rotation to occur. Putting an axis outside of an object we want to rotate basically creates an 'orbit' for that object. In our case, and in 99% of cases, you will want an object to rotate around its central point, because this then creates the impression of the object logically rotating in its current position, creating the effect of a rotating door, for example. This is all an elaborate way of saying that you need to put the axis somewhere central to where you have your rotating objects so that they will behave as expected.

The very last thing we need to do for our cabinet exterior is of course mark it for motion with "K", just as we did for sliding doors. For every exterior cabinet wall, mark it either blue or green. In our case, one half will be blue and the other green; one half of the cabinet will rotate "forward" and the other half "backward".

With this done, the exterior of our cabinet should gracefully open and close. We have not yet finished, however. The very last thing to do is set up the cabinet interiors.

For both cabinet interior sectors, also give them the type of "615: Rotate Marked" and give them an RX ID that matches your parent sector which sent the Link command. Thereafter, you will have to set up the 'axis' and place it in a central point for both, and then mark the interior walls as blue with "K", to indicator that there's motion.

When this is done, you will have a cabinet which rotates to open and close.

This is a fairly complex operation with quite a few new concepts, so let me know if you run into any trouble.

[RoosterMange]

I'm having trouble making the suitcase work. used your guide and looked at the example in Phantom Express, but the first problem I've run into is that the original box is a white sector that goes up to the ceiling. In the retail game, this isn't a problem because the box is pretty close to the ceiling anyways so it looks natural, but my car is a red sector and the container ends up looking extremely tall and unnatural. I tried turning it into a red sector and setting the height myself, but that comes with the issue of the top of the container being exposed. So before we get into the moving parts, the container is already starting to run into visual issues. Is there any way I can negate this?

I'm also more of a visual learner, but so far I haven't found your guide hard to follow. I just may need more visuals in the future if I run into more issues. For now, the biggest thing is trying to get the suitcase to look good before I start messing with the rotating sectors.

[Daedalus]

This will take quite a while for me to create, take pictures and write about. I will try get to it a bit later.

[RoosterMange]

When the sectors are white, they end up looking like this:

Screenshot 2024-02-06 015554.png (240.19 KiB) Viewed 505 times

And when I make the sectors red and adjust them to a height I feel is more reasonable, they end up looking like this:

Screenshot 2024-02-06 015636.png (109.23 KiB) Viewed 505 times

This is better, but the top is exposed and would reveal the contents before the suitcase is even opened. Not to mention, it looks very odd.

[Daedalus]

Looks like you're doing well enough that you might not need that picture guide.

So this is entirely expected, because again we're dealing with an artificial "interior" inside of a sector, just like your train carriages. Once again, the solution to your use case is to simulate a top using sprites. Luckily, this would actually be quite easy. Place appropriate sprite constructions in place and mark them for motion with "K", and you will achieve the illusion you're after. The danger here is that sprites do not block the player from collecting items. There is no solution to the problem whereby the player could likely stand on top and collect what's inside. Your only solution to that in this case is to adjust the scale (height) so that the player can't reach the item.

[RoosterMange]

The little marker with the tail doesn't rotate when I use the square bracket keys, so I'm guessing Xmapedit uses a different keybind. In any case, here's what I have currently

image_2024-02-06_072533561.png (72.21 KiB) Viewed 476 times

Edit: Okay I got the suitcase to open as intended, and decided not to allow it to close once opened. I didn't even need to do anything to the inner sectors, they move with the parent sectors already. All I need to do is add sound and add sprites that move along with the sectors.

[RoosterMange]

I tried adding sprites with the blocking flag to act as the missing piece of the suitcase, and it fit together well and went smoothly until I tried making the sprites move in unison with the sectors. I marked them for movement with k like you said, is there something else I'm missing? I can't give them the rotate marked tag like I can with sectors, so maybe it needs an rx id?

[Daedalus]

You can't assign rotate marked to sprites, and an RX ID will not affect them in this case. The sprites want their parent sector to have a motion command. By applying 'k' to them, you've got them listening for movement, but their parent sectors aren't applying motion to them. You will need to follow through with assigning properties to the 'inner sectors' if you want the sprites to move.