Updates to SKS1

After playing some Divinity2, I was feeling nostalgic for NWN. After seeing that the vault was still going and that the EE edition was on Steam, I decided to crack open the old Toolset. An embarrassing number of hours later, I’ve made a lot of progress on some minor improvements and fixes for SKS1: The Ruins of Tcheou Cherng.

It’s been fun getting into the scripts, conversations and level options.

I thought I’d add a few screenshots of how the town square at night. If people are interested, I can share more about the different factions.


The moon over the market.


The inn and the temple.


The market and Kiva Tower.

6 Likes

Great to see you again, vendalus!

The original package had outstanding DM documentation and the module appears suitable for multiplayer. If you are looking to update the module, the latest DMFI package (old but updated for 1.69 and still works) is here: https://neverwintervault.org/project/nwn1/script/dmfi-wands-widgets-109

I’d be interested in seeing an updated version run by a DM (yourself and/or others) as a mini-campaign, which I think would both be fun and a nice addition to the DMFI-certified module list (as “A Stop Along the Way” was).

1 Like

Nice! ive always been interested in seeing an asian style city but it seems thats something weve been lacking for some time. we have the rural/urban tileset and I think someone made an asian city for for a custom content challenge but i can’t recall and I know there is a nwn2 version thats very well done.

looking forward to seeing what else you plan to do with this module

Thanks for the kind words and encouragement, @Carlo.

I just checked and the DMFI scripts in the module are version 1.07. I’ll try importing the 1.09 and see how it goes.

Funny thing about the DM documentation: like many things in the module, I had totally forgotten I had done that (it was 17 years ago, after all). I found it halfway through. Now I’m working to expand it to also be documentation. It’s proving very helpful, since there are 70 quests, some of which interlock with each other.

1 Like

Thanks @Wall3t,

The tileset work that Coulisfu & Balzan did was pretty great (see https://neverwintervault.org/project/nwn1/hakpak/tileset/oriental-tileset).

Here’s a quick shot of the common room at the inn.

One question I have about the whole thing is that I’m testing using the CEP 1.69, which is what the original module was built with. I’m hoping I can get away with that for a release without trying to update to the latest version. We’ll see what happens.

1 Like

You should be fine with that CEP1 version. Players of CEP1 modules are advised to use the following version, which is backward-compatible:

https://neverwintervault.org/project/nwn1/hakpak/cep1-complete

As you may know, CEP2 is a complete rebuild, with more content - a good choice for new modules, but converting an existing module to CEP2 would probably be too much work, and certainly isn’t necessary.

Thanks @Proleric,

Good to have some confidence that I’m not doing things wrong on the CEP front. The module is using https://neverwintervault.org/project/nwn1/hakpak/cep1-complete. Looks like they are the same, it’s just that the on you linked is an exe installer?

PS - I can only image how often that question is answered in these forums, so sorry about that.

OK then you’re already using the latest version of CEP1 (those two links are the same).

When you mentioned CEP 1.69 earlier, I wrongly thought you were talking about this version but we are on the same page and good to go.

I’m getting pretty close to having the fixes and rewrites I want for SKS1 done. Soon I’ll just have a round of QA, documentation and consistency to run through. One thing I’ve been wondering is the correct way to release this.

My current plan is to release it on the current page as 1.6.0 and remove the old 1.5.x version. I have not started using the new version of CEP or the new scripting parameters, so in theory this is actually backwards compatible with the older version.

Is that what other people are doing for updates like this? Any feedback is much appreciated.

That was a boring question, so here are some images to make it more interesting. These are of a DM avatar posting with the creatures from the four factions in the DMFI area.

The Dayadhvam are a group who honor the spirits of the ancestors and are devoted to building a society based on good works.

The Maskoke are a group of elves who once ruled the area, but are now forced to defend their forests. They honor the spirits of nature.

The Yakuza are a group of assassins who have infiltrated the merchant class. They study the forbidden arts of necromancy.

The Oni are twisted demons who have come to burn down the hypocrisy of the current world.

Personally, I remove old versions, otherwise people download them. I make a note of the old download count in the description of the new download.

Regarding compatibility, even if you’ve not used any new EE features, if you’ve saved the module in the EE toolset, it’s incompatible with 1.69 (unless the player knows how to tweak the version in module.ifo).

Likewise, if the CEP2 haks are in the module properties custom content tab, players will need to download CEP2, even if you’ve not used any of the CEP2 material.

I leave up the old (NWN-1.69) versions of my downloads on the Vault, so people who only have that can still download and use them.

For the new NWN:EE version - using the toolset makes it EE, as Proleric mentioned - naturally you can add it to the page (and label it as such in the file title to help avoid confusion), or create a new project page. I’ve gone the latter route with new versions of modules and such, including a link back to the 1.69 version in the description. For example, the DMFI 101: Enhanced Edition. This also has the benefit of displaying the new content on the Vault homepage feed.

1 Like

Thanks for the comments.

It’s good to understand about using the EE toolset making it an EE module. That’s helpful to understand.

Is anyone even playing the 1.69 version any more? Seems like that would be a small group and therefore it would be best to just remove the old file and add the new EE one.

I still play on the 1.69 version as I don’t like some of the new changes and bugs Beamdog introduced, plus I don’t play multiplayer much anyway.

After the launch of EE, I believe most new players are on the EE version (unless they bought from gog then they get a copy of the 1.69 version), but as someone who is currently making a module, I do it in the 1.69 toolset for maximum coverage, since 1.69 modules are compatible with both versions.

1 Like

I play 1.69 also for the same reasons as BowShatter.

2 Likes

I did an upgrade to Ori Rural for EE. Its buried in this rather obscenely large compilation pack - Defunct PW Project | The Neverwinter Vault

If you like it, you’re more than welcome to extract it and use it. Its a rework/reskin with new texturing based on photos I found online of various structures used by the Haka people of Taiwan and some pics of rural villages in Vietnam.

Thanks for the feedback @BowShatter and @Greenman6220. Had I understood a bit more about how that works when I started I might have tried to go that path instead. But at this point I’m pretty far down the path on updating things using EE. But it’s helpful to understand where 1.69 players are coming from as I consider how to release this.

Thanks @Pstemarie for the info regarding the Ori tiles. I would probably only try to update that if there were fixes to the stairs tiles (they can be a bit touchy on a few of them at the seams).

After thinking about it a bit more, my plan is to create a new project and mark it as a 2.0 for EE. With that in mind, I’ll probably look to release something as an alpha, sooner rather than later.

Well, not sure which stairs you’re specifically referring to as a lot of the buildings had those and I did rework the meshes on almost all of them, welding seams, redoing smoothing groups, etc. It wasn’t just a retexture, it was a nearly complete rebuild.

After the initial geometry work was done, everything was passed through CM3 with some cleanups to certain tiles in post processing.

The pagodas were rebuilt as well as several of the houses (specifically the Western style ones directly ported from Bioware Rural. I also redid the bamboo meshes as well as made some new doors. Unfortunately, I never got around to fancy mapping it - maybe I’ll do that over the Holidays.

@Pstemarie sorry, I just realized that I had not responded to you. That definitely sounds interesting, but based on where I’m at, I don’t think I can take on trying to fiddle with tile sets just yet. If I get curious, I’ll reach out.

At this point, I’m pretty close to wrapping up horses.

@Proleric (and anyone else who has played with horses), I’m trying to resolve secret door issues, following the great work in https://nwnlexicon.com/index.php?title=Builders_Guide_To_Horses#Fix_for_Transition_Bugs.

The solution seems very elegant, but I’m running into a circular dependency issue.

  1. The updated x0_i0_transport script calls the new _transition_inc library.
  2. The new _transition_inc library includes ls x3_inc_horse.
  3. x3_inc_horse then includes x0_inc_henai
  4. x0_inc_henai includes x0_i0_henchman
  5. x0_i0_henchman includes x0_i0_common
  6. x0_i0_common includes x0_i0_transport, which takes us back tot he top.

Oddly, when I override x0_i0_common to comment out the include to x0_i0_transport, it works fine. I’m wondering if that’s legacy code that just never got cleaned up? I’m trying hard to not override core files, but it seems like that might be the thing to do, here. Does that seem correct?

Update:

Well, I spoke too soon, maybe. Compiling the module scripts revealed many errors where the my various secret scripts were including x0_i0_secret. It seems like that library includes x0_i0_common as a way to pull in x0_i0_transport.

I’ve side stepped this by instead updating the call to x0_i0_secret to comment out the include of x0_i0_common and instead include _transition_inc. I then replaced the call in UseSecretTransport() to use DoTransition() instead. I rolled x0_i0_transport back to the default version.

One odd thing is that I then had to override the script on the secret item. Otherwise, it didn’t seem to compile with the module. So after all that… I’m kind of back to customizing the individual secret scripts anyway. Seems like it should have compiled and I’m scratching my head as to why.

At least now I’m only overriding with x0_i0_secret and I have a path forward.

I’m very close to releasing something. I’ve got all my secret doors working (with some nice code to always open the other side also). I’ve also got all of my transitions working with horses.

I have a multiplayer game scheduled with some friends for later in the month. I’ll be the DM. Excited to see how that goes.

One thing I’ve done is to switch all my quest variables to live on the module, instead of PCs. I did this because my prime audience is a multiplayer party. I want to avoid any issues from when players have to drop due to real life conflicts or network issues. They were all running through common get and set functions, so that wasn’t a huge effort. Are there any thing to consider at part of that?

I’ve released an initial (beta) version. Any feedback is greatly appreciated!

I created it as a zip file, but I’m curious if others prefer a different (more secure) format.

My current roadmap:

  • Update some rumor scripts that I want to rework.
  • Investigate an issue I found with having the party mount with summoned creatures in the party.
  • Post my DM documentation.
  • Another playtest (and take more screenshots).
  • Prep for a session I’m planning on doing with some friends next weekend.

Thanks!