R Soul on 2/4/2018 at 01:18

---

I recently released an old city mission by Tomi and I ((http://www.ttlg.com/forums/showthread.php?t=146106&p=2387637&viewfull=1#post2387637)). This was intended to be a hub-style mission. One of the challenges faced with that sort of mission is that the Dark Engine doesn't support hubs, so authors have to make several copies of a single mission and adjust each one. One drawback to that is that if you want to make a change to the terrain brushes, you may have to do it three or four times.

While preparing the above mission zip file, an idea occurred to me:

We could combine TrapCampaignQVar (from tnhScript) with KDTrapNextMission (from KDScript).

Let's say you want the player to experience this: Hub, Mansion 1, Hub, Mansion 2, Hub, Caves.

The files can be like this:
miss17: Hub
miss18: Mansion 1
miss19: Mansion 2
miss20: Caves

Only 1 Hub mission.

I think it could work like this:
In missflag.str, the two mansion missions can be followed by the hub with these values: miss_18_next: "17" and miss19_next: "17"
In miss18, TrapCampaignQVar can be used to set a qvar called HubNext to 19. The _next value in missflag.str will take the player back to the hub.

Whenever miss17 starts, a QuestVarTrigger can activate if HubNext is > 0, triggering a KDTrapNextMission, which sets its next mission number to the value of HubNext (design note syntax: next_mission_on=$HubNext)

In miss19, another TrapCampaignQVar object can set HubNext to 20. The _next value in missflag.str will take the player back to the hub again.

Once again in miss17, the HubNext will be >0, so the QuestVarTrigger will trigger the KDTrapNextMission object again. This time the next mission number will be 20.

Mission objectives could also be shown based on that qvar. A while ago I wrote a custom script, SetMultQVars (which uses Squirrel.osm), which can change multiple qvars using just one object, so at the start of miss17, objectives will initially be invisible, and if HubNext is 0, a SetMultQVars object can reveal the the first set of goals. If HubNext is 19, the second set can be shown, and if HubNext is 20, the third set can be shown. The mission may have 16 goals but only some of them will be visible during any one visit to this mission.
- I'm not sure how making a goal visible works in conjunction with the min_diff and max_diff values, so that'll need some consideration. What will happen if the player is on Expert (2) and the above scripting system tells it to show a goal whose max diff is 1?


The most complex task will be managing different sets of objects for each visit. I think it could be managed with metaproperties. Create three custom metaprops (Visit1, Visit2, Visit3 etc) and add each one to to appropriate set of objects. All three sets objects can be hidden below the mission and teleported upwards when HubNext has the correct value, and if not, deleted (will the stats screen update when AI/loot objects are deleted?).

For testing in Dromed, you can use the highlight by archetype command (e.g. Visit1), and the multibrush highlight command to move each set into or out of position. To move them in game via scripting, choose nice round numbers for the offsets, e.g. 100, 200 and 300 units for each set. Each metaprop can have a receptron that moves its object up by the same value as its downwards offset. I think you could use a set of NVTrigQVar objects to send a stim to all objects with each Visit metaprop (e.g. NVTrigQVarTDest="@Visit1") based on the HubNext value.

Do you think the benefits of having one set of terrain brushes outweighs the complexity of having to manage multiple sets of objects? Bear in mind that I'm not planning any Thief FM at the moment, but I'd still be interested to hear other peoples' thoughts on the matter.

ZylonBane on 2/4/2018 at 02:05

---

Well, the Thief version doesn't. The SS2 version supports them like crazy. Arbitrary links from any location in a MIS to any other location in another MIS, carry-over of inventory, can even carry over stuff laying on the ground nearby. It's pretty awesome.

Yandros on 2/4/2018 at 03:49

---

I would assume it's possible, sure. But I would also imagine if it hasn't been done already in 6 years, it's probably a huge undertaking that isn't likely to ever be done. We can always hope, though, like also getting SS2-level MP support in NewDark.

SlyFoxx on 3/4/2018 at 14:04

---

Just reading stuff like this makes me glad we have people like R Soul, ZB and Yandros around here. The way I use (used) DromEd is akin to a cave man wondering why that brightly lit log burns my hand while you guys have harnessed fire to make steam engines that run everything in sight.:o

R Soul on 4/4/2018 at 19:23

---

I forgot to mention in the first post that active and inactive area brushes could be used to hide them, which may prevent the viewports becoming cluttered, so it wouldn't just be a case of moving them for the sake of it. However, I have no problem with people avoiding this method if they can.