Please read what I write with care - I put care in writing it. I′m not trying to be provocative, these are principles and objective point of views I′m stating, not attitudes and subjective opinions.


By your definition, CTD is "breaking a game". On the otherhand, conflict can cause a CTD. Is the modder then "breaking the game"? The way I see it, we have a conflict here with this mod and Vanilla quest - a mod can conflict with Vanilla just as well as it can conflict with other mods. With scripts or coding in general, the conflicts are never about things you can view via conflict editor, they are often about conflicting CONCEPTS.

And these conflicts are solved - not by hardcoding exceptions to an exception - but by defining common rules, standards if you will, which when obeyed remove the conflict. OR, the conflict is caused by the concept breaking the existing standards, and should therefore not be used.



Many serious problems require loading an eariler save. I′m just being honest and realistic here. You are focusing on a singular issue, when I′m actually talking about a bigger picture here. Again, 1000 pieces of duct tape are not good modding - if the concept is fundamentally flawed, the mod should be pulled altogether. Otherwise, for every problem found means one game "broken", even if they would be patched afterwards. It′s a never ending path.

In my last post, I try to paint that bigger picture for you - I′m not being irresponsible, I′m looking beyond that one problem.

So, again, if you care to join the real debate, is should I pull the mod cause the concept should not be promoted or used, or should we actively look and promote patches to quests that break the concept in this mod? I don′t have a personal opinion or stake here! Honestly!



To help with what the talk should be, here′s one point of view:

Because there apparently exists regular problems with "friendly NPCs" fighting each other, we need some system to "rule out" these fights. For "ruling out" we need a global rule, to deem (via script and with relative ease -> no perfomance hit) when a fight is not "legit". One such rule (and implementation) is this mod - NPCs in same faction should not fight.

Technically this SHOULD be fine - any quest related fight can be made so that the NPC is removed from the "conflicting" faction before the fight starts. Doing this breaks nothing, so the side that would actively favor the existence of a mod like this would probably favor this approach.

The flip side of the coin is that many existing quests probably don′t obey this rule. So while someone can claim the "rule" in this mod makes sense, and should be globally followed, it probably isn′t. Because this means that "some poor chump" will eventually hit a situation like you describe, should this mod be removed as a precaution, out of the fact that I can′t guarantee how this "rule" works in practice? I have absolutely no problem doing this, then again I released as a favor, so what would pulling the mod be? I need more REAL discussion on this before I decide.



On a side note, I feel the problem we have (had?) here, is that you obviously didn′t look at the references in my earlier post(s), like the request thread discussion. This is a not a mod I visioned and gloriously released, ready to take a bullet in order to make it work as a miracle cure for everyone. I made an extra favor releasing a script in an esp, "ready to test and use" form, instead of copypasting the script in the request thread.

Therefore I don′t vouch for this mod, I have no feelings towards it whatsoever, no ambitions or pride. The script is childlisly simple, anyone who can script could have wipped it up.

I haven′t tested anything else than that the script does what it says it does. That′s why the readme accordingly blatantly states what the SCRIPT does, not how the mod solves every problem related to the topic. And that′s why I also give full permission to edit and redistribute the mod, in the readme, incase someone wants to expand on the basic concept.



So please understand my point of view - I′m trying to do the RIGHT thing here, even though I should be using no time at all for this mod, as it′s not even something I terribly enjoyed making, releasing or discussing. And STILL I′m wasting my time trying to explain why hasty action is not the best path to go. Yet I get blaimed irresponsible.

Like I said, I have no trouble pulling the mod if it′s deemed a faulty concept. And because I KNOW I′m not there to include 1000 small edits, this is what I MUST do, to be responsible. Not add a disclaimer or 1 edit and then let the thing float on.But this requires - in my books - some real conversation about the bigger picture, at least one opinion about the points of view I mentioned earlier.

You're missing another option, a simple "Known Issues" entry in the readme. It's not uncommon for modders to mention problems that they're aware of and either can't or won't do anything about. In the case of this situation the fix is very simple, simply turn off the mod if the player gets stuck then turn it back on when the normal game resumes. If the player is made aware of what can happen and how to fix it, then they can at least quickly pinpoint where the problem is coming from and deal with it accordingly. I can appreciate the fact that you don't want to spend alot of time on this. But by making this available to the general public, you have an obligation to ensure that the end-user isn't unduly inconvenienced by downloading and using it. If you're not going to even go that far then you should just pull the mod and simply make the script available to anyone who wants to use it themselves.

I guess this counts as third strike. Again no comment or discussion about the subject I have tried to point out is the one that determines the fate of this mod.

Including such messages in the readme comes AFTER I decide on that issue - if even then. Because that means I have decided the concept stands, and the mod should NOT be pulled. It means I have decided the concept is worthy, even if not perfect, but maybe over time more and more useful, and thus for now the users should simply be informed of the possible "conflicts". And of course the irony here is - I′m not meaning to decide, I have tried to urge YOU as USERS to decide for me, and to help with that I attempted to provide aspects from both sides of the river.

So everything you have said so far, and really I mean no offense, helps nothing at all. This is what I have been trying to articulate - the mootness of that one quest, in the face of the whole concept and all the other quests out there. I was really hoping for some real opinions/debate about the decision I should be making here.

But yeah, this is getting pretty tiring. Unless anyone has anything constructive to say about the subject I′ll just pull the mod in a couple of days, as said I have nothing to win or lose here (but time).

Okay for the "Known issues" statement, seems prudent and releases Skycaptain from any blame, although using any kind of mod does bring the possibility of breaking something. Even using a standard unpatched game can do that.

Seems also like a good idea to take up the issue with UOP if they feel it fits. Quest involving inter fighting because of story line can be faction adjusted by setting the faction value to -1 in the appropriate quest stage.
This wont solve similar problems with modded quests because as far as I know it has not been recognized as good quest writing to remove the faction when such a situation arrives.

This mod is a tremendous life saver for me, or my game rather, since I have some NPC's fighting I can't pin down the cause of. With this mod I can feel confident no silly faction fights occur.

I have not yet implemented any switch and I feel that really is not optimal. As it is now it runs quietly in the background and one can enjoy the game.

I want to push for either an inclusion in the Unofficial Patch for Oblivion and Shivering Islands, or making a filter mod to include as much as possible (can one do a filter on quests?). Also promoting the information in related tutorials on Wiki construction set for good quest programming if it is not already done.

I feel very strongly that this mod is the right way to go and that affected quests should be adjusted elsewhere and as standard in mods where there is need for inter-faction fighting. Remove the offending party from the faction where needed.

Robin

This doesn't fall within the purvue of the UOP. It's a problem caused by a mod and the UOP doesn't fix those. PetrusO already asked Arthmoor and he said no for that very reason.

I would prefer to simply fix the problem. I know that you can detect when that quest is running and simply remove Aldos from the Cheydinhal faction. I like what this mod does and I think it's a good idea. I think it just needs a bit of tailoring here and there when someone finds a situation in which it wouldn't work. We aren't talking about a conflict with another mod, we're talking about a problem with a vanilla quest. Why not fix it?

Thank you so much for the input, this is finally something about the subject I think needs to be discussed. (and I really don′t favor keeping the mod alive anymore than simply pulling it, which would be the easy way to go)


Your post addresses well the problem I have here, I do things "the universal way" or not at all, and naturally thus promote standards. What I′m unsure of is that if I should promote the "way" of this mod as standard, or pull if it doesn′t deserve it.

I′m also I realist, so eventually it comes down to the usefulness of this mod against the trouble of patching the quests needed, and the amount of them. That′s why I need opinions - if the problems seem numerous, it′s unrealistic to see this mod useful. If they seem scarce, and the mod seems helpful, it favors the idea of patching the quests.

The only reason I didn′t pull the mod yesterday (out of convenience) was because I eventually think against pulling mods once they are released as a principle, so I need to feel it′s the right thing to do for everyone before doing it.



I think he meant patching the quests so that when NPCs in the same faction has to fight, one of them is first removed from the faction - so they are not considered "brothers" (by this mod) when they do fight. And as crazy as it may sound, that IS the right place it fix it, if ANYWHERE.

If you think this mod′s priciple should be followed - then it should be followed, and the script and the principle kept simple itself. After all, it runs all the time in your game, while fixes in the quests add no extra code running! And we are not talking about ONE quest - there′s many to come for sure. And I even can′t handle checking every mod out there, and I have practically no slot for support of this mod in the first place, while any new quest maker COULD take it into account with practically no extra effort.

I′m not saying this SHOULD be, even arguing, just saying that in PRINCIPLE that is that way it SHOULD go, logically, or else this system won′t hold and this mod should be considered the wrong way to go.


As a modder and a programmer and someone that deals with standards in that area, I′m inclined to be pretty hard headed in situations like this, if I think the "easiest" solution is not the best one, or right thing to do. I avoid hardcoding fixes, and I avoid open-ended patching (meaning you fix explicitly something you see, without fixing the cause of the problem, knowing you′ll have to do it again in another situation).

I have had a lot to learn during the last few years, and the fact that I have to deal with my own code and the limitations of the scripting system makes most of my own scripts terrifying in my eyes nowadays. But I still try to follow and promote the things I believe are the right thing to do on a bigger scale. Obeying certain styles to do things is hard, it takes time to learn the disciple and the only way to succeed is to actually BELIEVE and PROMOTE the "right ways". So in this case, I refuse the easy fix cause I don′t believe it′s the right thing to do, it′s the easy thing to do now and wrong in the long run.

My sentiments exactly. I wouldn't have bothered to mention the issue if I didn't see a value to having this mod, I would simply have pulled it from my list and never bothered with it again. But it definitely serves a purpose in the game and IMO deserves to have the rough edges ironed out, one of those being the potential of not only breaking a quest but someone's game as well. Fortunately the problem I experienced wasn't a permanent one, simply turning off the mod for that fight allowed the action to continue again. But for someone who may not be experienced enough with mods to be able to troubleshoot conflicts, that could mean having to go through alot of headache trying to find the problem.

Thanks for releasing the script. Mod does exactly what it describes to do and I see no problems "tailoring" it myself for my game.

:foodndrink: For keeping it simple.

No it shouldn't. The UOP fixes bugs in the vanilla game. Just because two NPC's are part of the same faction, that doesn't mean they shouldn't fight. "Brothers" fight all the time This quest is not broken in the vanilla game, so there is nothing for the UOP to fix.

You can't go through every quest and try to anticipate a problem and fix it - the UOP can't do that and we're not asking you to either. I mean we're really dealing with a short-coming of the engine or the base logic here. You are trying to fix it using the resources at hand. It may not be the ideal fix, but that's what we have to work with.

All I'm suggesting is that you look at issues as they arise. If the issue is the result of something in the vanilla game, consider fixing it. So far this is the only quest that has this issue. We thought there might be one with a Dark Brotherhood quest, but fortunately Bethesda had seen to that already. Besides Guild affiliations are different because the game has already set things up that if you fight a guildmate, you are expelled. This is why Bethesda ensured the DB quest wasn't going to be a problem. City factions are different. They are just used to control rumours and little things like that. We just need to do something similar to the DB quest for this one. I really don't think there are going to be a lot more.

If you are a professional programmer, then you know it is up to you to fix bugs in your delivered product when you are told about them (unless you're Microsoft, of course). There are standards to adhere to and those standards have been derived from best practices. Best practice dictates that you do your best to mitigate issues... and a potentially game breaking bug is an issue. Sorry, but that's my opinion on the matter. Coming from a professional programmer and computer consultant...

I wish there was a way for guards to not outright attack NPCs that attack other NPCs within a city or attacking the player. If you attack an NPC the first thing a guard does is come to arrest you.
The first thing a guard does when an NPC that lives in the city attacks you is the guard kills that NPC.

That is a double standard in justice eh?

Guards need to arrest that NPC, then that NPC is teleported/escorted to jail where they stay for x amount of days, then they are released either by walking out or they reappear / respawn in the city somewhere. If they are a merchant, then a script should lock their store for that amount of time. I guess this is something a bit more involved than this mod.

I once had a game where this merchant (the male alchemy merchant in IC) attacked me because my disposition fell to at least zero when trying to get used to Persuasion Overhaul. He attacked me just because he didn't like my conversation...so I ran out into the streets where a guard killed him. His naked roberts body (that I had looted; looted his entire shop while no one was in it after his death too) lay in the street for days and days. He was no longer in the game after I left IC and his body was cleared.

But the UOP does edit the quest as well as the quest script. And it alrady makes edits in the name of mod compability

I guess we are just looking at things from the different ends of the rope. For me, pointing out a problem is not pointing out a fix - it′s often pointing out a sign of a bigger problem. I apprecitate you reported the "bug", cause it pointed out the bigger problem. But what you are suggesting as a fix, is simply easing the symptoms, not a cure.

I have explained that the real problem is bigger than that quest, which naturally needs deciding on first, as it serves the bigger audience. Unless we can safely say that that quest is an EXTREME exception, treating it exclusively and moving on is simply setting up a time bomb for more trouble. It′s not good practice. Good practice is seeking out a path that leads to no such problems - either by pulling the mod, or promoting certain practices of quest making (in which case I should add warnings about the possible problems, but NOT fix the ones I know, as two sides should never fix the same thing!).

This may sound over dramatic if you haven′t experienced the path of adding "small fixes" to your script multiple times, or witnessed in your work how everything is f***ed up in certain programming environment just because people can′t keep things coherent or up to standards. Looking at one problem in one situation with one mod, the solution is always conceivingly simple - and it IS, it′s not illusion. But that′s not the whole story, either.

I think the concept of this mod is worthy of being pursued further. But I wonder if faction alone is the best way to do it. What if you added a second script tied to disposition? If both npcs are in the same faction, and one of the npcs fighting has disposition towards the other high enough that the player could yield to him, than the fight is stopped, simulating yielding between npcs. If Aldos is made to attack the guard through a hit to disposition, this should (I think) stop the mod from saving him (and dooming the player).

I'm no modder, but I think something like that would stop accidental fights while still allowing scripted fights between faction-brothers.

Well I wasn't really trying to suggest a fix, though I suppose I did eventually. My main goal though was simply to let you know there's a problem. I'm not a scripter so I'm in no position to recommend anything but a very basic fix, which would in fact work in this particular case. I guess we're just looking at things from opposite sides of the spectrum here.

When first reading andalaybay's response I also thought about how unweidly it would be to have a script running that checks for specific characters all the time. I am told how efficient the script engine is but bloating a script seems, well, unnecessary.

Adalos (or whatever his name is) already has a reference script locked to the quest, haven't checked the quest for Dark Brotherhood but I guess it's the same. EDIT: Read andalaybay's second response. Aha, great - leaves them out Still, a companion filter patch so one can add troublesome quests from other mods seems to me a good way to go instead of updating the main script all the time with checks, even if it is just the one we know about right now. END EDIT

But if the UOP wont do it I vote for a filter patch that adjusts the Ref.scripts on the NPC's in question and add a faction remover at the right quest stage and/or fixes quest if necessary. Rather this than having it being part of this script that runs every frame.

I see no issues having a filter patch for it, it does not take up a slot and can be made compatible with many mods. I don't know enough about filter patches to know if they can include all this?

Cheers!

Fare enough - I can perfectly understand if you draw a line there.


But note that my point here was NOT that it′s "your job, not mine". I don′t consider this concept "my mod", therefore I don′t defend or aim to sell the concept. What I see is a concept that seems to have certain value, yet the rule it′s based on is not universal in the game, mods aside.

For me this means that UNLESS people consider it so good a concept, that if any situations in Vanilla game are "bugged" relative to this concept they should be fixed (whereas UOP would be IMO the proper place, as it also breaks nothing for the non-users), the concept is NOT good as it breaks Vanilla standards (or more literally, assumes a standard that does not exist) and therefore is a mistake on my part.


I may sound a like an uber fundamentalist here, but I do consider these IDEALS situation by situation basis. In this situation, the mod is VERY small a script. But if the rule it bases on is not valid and it gets messy, it nulls the whole point of offering a simple lightweight solution.

Mods that offer something extra to the game should not break existing features, naturally. They should be patched responsibly when they do. But this whole script is essentially the same as adding an extra Global setting to the game, and turning it on. The question is about keeping it, or loosing it. Otherwise it′s not an extra convenient gameplay setting, but another spiderweb of a script that attemps to change the game. That was not my attention, and therefore I′m pulling it if that′s the case, cause I don′t have the time for another project right now.

What if you just excluded city factions from being checked? That would solve the issue, and being from the same city shouldn't be reason enough to stop two people from fighting anyway.

btw, please don't pull the mod, this is a really great idea and imho fixes a fundamental immersion shattering flaw in the game.

@Skycaptain: Yeah I think I see where you're coming from now. You are concerned about the so called "slippery slope". Pretty much what the UOP itself has wound up on. Start fixing a few little things and next thing you know, you've rewritten the game!

I can't comment on the scope of this - I really don't know and it might be something that only becomes apparent in time. There are two different approaches to fixing this. One would be to add some code to the existing script that would test for this particular quest. Yes, it would be running all the time. Yes it would bloat this one script and if other quests need fixing, you are well on your way to the "slippery slope".

The other option is the UOP approach. Basically you would override the quest. This has the benefit of not running all the time. The game engine is optimized to handle stuff like this very well. The problem with this approach is how to incorporate other changes to the quest into your mod. I've had several mods that used an earlier version of the UOP to base their changes on and so subsequent versions of the UOP would be overwritten by these mods. I've gone in and fixed them myself to add the latest UOP changes back in.

I wish there was a method for extending quests (I'm referring to the java term here where you would extend a method in a descendant class). Basically you could add to an existing quest in a mod without overriding the whole thing. But that's not possible. About the only thing I can say is the most of the work on the UOP is done now, unless something game breaking is found, so I think overriding this quest would be fairly safe. What other mods do to that quest, I can't say.

As suggested previously in this thread, it would be nice to overhaul the whole crime mechanic in the game so that NPC's aren't killed anyway. I think that is outside the scope of this mod though. It wasn't Skycaptain's intent to overhaul the crime system, he was just hoping to alleviate the effects of fights when they do break out between NPC's, for whatever reason.

I will mention that we ran into a similar problem with another mod. I was helping the author do some testing and we discovered some unintended side effects when he had certain NPC's move to new areas. Basically these NPC's wound up attacking everybody in sight. The fix in that case was to simply lower their aggression. We can't do the reverse to Aldos though, because we don't want him attacking everybody all the time

So, some things to think about I guess. I'd be inclined to override that quest and put the fixes in. If this winds up being an unending task, then you reconsider the whole mod. I don't think it would be though...

That′s not a bad suggestion, in concept that would be a working global solution probably covering many cases. But unfortunately the only really useful faction related script function is "samefaction", that only tells if two NPCs share any a faction, by returning 0 or 1.

Man you put it shortly. Not my main talent I guess. :rofl:


But really, I′m thankful that someone finally reflected what I was trying to say. Moreover, I feel this is my not slope. What I released was simple - if it won′t stay that way, I don′t want anything to do with it. I already took that 15min (and all this posting as well) from finalizing DR6 , which is my slope if it really needs to be underlined, and that has been a long one already and probably just continues after release.

So I′m torn between two here, I′m long past the point when I felt I made a huge mistake, and my principles tell me to pull the mod if I′m not going to support it further (with the issues brought to my attention), on the otherhand I don′t favor the idea of pulling mods just because they are not supported. Sigh, if someone would walk here right now and say "may I look at what you got there?" I would hand him the script, and run away as fast as I can. :bolt:

I finally downloaded this and took a look at it. I can see why you wouldn't want to get into overriding quests - this isn't dependent on oblivion.esm at all! Anyway I would like to take a look at this if you don't mind. I wonder if we could solve this by simply adding some flags to the ini file. I'm thinking of an override flag when a specific actor or situation was involved. We wouldn't care why the flag was set, but if it was, then we wouldn't stop combat. I'm thinking that this way we could maintain the independent and light-weight nature of this mod, but still be able to add to it if we find situations in which we need to abort the usual processing. Now we'd still need a way to identify the situation so that the flag could be tested - I haven't figured out how to label or identify these situations yet. You have identified the actor already and it might be as easy as testing one of the actor attributes - not the form ID though! That changes

What do you think?

I′m actually relatively new with Oblivion mod INI files, but I think we can′t exactly READ the mod ini files like we can read Oblivion ini - rather the ini files write to the quests/variables, when the INI is run like a set of console commands?

Anyways the overall idea is good, it could be some global as well, IIRC we can check if one exists and manipulate it via "runscriptline" which has the same global scope as the console has. But the detection of an exception is hard - it kinda all comes around, if I knew how to do it via script commands, there would be no problems in the first place. I really don′t know if there′s any other way than addressing the source, unless this one particular NPC discussed carries a peculiar feature that could be further looked into?

Yes, basically an ini file is a bunch of set commands that initialize variables. This is only a rudimentary idea at this point, I need to flesh it out more. But I'm thinking of something like, set x, y and z. In the function, you would test x, y and z and if z is true, you wouldn't abort combat. This would allow you to set a condition and a target and if those are true, set override to true. Three variables might not even be necessary, but I'd like to build in some flexibility too...

Let me play with it some more and I'll send you some script via pm. Then if you want you can include it in the mod.

Yeah, please don't pull the mod. I'd rather see a mod that is still out there unsupported rather than one pulled. At least the general public can help support it if anything.

Found a second problem situation - watching arena fights. The combatants are not members of te Yellow Team and Blue Team respectively, but instead they are both members of the ArenaSpectatorCombatants "Arena Spectator Combatants" [FACT:0001E65B]