Filthy Gringo

Merging logic like this should be fine, multi-casting is encouraged as a more efficient use of resources. Despite Bethesda's response, you can perform your own checks to try and identify the cause. Maybe check your objects and see if you're deleting something early on that might be referenced later in the map. Also check integer and number calculations to see what they're doing. Check nodes that delay inputs/outputs to try and figure out what will happen when they execute. Just spit-balling here, but the editor is young and there are probably lots of issues that haven't been uncovered yet. That doesn't mean we can't help isolate and report them.

Co-op maps require lots of finicky code to effectively manage demon spawns, especially if you want to revisit rooms and maintain the pressure with demon spawns. I had to code a solution that essential disabled room spawns and objectives until all players are present. If even one person leaves the rooom to explore elsewhere, it would break the spawning system, so all enemies get removed and certain key objects disappear. You *could* devise a system that captures live demons in visited modules, caches them in cached objects and respawns them when the players enter again, but it would be a resource-heavy solution and require a lot of work. The simpler solution, as VentedPennies suggests, is to keep your players together. If your map uses scoring, you might want to use the AI iterator to remove demons. Killing them might mess with the score. Another thought - you could store the number of alive demons in an integer count when leaving a room, then create a random spawn system that populates the room with the counted number of demons when players enter again. Would require a bit of work. With a bit of mathematics, you could even devise an integer storing system for all demons by picking a unique number for each demon that, when added together, doesn't clash with other demon types. But I'm getting ahead of myself I think.

You can manually place demons and link them to an objective to show their health. Manually placing demons allows you to trigger events when they reach a specific % of health. Other than that, I'm not aware of any. Is that what you're after? Health and armour tracking properties/variables would be helpful in a future update.

If you're looking to modify the base damage for a player, I'd recommend using a number instead of an integer. All base player stats are number-based, and if you use integers you'll need to do a conversion to number to apply them anyway. Also note that numbers are percentages. 0.01 = 1% 0.1 = 10% 0.5 = 50% 1.0 = 100%

Yeah, that's rough. I was deleting some old backups post-update and found I couldn't touch a couple of them because they were corrupt (mostly the ones with network, memory, and object resources over 90%). That update broke a lot of WIP for some people. I wonder if any of the published maps suffered. I create a new backup after significant changes, or every few days (whichever comes first). Saves a lot of heartache.

Try setting up a counter variable to check how many AI are spawning in and getting killed again. I've seen a few posts floating around that mention issues when having an AI conductor module and spawn events together in the same map. The AI conductor does a lot of cleanup work which can break spawn events and logic chains dependent on Event Finished nodes. If the counter goes up, but doesn't come down again accurately then you have a problem.

Alternately, you can set up a player resource called something like Armour Pickup Value. For each of your Armour pickups, you would need to set the Armour Pickup Value resource (setting it to the exact value the Armour gives you). You would also want to cache the Armour using the Cache Object module. Then you would have a standalone node for Armour Pickup Value -> On Changed, test if the user is allowed to pickup armour. If not allowed, deduct Armour Pickup Value from Players Armour, then respawn the Armour by referencing the cached object. Haven't tested this, but the logic should work. Not sure how the coding works in the background though, may do strange things if 2 players pick up Armour at exactly the same time. It's still extra coding, but less than if you filtered every spawn, and it works across all players.

Variables can be calculated and assigned on the fly. The devil is in the detail. Create a branch from the node you want the calculation to fire from, point it to your variable, choose the type of calculation (addition, subtraction, multiplication etc) and you're set. No need to "Set" values. The output of the calculation will change the value of the variable it's linked to automatically. You can even change to value in the calculation node to a variable, which paves the way for things like a scaling experience points systems, or scaling demon difficulty. I've used this method extensively for exactly this purpose in the map I'm creating. Hope that makes sense. I'm not in front of my computer atm but can provide an example later if required. Also worth mentioning that the order in which you connect events to a node determines when they get executed. For example, say you had a Module->On Entered node with 2 branches hanging off it: one branch adds 1000xp to an xp variable and the other branch gives the xp to the player proxy. If you connected the "give xp to player" to the On Entered node first, then connected the "increase xp value" second, it would give the player xp then increase the xp value. If your XP value starts off at zero, you'd give the player zero xp. All you'd need to do to fix that is delete the line connections to the On Entered node, then connect the "increase xp" branch first, then connect the "give player xp" branch second. You can have a whole bunch of stuff fire in sequential order without needing to perform nasty logic checks or time delays just by connecting them in the order you want them to process.