Making OGConsole work with opengui about opengui HOT 40 CLOSED

I wrote a console backend for our game as well, but I never thought of making one as part of OpenGUI. I can imagine that perhaps it would contain an array of OGConsole.Command (a private class for OGConsole with a "consoleString" and "eventMessage" variable) that it would listen for in the Update loop. Then when it came across a matching Command.consoleString, it would send the Command.eventMessage to an assigned event handler. That's the most generalised application I can think of right now, although it would require some more work to make it support multiple arguments.

Did you start writing this OGConsole yet, or was it just an idea?

from opengui.

A bit of misunderstanding has happened. My bad. I should probably been more precise. GConsole is an already existing console implementation which uses NGUI as default but with a fairly simple connection between the two.
It basically uses an input and an output ui fields aswell as some optional fields for suggestions (as in type 'he' in the input and suggestions will include 'help'). What i am doing is rewriting the GConsole's NGUI interactive classes which it relies on to detect stuff like changes in the inputfield.

Link to the forumpost of OGConsole
http://forum.unity3d.com/threads/free-open-source-gconsole-developer-console-for-unity.227510/

from opengui.

Ooh, neat! An OpenGUI implementation would be cool, I'd want to use that. We could implement a "changed" flag to every OGWidget, but until that can be done, maybe just check that in the Update loop.

from opengui.

In OGTextField you use the Unity GUI class so I thought I might be able to get its changed flag to detect any changes on the input.
http://docs.unity3d.com/ScriptReference/GUI-changed.html

I made an OGTextList for the output. IT's just an ugly OGLabel with..
//////////////////
// Add
//////////////////
function Add(newLine : String) {
text += "\n"+newLine;
}
added. But it works for the output. Now if only the colourcoding worked ;)
"Type [33EE33]help list..." Locks like NGUI accept it but I don't know if it's a standard for any markup.

from opengui.

Hmm, maybe this implementation should use the DrawText helper method directly. I wonder how the NGUI imlpementation does it, because as far as I know, NGUI doesn't support colour coding either.

from opengui.

Well that part is beyond me tbh. The font drawing and placing I just glanced at and figured it is better left to more capable people then me. :P

from opengui.

In OGTextFiled you have an boolean called stealReturnKey. It doesn't seem to do anything. Was the plan to have return trigger an submit event perhaps?
Seems to me what is missing to get the console working fully is events like OnInput, OnSubmit and OnChange from the inputfield. Is there any way to get around this for now?
Within the OGTextField the GUI.changed never trigger so I tried..
if( text != oldtext ) { changed = true; } (inside OnGUI() )
text being the OGTextField.text. But that doesn't work either so just how do OpenGUI grab input to text and so on.

from opengui.

stealReturnKey is an inherited property from the OnGUI TextField, but it isn't fully implemented yet. The only way to check for changes is in the Update loop, that's how they do GUI.changed too. Something like this:

private var prevString;

public function Update () {
if ( prevString != text ) {
 DoSomething ();
}

prevString = text;

}

from opengui.

I tried to stay away from making anything within Update() but at least it works now. Also the colourcoding is turned of so no more obnoxious [AABBFF].

But now I've gone and messed up the OpenGUI bit again. I tried putting all the UI bits under a OGWidget but since it turned everything under it to scale from it parent widget instead of pixels it turned bad. Problem is after i removed the OGWidget and reset all the values the ones that was effected before is still using scale against the (now deleted) 400px_400px widget.
So the OGTextField I use for output is scale 1.1 and ends up 400x400 on the old position. Even using stretching just doesnt work anymore. Position is still from the old widget and then the scale even on stretch screen width is ending up in 400px_ScaleValue.

Don't know if it's something I'm missing. Very likely is. Or if it is something broke with the new Unity version.

Optimaly I figure I want all the consolefields under a widget to control the height and width but then in pixelheight chop up that 7 fields by pixelheight. 5 suggestionfields + Input being same height on bottom with rest of space above being the outputarea.
That way the fields would stay consistent in height while you could resize the parent widget.

Feels like I missed something obvious though...

from opengui.

I'm not quite sure what the problem is, but I have 3 guesses:

If you want to just fix the transform values, you can make a new GameObject with x: 400, y: 400, set that as the parent to the messed up widgets, unparent it again and they should be restored to their former appearance.

If it's that you are getting unexpected widget sizes, it could be that the culprit is a transform further up the hierarchy.

If you are using the background (i.e. an OGSlicedSprite) as parent, that's wrong. It should be a child object too.

from opengui.

Yeah seems I just messed up again. It is kinda hard keeping track of where all the UI gets its input from it seems. :P
The parent object with all the console UI still had the size and position in its transform.

from opengui.

Yeah, that's always a bit hard to wrap one's head around when doing UI, I think. The best you can do is label everything sensibly.

from opengui.

What was it that determined z-order? As in what ui elements will be ontop and such?
Buttons(suggestionfields) that I clip to the console OGWidget gets dropped from view.

from opengui.

Only the transform's z position should do that. If the widgets are being clipped, and they are not children of a scrollview, make sure they don't have a "clipTo" widget linked.

-- edit --
Or if you actually want them clipped, try just making sure the z position of these widgets is below 0. That way they will always be on top. However, if they go below world 0, they are dropped, as that is the nearest clipping plane. You can just make sure that the parent object is z: 20 or something like that.

from opengui.

As soon as I connect things with the ClipTo it gets messed up.
I got one object that has the OgWidget in it. Under that is all seven UI objects, 5 buttons, 1 OGTextField and one OGTextFieldActive(slightly modified to trigger on updates).
The only thing visable is the text when they are bound to the OGWidget with ClipTo. If I drag and drop the OGWidget component so the connection breaks all the rest gets drawn.
But I really need them to stick together so I want to make use of the widget function but when I break the connection only the TextFields (input/output) moves when I change the OGWidget position.
Should they even be moving with the widget? I mean the clipTo is missing or none and they still move with the parents OGWidget while the 5 suggestionbuttons does not.

Upper:All connected to the Parent OGWidget
Lower:after breaking the ClipTo connection

from opengui.

Aaah. Well, then just make the clipTo object a child as well. It doesn't have to be the parent. Let me be clear about the clipTo variable just in case: It doesn't affect the position of any object, it's just an overflow controller like a "< div >" in HTML, which means that if widget B is clipped to widget A, only the parts of widget B that are inside of widget A's drawing rectangle will be shown.

The drawing rectangle is determined by the transform dimensions, except in OGScrollView which is always x: 1, y: 1, z: 1

from opengui.

OK. Now it all makes sense.
So ClipTo doesn't actually Clip onto anything. It is more like a viewport that can show other layers of the UI. A

from opengui.

Yeah, the < div > example wasn't that great, I just had to give the word "overflow" some sort of context :) The analogy might still work if we assume the children had absolute position. Nah, it's just not the same.

Whenever I want to have a group of widgets, I just make them children of a GameObject and move that around. You can attach the base OGWidget class to that parent if you want the anchoring features.

from opengui.

So now there is just one thing to solve really. How to make a correctly positioned scrollable output text that snaps to bottom when it is updated.
ScrollView doesn't follow the pivot rules (Broken? bug?) and it needs to hold a dynamically resizing text container of some sort while also itself resizing accordingly.
Is there anything right now that can help or is it a matter of making two new OGWidgets? If so, is there even anything in OpenGUI that tells when text overflows so you can trigger an expansion of the container?

from opengui.

Hey, awesome work so far! If you ever have questions on GConsole or how something was done, just shoot.

I think the next sensible step for me would be to split up the repository of GConsole into GConsole and GConsoleNGUI. So that using GConsole with NGUI or OpenGUI becomes a matter of drag n dropping GConsole and then the front-end of choice, instead of having to remove folders that belong to the wrong UI system.

EDIT: Done, GConsole is now split.

from opengui.

@MuNgLo: I will have a look at the OGScrollView pivot issue. I think if we want automatically expanding textfields, we need to add a new "overflow" variable. I'll get on that too.

from opengui.

@Rahazan: Great, that sounds convenient! If the frontend integration scripts are just one file each, you could even just have them in the wiki of your main repo.

And thanks for sharing your awesome work with us, GConsole is a really cool asset. We should make sure to make a big deal out of it when this integration script is done too, to promote GConsole in our corner of the forums.

from opengui.

Sounds awesome guys.

from opengui.

I've committed a new release with a dynamically fitting OGTextField update in it.

2 things worth noting:

This new feature does not work perfectly yet, as it brings to light some old problems with the OnGUI solution for OGTextField, which means we may have to write our own text editor in the end anyway.

The OGScrollView cannot work with pivot just yet, as it does not work entirely like all other widgets. I will add it to the tracker, but in the meantime, just use a container like so (assuming the OGScrollView is 400px wide):

• Anchor: OGWidget ( pivot = center, pivot offset = -200px )
  • Content: OGScrollView ( size.x = 400px )

from opengui.

Update:
The feature works better now in the latest release with some modifications to the OGFont class.

Take a look at the example project or the web demo for a demonstration. It's basically just a manual workaround. Note that you have to update your font file as well when updating this time.

from opengui.

Will look into it. Been bashing my head against Unity.Network lately so might need a distraction. 😃

from opengui.

For me it seems the textfield just extends when using FitToText but only horizontally. Also FitToText forces a remove of newlines. Making all output single line if the field is active and you focus it.
Does it only extend on X or am I missing something?
Also it extends insanely much. After a few console outputs it is a couple of thousands at least.

Maybe make a separate OGTextOutput and keep all the input options out of it. Optimally it should only dynamically resize on Y and have text wrap if it extends beyond the width. All the console output needs is a textarea to insert new textlines into.
Sure it would be nice to be able to mark and copy text but it really isn't needed.

As long as it extends on Y it is easy to grab the height and offset the scrollview accordingly.

from opengui.

I thought that was what you meant. Why would you use an OGTextField for a console output and not an OGLabel, though? A textfield without input is a label :D You can stretch it to fill the amount of the screen that you want.

from opengui.

can you copy/paste from a label?

Yeah I don't actually remember why I ended up with a OGTextfield. But a console can over a couple of hours be many thousands of lines so just stretching a label to whatever size will not do. Also the scrollview needs to be able to "snap" to last line.
Sure you would have to limit the console to some amount of lines.

You could limit a label with X height and then snap the scrollview to that but then you would need to reverse the way it draws the text starting in lower left instead of upper right corner of the OGLabel.
As it is now I made a OGLabel Variant (OGConsoleFeed) with a fixed height and adding the new lines to the start of text string.
It's just backwards from almost all other consoles. :/ Feels so wrong even though I can place console input on top and output under it. I will make it work this way though so I can get rid of all the NGUI stuff. Having some conflicting captureing of cursor and I worry how much it might mess things up.

--EDIT--
So now it works but layout is basically reversed to normal and the label with console output is just 1200 heigh. Only the suggestionbuttons left. But Now I completely dropped NGUI so I don't have to be afraid of any weird stuff.

from opengui.

What's up with the keyinputs when textfield is in focus?
I want enter to submit and esc to close the console but there's problems getting it to work. First of the workaround of checking for enter inside the OnGUI works as long as the flag doesn't get reset to false there to since it seems that when running it in standalone the OnGUI can be triggered more then once per FPS. That took me a while but as it is now I end up getting the console stuck since I don't release the mousepointer just because console is up. Even though I setup escape the same way as enter it doesn't trigger as long as the textfield is in focus.
What would be the proper way to get the keyevents when the textfield is in focus?

var e : Event = Event.current;
if (e.type == EventType.KeyDown && e.keyCode == KeyCode.Return && GUI.GetNameOfFocusedControl() == "ActiveTextField") {
        submit = true;
    }
if (e.type == EventType.KeyDown && e.keyCode == KeyCode.Escape && GUI.GetNameOfFocusedControl() == "ActiveTextField") {
        close = true;
    }

Within the textfield OnGUI() is what I use and then I reset the flag after I've done the action.

from opengui.

I'm not 100% sure why this is directly related to the textfield class, but it sounds to me like you need to set the "listening" flag as well when you want to remove focus. Let me know if that's what you meant.

from opengui.

I'll have a go at it again. Just got frustrated cause of the work-in-editor-but-not-in-standalone bit. Thought there might be some good tips to be had. Figure it's something that comes from the OnGUI Textfield class. Something about how it handles input when it is in focus. Anyway I will get around to it again.

from opengui.

Yeah, it's a pain stealing the OnGUI behaviour of the TextEditor class, as it is undocumented, but I bet it would be even more of a pain to write an editor from scratch. And if we did, I'm not sure we could even access the system clipboard, which is a feature I use quite a lot myself. I'll have another go at it soon, see if I can solve some of this confusion.

from opengui.

Looking into it now again and figured I'd start with seeing if I can trigger a loss of focus at least. That would make the consoletoggle bind work atleast.

from opengui.

I've begun work on an OGTextEditor class that gets passed through the OGDrawHelper, but as I expected, it's a big mouthful. I'm halfway there, though, and when it's more or less done, we can do anything we want. There's currently support for inserting, deleting, navigating, selecting and setting a default unfocus action along with an unfocus key. It's in the uncompiled git repo in the example project, you just have to enable the editor in OGTextField to test it.

from opengui.

That sounds awesome.
I have it working now so I'll add the modified textfield class file I made to the project. I figure it is better to leave it here in OpenGUI since it is in unityscritp and is dependant on being placed in the script folder so adding it to GConsole makes no sense.

I have no idea what kinda stupid thing I was doing last time to not get it working but I blame lack of coffee and sleep. :D This time around I went step by step and made sure I didn't fall into the pit of relying on OnGUI() in the standalone to reset the close/submit flags. So Escape button now works as close even when the inputfield is in focus. So at least now it is usable as you don't get stuck on it unless you have the mousecursor to change the focus.

Oh and You could probably clean out a bit of the code in the class but I left all in there for the upload. I am not really pleased with the code. Feels unclean jumping from OnGUI() to get flags for closing/submitting.

from opengui.

Oh I don't know the inner workings of the texthandling but if it means we'll be able to colourcode text I bet lots of people would be interested. It really makes a big difference.

from opengui.

So this was the solution. Since Rahazan split the NGUI frontend to a seperate repository I ended up making one for the OpenGUI frontend.
https://github.com/MuNgLo/GConsoleOGUI
First time I set a repository up so I hope I got it all right.

from opengui.

Cool! Do we consider this issue closed, or is there more to it?

from opengui.

Well it works so this issue can be closed. Whenever you push a big change in in texthandling I will look into making it better.
I really don't like the way it is functioning now since it is more or less a polaropposite to any usual console in how the layout is. But it works. 😄

--edit--
I just found the close and comment button 👅

from opengui.