Machaera Unleashed

[MarkInMKUK]

Motivations: Greed, Protection of Others, Fear, Faith, Obedience... plenty of them

[nosisab]

To answer that question I need to know if you ask as a philosophical question or practical gaming question.

 

To the game there is a strong distinction about creatures and NPCs. To define how a creature or NPC reacts to another or the player is based in some statuses:

 

1 - The inherent "aggression" level - this is somewhat fixed and almost never changes for each creature type or NPC. Changing it must be done carefully.

 

2 - The "disposition" toward another creature, NPC or the Player - this is tell how much they like or dislike one another and is the status that is easily changed by actions, spells (like frenzy, calm and charm).

 

The combination of these two statuses governs the primary reactions ... a low disposition plus low aggresion dictates the deer behavior, it will always run from anything or anyone approaching them. High aggression level alsmost always mean the creature/NPC tend to attack. This is dictated by the difference between that two statuses, less than 6 on aggression means never fights, not even to defend self.

 

The "faction" plays a significant role on adjusting disposition toward members of same faction and different factions.

 

3 - "Responsibility" dictates the behavior toward certain actions. A NPC with low responsibility will not "give up" the player when witnessing a crime, from a minor trespassing or even murder. This status is important for the thieves guild quest, all the fencers are low responsibility and a few can even steal blatantly everything they can get the hands and the AI package instruct them to do, they will not be hindered by "ownership" if the opportunity arises. This is the status governing the merchants behavior too.

 

As can be noticed, even these few "behavior changing" statuses do have a complex interaction... you should search the CS wiki to get the math behind them.

 

Finally, even with determined combination of those statuses, the reaction can still be bypassed by scripting... for example, the highwayman will not attack if the toll is paid.

 

Although not impossible... introducing more conditions determining behavior should be carefully done and possibly not even necessary, maybe the expected reaction can be reached manipulating these above.

 

A few other "parameters" are used as reaction modifiers, like "Fame", "Infamy", "Bounty", etc. The game provides several variables which can be used to adjust reaction and quest scripts can extend yet more the flexibility.

 

Lets stop here before the post become unbearably long :) This topic is actually one the most "rich" and grateful to make quests beyond just go there and do something. Almost any interaction between specific characters can be scripted with base on them... But I understand they are too much "universal" to attend specific situations. Lets say some character is not interested in the Players endeavor with others at all, he/she is most concerned toward what the Player does to them or their interests. To this, quest variables may be the answer.

 

****---- There is a somewhat unknown risk related to quest variables. Although it triggers only in special combination of factors.

 

The problem being quest variables are stored in the savegame based on its "position", not by specific identifier.

 

If the quest is modified by another ESP it can have the order of it's variables changed. The game see the FormID did not change and assume the variable position is still the same of that on the save game. The consequence is Var1, Var2,...varN, originally stored in this order, have now different order and the results become totally unpredictable.

 

For self contained MODs, not spread on several ESPs, this risk is practically null. On the other hand it is one the reasons for "mysterious" behaviors or even game crashing just by changing the load order.

 

To be on the secure side, I try to avoid changing quest variable order... introducing new variables if needed after the last, not in between already existent ones. That comprehensible desire to make things organized and coherent can be fatal in this case... like reordering the variables to attend some criterion...

Edited July 5, 2011 by nosisab

[fg109]

Done some testing today, got a basic menu set up for the upgrades. Still trying to work out the best way to use "AddEffectItem", but it's getting there. All the functions that modify the physical aspects are doing ok. Sadly, the maximum number of enchantments that can be displayed on a weapon is 7, I will look through some settings to see if there is something that can be altered to display more.

 

One way to display more would be to use MenuQue. Check TheNiceOne's Display Stats mod to see an example of how it can change the menu. I know basically nothing about MenuQue though, so I have no idea how you might be able to achieve the same results.

[nosisab]

Supposing you are changing the enchantment to be applied on the weapon, the AddEffectItem adds the empty effect (without damage and duration, for example) to the end of the list, you can try the AddFullEffectItem to pass the actual working effect.

[WarRatsG]

Motivations: Greed, Protection of Others, Fear, Faith, Obedience... plenty of them

 

Fear generally comes under survival, and technically you could say obedience does too.

 

Greed is usually to do with money, money is essential to survival (and helps with reproduction ;))

 

Protection of others and faith... Possibly, good call

 

To answer that question I need to know if you ask as a philosophical question or practical gaming question.

 

It is a philisophical question, not a gaming question. I've never seen an npc act on his need to reproduce in oblivion, however I will remember your point about quest variables :)

 

 

One way to display more would be to use MenuQue. Check TheNiceOne's Display Stats mod to see an example of how it can change the menu. I know basically nothing about MenuQue though, so I have no idea how you might be able to achieve the same results.

 

I've seen that mod before, although I've never worked with MenuQue before. Good suggestion though, it's something I shall definitely look into.

 

Supposing you are changing the enchantment to be applied on the weapon, the AddEffectItem adds the empty effect (without damage and duration, for example) to the end of the list, you can try the AddFullEffectItem to pass the actual working effect.

 

Yeah I meant AddFullEffectItem. I'll test from the console first, so that I definitely know it works.

 

__________________________________________________________________________________________________________

 

My own answers to my question were the "Thirst For Knowledge" and "Self-Actualization (the need to realise your potential)" or the "Pursuit of Happiness". None of these are essential to survival: you don't *need* to know everything, but we want to. And the football players who earn 250k a week survive just as well as the guy who earns 20k a year - It's a matter of fulfillment, as Maslow states:

 

"What a man can be. What he must be"

Edited July 5, 2011 by WarRatsG

[WarRatsG]

It was difficult and confusing as hell, but I have mastered the ability to modify weapon statistics and enchantments, at least the vanilla ones, so I know this mod isn't heading for a dead end.

 

Thing is, is because the changes are part of the "savegame data" and not the "mod data" any changes made to the base enchantment are not kept when oblivion is restarted. I have tested this myself, and found this to be true, so my next task will be to find a "restore enchantments" spell, that will bring back any lost enchantments. Maybe this will get fixed as of OBSE 21.

Edited July 6, 2011 by WarRatsG

[nosisab]

You may want to verify the OBSE new cloning features for weapons. The point is the savegame does not register changes in the original, but it does with cloned objects. This solved that issue with the base enchantments reverting after game reload.

 

To the player's stand point there is no differences between the cloned and original objects.

 

PS: I had this problem with Afinity even though it was not in the enchantment. As I told before, the weapons reach and speed don't register on an equipped weapon, the effect is applied only after it is unequipped and equipped again. Cloning would not solve the problem in that case since these values are given dynamically and not as part of enchantment and such.

 

The problem was the weapon reverted to vanilla speed and reach every time the game was reloaded, and if the player never unequipped it it would never update the values. One dirty solution was making this unequip-equip thing happening timely... but I was not willing to let it that random... worsen yet if it happened while the weapon was out, because it is perceptible and immersion destroyer.

 

Man, soon enough I saw how difficult is to keep it under control, but was OBSE itself which came in help with a few new functions, being in that my case, that "GetGameLoaded" function... which return true Once and only once by game session. So I could do the manouver once to grant the weapon speed being updated and in this case, the effect of being visible the weapon being equipped (case the save was done with it out) is bearable happening in the game load. Afterward I needed only to keep trace of actual changes in speed/reach and apply the unequip-equip thing while the player was idle and the weapon sheathed, with no perceivable effect.

Edited July 6, 2011 by nosisab

[WarRatsG]

I remember seeing the idea behind cloned form, but I forgot about it. Great suggestion, thank you for reminding me about it, but putting it into the script is driving me insane.

 

Basically, a lot of the functions and commands require the objectID of the item or enchantment to work, however, it is difficult to retrieve the object ID of something which does not yet exist. "CloneForm" not only clones the object, but also returns the new objectID, so I captured this by saving it to "Ref WeaponClone" or "Ref EnchantClone", but the functions in question still perceives this as a reference, not the object ID. So, the script won't compile basically. Using "Long WeaponClone" is no different - it only returns 0 anyway would be no real effect. I've heard that you can get programmes that compile your scripts no matter what you put in - maybe that is what I need.

 

This may sound like I am telling you cloning and modifying the weapon is impossible, but rest assured I will make it happen. When this part is over I am definitely going to try and put an article on the CS Wiki, so that if anyone else tries this they won't need 10 bottles of aspirin for brain-ache. Don't worry though, it should be plain sailing once the core mechanics of the mod are set in stone, just have to chuck in a quest and a few unique scripted powers and all will be good.

[fg109]

Are you using the syntax correctly? I made a mod recently that used CloneForm, and I didn't have any problems using it. Something like:

 

let CloneObject := CloneForm BaseObject

 

would save the object ID of the clone in the CloneObject variable.

[nosisab]

I may be missing something, you don't need to script the cloned weapon, just the original

what I see you need to change is just the enchantment to be put in it.

 

You can get the ref using:

 

Set YourWeaponRef to Player.GetEquippedObject 16

 

where YourWeaponRef is defined as ref variable.

 

Afterward your script will refer to that YourWeaponRef to everything you do to it.

 

PS: I don't know if made myself clear... I mean the script will refer only to the actually equipped weapon... if it is an object script you can even skip the verification test of the weapon identity, because it will surely be itself.

 

Depending on the script needs, you can work on the base object, clone it again and add it to the player after disabling the former.

 

Well, I'm talking on suppositions here, I didn't make it personally in a mod yet. Give it a try.

 

Footnote: you may want to force the weapon being equipped so it can be altered, what makes sense.

Edited July 7, 2011 by nosisab