GECK - A question about dialogues

[Guest]

Hello, I have a little issue with dialogues, I suppose it comes from my misunderstand of how it works. I'm quite disconcerted because I wrote... I don't know, 2000 lines? more? well, only now I find this issue. Essentially, even if I tested in game for more than a hundred hours, I found this issue only now playing another mod, while mine was active. I was testing my mod on vanilla and never had this issue, but another tester already noticed it once and told me about that, but  I couldn't do anything because I really didn't know why this was happening. Now I've also seen it with my eyes the issue and I really must understand it better.

 

So... this is what I do on dialogues:

 

- I use very peculiar and long names for topics, it's impossible to have a conflict with that or another mod

- I place GetIsID as condition ONLY on shared topics (as GREETING)

- After that I link to the other topics using Choices

- I don't use anything else than that, I don't use Top-Level, Speaker, etc.etc. (apart result scripts, conditions and flags like SayOnce)

 

I was thinking that this was enough to create a univoque way to trigger a certain topic: it is only linked by Choices, I take very much care on placing GetIsID on GREETINGS or other shared topics. But when I've seen one of my dialogue lines popping out on the npc of another quest mod I really fell down on an endless pit... I opened both the mods to check: concerning what I was thinking (THAT SURELY IS WRONG) there weren't apparent reasons.

 

Now I'll have to take all those dialogue lines one by one and modify them all so that this can't happen anymore. But since it was very hard to notice (I only noticed this time; another user testing it reported the same with a companion - this means 2 cases in thousand lines and hundreds hours spent in testing) I REALLY NEED to know exactly what should I do to avoid something like that.

 

The first thing I can think is placing all the GetIsId in every topic. But also I'm wondering if the Speaker droplist must be set etc. I mean, I really would like to know how to definetely avoid issues so that I can spend the next days correcting all that huge amount of lines without do a useless work...

 

I really thank you all.

[DoctaSax]

I've never used the speaker droplist myself; don't see the point of it other than scripted conversations between npc's etc maybe, and I think it's tied to the prompt.

this could just be a case of that particular line being flagged as top-level by accident. Otherwise using "choices" is very reliable, really, especially in combination with well-named topics. It could also be conditions leading the "choices" result to blank. Hard to say much else without a look at the esps. I always use GetIsID conditions on every topic line myself though - if it's just meant to be for one person. This may sound like a lot to catch up with, but you can copy/paste conditions pretty easily.

[Swyke]

Sounds realy weird.

 

I am usualy starting dialoges by using the 'greeting' or 'top level' and the GetIs ID, too. The 'choices' get sometimes the GetIs ID condition. But most times I am to lazy and if I have a topic with five or six conditions every further (and imho unnecessary) condition gets it more confusing.

 

I had the issue with sudden topics on wrong npcs only twice, and both where replicable: As I checked the 'top level' by accident. And as I used (also accidentaly) the 'add topic' instead of the 'choices'.

[Guest]

Thank you very much for your answers. Wow, from what I read I can get that maybe I didn't misunderstand everything, maybe I was doing it correctly, this counts very much to me! Wohoo!

 

I opened both my mod and the other one, to check Top-Level: mine wasn't flagged, it was everything as I always did, and with a topic ID like aaPKatHeyAfterTopic1a I doubt that there's a duplicate but yes, I already checked those things since I thought it was unbelievable. Still, they all are in Choices and not Topic.

Now I'm still investigating this thing because is very strange. But if you have more infos I'll be really glad.

What I can say is that NPC from the other mod had a dialogue in a different way, I never did them in this way: it had GREETING with GetIsID, then it was linking to 5 topics using choices, those 5 weren't linking anything else but they all were Top-Level. Anyway, my little mind would think that I could expect the contrary happening, if it makes sense... I still can't understand how one of my topics popped out on that mod. And in vanilla too, in one of the followers, as my other tester reported.

 

Ok now if this thing is too stupid please just go over... I was thinking... You know when you start an ID with numbers it could confuse the game... I've read it is because it can't understand if it's hex or ascii, I don't know exactly what's behind it. Anyway... have you ever tried to filter 000 for example on the GECK? random results appear. Also with other combination, I don't know if you already know why that happens. Anyway... while I was checking that mod in GECK, I filtered the prefix the modder used: "BAD". I found unexpected results. Strange, uh? ...

 

Here, this is the mod whose NPC popped out my topic:

http://www.mediafire.com/view/s5t0151hiln6uav/HisMod.jpg

PS GREETING links to those IDs, they are all Top-Level with no Choices or Topic

 

And this is my mod, the topic I underlined is the one that will show in the third image:

http://www.mediafire.com/view/97iv4c19ojiwwi8/myMod.jpg

PS this topic comes from GREETING, from Choices

 

And this is how the first mod (not mine...) shows in game, with my topic on top...

http://www.mediafire.com/view/x5caxh5w3pay73l/Result.jpg

[Odessa]

I never use GetIsID for choice subtopics that are only linked from one place (which will have the GetIsID)

 

I wouldn't bother going to the effort of changing every topic to have that condition, because if the check failed once it will probably just fail again.

 

You should check your conditions again and again in case there is an OR not an AND, etc, but the GECK has a hidden mood variable, and dialogue makes it particularly ornery.

 

Conversation scripts are very unpredictable; I assume you aren't using the 'AddTopic' function within them? Even if not, they are perilous- I have copy/pasted scripts between 2 topics and got inexplainably different results. I put nearly all code in Quest and Effect scripts in SexoutSoliciting for this reason. Astymma has some insight in the scripting 101 thread.

 

Good luck

[Guest]

I never use GetIsID for choice subtopics that are only linked from one place (which will have the GetIsID)

 

I wouldn't bother going to the effort of changing every topic to have that condition, because if the check failed once it will probably just fail again.

 

You should check your conditions again and again in case there is an OR not an AND, etc, but the GECK has a hidden mood variable, and dialogue makes it particularly ornery.

 

Conversation scripts are very unpredictable; I assume you aren't using the 'AddTopic' function within them? Even if not, they are perilous- I have copy/pasted scripts between 2 topics and got inexplainably different results. I put nearly all code in Quest and Effect scripts in SexoutSoliciting for this reason. Astymma has some insight in the scripting 101 thread.

 

Good luck

 

Sometimes I use abstruse AND/OR conditions and I always test ingame soon after I finish a dialogue, because almost always I do mistakes with that, forgetting flags, etc. Also sometimes things don't work as I expect: few days ago I found that using a AND and two OR conditions, makes the OR completely useless, it checks only the AND ignoring both the ORs, while I was expecting it was going true with the AND and at least a verified condition between the two ORs. I had to split it in two different topics, both with the same AND and a single OR changed to AND...

 

Anyway, this issue I'm having now is really different, as you can see in that picture my topic had not conditions (it was just linked by a GREETING with only my correct GetIsID), the other topic of the other quest had its own GetIsID... This is ... unconfortable.

 

If you mean using AddTopic inside the result scripts or in an external script during the game, no I don't use it because I feel it's dangerous, not for your experiences but because when a dialogue has many topics it's hard to track down what's happening after a while: if I place more topics in other ways it becomes harder and harder. I prefer handling all my topics with conditions and variables, so that if a topic must come out at a certain point I'll do that setting a variable and checking the conditions (sorry if I explained bad).

 

And about copy/paste... well... my dialogues are all copy/paste from Notepad, I write them down before. I hope this too doesn't create issues :-O

 

MORE UNCONFORTABLE is what I just discovered... having a topic highlighted, I clicked on the top left flag "only Top-Levels", which should show me the Top-Level topics I have in that dialogue: doing this operation, it erased the Prompt tab of the topic I was highlighting. Well, no problem, I'll write it again. Fact is, it was the same topic I had the issue... after rewriting it and saving again, I had no more issue with that mod. This is... SCARY... Now I know there's at least another topic that has the same problem, but who knows how many other ones! This means I should play the game, other quests, vanilla, other mods etc. for dozen and dozen hours to see if some other topics of mine will pop up randomly in other NPCs dialogues! Oh god, can you believe me I was going to upload this mod tonight, and I found this issue at the very last? Grrr GECK you're mean!

[Victoria K.]

First thing I would suggest you is to put the conditions on the Quest Data tab first when it's possible instead of filling the Topics or Conversations tabs.

Exemple: if a quest involves only a bunch of people and it's not affecting a vast number of the population, just put them all in a faction (create a new one), then put the function GetinFaction in the field conditions of the Quest Data tab. This is a secure way to not get involved in that dialogue anyone else than the ones inside that faction and a good way to not mess more than necessary the Topics and Conversation tabs, there will be no need to put the condition in these "internal" tabs and everything gets simplified.

The same goes for single NPC via getIsId and anything else you could put as a first general rule in the Quest Data tab.

 

My english isn't very good and it's quite difficult to explain it a bit better, only thing I want to say is there is no dialogue issue that could not be solved, I speak for my experience, I managed to get working very complex and tricky quest dialogues, not because I'm that good but because the geck is not that broken, only a bit messy but you should get it working if you really care about your project.

 

Feel free to pm me the esp if you like, I would gladly help you out. I know what's mean to create a lot of dialogues and not see them working properly. Can be quite frustrating, but I repeat, I think there is no dialogue problem impossible to solve, eventually, if you really care, you will be able to get it working.

 

 

Edit: Oh, now I see your pictures and your post is more clear to me, yes, you MUST assign the id to the others lines too, it's needed, even if these are directly and uniquely originated from that greeting. Except the case you put a general ID rule on the Quest Data tab.

 

If you can't do this because there are too many characters involved and you think you could mess or/and, try with the voices, you could create a condition for some kind of voices only or create a new custom voice (a vanilla faked custom) for a character, then you would need to just change the path folder, not the lines filenames, not sure I've made it clear. Long story short: you must add the ID to the lines, you could avoid this only with general conditions on the Quest Data tabs if possible (IDs, factions or voices are the most common ways).

 

In any case, if this is really all the problem, shouldn't be a big deal to copy and paste the getIsId from one line to another, you have lot of lines, of course, but it's not so incredibly awful either. The important is to get the dialogue working.

 

 

 

 

[Guest]

Hello, I answered in uppercase inside your post

 

First thing I would suggest you is to put the conditions on the Quest Data tab first when it's possible instead of filling the Topics or Conversations tabs.

Exemple: if a quest involves only a bunch of people and it's not affecting a vast number of the population, just put them all in a faction (create a new one), then put the function GetinFaction in the field conditions of the Quest Data tab. This is a secure way to not get involved in that dialogue anyone else than the ones inside that faction and a good way to not mess more than necessary the Topics and Conversation tabs, there will be no need to put the condition in these "internal" tabs and everything gets simplified.

The same goes for single NPC via getIsId and anything else you could put as a first general rule in the Quest Data tab.

 

---- THIS IS A VERY GOOD IDEA, I DIDN'T THINK ABOUT THAT. HOW THE CONDITION IS HANDLED INSIDE THE "QUEST DATA" - "QUEST CONDITIONS", FOR WHAT CONCERN THE TARGET/SUBJECT? IS THE NPC SPEAKING THE "SUBJECT", AND THE PLAYER THE "TARGET", AS FOR THE OTHER CONDITIONS UNDER "TOPICS"?

 

My english isn't very good and it's quite difficult to explain it a bit better, only thing I want to say is there is no dialogue issue that could not be solved, I speak for my experience, I managed to get working very complex and tricky quest dialogues, not because I'm that good but because the geck is not that broken, only a bit messy but you should get it working if you really care about your project.

Feel free to pm me the esp if you like, I would gladly help you out. I know what's mean to create a lot of dialogues and not see them working properly. Can be quite frustrating, but I repeat, I think there is no dialogue problem impossible to solve, eventually, if you really care, you will be able to get it working.

 

---- I'M SURE OF THIS, I'M JUST LOOKING FOR THE BEST / A BETTER WAY TO MAKE A DIALOGUE SO THAT IN THE FUTURE I WON'T DO THE SAME MISTAKE. FINDING IT AFTER HUNDREDS HOURS OF TEST IS DEFINETELY DISCONCERTING... :-O

 

Edit: Oh, now I see your pictures and your post is more clear to me, yes, you MUST assign the id to the others lines too, it's needed, even if these are directly and uniquely originated from that greeting. Except the case you put a general ID rule on the Quest Data tab.

 

---- IF YOU ARE SURE OF THIS (THE GETISID CONDITION OR ANOTHER UNIVOQUE CONDITION ARE MANDATORY FOR EVERY TOPIC), I THINK THIS IS AN IMPORTANT THING THAT SHOULD BE STICK IN SOME POST/THREAD, SOMEWHERE, BECAUSE EVERYONE SHOULD KNOW THAT: I SAW I'M NOT THE ONLY ONE THAT DOESN'T PUT THOSE CONDITIONS WHEN A TOPIC IS UNIQUELY CONNECTED BY ANOTHER TOPIC.

 

If you can't do this because there are too many characters involved and you think you could mess or/and, try with the voices, you could create a condition for some kind of voices only or create a new custom voice (a vanilla faked custom) for a character, then you would need to just change the path folder, not the lines filenames, not sure I've made it clear. Long story short: you must add the ID to the lines, you could avoid this only with general conditions on the Quest Data tabs if possible (IDs, factions or voices are the most common ways).

 

---- THE THING OF THE VOICES SEEMS INTERESTING, BUT I DIDN'T UNDERSTAND EXACTLY WHAT YOU MEAN. I CAN CREATE A NEW VOICE, DUPLICATING A VANILLA DEFAULT, THEN I CAN PUT IT ON A CERTAIN NPC. BUT THEN? HOW THIS MAKES A DIALOGUE UNIVOQUE FOR THAT NPC? PUTTING A "GETISVOICETYPE" INSIDE THE CONDITIONS?

 

In any case, if this is really all the problem, shouldn't be a big deal to copy and paste the getIsId from one line to another, you have lot of lines, of course, but it's not so incredibly awful either. The important is to get the dialogue working.

 

---- I AGREE, I MAINLY WANTED TO KNOW WHY THIS WAS HAPPENING, SO THAT I COULD AVOID THE MISTAKE IN THE FUTURE. IF THE REAL PROBLEM IS WHAT I HIGHLIGHTED IN THIS POST BEFORE, IT SHOULD BE STICK SOMEWHERE, REALLY.

 

 

[Odessa]

When I said copy/paste I mean in reference to result scripts not dialogue text. Sometimes result scripts just inexplainably don't work in one place even when an identical one somewhere else does. Hence, if I need to do anything complex I either via result script do a CIOS to run an effect script or start a quest / set a var in one to run instead.

 

Quest scripts have a lot of advantages- multiple runs, easy conditionals, static variables and more, just use StopQuest  ... return  to end. But, GameMode blocks do not run whilst in conversation, they run after. If you CIOS an effect script then this does run in dialogue, and can be used to set quest vars elsewhere- in Soliciting I use this to partly calculate 'random' dialogue across multiple topics.

 

I again dispute that you need to set any conditions in single option dialogue that is not top level, HELLO or GREETING- I probably have 500-1000+ topics in my mods and don't do this with choices. Although it is good practise.

 

There is an exception: if you are using recorded voice then you need GetIsID set on every topic.

 

I would suggest checking for errors using FNVEdit. It may well not show anything, but its easy and worth a go if you haven't

 

Also: if it is just this one difficult to find bug that is stopping you uploading... you could just upload it anyway and maybe say 'beta', because with more people looking it will get found faster.

 

[Guest]

When I said copy/paste I mean in reference to result scripts not dialogue text. Sometimes result scripts just inexplainably don't work in one place even when an identical one somewhere else does. Hence, if I need to do anything complex I either via result script do a CIOS to run an effect script or start a quest / set a var in one to run instead.

 

Quest scripts have a lot of advantages- multiple runs, easy conditionals, static variables and more, just use StopQuest  ... return  to end. But, GameMode blocks do not run whilst in conversation, they run after. If you CIOS an effect script then this does run in dialogue, and can be used to set quest vars elsewhere- in Soliciting I use this to partly calculate 'random' dialogue across multiple topics.

 

I again dispute that you need to set any conditions in single option dialogue that is not top level, HELLO or GREETING- I probably have 500-1000+ topics in my mods and don't do this with choices. Although it is good practise.

 

There is an exception: if you are using recorded voice then you need GetIsID set on every topic.

 

I would suggest checking for errors using FNVEdit. It may well not show anything, but its easy and worth a go if you haven't

 

Also: if it is just this one difficult to find bug that is stopping you uploading... you could just upload it anyway and maybe say 'beta', because with more people looking it will get found faster.

 

Thank you Odessa. I'll tell you more about result scripts: I noticed they compile even with mistakes inside sometimes. Well this happened at me in normal scripts too, but very very very few times (just a couple of times) compared to result scripts.

 

Script quests are definetely the best. But you know there are some things that must happen inside the dialogue itself, think for example when you give a piece of equipment to someone, by dialogue, and you want him to wear it while you are still speaking with him. Also, I used quest scripts to replace some dialogue end results sometimes, but this means introducing a Gamemode block that will be trigger when a specific condition is set (I.E. in scripts result I setstage, then on a gamemode quest script I place if getstage etc.etc. do that). This creates two side effects: on a side, it will introduce a delay because of the Default timing of quest scripts, this often is annoying for me, but I'm trying not to low that delay from default because of the second point >>> On the other side, this introduces a new Gamemode block: this is an aspect I'm still trying to evalutate carefully. I don't know if you've read the thread when I was asking about ways to purge my mod etc. Well, this is came out when I spoke with a scripter that made many incredible mods, heavily and incredibly well scripted: he told me my way to handle things with gamemodes isn't good because it creates unuseful delays that could create unexpected issues, I should avoid that kind of behaviours. Since I'm a newbie, I'm just trying to find a compromise, good ways to do things to not create issues to other peoples. That guy told me my 160+ scripts are not a good thing when many are Gamemode... I guess you can agree with this. This is the result of my first mod experience, you know... you start with an idea, then you place patches over patches over patches and at the end you have a "repaired" mod, not a new one. I'm sure in the future I'll use more common sense.

 

Putting a Beta on the Nexus is against the rules. I know people do that, but I'd prefer sticking with their rules more than I can. Also, I could care less if my mod has an issue like the quest stage isn't updated and the quest breaks; but having an issue like this means that potentially my dialogue could pop up in someone else mod, I find this issue very serious.

 

FNVEdit - Check for errors has everything good: it only has a single error that I can't track down because I ignore its meaning. Should I do something else?

 

--------- NOW I ADD MORE, THE LAST BLOW TO THIS CONTROVERSIAL GECK BEHAVIOUR ----------

 

Yesterday I tried that part many times, to see if I could find a reason why that line should pop up. Everytime I was doing a modify in GECK then trying the same exact sequence in game. Everytime it was popping out. Today I recovered the backup of yesterday to put myself in the same exact situation of the issue before I did those tries, so that I could investigate more: I overwrote the esp, I reloaded the same savegame, I did the same things, THAT DIALOGUE LINE DIDN'T POP UP! load order? no, it was the same; broken savegame? mmmh, I tried many different savegames too; mod conflicts?  well, one of my testers, with a brand new vanilla installation and a new game, noticed the same issue with a completely different dialogue, with other NPCs. This - is - disconcerting. So I really think that condition is becoming mandatory: even if it shouldn't be, I think it's a good way to avoid a situation like that (that after the last events, I'm starting to think it's a bug and not my mistake).

 

The same reason why I use to script in this way, don't look the effect of the script but the way I placed conditions, if you can understand my feeling in what I'm writing:

 

if NPC.getdisabled == 0

  NPC.disable

endif

 

instead of

 

if doonce == 0

  NPC.disable

  set doonce to 1

endif

[jaam]

Hu!

Thank you Odessa. I'll tell you more about result scripts: I noticed they compile even with mistakes inside sometimes. Well this happened at me in normal scripts too, but very very very few times (just a couple of times) compared to result scripts.

 

Can you provide an example ? That's totally not what I ever saw.

[DoctaSax]

I've never had problems with simply setting quest vars, casting spells, calling UDFs etc in result scripts. Anything more complicated than that, I try to avoid. Also, I hit "compile" religiously, sometimes several times without good reason other than superstition, and get out of the quest window to save excruciatingly often.
 

Sometimes I use abstruse AND/OR conditions and I always test ingame soon after I finish a dialogue, because almost always I do mistakes with that, forgetting flags, etc. Also sometimes things don't work as I expect: few days ago I found that using a AND and two OR conditions, makes the OR completely useless, it checks only the AND ignoring both the ORs, while I was expecting it was going true with the AND and at least a verified condition between the two ORs. I had to split it in two different topics, both with the same AND and a single OR changed to AND...

Setting conditions in all your lines... well, usually unnecessary, I suppose, but better safe than sorry If that leads to many conditions for the same line, all is obviously well if they're all ANDs. If there are a couple of ORs, I put them on top - both AND & OR are the relation between the condition it's attached to & the condition underneath, so if you go:
- condition1 OR
- condition2 OR
- condition3 AND
- condition4 AND (final)

that works out fine for me, if I want "always 4" AND "one of the first 3", ORs taking precedence over ANDs. But if you're looking at something that goes like:

- condition1 OR
- condition2 AND
- condition3 AND
- condition4 OR
- condition5 OR
- condition6 AND

then you'd better be sure about what you're doing. CheckMeOut has some of that, for hundreds of lines, and I'll never do any of that again if I can avoid it by just making 2 separate lines - which would've been more impractical in that case. You can't use parentheses like you can in a script line with || and &&, so because OR > AND, you need to work all that out carefully to something that follows geck rules (or > and, no parentheses, from top to bottom)
Let's say you want conditions like:
A OR (B AND C), then you need A OR B AND A OR C AND -- the geck condition version of (A OR B ) AND (A OR C)
(A AND B ) OR (A AND C), then you need A AND B OR C AND -- the geck condition version of A AND (B OR C)
 

MORE UNCONFORTABLE is what I just discovered... having a topic highlighted, I clicked on the top left flag "only Top-Levels", which should show me the Top-Level topics I have in that dialogue: doing this operation, it erased the Prompt tab of the topic I was highlighting. ... Grrr GECK you're mean!

Yeah, that's just weird.

[Guest carywinton]

This is an excellent topic and one of the main reasons I came to "LL" in the first place. I have always had a deficiency in this area, and most of what you folks are discussing is still over my head, but I am at least getting some of it. And with the Docta! in the house, we are sure to have a really informative topic.

[Guest]

Doctasax

I still have to fully understand what you wrote, I'll do some tests to verify if I really understood it. But what I can get is that I probably I didn't use the same common sense on using OR AND inside the Topic conditions, and when I noticed they weren't working I used workarounds. Thank you very much for that explanation.

 

Jaam

The first example happened not a long time after I started with scripts.

I had a script with (some condition) && (some other condition). I placed %% instead of && (or it was !! instead of ||? anyway, very similar). I continued to not notice that for 3 days, banging my head and not understanding why it was breaking in game... Then an angel decided to come down to LL and saving me from the breakdown (Doctasax...  http://www.mediafire.com/view/myfiles/#obfhvpvndaujfh6)

After that I had only 2 more examples like this. The first one, I killed it when I feeled the same situation, I simply rewrote everything, I didn't want to spend 3 days checking and then posting a silly question like I already did before... The last one was the one I spent more time investigating because I was feeling a little more confortable with scripts, I want to describe everything because it was really interesting for me.

I had a 150 lines script with many if else endif. As the previous one, it was compiling but in game it wasn't doing everything. I soon thought I had the same case, now when only half script is executed even if compiled, I must look where this half stops and I find the bad line. So I started re-reading and placing sometimes my semicolons to isolate the blocks. Doing that I did a mistake, I semi-coloned an endif without placing the semicolon to its if. It was then that I realized what I wrote: I started placing random mistakes and typos, everything was compiling, in game it was breaking (not CTD, only it was executing till the first mistake). Since they were the days when you asked me why I wasn't using PU, I fired it and recompiled it with PU on... can you guess what happened? no-thing. I started another script, I copied on notepad the first one, I pasted on the new one, changing the SCN: it compiled. I attached the new one it and tried it ingame: same exact issue, it was breaking at the first typo. I re-read more and more, correcting the obvious typos I introduced, looking for the one that was breaking in game. I was almost sure I had done another silly mistake like placing those %% and I still couldn't see it. So I started to semi-colon EVERY SINGLE LINE THEN TRYING IN GAME: I didn't find it. I was thinking I was crazy. At the end, I started a third new script, I started to copy paste EVERY single line and trying it in game. It was working... and again... and again... TILL THE END! The last version of the script was corrected! So... I took again the previous script (since it was correct...) and tried to re-attach and tried in game: break, again! I really didn't know if I had to laugh or cry but I found how to understand when this is happening: I place a semicolon on the very last endif or end: if it compiles it means that there are other errors and my script is messed.

 

Anyways, this is general issues about new scripts (when I click on the pencil). Instead, in End Result I usually place shorter things, so it doesn't happen often to make a mistake. But it happened that it compiled even if I had mistakes, I say it happened more frequently that with the other types of scripts. I noticed issues with copy / paste me too, and also sometimes when I had 2 mistakes and it wasn't compiling, then I was correcting only one and it was starting compiling (even if another mistake was remaining).

 

Last, the Stage Quest scripts: those are mean for me. I try to place very very very little things there. The last ones made me a lot of crashes in game and I had to use workarounds.

Following other quests as example and reading in Bethesda guide, I used to do something like this:

10 SetObjectiveDisplayed 10 1

20 SetObjectiveCompleted 10 1 - SetObjectiveDisplayed 20 1 - RewardXP etc.etc.

then, by dialogue for example, I was placing a SetStage.

On the last quests, it wasn't working anymore, causing crashes in game. First, I found the RewardXP was causing the CTD so I had to put it in the dialogue just after the setstage. Then, during the last quests I wrote, even the SetObjectiveCompleted was causing the CTD, so I had to place that in dialogue too or inside scripts attached to the quest.

 

As before I said, after our "discussion" I sometimes fire up PU when I have these kinds of issues, just to see what it thinks about it. It usually doesn't comment at all, while I know for sure it has always something to tell me, you know it points out a lot of mistakes. As for that Persistence Reference flag I missed, for example, it found it in a second, when you told me to do a "check all the scripts" with PU on.

 

Do you know what I think about this all? I'm starting to think I'm becoming an exception. I think I created some sort of monster inside the GECK that plays me bad tricks. I could tell you many of those, but please believe me if I tell you that everytime I really spend a lot of time trying to understand why these strange behaviours happen, because if I find something new I really would be glad to share it. But at the end often I find that I won't obtain anything and it's just "acting strange", so I usually decide to find a workaround that make issues impossible to happen (like that little script example on the previous post). I thought "hey, I can't be the only one having these kinds of issues", then I read things in LL and I see that everything works flawless for you and these things seem not happening. I'm wondering if it is caused by the fact the GECK CTD everytime I close it, I'm wondering if leaving it open then going ingame to try if the results work could damage it, etc.etc.etc. I wonder a lot why these things happen, really. Just to say, my GECK is the 1.4.0518 and my NV is updated by Steam, I don't use PU and I use NVSE on GECK, but the first issue with the script saving even with typos came out when I still wasn't using NVSE.

 

Sorry if I was a little too "long"... oh, and if you all think GECK is driving me crazy, I can't blame your opinion of me *laughs* But please tell me: if these weird events never happened to you after all your years of experience, while I had many in 4-5 months, just tell me so that I can stop posting them: I think reporting these things when I'm the only one having them is not only useless but also more dangerous than helpful.

[Halstrom]

Lol, GECK drives us all crazy, I spent 2 hours yesterday trimming my Load Order, reinstalling NVSE, Extender, GECK & PU because an extra endif in a quest script somehow caused a CTD so bad I had to restart the computer and do all of the above to get the game to work again. Even then it was still freezing the game even though I had commented out the line starting that quest

 

all I could get to was that NCR Ranger with his revolver staring at me through his red tinted mask, but oh yes I could tell he was laughing and mocking me behind it

[Victoria K.]

 

Edit: Oh, now I see your pictures and your post is more clear to me, yes, you MUST assign the id to the others lines too, it's needed, even if these are directly and uniquely originated from that greeting. Except the case you put a general ID rule on the Quest Data tab.

 

---- IF YOU ARE SURE OF THIS (THE GETISID CONDITION OR ANOTHER UNIVOQUE CONDITION ARE MANDATORY FOR EVERY TOPIC), I THINK THIS IS AN IMPORTANT THING THAT SHOULD BE STICK IN SOME POST/THREAD, SOMEWHERE, BECAUSE EVERYONE SHOULD KNOW THAT: I SAW I'M NOT THE ONLY ONE THAT DOESN'T PUT THOSE CONDITIONS WHEN A TOPIC IS UNIQUELY CONNECTED BY ANOTHER TOPIC.

 

 

I'm sure about this to the extent to which the Geck manages the dialogues this way and I never had a problem doing accordingly.

 

Look at the very simple Example in the picture: a complex quest with NO Conditions in the Quest Data tab and so many lines in there originated by greetings with unique ID (like in your case).

 

 

Here the page of the Geck tutorial that explains the importance of the ID/conditions in the topics, should help:

 

"These are very important for the quest. If there are no conditions for the topics, every one of them will be displayed almost always and every NPC could use them."

 

http://geck.bethsoft.com/index.php?title=Quest_and_Dialogue_Tutorial

 

[Guest]

Halstrom

"...because an extra endif in a quest script somehow caused a CTD..."

Do you... do you mean that it was compiling with an extra endif? If it is so, I'm GLAD! I mean, don't misunderstand me it would mean that this "compile even with errors" happens to you too and I won't feel alone anymore against this GECK monster!

 

Victoria K.

Thank you, it is exactly what I wanted to point out in my first post. I admit I've read carefully Bethesda guide and I always use it as reference, but when I've read that thing about GetIsId I simply decided to not do it because I was thinking it was redundant... And an explanation could be Odessa's sentence: "There is an exception: if you are using recorded voice then you need GetIsID set on every topic." which is the case of vanilla game and not my case since my dialogues use only subtitles. Also, I asked about the Speaker dropdown menu because I already noticed vanilla puts names on it, you can see it in your picture too: see how they placed Dazzle in the Speaker box at the right? Could it be necessary?

[jaam]

Ok. I have to agree extra endif CAN compile, I should have remembered that. I recently found one in one of SexoutNG script. The way to find where they are is to use a better editor, like Notepad++, and collapse the if blocks until one stand out. By the way, anybody can confirm it happens without NVSE ?

[Victoria K.]

 

Also, I asked about the Speaker dropdown menu because I already noticed vanilla puts names on it, you can see it in your picture too: see how they placed Dazzle in the Speaker box at the right? Could it be necessary?

 

Speaker should theoretically work as ID. I personally prefer to put directly the ID since I can copy/paste the condition from a line to another (IF I've not already used a suitable condition in the Quest Data tab - which I prefer-) and never used Speaker for common lines but only for "special" ones: I used that in two quests where the characters had animations on specific lines just to be sure (the important "Speaker" in this case is in the Edit Response window but I used it nonetheless). So with no animations or specific emotions settings I don't use that.

 

[Halstrom]

Halstrom

"...because an extra endif in a quest script somehow caused a CTD..."

Do you... do you mean that it was compiling with an extra endif? If it is so, I'm GLAD! I mean, don't misunderstand me it would mean that this "compile even with errors" happens to you too and I won't feel alone anymore against this GECK monster!

 

Yeah, extra endif always have compiled ok, missing ones don't though, if a script is being screwy often I will deliberately delete the last endif and try saving it, many times this has shown me I have an extra one somewhere.

[Guest]

Ok this is quite a dumb example... but this compiles too, even with PU, even if I don't really know what it means:

 

if (player.getangle x 0) %%%% (player.getangle x 0)

if (player.getangle x 0) £ (player.getangle x 0)

 

Or... a complete script:

 

scn aaptry

begin gamemode

    if (player.getangle x 0) %%%% (player.getangle x 0)
    if (player.getangle x 0) £ (player.getangle x 0)

    endif
    endif
    endif $hh

end

 

 

Victoria K.

Thank you very much for those infos about dialogues. For now, following your suggestion and I've put general conditions under Quest instead that adding GetIsId in every line, not for a matter of lazyness but because I'm really scared to mess something and I would prefer be very careful.

[Odessa]

But please tell me: if these weird events never happened to you after all your years of experience, while I had many in 4-5 months

 

Getting GECK weirdness and no errors definitely isn't just you, the PU isn't perfect.

Your '£' above is unicode. Terrifying.

You don't get an error for this either, but its broken (rogue ||)

 

if (GECK == ornery) || (BloodPressure > 200) ||

     set odessa to sad

endif

 

My personal favourite script issue was in a wear and tear effect, trying to track it down I eventually had this line:

 

MessageEx "x = %g" x

if x > 0

    MessageEx "now x = %g" x

endif

 

then when playing you sometimes got "x = 0", "now x = 0"  message (the 'if' misevaluated). If someone can explain that, I'd love to hear it.

[Guest]

A very nice example, Odessa, it really conforts me a lot. I'm going OT but it's nice to see weird things happening around me too. PS you can see many mistakes in that script, I exaggerated just to show some different mistakes, it will compile in any way, even if you erase that £ or others of those mistakes and leave just one of those mistakes.

 

Another weird thing happened with a temporary follower: she had 7 package regulated by 7 values of a quest.var.

After changing 3 cells, the follower was getting stuck. Using my little debug tool (I don't know how to use messageex and printdebug) I found that the variable was getting the value of 5 when I was entering in the third cell. It wasn't possible at all, because that value was set ONLY by a ontriggerenter player in a completely different place. I solved adding a if player.GetInCell condition to that trigger! "when player enters in the trigger, If player is in the same cell where the trigger is, then set the variable to 5"... funny, uh? you could think "you placed another trigger and you duplicated it from that one, even if you used a new ID before it had a script attached and it came out with it even when you changed with the proper script" - no sorry, there were not absolutely other triggers there!

[Halstrom]

Worst thing is that crash I induced 2 days ago by script, somehow screwed something major in my game, I get a CTD still now if I try to save the game or enter a door even with no mods activated, I've reinstalled NVSE, etc with no joy, and I'm also getting a crash trying to save GECK scripts, so going to have to delete & reinstall NV from a backup by the looks

[Odessa]

Using my little debug tool (I don't know how to use messageex and printdebug)

 

Then you will really appreciate learning, I would have long given up modding without them.

 

ref rMyNPC

int iMyNumber

 

MessageEX "My npc is %n and my variable is %g" rMyNPC iMyNumber

 

message text shown in corner for 2 seconds

--

 

PrintC "My npc is %n and my variable is %g" rMyNPC iMyNumber

 

message always printed in console

--

 

DebugPrint "My npc is %n and my variable is %g" rMyNPC iMyNumber

 

message printed in console with debug enabled

--

 

In game, these will show; "My npc is VFSTheKingREF and my variable is 38"  (example)

 

%n = reference name, %g = any number (int, float..) printed in decimal. GECK wiki shows other options too.

------

 

To enable debugprint, use or type into ingame console:

 

SetDebugMode 1 iMyModIndex

 

For some reason you have to use the mod index is decimal form when using ingame console, not hex (eg: 31 not 1F)

 

-------

It is great idea to add these lines to your mod in some always running quest script, because you need to run them every time the mod is loaded- debugmode ON will not persist between game loads.

 

int iMyModIndex

int iDebugModeYes

 

if GetGameRestarted

    set iMyModIndex to GetModIndex "My-mod-file-name.esp"

    PrintC "My mod  version 1.01 / Dec 10 2013 is loaded: Main Quest is     %x2000ADD" iMyModIndex

    if iDebugModeYes == 1

        SetDebugMode 1 iMyModIndex

    endif

endif

 

----

%x2 means, print number as hex. This way you can tell what version of the mod is loaded, and the correct index for testing things via console. Also, this way whenever someone reports a bug, you can say 'what is printed in console on load?' Then you know what version and load order they are actually using, because what they think and report may be wrong. What FOMM says is inaccurate if an unticked plugin still loads because of dependency.