In Oblivion most dialog is only used for "Rumors" and "Give quests". You can do a lot more. Dialog trees, which are common in other RPGs like NWN 2 are also possible to create with the Construction Set, but there are some pitfalls. I'm going to give a short introduction about how to create more complex dialog in Oblivion.
1. Use the quest window!
The CS offers both the filtered dialog and the quest windows to create and edit dialog. Problem is that dialog itself is part of a quest (even hidden ones). Dialog not being part of a quest isn't played. Dialog of a non running quest isn't played. You can't really control this in the filtered dialog window, so use the quest window. It lists all topics associated with a quest. You can easily add new topics by just right clicking into the topic list and choose "Add". To create new topics, in the now opened list rightlick and choose "new".
2. Prefixes are of the utmost importance!
If you only add stuff like "Rumors", it doesn't matter that the dialog topics are ordered alphabetically. If you want to create something like a dialog tree though, this will become a major pain. Simply for finding topics I suggest to use an individual prefix (e.g. I'm using "bg" for obvious reasons), followed by the questid (makes it easier to assign topics to the right quest). And then I usually use something like a quest stage, and option numbering.
Quite obscure, so an example. Let's say I've got a "towngeneral" quest, and I want to have a conversation with someone about the weather. Then I would use something like
- [*:bc308d9d92]bgtgweather0start <- starting point[*:bc308d9d92]bgtgweather1favorite <- triggers that the NPC asks for the player's favorite weather[*:bc308d9d92]bgtgweather1favoriteASunny <- actual answers[*:bc308d9d92]bgtgweather1favoriteBRainy <- actual answers[*:bc308d9d92]bgtgweather1favoriteCSnowy <- actual answers[*:bc308d9d92]bgtgweather2plans <- triggers that the NPC asks for the player's plans
Sounds constructed, I know. Problem is, that the benefit is mostly visible when you've seen an actual example - and they can easily have fifty or more topics. That would be a bit much for a small text 
. If they're not ordered (which is only possible through using prefixes) you'll likely lose your mind. Keep in mind that the internal "names" of topics are not the topic name in game. Example given Rumors have the internal name INFOGENERAL.
This is one of the keys to complex dialog. If you want to include something like dialog trees, persuading NPCs or similar, the CS will not order the topics for you. That is something unfortunately you must do.
3. Beware of bugs!
There are two major bugs with Oblivion's dialog system you should be aware of. First of all, don't use the "AddTopic box" in existing topics. Only the last loaded mod can use them, which e.g. causes some of KotN's bugs. Instead use the Result Script box and write "AddTopic TopicID". Yes, takes more time, but it is necessary.
Second if you add new topics to a quest, make sure to not click on any topic which has any flag, result script, or choices. They will be deleted, then. I'd suggest simply adding a dummy topic without actual text, so you've got a place to click to. This is less of a concern as long as you've got enough space to click, but once the list is full, you need a dummy or safe topic.
I know, being aware of both bugs is annoying. My personal experience, as the unfortunate soul who discovered the second bug, is that this bug alone caused most (easily over 90%) of problems in my mod, and the few seconds it takes me now to work around it saves me hours of debugging later.
Before I forget, there's another oddity: If you duplicate a reply, the CS marks (until you restart) the wrong reply as new (which means the Vanilla one is looking like a newly created one, while the new one is looking like the Vanilla reply). This can create severe compatibility problems if you pick the wrong reply for further editing. So if you duplicate a topic, expand the "FormId" row to see which is actually new. If you pick and edit the Vanilla reply all kinds of weird stuff can happen (aside from compatibility problems also mismatched or missing dialog files).
4. Condition everything correctly!
Dialog usually has conditions. If you add a topic without conditions, every NPC will say it. That's usually not intended ;-). Also when it comes to quest stages, that's also important. Otherwise an NPC may tell the player something long after the actual event is over. Example given you've included a rumor regarding a danger in Bruma, forget to include a check if the quest isn't finished, then it may be played even if the quest is long since completed.
Remember that you can copy & paste dialog conditions by using right clicks. This is especially useful for making sure that only the intended NPC plays the response.
5. Use scripts to store variables!
Now here's a funny one. In Oblivion dialog can't directly store variables. Example given you're creating a multiple dialog tree for a quest in which you need to persuade someone. How to make it so that you don't need thousands of interconnections between the topics? The trick is, you can store and evaluate variables through use of a quest script. They are only there to store variables, they don't actually do anything. Example given a quest script for persuading someone can look like this:
scn bgMyPersuasionTrackScript
short successful
short fail
short conclusion
As you see, there's no actual code running. It's just several declared variables. But if this script is applied to a quest (e.g. bgMyPersuasion) you can do stuff like this with the result script:
- [*:bc308d9d92]set bgMyPersuasion.successful to bgMyPersuasion.successful + 1 <- whenever the player succeeds[*:bc308d9d92]set bgMyPersuasion.fail to bgMyPersuasion.fail + 1 <- whenever the player fails[*:bc308d9d92]if bgMyPersuasion.successful > bgMyPersuasion.failset bgMyPersuasion.conclusion to 1elseset bgMyPersuasion.conclusion to 2endif
Now the last one evaluates successes and failings. And this then can be used as a condition for later dialog checks (e.g. if it is set to 1 -> "you've convinced me!", if it is set to 2 "get lost!"). Normally you cannot store the outcome of a dialog for later, unless you create the same paths over and over again for every branch. This method is a lot more effective, easier, and less time consuming. With it you can create some very interesting dialog challenges.
Hope that helps,
bg
