Ok so the graphic requests I had have been taken care of.
The only thing that is really missing is the "key rotation fix in a_ba" that wont break dwarven cloak animations. Aaaand the documentation to all these features from 1.72 which is huge task Im slowly working on.
I also moved towards to 2dilate from leo_x as for automatic 2da merging. Its so easy now and user friendly, it let user to decide what to merge and what not (which is controlled by definition design which I tried to divide in a way that anything else than clear fix is in serapate definition).
Till I finish documentation there is still a gap for new features and changes you can help me decide with. Now prepare for a huge wall of text, apologies for that but Im trying to explain the issues as close as possible with every detail mentioned. It matters. So there we go:
1) I recently found out Ioun Stones are still dispellable. Like wtf I thought they are not. Looking in history, they actually were at first till someone had a problem with this change claiming its huge balance change that will break his environment and so I decided in spirit of a proffesionality to remove this and keep them dispellable.
1.70 beta6 notes:
- ioun stones set back to "magical effect" from balance reasons (not everything have to be per rules)
Well, I guess I know why I kept it dispellable. I was admin of Arkhalia PW, lvl 40 high magic loot module where ioun stones were used pretty heavily to reach +12 stats. The problem with ioun stones was that there were lots of dispell traps (no problem with my modification) and also a dungeon where all npcs had holy sword which was able to dispell ioun stone with like 50% chance on each hit (which meant that ioun stones were useless there as the effect was immediately dispelle with a first npc player encountered). Now, while dispelling ioun stones makes no sense in a term of how they work, on Arkhalia PW, the fact that these NPCs were dispelling Ioun Stones turned to be an advantage for the module design as character that wanted to go there had to seek another ways to get +12 or just do it with +10 stat, player simply had to count with this and it made the dungeon harder. So on Arkhalia, while the change makes sense it wasn't really appreciated. I realized that it can be viewed this way even in other modules and different environments. This is why I kept it dispellable.
However. Now, the latest 1.72 is featuring a multiscript for all ioun stones. So if builder had really problem with this and wanted to make them dispellable he wouldnt have to modify all 7 scripts one by one, but only one script. So Im thinking maybe it would be worth to make Ioun Stones undispellable as they should be? What do you think guys?
2) Removal of the beast racial type.
This discussion was already there and it was suggested not to do it but things are bit different now due to the new features of nwnx_patch.
So again what is it about. The issue is that the beast race is a remnant of the DnD 3.0 and this race was removed in 3.5 and all beasts were turned into magical beasts. In NWN particulary, the Beast race is very unused and there are only three such creatures, Bulette, Gray Render and Stirge. This wouldn't be any problem at all if there wasn't ranger and his Favored Enemies. Whats a point of having two races where one contains 3 creatures only and another one contains maybe 10. Not even custom content adds more "non-magical beasts". Plus, there wasn't favored enemy feat for oozes which actually unlike beasts has quite good presence in NWN appearance selection.
So the plan was swap Ooze race with Beast race, rename the feat from Favored enemy: beasts to Favored enemy: oozes and change Stirge, Gray Render and Bulette to be magical beasts. If you look into few pages back this was suggested not to do from various reasons, but again things are a bit different now with nwnx_patch.
nwnx_patch allows to modify which favored enemy feat works for which race. Thus, the actual position of the ooze and beast races could stay, so it won't break any custom content, custom oozes from cep will still be oozes, custom beasts from cep will still be beasts which is major reason why this was throwen out of window. Feat would be renamed (I wouldnt make a worries it could break anyone's game unless its a module kill 1000 gray renders where that Favored enemy could reaaaly get handy!) to "oozes" and the functionality would be maintained via new collumn FavoredEnemy in racialtype.2da and NWNX.
The only disadvatage I see is that it won't work for players playing on a server without CPP or playing without NWNX. There is nothing I can do to make it work on servers without CPP its server-side, the fact it won't work without NWNX is a bit sad but its a price for a custom content compatibility (whereas previously suggested solution would work without NWNX, but since the CEP oozes would technically turn into beast race it would work reliably only in vanilla content module anyway). So what do you think, still too controversial?
EDIT: another option would be to create a new feat for oozes. The small problem here is that if player tries to take this feat in a server not using CPP it wont let him level up and print and error but nothing serious except that won't happen.
3) And again the Contiunous Light!
I don't like current solution. The idea is very good and its a nice example that CPP allows to modify item cost via script without hak or nwnx, but due to the way how item cost is calculated I don't think its even possible to create an alghorithm that will maintain the same cost. The problem is that my script is actually making the item cost less than before. Either this or I can modify it so it will be still more than previously and it will still generate some profit (almost 0 on mundane items, still enough on magic items of already high value). Neither solution is perfect and other solution are even worse. Make it temporary nah - wont match the description then, change light itemproperty cost (too many side effects unusable for CPP as it would heavily altered custom content).
So Im thinking about changing it back to the stolen flag. Now why. First, every serious multiplayer module has this spell already modified, disabled etc. So they don't have to care about this change in CPP at all as their script gets priority (and be a little serious here, PWs arent willing to install this patch and even if they were then they are using 1.71 in which it has stolen flag already (it was changed in 1.72 beta on player suggestion). Second, I could provide the switch to change this behavior ingame via PC Widget tool. The switch was there in 1.70 but then I decided that making a switch for a single spell/single feature especially such that is like changing one line in spellscript is not worth to make a "module switch". This make sense because given to the number of changes CPP does, every second could have a switch and in the end we would end up with 1000 switches and who would want to go over all of it and find a single switch he wants? But since this is issue for a players they are not able to modify script. So either they have to download override package or I have to provide the switch for them. Switch seems to me as an easier solution. So what do you think, is this enough of a compromise?
4) Tileset animloops.
In past I was working on the simple tile modifications that allowed to remove certain features like plants, evil symbols, items on the tables and similar stuff via animloop feature. Sadly this feature is not toggleable ingame (actually it can be but there is a little problem with client synchronization, which I might be able to provide too in future), but it still allows builder to add more variability into areas. Problem with this feature is that from some strange reason, this can't be used as override/patch as it might randomly crash a game (especially after area loading).
But I can still add these tiles into hak version. I don't know how big interest is in using patch170/1/2.hak but if there is anyone who would like this feature there are absolutely no disadvantages for this. And those who don't want to add patch172.hak into their module (as it would force players to download and install my patch which is really needless and neither I wouldn't do that in my module) still anyone with custom haks could just add patch172.hak content into their haks and get this functionality without the CPP requirement on the player side.
Link to few images of this features. (I already got this feature working in dungeon tileset and city interior)
5) Detect Evil paladin ability.
This is something I probably didnt add into documentation, This ability actually exists in the game but its unfinished. Yet, I completed the spellscript, and I provided valid values into 2da. So its now 100% working just not added into paladin abilities. It is not added from a simple reason. This should be a feat and as new feat I expect there would be huge issue with servers not running on CPP. Like player character would be refused by server for too many feats.
Now the thing is I might know a way to workaround this. First is something I get idea just now, so I wont bother you with details. Second method is adding this ability not as a feat but as a paladin-only spell. This wouldnt be so good of course but still could be nice to have. This spell doesn't have much usage its more a roleplay thing but I guess players might like it anyway. Would you like it or I should not bother?
EDIT: ok so the first method doesnt work, it doesnt matter the feat is invalid/nonexistional, player wont be allowed to join server/level up anyway. So it would have to be spell to make it compatible in multiplayer.
Modifié par Shadooow, 10 juillet 2015 - 02:23 .
