Magistross's Recent Forum Activity

  • "Wait" action and function parameters don't mix that well as you figured, and local variables don't do better for that matter. And that's a shame, because it would allow us to do some kind of "closure" where variables have their own scope. However, the SOL is saved even after a wait action. Knowing this you can create a temporary object that will be used to store all variables for the duration of all functions.

    Here's a quick exemple : https://dl.dropboxusercontent.com/u/700 ... osure.capx

  • It depends a lot on the scope of your system. Will it be used generically for a variable amount of entities or will it be more static ? If it's static, go ahead with arrays and vars. Otherwise, it'll be easier to propagate the arguments function to function.

  • Deferring function calls isn't really done that way. You would probably be better off using callback functions than return values. By the time line 4 of your second screenshot gets evaluated, the function isn't over, and it won't wait to evaluate, so "ReturnValue" will evaluate to "" (or the last returned value). Instead of line < Set return value to "Return" > in your last screenshot, call another function, like "eAni_DummyAttackFinished". This particular function will signal that the animation is done, and you can continue with the rest of your logic.

  • — I did an example a while back that iterated through a list of nodes to build said list but on the UI. Might not be exactly what you wanted, but whenever you need to iterate through all nodes, this is the way to go. Note that in a "for each node", subsequent XPath calls are relative to the current path.

    https://dl.dropboxusercontent.com/u/700 ... ample.capx

  • Pretty clever actually, the idea had crossed my mind but seeing it in action sure does help realizing how useful it would be. I'll be sure to add it in the next version!

    That said, that game of yours looks pretty good. If it plays as well as it looks, I'm sure it will be a hit!

  • In the end, it all comes to preference and how your XML is built. If you are manually creating the file, using numbers to identify nodes is a sure way to get lost in the long run! But say you are building your XML from a database, it would be completely normal and fine to have "auto_increment" IDs.

    That said, the question of whether or not you should be using indexes in your XPath depends on what you are doing. If you are iterating nodes, you can either use them or do a "for each node", but if you are reaching for a particular node, you should use its ID. Kyatric's example also had links between nodes, those should also be done with IDs, and not indexes.

  • Haha! Good going, nice to see you're getting the hang of my system.

    Don't forget to adjust the other variables if you need. DIALOGUE_PORTRAITWIDTH and DIALOGUE_LINEHEIGHT might need some tweaking. DIALOGUE_HEIGHT - DIALOGUE_MARGIN * 2 should be a multiple of DIALOGUE_LINEHEIGHT, this way the space available will be optimally used. Might also consider tweaking DIALOGUE_ARROWSIZE too if you plan on having dialogues with lots of "choices" ({choice} command with many different inputs), you'd need smaller sprites too for DownArray and UpArrow. The ContinueIndicator could also use a new, smaller sprite, and if you want to change its position, look at events 27 and 30, where it is created.

    Glad I could help!

  • I'd go with something like this :

    root

    -npcs

    --npc id="tom"

    ---scene

    ----message hello there /message

    ----message can i help you /message

    ---/scene

    ---scene

    ----message welcome back /message

    ---/scene

    --/npc

    --npc id="john"

    ---scene

    ----message

    ...

    Grouping all npc under "npcs" would allow you to do a for each node /root/npcs/npc, load stuff inside objects and be done with XML parsing.

    Also, IDs aren't indexes, we aren't numbering stuff, we're giving names per say. I don't see how it would force us to change the previous ones as we insert new data.

  • A unique ID provides a way to associate a particular XML node to a particular Construct object. Yes you could assiociate an index, but indexes are volatile, they change as soon as you insert new data (unless you always append). IDs will stay the same until you change them, even if you insert new data right in the middle of your file.

    Suppose you are interacting with an npc, and you know its IDs, reading the right XML with XPath is as simple as /root/npcs/npc—, and this statement will always return the npc node with id = "myId", even if its index changes.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • — Attributes can be anything you want, I guess tutorials used "id" because it's short and is usually quite self-explanatory. The values could have been something else though, and maybe more verbose to include a bit of metadata (i.e <npc id="Guard1_Town1">...</npc>).

  • —

    The reason to use IDs is to uniquely identify each of the dialogue. So if you want a particular dialogue, you can retrieve it using its ID, whatever its index is in the parent node, and wherever it is in the document.

    You should always prioritize the use of attributes to distinguish nodes instead of using different tag names. The structure of your XML document will be much more robust and easier to navigate through.

  • Alright, this problem is most likely spritefont's height related. Since you are using a very low resolution, you needed to reduce the dialogue height in such a way that there is not enough space to display a single line of text, meaning the system will enter in a perpetual "text overflow" mode, continually prompting the user to continue the dialogue.

    I definitely did not think this would ever happen !

    What you need to do is adjust things a bit so you can better use the space inside the window. First, reduce the DIALOGUE_MARGIN variable to something much less than 16. This number represent the amount of pixels between the window border and the spritefont, normally equal to the 9-patch object's margins. So you could use a low number like 2 and alter the 9-patch sprite to have a single pixel border, and adjust its margin to 2 on all sides. Second, you should probably use a spritefont better suited for such a low resolution. The font I provided with the template is 16x16, which is quite big considering your window size.

Magistross's avatar

Magistross

Member since 4 Jul, 2011

Twitter
Magistross has 14 followers

Trophy Case

  • 13-Year Club
  • Entrepreneur Sold something in the asset store
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Regular Visitor Visited Construct.net 7 days in a row
  • RTFM Read the fabulous manual
  • Email Verified

Progress

20/44
How to earn trophies