joebarnin

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.

For #3, there's a setSkin() script command.

I don't think you can 'reset' a trigger_once. One way to do what you want is make it a trigger_multiple (wait = 1), then write script code that sets a flag the first time the trigger fires. The code that processes the trigger_multiple only does it if the flag hasn't been set. E.g. boolean hasTriggered; // code that processes trigger, only once void myTriggerCode() { if (!hasTriggered) { hasTriggered = true; // do whatever you want the trigger to do here } } void main() { hasTriggered = false; } Then, put additional trigger_multiples around the main trigger area, and all these do is reset the boolean (hasTriggered = false). So when the player leaves the trigger area, the flag gets reset, so when they come back, the trigger is processed again.

I'm sorry about your frustration - I'm glad you've stuck with the mission so far. As for the library:

Sure. It's a bit rough now. I'm going to clean it up and do some more testing. Once I'm not embarrassed to show it to others, I'll post it here lol.

What I ended up doing is to getting several pieces of data: the position of the player's eyes (getEyePos()) the position of the object ($object.getOrigin()) where the player is looking (getViewAngles()) the FOV of the player (getFov()) and doing math/trigonometry to determine if the player can see the object. This code is not general purpose, since it doesn't deal with walls/obstacles/line-of-sight. In my case it will only need to run in a certain room, so it'll be "good enough".