Skip to content

Who will be rebuilding the PRC to take advantage of the new unhardcoded possibilities?

Because I would like to contribute. I can't do much, but I can always try.

Comments

  • ShadooowShadooow Member Posts: 402
    Well I kind of started such project for 1.69 using nwnx but now I don't know what to do.

    I wasn't checking NWN:EE for some time, can you tell me what unhardcoded possibility NWN:EE already brought? I didn't notice any to be honest...
  • Dark_AnsemDark_Ansem Member Posts: 992
    Shadooow said:

    Well I kind of started such project for 1.69 using nwnx but now I don't know what to do.

    I wasn't checking NWN:EE for some time, can you tell me what unhardcoded possibility NWN:EE already brought? I didn't notice any to be honest...

    At the moment, NONE.

    However, eventually, new metamagic is going to be possible, as will be spellcasting classes with proper spellbook. So, the Archivist and other classes that make use of the workaround spellbook will likely need to be rebuilt?
  • FreshLemonBunFreshLemonBun Member Posts: 909
    I think it will be better to make class packs in a similar trend NWN2 modders did.

    As long as it isn't spellbooks or metamagic related it doesn't need to be unhardcoded. There is a work around for sneak attack and for unarmed damage progressions, so while opening them for some kind of hook-in scripting would be better it's not essential to implement features that use them.

    The main difference is that haks preload. I've been doing some conversions of NWN2 based mods I was working on but I'm not certain I'll be releasing a pack for public consumption.

    The problem with the unhardcoding of spellbooks is that we can't anticipate how Beamdog will decide to change the 2da data and encode it with scripting. The best you can hope is that spell scripts will only need minor editing to use new metamagic values.

    Spontaneous casters are still easier to spoof, tho I think NWN might not have a GetRemainingFeatUses(int nFeat) function nor an AddFeat(int nFeat, object oPC) and RemoveFeat(int nFeat, object oPC) function so you're still kind of limited in what you can do neatly with modding.
  • Dark_AnsemDark_Ansem Member Posts: 992

    I think it will be better to make class packs in a similar trend NWN2 modders did.

    As long as it isn't spellbooks or metamagic related it doesn't need to be unhardcoded. There is a work around for sneak attack and for unarmed damage progressions, so while opening them for some kind of hook-in scripting would be better it's not essential to implement features that use them.

    The main difference is that haks preload. I've been doing some conversions of NWN2 based mods I was working on but I'm not certain I'll be releasing a pack for public consumption.

    The problem with the unhardcoding of spellbooks is that we can't anticipate how Beamdog will decide to change the 2da data and encode it with scripting. The best you can hope is that spell scripts will only need minor editing to use new metamagic values.

    Spontaneous casters are still easier to spoof, tho I think NWN might not have a GetRemainingFeatUses(int nFeat) function nor an AddFeat(int nFeat, object oPC) and RemoveFeat(int nFeat, object oPC) function so you're still kind of limited in what you can do neatly with modding.

    I am aware it's best to wait, just in case.
  • FreshLemonBunFreshLemonBun Member Posts: 909
    Martial classes are much easier however. The custom feat method in NWN is a little archaic and not as simple as it is in NWN2 but as long as you have set the right values and added it to the class's personal feat 2da it should work normally.

    Classes like Knight should work easily enough, and casting prestige classes like Force Missile Mage and Abjurant Champion should be doable within reason.
  • ShadooowShadooow Member Posts: 402

    At the moment, NONE.

    However, eventually, new metamagic is going to be possible, as will be spellcasting classes with proper spellbook. So, the Archivist and other classes that make use of the workaround spellbook will likely need to be rebuilt?

    Well then, in that case it is a little bit early to work on this.

    Plok is also trying to modularise PRC so that might be first step needed...
  • Dark_AnsemDark_Ansem Member Posts: 992
    how could you make the PRC modular?
  • ShadooowShadooow Member Posts: 402

    how could you make the PRC modular?

    I had similar comment on his effort, but maybe something can be done in this regard...

    here is the link to the original thread: https://forum.neverwintervault.org/t/modularising-the-prc/653
  • PlokPlok Member Posts: 106
    edited May 2018
    Oh hey, just noticed this thread.

    how could you make the PRC modular?

    By untangling its dependencies. :)

    First step is breaking up the dependency of the PRC scripts on the classes they provide - there's odd bits and pieces of if (SOME_CLASS) { DO A THING }else{ DO OTHER THING } littered everywhere and they get in the way of doing anything else. These need to be removed before anything else can be done.

    TLDR plan for breaking up classes: instead of having the PRC being a bunch of scripts to implement a bunch of classes it will be a bunch of scripts to implement a bunch of class features (such as sneak attack, caster level etc.). Then a class initialisation script describes how a given class uses those features. That way there's no special case code for individual classes. All spells/active feats will remain untouched and should work exactly the same.

    The word describe is incredibly important here. It turns the class code from being procedural (do this thing, give me the result) into declaritive (I want this result, how you get there is up to you). This means there won't be any class independent code - only a description of a class. No code means no dependency. As an added bonus, making a new class will be much easier because it now lives in one solitary directory.

    I say there's no code, that's not entirely true. The init class scripts can also define callback events by providing a script name for an ExecuteScript call. It's working on the assumption that it's something that can be cached and has them provide a set of conditions in which the cache is out of date - e.g. level change. I've used this to do a high level test of things like Ninja's Wis to AC, Archmage's Spell Power and Red Wizard's enhanced specialisation.


    I haven't really planned too far in advance of that, but I'd imagine that Tome of Battle, Psionics, Invocations, New Spellbooks, Crafting etc. could all be pulled out into their own systems. The key thing is to try and get a collection of files together that are for a particular system and have the rest of the code be oblivious to them. This is going to involve using ExecuteScript to call them rather than #including them and caching the crap out of things to minimise the performance cost.

    There's a crap load of work to be done to achieve this. I still haven't even finished updating the tools the PRC uses yet. This isn't something you're going to be seeing any time soon.

    P.S: I'm ignoring 2das/tlks. I can't do anything about them without some way of adding rows to 2das/tlks via hak instead of just overwriting the whole files. It could be that using an external program to generate the 2das/tlks is a way around this. You could also support the suggestion I've been putting forward of being able to add rows to a 2da via hak. ;)
  • clansunstarclansunstar Member Posts: 33
    I assembled a team to start debugging and upgrading the PRC. I've been working on my merge hak for PRC and CEP as I had a minor bug report to look into. So far Plok has gotten more accomplished for the PRC EE side of things. I have been working on the 1.69 version of things.

    But I took the reigns of the PRC a couple years ago. Just got a team together as interest in it was not active till the EE edition came out.
Sign In or Register to comment.