Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - bac9

Pages: 1 2 [3]
31
NGUI 3 Support / Adding new line support to the localization script
« on: March 04, 2014, 04:16:51 AM »
It's probably relatively simple to implement, but I'm not sure how to. I have hundreds of long multi-line strings in my project, and putting localization files together was a bit of a pain with the way language file syntax works at the moment. As an example, I'd like to do away with this:

  1. L1.Scene1.Window1.Label1, "Lorem ipsum dolor sit amet, consectetur adipiscing elit. \n\nDonec faucibus nisl a orci pulvinar laoreet. Pellentesque eu condimentum dui. Nunc quis justo tortor. Fusce quis massa ut enim pellentesque semper vitae eget elit. Phasellus ut turpis egestas augue tempor laoreet.\n\nPraesent suscipit commodo ligula eu dignissim. Morbi at arcu eu quam ornare vehicula. Duis mollis sem in lorem fringilla, porta lobortis justo suscipit. Vivamus venenatis ullamcorper diam quis mattis.\n\nAliquam ante dolor, ultrices et vestibulum vel, dignissim ut magna. Donec tempus lacus at sapien fermentum fermentum. Morbi convallis eleifend arcu, vel imperdiet libero varius aliquet. Aenean justo metus, dignissim nec nisl vitae, lobortis vulputate sapien. Donec quis tortor sit amet tortor pulvinar lacinia. Vivamus interdum massa ut venenatis facilisis. Morbi lacinia fermentum ipsum, at ornare massa posuere ac. Duis tempus mi nec leo semper vulputate. In fermentum ac lacus vel interdum. Pellentesque et hendrerit nulla. Sed tristique dignissim hendrerit. Praesent id rhoncus nibh. Nunc nec egestas nisi. Morbi et tincidunt magna. Nam ut velit nec ligula feugiat ultrices.\n\nPraesent lacinia vestibulum nulla vitae mollis. Aenean dolor lectus, porttitor quis rutrum eu, scelerisque non augue. Donec in nunc eros. Morbi adipiscing vitae felis condimentum pellentesque."

And use something like this in my files:

  1. L1.Scene1.Window1.Label1 =
  2. "Lorem ipsum dolor sit amet, consectetur adipiscing elit.
  3.  
  4. Donec faucibus nisl a orci pulvinar laoreet. Pellentesque eu condimentum dui. Nunc quis justo tortor. Fusce quis massa ut enim pellentesque semper vitae eget elit. Phasellus ut turpis egestas augue tempor laoreet.
  5.  
  6. Praesent suscipit commodo ligula eu dignissim. Morbi at arcu eu quam ornare vehicula. Duis mollis sem in lorem fringilla, porta lobortis justo suscipit. Vivamus venenatis ullamcorper diam quis mattis.
  7.  
  8. Aliquam ante dolor, ultrices et vestibulum vel, dignissim ut magna. Donec tempus lacus at sapien fermentum fermentum. Morbi convallis eleifend arcu, vel imperdiet libero varius aliquet. Aenean justo metus, dignissim nec nisl vitae, lobortis vulputate sapien. Donec quis tortor sit amet tortor pulvinar lacinia. Vivamus interdum massa ut venenatis facilisis. Morbi lacinia fermentum ipsum, at ornare massa posuere ac. Duis tempus mi nec leo semper vulputate. In fermentum ac lacus vel interdum. Pellentesque et hendrerit nulla. Sed tristique dignissim hendrerit. Praesent id rhoncus nibh. Nunc nec egestas nisi. Morbi et tincidunt magna. Nam ut velit nec ligula feugiat ultrices.
  9.  
  10. Praesent lacinia vestibulum nulla vitae mollis. Aenean dolor lectus, porttitor quis rutrum eu, scelerisque non augue. Donec in nunc eros. Morbi adipiscing vitae felis condimentum pellentesque."

At the moment the parser expects every single new line to begin with a key name, which renders this impossible. Obviously it would be nicer to somehow change that so that it will e.g. recognize only the contents of the lines starting without " and ending with = as valid key names, and all the rest inside the following "..." blocks as assigned values. Particular syntax doesn't matter, though, I'll be more than happy with something like that too:

  1. <key name="KeyName1">
  2. <value>TextLine1InEnglish
  3. TextLine2InEnglish
  4.  
  5. TextLine3InEnglish
  6. TextLine4InEnglish</value>
  7. <value>TextLine1InGerman
  8. TextLine2InGerman
  9.  
  10. TextLine3InGerman
  11. TextLine4InGerman</value>
  12. </key>

Or with any other setup that makes sense and allows you to use new lines freely. How should I go about modifying Localization.cs and ByteReader.cs to achieve that?
Most likely I need to change how ReadCSV() in the ByteReader works.

32
Hi! I've encountered a bit complicated task and would like your opinion on how should I best approach implementing it.



I'm making an measurement screen where you can drag and drop several elements around while a sprite under them gets resized as sort of a bounding box, with two side clones following it's width and height and displaying the size of said sprite. Think of it as a room. You drag the furniture around, trying to arrange it into the most optimized square possible.

I'm a bit stalled on figuring out how to handle the resizing of that sprite best. What I'll attempt to do right now is:

1. Set all objects and a room to the bottom left origin mode to simplify the work (so that stuff like pos.x - width/2 won't be necessary);
2. To determine the X position of a room, loop through all objects and find one with the smallest X position, use it.
3. To determine the Y position of a room, loop through all objects and find one with the smallest Y position, use it.
4. To determine the X size of a room, loop through all objects and find one with the biggest sum of the X position and width, use it.
4. To determine the Y size of a room, loop through all object and find one with the biggest sum of the Y position and height, use it.
5. Force those new values into the NGUI sprite of a room.
6. Resize the X/Y "shadows" of a room accordingly.
7. Update the labels from the room sprite size values.

Is that a good way of achieving the functionality, or there is a faster or easier one? For instance, I'm not very familiar with NGUI table functionality, only ever using them for simple horizonal and vertical scrolling lists. Is it possible to repurpose the table for something like that, seeing that it already has some of the similar functionality (checking children positions/size, resizing itself, etc)?

33
NGUI 3 Support / Allowing the Notify feature to send arguments?
« on: November 27, 2013, 07:47:35 AM »
Notify function is available with almost every single NGUI element and is immensely useful. Still, there is something that will make it much more versatile.

Right now, as far as I understand, Notify window populates the Method list strictly with public voids that contain no arguments whatsoever. Adding an argument stops the void method from appearing in the list. It would be nice if methods requiring arguments will be listed too, as they allow to simplify the code surrounding some stuff immensely.

For example, I have a complex encyclopedia style app with multiple screens containing various interfaces and 3d models on them, with animated transitions between those screens. As of right now, I have to make a transition manager script containing methods like:

  • public void L1_To_L2 ()
  • public void L1_To_L2_Reverse ()
  • public void L2_To_L3 ()
  • public void L2_To_L3_Reverse ()
  • public void L3_To_L41 ()
  • public void L3_To_L41_Reverse ()
  • public void L3_To_L42 ()
  • public void L3_To_L42_Reverse ()
  • public void L3_To_L43 ()
  • public void L3_To_L43_Reverse ()
  • public void L3_To_L44 ()
  • public void L3_To_L44_Reverse ()
  • public void L41_To_L43 ()
  • and so on

Each of them looking like this (or containing something additional like animation playback if I don't want to use Play Animation components on buttons):

  1.         public void L43_To_L53A1 () {
  2.                 L43Equipment.gameObject.SetActive (false);
  3.                 L53A1Generator.gameObject.SetActive (true);
  4.         }

One of those methods is then added into the Notify slot of a button triggering the appropriate transition (e.g. "Back" button on screen L3 runs the L2_To_L3_Reverse method). Of course, each GameObject variable has to be manually populated by the user in the scene manager component too.

As you can imagine, it's not exactly the most pleasant setup to work with. It's manageable if, like in my case, screen count is under a dozen or two, but it quickly becomes inconvenient. So, I've been looking to replace it with something more efficient. Like this:

  1. public void LA_To_LB (GameObject LevelA, GameObject LevelB) {
  2.                 StartCoroutine(LA_To_LB_IE(LevelA, LevelB)); }
  3.  
  4. IEnumerator LA_To_LB_IE(GameObject LevelA, GameObject LevelB){
  5.                         LevelB.gameObject.SetActive (true);
  6.                         LevelA.gameObject.animation.Play (exitAnimationName);
  7.                         LevelB.gameObject.animation.Play (entryAnimationName);
  8.                         yield return new WaitForSeconds(LevelA.gameObject.animation[exitAnimationName].length);
  9.                         LevelA.gameObject.SetActive (false);
  10.                 }

Then, a Notify list on a "Next Screen" button will show the LA_To_LB method, and upon selecting it, you'll see additional fields created in the Inspector window under the method name: them being two GameObject slots where current screen and target screen will be inserted into.

Or maybe (a man can dream, right?), even listing public IEnumerators in the Notify list, with the Notify method starting the coroutine by itself if one of them is selected.

So, how can that become a reality? Can the argument support be added by myself (if so, which scripts have to be modified and how?) or, perhaps, is it planned for future releases of NGUI?

34
NGUI 3 Support / Few questions about NGUI localization methods
« on: November 25, 2013, 01:19:25 AM »
1. How should I go about rewriting the script to support multiple paragraphs per string properly? Having to use \n every time makes editing of stuff like huge encyclopedia entries quite a pain.

I understand why it's currently not supported: so that first word of the paragraph won't be interpreted as a name of a new string, so apart from adding the recognition of line endings to the script, I'd like to ask how to add safer syntax to the text files - for example, replacing this:

  1. string1 = text1
  2. string2 = text2part1\ntext2part2\ntext2part3

With this:

  1. string1 = "text1";
  2. string2 = "text2part1
  3. text2part2
  4. text2part3";

That, or replacing whole .txt reading with .xml reading where string name would be a name of a certain tag.

2. Is whole range of UTF-8 symbols properly supported (given that the font used in the game to display the game supports it)?

3. Can someone point me to the documentation that covers how can you leave certain assets accessible for editing in a build? I realize it's more of a question for Unity documentation, but I was unable to find anything in Google so I'm probably formulating the question wrong. Essentially: how can you force Unity to leave the .txt files out in the open?

35
Hi.

I'm working on a project that will be shipped on touch-enabled Windows 7 PCs with some weird touch screen implementation, which is a problem for standard Unity input methods. Internally it works like a mouse, but I can't figure out how mouse drag is implemented there, which is a problem for some of my scripts. While Input.GetMouseButtonDown(0) works, Input.GetAxis("Mouse X") receives no value changes ever on that PC, for some reason. Here is an example of small script that rotates the models in front of a secondary 3D camera in my UI for as long as you press a mouse button and move your mouse horizontally. Ideally, it should also translate to "hold your finger on the screen and swipe":

  1. public float horizontalSpeed = 1.0f;
  2. public float drag = 0.95f;
  3. Vector3 v3Rotation = Vector3.zero;
  4.  
  5. void Update () {
  6.         if (Input.GetMouseButton(0)) {
  7.                 v3Rotation.y += horizontalSpeed * Input.GetAxis("Mouse X");
  8.         }
  9.         v3Rotation *= drag;
  10.         transform.Rotate (v3Rotation);
  11. }

Good thing is, I have noticed that all NGUI elements are still performing flawlessly on that PC even without a mouse, probably owing to using some custom methods that continue to work no matter if Unity writes down some stuff or not. In particular, scroll bars were still functional.

So, the question is: can I get a value similar to Input.GetAxis ("Mouse X") from NGUI scripts, or can I rewrite the code above in a way that will use NGUI drag detection? I have tried testing OnDrag () but it wasn't firing for some reason (maybe it's for objects that are being dragged and not something that gets called every time drag is done anywhere), so I would appreciate a proper example of using NGUI methods. I don't need anything fancy like collision detection, it's literally the "swipe anywhere on screen, rotate anything on screen" kind of deal.

36
NGUI 3 Support / Targeting a fixed resolution and disabling any scaling
« on: November 15, 2013, 12:12:19 AM »
Hi there!

First of all, thanks a lot for the gorgeous product, this is the first UI system on my memory that is such a breeze to work with. I've had a rather simple question about NGUI, though.

Right now I'm working on a project that will be targeting a very, very limited set of hardware, with absolutely predetermined display resolution (1920x1080). So I was curious if there is a way to completely disable of any and all NGUI elements in the Editor window, as it makes it pretty hard to preview how UI will look, especially when I'm working on a 1680x1050 monitor. I understand that in that case I won't get pixel perfect rendering in the editor window, and I realize that I will need to frequently use zoom in the scene view, but nevertheless, for this particular project I need the size of the screen to be completely set in stone, and elements constantly jumping around to fit to the changing editor viewports are complicating the work a bit.

I know there is a feature in UIRoot allowing me to lock the height of the screen, but as far as I understand, it won't guarantee a final and stable representation of UI as the window layout and proportions get shifted around.

[EDIT] Oh wait, I think that can be disregarded: I forgot about Game viewport aspect ratio lock, which, coupled with the height locking in UIRoot, forces the UI assume a proper width and thus shows it in the same way as in the final build. Nice.

Pages: 1 2 [3]