Working Dialog Example

[ChicK00o]

Just have added the files for a working example of Dialog System

[Seneral]

Can you also commit the actual canvas type and such? All the scripts of the dialogue example, you know;) Also, can you delete everything else in the branch, so in the end it's like a folder you drop into your existing project with the latest Node Editor so we don't have to care about keeping this branch updated with the others:)

[ChicK00o]

Yup That is easily possible, best then lets just delete this branch, and for now create a empty branch to push too?? or you want me to delete everything, push that commit then just push a folder with the relevant data??

[Seneral]

I actually don't know how to create an empty branch lol

[ChicK00o]

well you aren't the only one, best i will delete everything and commit just one folder, you again just squash merge this too :D

[Seneral]

Alright:)

[ChicK00o]

There that should do it

And i don't think you will ever be able to see all the file changes and make sense of them :D

[Seneral]

Ok cool! Just one questions, you committed canvases both in your first and your last commit, you sure they are not duplicate?

[ChicK00o]

This commit does not have the LastSession canvas. And there is only one Canvas the Dialog1 in the last commit, because in the removal commit, i deleted everything inclusive of the readme, so just wrote a short readme [explaining the default functionality and how to look up the example folder in basic terms from a programmer's perspective] for the project before committing

So yup no Duplicate Canvases there :)

[Seneral]

Cool! I'll try it out after merging!

[Seneral]

There are four errors with the NodeGUI function header of all four nodes, it must be protected override void NodeGUI() instead of protected internal override void NodeGUI(). Hope you can add it in here:) Thanks!

[Seneral]

Other than that it's looking really good. Noticed changing the value in dialogue 3 doesn't affect the output, always 1, but still a great resource to start from.

[ChicK00o]

Well the develop branch i pulled in has "protected internal abstract void NodeGUI()" in the Node.cs, so when derived and implemented, Resharper creates a protected internal override , and changing it to just protected override should result in error, saying change of access level not allowed kind of things

For dialog 3 do you mean the dropdown in the canvas??, there the random option works, you could just set to random, then load the 3 dialog in play mode by setting dialog id to 3 and pressing "L" to load the dialog, try it multiple times and it will show various path randomly

other 2 enum don't do anything for now, the "trying this too" enum is currently mapped to a value in the dialog blackboard, which can be changed by pressing "A" in playmode, and as per the value being changed, the path will be different, so that's how it works.

If i assumed your question wrongly and have given a unrelated answer, let me know, and explain me further by what you mean dialog 3 and always 1

[ChicK00o]

The drop down is not a value but an enum that represent the key in the dictionary for the value we will lookup to see which path to take at runtime

The value changed for this to work is publicly displayed on the Testobject inspector, i could have created a label, but it seems i was just too lazy sorry :) I just kept my debugs, and made any presentable debugging in canvas the multi path display the values that needs to be present for it to take different path. Idea being, say there are 5 path, so path selection will depend on value being supplied between 0-0.2, 0.2-0.4, 0.4-0.6, 0.6-0.8, 0.8-1, always between 0 and 1

[ChicK00o]

@Seneral just tagging you here in case you did not get the notification of the above messages

[Seneral]

I did but as I said I didn't received them because I shut down my PC and don't have a working phone:/

So, it did throw errors for me without the change I noted above - even when reshaper says so, it is actually wrong. Because whats going on is that the derived function with 'Internal' tries to claim the internal for it's own namespace, so 'Internal' on an overriding function would work if it was in the same namespace. But in this case it is in a different namespace, so internal does have a different meaning here. In Node.cs it means it's accessible from within NodeEditorFramework, in your nodes it means it's accessible from within the default namespace. So it throws an error because it's not allowed to change accessibility of the function when overriding. I hope that's right and you understand. So I can't believe you don't get errors?

Anyway, seems I did not fully understand the example then;) I'll take a closer look when I have time. Because basically I changed the value in the component and not using the keys;)

[ChicK00o]

Hmm, if i remember right, "internal" accessor works on the Assembly level, i wasn't aware of the namespace behaviour as you explained. Could it be, that your main framework files are inside "Plugins" folder, for when i tested the working of the project, my main framework was general project, and part of the same assembly as the addon example. Yeah have a look at the example when you get time, and let me know if it doesn't work as explained

[Seneral]

Yeah then I mixed something up... Anyway I put it alongside the Plugins folder and it threw the error. If it works when inside the Plugins folder, does it throw an error when we make the change noted above inside the Plugins folder?

[ChicK00o]

yup just tested, if i put framework in plugins and my example folder is outside, i got the errors you explained, so it has to be protected internal override when in same assembly, or only protected overrride when in different assembly

this will happen one solution is to remove the "internal" keyword altogether, and this error will not happen. i.e. make the node.cs function just protected

[Seneral]

This will not work, internal is needed so that other parts of the framework can call this method. If it must go, you need to make it fully public.

[ChicK00o]

well if other parts of the framework had access as protected internal then they will easily have access as only protected, as protected is more lax than protected internal or am i seriously missing my something?

[Seneral]

Well protected means only subclasses, internal means the whole assembly it's in and protected internal means both subclasses (doesn't matter which assembly) AND the own assembly. So it's actually less restrictive, it's a bit deceiving...

[ChicK00o]

yes it's very deceiving.... you are right, then the next applicable accessor is public