Magistross's Forum Posts

  • — 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.

  • — 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.

  • Ok, I thought your image was a mock-up of the actual loading events. You need to do an AJAX call to get the project file and retrieve its content. First you use "request project file", select your file, and then add a "On completed" AJAX event where you do the actual dictionary loading. (i.e. Load from JSON string AJAX.LastData)

  • Hi bclikesyou, you are indeed calling dialogue the right way, assuming the dictionary is correctly loaded before the call.

    You also have to change the default position of the dialogue objects, by adjusting the following variables in the dialogue event sheet : DIALOGUE_POSITIONX, DIALOGUE_POSITIONY.

    Let me know if this helped you!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Also, if you actually have different array object types, put them all together in a family aptly named "Arrays". You could then use this family to easily access any array provided you have its UID.

  • After that, time to add Magistross 's dialogue plugin which I bought! Really excited to get that up and running as my current dialogue setup is pretty patchy.

    Nice! It's always thrilling to see a new creation that use a bit of your code. I'm eagerly awaiting further dev logs!

  • Are you trying to limit the object selection with the condition ? Compare two values isn't suited for that. Since two object types are in your condition, you will need to nest two "for each". Or maybe a single "for each CollisionBox1" with a pick by comparison under it.

  • System's "Compare two values" doesn't do any picking, thus all sprites get selected and destroyed as soon as the first tile reach the border. You can either add a "for each sprite" above your condition or ditch "Compare two values" in favor of sprite's "Compare X".