joebarnin

I don't know of any "pure" way of doing this. But I think I've come up with a semi-kludgy way. Assumptions: path_cornerA points to path_cornerB (if guard) or path_cornerC (if thug). On the path_cornerA, target a atdm:target_callscriptfunction. This callscriptfunction object has the following spawnargs "foreach" "1" "call" "pathChoice" "target" "pathCornerA" path_cornerA also has two custom spawnargs: "guardPath" "pathCornerB" "thugPath" "patchCornerC" Write a script function, 'pathChoice': void pathChoice(entity ent_pathnode, entity ent_ai, entity ent_callscriptfunction) { if (ent_ai.getTeam() == 2) { sys.println("guard"); entity nextPathGuard = ent_pathnode.getEntityKey("guardPath"); sys.println("the next path is " + nextPathGuard.getName()); ent_ai.stopPatrol(); ent_ai.addTarget(nextPathGuard); ent_ai.restartPatrol(); } else if (ent_ai.getTeam() == 6) { sys.println("thug"); entity nextPathThug = ent_pathnode.getEntityKey("thugPath"); sys.println("the next path is " + nextPathThug.getName()); ent_ai.stopPatrol(); ent_ai.addTarget(nextPathThug); ent_ai.restartPatrol(); } } The script code determines whether the AI is a thug or a guard, and gets the appropriate custom spawnarg from the path_corner. You just need one pathChoice script. For each of the "decision" nodes, you need an atdm:target_callscriptfunction that targets back to the node. And the node needs the "guardPath" and "thugPath" spawnargs. Not perfect, but hopefully good enough?

The mission was quite large, and I wanted to have checkpoints at the end of each "chapter". Just to keep people from losing too much if they forgot to save. Glad to see that it's probably fixed

ai_should_not_close spawnarg on the door will leave it open. To get them to close it later, maybe use Path objects to get the guard to interact with the door (that will close it and lock it I think). You may have to do some scripting to dynamically get the guard to interact with the door only when it is open. No idea if this will work, just throwing out ideas.

The mission count for 2024 is even more impressive when you realize that one of them was @JackFarmer's epic campaign Hidden Hands: Blood & Metal, which was really five missions in one!

Great stuff, this will be a lot of fun to play with. Speaking of gravity, is there any way to reverse gravity, so that the player falls up? I experimented a bit with calls to $player1.setGravity with positive numbers in the Z direction, but the results were weird. Kind of seems like the player is turned on his head? Anyway, I wonder if the game engine isn't meant to handle this. It would be nice if it did, for a mission that I'm working on.

I don't know if this will help, but my mission Now and Then dynamically creates readable content, based on user actions during the mission. So I know it's possible to have variable content in readables. In nowandthen.script, check out adjustFutureReadables(). It does a ton of work, and is lot more than what you need, but it does show the concept of setting the value of readable variables (e.g, "page1_body") dynamically.

Fun little mission. I always appreciate verticality. Looks like a good starting point for a larger mission?

A simply gorgeous mission! I love the unique textures, especially the stonework in the storehouses/market area. Intriguing layout, both of the storehouses and the ship. The lighting was outstanding - visually, and from a gameplay point of view. Here is some z-fighting that I noticed: https://www.dropbox.com/scl/fo/prpoujb1lhd5ybftw3von/ACbqye0LJOevb6FZipoS8sM?rlkey=cyfx6z3st6v1du0cmedoi51od&st=zldqvjoh&dl=1

Wonderful mission(s)! Love the airship design, including the I did them in order, which is probably how it was designed. But I wonder how it would be to do them "out of order"? Too late now. One thing, when doing the Mortimer mission,

I agree with @SeriousToni, I like missions where you can see inside from outside. A nice touch!

Okay, I think I see the problem. I have two keys, same inv_name. They both stack and can be dropped: And a door: Each key opens the door fine. If I pick up both keys, the "stack" still opens the door. The problem occurs when I have a stack of keys (in this case, two), and I drop one of them. When the stack size is >= 2, the dropped key is created based on the classname of the item (which in this case is atm:key_mysterious). The unique spawnargs of the original key are ignored, so the inv_droppable, inv_stackable, and inv_name spawnargs are not used. In this case, the dropped key is named "Mysterious Key" (the default inv_name for that classname), it is not droppable or stackable, and is "name" is generated on the fly (in this case "idMoveable_atdm:key_mysterious_7"). This behavior is confirmed in a code comment: // Stackable items only have one "real" entity for the whole item stack. // When the stack size == 1, this entity can be dropped as it is, // otherwise we need to spawn a new entity. The upshot is that the dropped key behaves incorrectly: it has the wrong name, so it won't open the door. It isn't stackable or droppable anymore either. If I drop the "second" key (the last one in the inventory stack), it'll have the correct name and spawn args, so it will work to open the door. Now, solutions. It would be nice to use used_by_inv_name, used_by_category, or used_by_classname. But this wiki entry says right at the top "DOES NOT WORK FOR DOORS - use the normal key method". So those spawnargs don't work for doors. One possibility is to avoid key stacking in the first place. As soon as the player grabs a key, delete all of the other keys that can open that same door (I think @JackFarmer did this his most recent mission?). So for example, keys A B and C all open a door. If the player picks up A, delete B and C. If they pick up B, delete A and C. And so on. That way the keys will never stack, and you avoid the whole problem. It kind of avoids the key accumulation problem too. @DeTeEff Will that work for you?

I’ll take a look

I like the curves (bridge & road)

Wonderful mission. Beautiful to look at, nice geometry. Good use of verticality. I was I found a few issues: https://www.dropbox.com/scl/fo/ymo4atbtil7v4twke4zwj/ABKgFsFTeXiUAsyQ6Q7kxiI?rlkey=zwxi27vkvo19c4nfaindmjz4v&st=crogqgmk&dl=1 The readable screengrabs show the problem reading from left page to right.

I think if you create spoiler section, and then drag in the graphic into it, you should be safe. But if you're really worried, store the graphic out in a free file storage site (e.g., Dropbox) and put a link to it in your post.

See https://wiki.thedarkmod.com/index.php?title=Doors#AI_Door_management. Looks like ai_should_not_handle is the spawnarg you want.

Hmm, interesting. I know The Painter's Wife mission updates the map as you traverse it (it shows you where you are on the map). So I guess that technique could be extended to actually color in the whole map as you travel.

I actually appreciate missions that confuse with their complex geometry. It can be frustrating, but it's all part of figuring things out. YMMV.

Congratulations on this epic release! Taffers, this is a brilliant campaign. For those who want to play this 'blind', I'll put some comments in spoilers (they don't spoil much, but just in case) Bottom line - take a deep breath, allocate some time and PLAY THIS!

I've been prototyping something very similar. The idea is, if an object is in your FOV, you don't see it. If your "back is turned", it's there (and you can see it in a mirror). I've got it working, except for some edge cases. I'll be happy to share what I've done, once I clean it up.