cfh85 Posted August 24, 2012 Author Share Posted August 24, 2012 As for making the mod stand out, everyone loves RPG elements. I've been planning to add followers into future updates of my own mod, but with a twist. My solution was to create some kind of EXP system, possibly with branching abilities. It would add a sense of attachment to any and all followers involved, a sense of achievement for creating an elite army, and most importantly a memorable experience for doing something different to the norm. This a a pretty awesome idea. I'd like to be able to limit the equipment each NPC can use based on their level but, to make it more compatible it would need to compare the base stats of the equipment which would be a lot of script processing to evaluate the equipment, remove any over powered etc etc. What I think would be a good work around is a container linked to each NPC. Based on the NPCs level it would transfer suitable equipment and only run on begin activate (which would mean activating once you've added to it).To go with this I'd need to prevent the PC from being able to edit the NPCs inventory and I'd need a central way to access the containers whilst allowing others to add to it without interfering with each others additions ( should more than one person wish to make companions to go with my mod). I'm also going to make them level up with the PC. Whilst in the service of the PC they will level up at the same "rate" as the PC. I will need to workout an exp system based off of level increases at different levels. Obviously if the PC is Lv5 and the companion is Lv50 I don't want the companion going 1 for 1 with the PC leveling. When not in the service of the PC they will level at a diminished rate. Link to comment Share on other sites More sharing options...
cfh85 Posted August 24, 2012 Author Share Posted August 24, 2012 Hmm, sounds interesting. I'll keep a watchful eye on this thread. I can see some potential mod conflicts with a few popular mods, such as SDR. For example, changing any of the sneak functions including changing the actor alpha's can cause several problems with SDR. SDR already does that. If you can either exclude that or make an option to exclude that particular function, you can get around that particular conflict. This wont conflict with anything. It uses new AI packages/classes/combat styles/scripts/dialogue/questit doesn't change any game settings or anything not added by the mod Link to comment Share on other sites More sharing options...
WarRatsG Posted August 24, 2012 Share Posted August 24, 2012 This a a pretty awesome idea. I'd like to be able to limit the equipment each NPC can use based on their level but, to make it more compatible it would need to compare the base stats of the equipment which would be a lot of script processing to evaluate the equipment, remove any over powered etc etc. What I think would be a good work around is a container linked to each NPC. Based on the NPCs level it would transfer suitable equipment and only run on begin activate (which would mean activating once you've added to it).To go with this I'd need to prevent the PC from being able to edit the NPCs inventory and I'd need a central way to access the containers whilst allowing others to add to it without interfering with each others additions ( should more than one person wish to make companions to go with my mod). I'm also going to make them level up with the PC. Whilst in the service of the PC they will level up at the same "rate" as the PC. I will need to workout an exp system based off of level increases at different levels. Obviously if the PC is Lv5 and the companion is Lv50 I don't want the companion going 1 for 1 with the PC leveling. When not in the service of the PC they will level at a diminished rate. In my opinion, stats and equipment should be the least of your worries, although limiting the strength of equipment could be interesting. To set yourself apart, you need something that defines the specialisation - a healer may start using an AOE healing spell, an archer may start using invisibility, etc. Think along the lines of perks and new abilities rather than better stats. Link to comment Share on other sites More sharing options...
lonewolfkai Posted August 24, 2012 Share Posted August 24, 2012 (edited) If you decide to change the alpha shading on the NPCs in any way, whether it be from game settings or scripts, it'll conflict with SDR since SDR already does that. It affects all npcs, mod added or not. Edit: now that I think about it though, there is an option to turn the feature off in the ini file of SDR. However, doing that, will remove one of SDR's best features. Edited August 24, 2012 by lonewolf_kai Link to comment Share on other sites More sharing options...
cfh85 Posted August 24, 2012 Author Share Posted August 24, 2012 I don't know how SDR works, but if it conflicts with any mod that uses setalpha then that would seem like a pretty big flaw. Whether it will conflict or not depends on the way SDR changes the alpha. WarRatsG, that sounds good, but how can you guarantee the companions use the added spells? Especially if you were to use scripted spells. The script for my companions is getting to be pretty big, so I've set fQuestTimeDelay to 60 as nothing it does needs to work fast. Forcing them to use spells in combat would probably mean running the scripts more often Link to comment Share on other sites More sharing options...
WarRatsG Posted August 24, 2012 Share Posted August 24, 2012 @lonewolf_kaiI think you misunderstand what I am trying to say - even if the mods do conflict, the impact will be minimal. Only one actor will have his alpha changed, and he will probably be too small to notice anyway. An invisibility ability could be added as a backup if necessary. @cfh85Thats up to you. You could obviously remove their other spells to ensure that they use the improved ones. To solve the oversized script problem, you could develop a group of user defined functions. If each one has plenty of return calls, then your entire system will be much more optimised. Link to comment Share on other sites More sharing options...
lonewolfkai Posted August 24, 2012 Share Posted August 24, 2012 I understand perfectly well what you guys are doing, and in all honesty is sounds fantastic. I'll let you guys figure out the conflicts when they come up, but I'm just giving you a heads up for when it might occur. And what you are proposing to do sounds like it will conflict. It's not necessarily a flaw of SDR though and the mod's goals anymore than yours is a flaw by using the same function as SDR's. That's just the nature of mods. They conflict with each other. What should theoretically occur is that the one actor you are changing the alpha shade on should have it done twice. Depending on how the mod list load order is set, one will overule the other, thus the conflict. Now, you have several options to fix that. The one I listed above or another simple one I just thought of is correcting the load order. You can place the mod you guys are making to load after SDR. That should override what SDR is doing to the shading you guys are planning. Howeve, if this particular conflict results in crashes, you'll need to disable the alpha shading function on either SDR's or your mod. By chance, are either of you going to use tokens as part of your scripting? Link to comment Share on other sites More sharing options...
WarRatsG Posted August 24, 2012 Share Posted August 24, 2012 I understand perfectly well what you guys are doing, and in all honesty is sounds fantastic. I'll let you guys figure out the conflicts when they come up, but I'm just giving you a heads up for when it might occur. And what you are proposing to do sounds like it will conflict. It's not necessarily a flaw of SDR though and the mod's goals anymore than yours is a flaw by using the same function as SDR's. That's just the nature of mods. They conflict with each other. True. The point I am making is that it will not matter if it changes the alpha of this one NPC. No-one will notice him anyway. Conflicts happen all the time between mods, but if the effect is minor and unnoticeable then there is no need for a disclaimer saying "DO NOT USE THIS WITH MOD X!!!". It's the same here - the effect of the possible conflict is minor and unnoticeable, meaning there is no need to create a workaround. If it ain't broke, don't fix it. What should theoretically occur is that the one actor you are changing the alpha shade on should have it done twice. Depending on how the mod list load order is set, one will overule the other, thus the conflict. Now, you have several options to fix that. The one I listed above or another simple one I just thought of is correcting the load order. You can place the mod you guys are making to load after SDR. That should override what SDR is doing to the shading you guys are planning. Howeve, if this particular conflict results in crashes, you'll need to disable the alpha shading function on either SDR's or your mod. Alpha and shaders don't work that way. They are not something you can set in the CS, at least as you would set a name. Bethesda themselves use SetActorAlpha and PlayMagicShader in abilities to create pre-existing alpha and shaders. In-game, if one script changes an actor's alpha, then another script changes the same actor's alpha in the same frame, then the second script overwrites the effect of the first script. It's almost exactly like if you change a script variable twice in one frame. Also, load order has no effect on dynamic scripting, which I assume is what SDR is built on. Load order only makes changes before you even load the game, and these pre-existing changes can only happen to resources in the esp and it's masters - it cannot make changes to entirely new data added by other mods that it is not related to, which means our invisible friend would remain invisible anyway. In-game scripts built to work dynamically can make changes to any data that is present in the game world at runtime though, regardless of load order. By chance, are either of you going to use tokens as part of your scripting? I'm not actually involved in the coding - I'm just sharing design/concept ideas, seen as I've already put quite a bit of thought into this kind of thing. May as well save someone some time and effort in coming up with ideas themselves ;) Link to comment Share on other sites More sharing options...
lonewolfkai Posted August 24, 2012 Share Posted August 24, 2012 I think there might be some miscommunication with us going on here. Allow me to clear up a little. SDR does half of its functions based on adding tokens to all NPCs that the PC comes to every .5 seconds by default (I think that's the default anyways). This token does a number of things, including changing the alpha of an actor based on the value of sneak skill the NPC has. I was a bit confused by what you were suggesting to do, thinking you'd be using a script to do so, but after your explanation, yes, I can see where a conflict wouldn't arise afterall and load order unnecessary. However, I now see where it could be that SDR would possibly change the alpha shading of your proposed invisible NPC. I would also debate a few things on your load order and scripting points, but that's a whole different topic, and is also needless with relation to the development of this mod since that has been cleared up. Link to comment Share on other sites More sharing options...
cfh85 Posted August 25, 2012 Author Share Posted August 25, 2012 (edited) these tokens would most probably only run the script once, probably just using onadd, change the NPCs alpha and then stop the script, with it not running again. So after the initial change the token will do nothing. This would result in 1 instance where the NPC uses SDR's alpha value before being returned to it's original as scripteffectstart would return it every time the spell is cast. However, unless there are very obvious and large conflicts then I wont be worrying about them before release, until it's confirmed. I don't want to seem rude when I say this, but I'd prefer it if the SDR discussion ended as it's going nowhere without someone with complete knowledge of how it works and how my (unreleased) mod works. As a way of reducing my standard NPC script, and as a way of reducing the number of different NPC scripts I'm now using a combination of abilities with scripts attached (such as an ability to make arrows/lock picks/ perform other tasks) which are added and removed during dialogue when they're asked to perform the tasks, and the other change I made was to create a faction dedicated to my now 29 hireable classes. Each class has it's own ranks which then changes the dialogue options (and thus abilities that can be added) for each NPC. The bulk of my NPC script now is in an activate block. I've got several ideas for special earned abilities now. For my spell casters the ability will trigger a custom scripted spell to be cast when the right conditions are met (probably %health)my stealth companions will gain a blend in ability which will hopefully allow them to act as guards/servants/faction members.I'm thinking for an NPC with endurance and armorer they should be able to deal more damage to an armors health as they have a better understanding of it. My aim is to develop a range of task (non combat) abilities, skill based abilities and unique class abilities. The task abilities will be given to any relevant companion when they're asked to perform the task.The skill based abilities I want 1 for each skill and each NPC will have 3, depending on their skills and primary attributes The class abilities each class will get only 1 All will level into better versions where appropriate. Some abilities will be made completely unique for the 'adventurers' who can't be hired, but instead must be won over for a limited amount of time. Some I don't have the first idea what they will be, some I don't know how to make and others I haven't started yet :rolleyes: but I'm making some progress. I have however hit a wall with the target selector. I've been to tired to troubleshoot it, hopefully this weekend will yield some results Edited August 25, 2012 by cfh85 Link to comment Share on other sites More sharing options...
Recommended Posts