Kyatric's Forum Posts

  • You do not have permission to view this post

  • : Thanks for the notification, I've modified the capx so that WP0 ID is 0 when downloaded now.

    I guess I was still messing in the file while writing my description and making permutations before providing the capx.

    Now the download should work as intended.

    , newt: I agree that a better picking order should be to have NPC as "main object", but I actually was asked the problem in this very way and couldn't come up with an actual explanation that made sense.

    The assumption that it "picks" the default waypoint instance by default is logical, but actually do not match the observations, otherwise, when having "pairs" and/or two NPCs targeting the same Waypoint, they all should end up targeting WP0, which is absolutely not the case.

    R0J0hound interesting "translation" into more verbose events.

    "Pick sprite2 instance loopindex%sprite2.count" would actually make a good explanation of what is going on with some of the actual results observed and why it makes it difficult to anticipate some of the results.

    Still a bit esoteric, but at the same time it feels close to the behavior observed.

    Thanks for your weighing in guys.

    This is more a "philosophical" issue here and again, I agree that the correct way to do correct picking is to have the NPCs comparing their instance variable (being cycled through by the implicit "For each") and have another explicit "For each Waypoint".

    I'm still waiting on Ashley to have some confirmation though and possibly a "clean" explanation as he knows how to provide them.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • : No idea. I guess the best placed to answer this would be Ashley or

    If they are willing/allowed/able to answer it though.

    Again, the service is provided as is to help facilitate "non-tech savy users" making multiplayer games.

    I would still recommend for a serious project that you handle your hosting yourself as it just is making sense.

  • Ashley

    Please consider this capx.

    The idea is that each NPC instance has a Target instance variable that allows to match with a destination Waypoint thanks to a "Compare instance variable value" condition.

    Each Waypoint has an ID instance variable that is used for the picking/determining the target of the NPC and is the instance variable compared in the condition.

    A single condition event is used.

    We know that C2 will implicitly loop through all the instances of the "main" object type referenced (in our code: "Waypoint") as if there was a "For each Waypoint" (implicit).

    We also know that to actually achieve what we are willing to do, having the condition "For each NPC" (explicit) will loop through all the instances of the NPC (and has to be placed before the comparison in order to work, otherwise the looping would happen only to the picked instances after the comparison).

    This condition is disabled for now though, in order to try it with a single event and determine a theory on how the picking is working and how the "second reference" object (NPC) is being picked.

    As the capx is set by default, our goal is still reached, each NPC is going toward the Waypoint it is supposed to (each NPC instance is reaching for a unique Waypoint instance).

    We could then assume that under the hood, C2 is still looping through the NPC instances to find a match for the condition.

    Now take NPC instance NPC 1 (currently of Target value 1), and modify its Target value to 2.

    Expected NPC 0 going to WP0; both NPC 1 and NPC 2 instances to go towards Waypoint WP 2; NP 3 going toward WP 3; NP 4 going toward WP 4.

    Happening : The NPC 1 goes towards Waypoint WP2 instance, NPC 2 instance goes towards Waypoint WP3 instance, NPC 3 goes towards WP4; NPC 4 goes towards WP0 (ID = 0)

    Theory : When a "second reference" (our NPC object type) instance is a match, the looping stops.

    For the reminding instances though, it seems the destination Waypoint is Destination + 1 (with the last instance going back to the "default"/first waypoint instance).

    (Might have to see with the IID stack)

    ---

    Now modify the NPC1 instance so that its Target is 0.

    "General expectation", would be both NPC0 and NPC1 going to the WP 0, NPC 2 going to the WP2, NPC3 going to WP3, NPC4 going to NPC4.

    Although, according to our previous theory, we could expect NPC0 going to WP0, NPC 1 going to WP1 (destination + 1), NPC 2 going to WP3, NPC3 going to WP4; NPC4 going to WP 0. (Theory expectation)

    Happening : Same result as previously.

    So a difference with our "Expected theory" is that NPC1 is not going to destination + 1.

    ---

    Let's try something else.

    NPC0 to Target0, NPC1 Target to 0, NPC2 target to 2, NPC 3 target to 4 and NPC4 Target to 4.

    We have two pairs of instances set to go to the same waypoint.

    "General expectation" would be NPC0 to WP0, NPC1 to WP0, NPC2 to WP2, NPC3 to WP4, NPC4 to WP4.

    "Theory expectation" would be NPC0 to WP0, NPC1 to WP1, NPC2 to WP3, NPC3 to WP4, NPC4 to WP0.

    Happening : NPC0 to WPO; NPC3 to WP0; NPC1 to WP2; NPC4 to WP2; NPC2 to WP4.

    From there I must admit I have no more theory to what's going on and how NPC instances destination's Waypoint instance is being picked in that case.

    ---

    Let's try even further

    Reset each NPC to have a single destination, in order as it was originally.

    NPC0 Target 0; NPC1 Target 1; NPC2 Target 2; NPC3 Target 3; NPC4 Target 4.

    Now let's change WP2's ID from 2 to 6.

    "General Expectation" : NPC 0 to WP0; NPC1 to WP1; NPC 2 to not move; NPC3 to WP3; NPC 4 to WP4

    "Theory Expectation" : NPC0 to WP0; NPC1 to WP1; NPC2 could go to WP 3; NPC3 to WP4; NPC4 to WP0

    Happening : The Theory expectation is happening. So our first observation/guess was not that bad.

    ---

    Modify NPC 1 Target to 6

    "General expectation" : NPC0 to WP0; NPC1 to WP2; NPC2 to not move; NPC3 to WP3; NPC4 to WP4

    "Theory expectation" : NPC0 to WP0; NPC1 to WP2; NPC2 could go to WP 3; NPC3 to WP4; NPC4 to WP0

    Happening : NPC0 to WP0; NCPC3 to WP0; NPC1 to WP3; NPC 4 to WP3; NPC2 to WP4

    I don't know what's happening.

    In all those permutations though, if you enable the "For each NPC" condition, the "General expectation" scenario is happening, as expected, and as we know it should/has been the solution for these kind of picking for years.

    Nonetheless, what is the actual picking scenario that is going on inside C2 when only a single condition is applied and that would explain all those observations ?

    My original assumption was that only the first instance of the object type was picked.

    Nonetheless, on trial, it seems it wasn't the case in a specific set of use.

    And through those observations, I must admit I don't have a working theory that would allow for a valid expectation when only using the single condition in whatever setup.

  • : Please do send an email to as well, if you haven't already, providing the Scirra reference payment number and your account's username.

  • : I don't know which one was specifically in cause.

    All I know is that the server is far from "constantly" crashing (at least according to the dates in this topic, the previous crash issue was during October 2016, that's not what I would call "constantly").

    Moreover, anybody running a website and or software on a server knows that they need regular rebooting and other maintenance (whether hardware or software).

    If your game is a hobby project and that the multiplayer part is not the heart of the gameplay/that important, I guess relying on a service provided "as is" is indeed enough.

    For any serious commercial project or project based around multiplayer, it would make more sense to handle its own server and be able to restart/configure/maintain it in order to react quicker and not share the load with any C2 user that wants to use the signalling server as well.

  • Server had crashed and has been reboot now.

    If you have questions about reliability you can always buy the signalling server software in the online shop and run it on your own hardware server to keep a constant access on your server and configure it as you like.

  • Well again, make sure that Construct 2 is displayed by your GTX960 and not your intel HD chipset.

    And make sure to update the graphic drivers of the GTX as well. You want THIS graphic card to display Construct 2 not the Intel chipset.

    Look on google using the keywords "laptop using graphic card instead of chipset".

    You may even add the GTX960 reference to your graphic card in the search.

  • When you "clean install" are you downloading the release again from the website each time or are you always using the same executable you already downloaded ?

    If not, try another clean install with a new download.

    Is your computer a laptop with an Intel chipset and a graphic cards ?

    If yes are you sure Construct 2 is not using the Intel HD chipset of your computer ?

  • Try to update your graphic card drivers.

    Make sure when you make a clean install, to uninstall any previous release and try and clean the registry base as well before making a new install.

  • Topic covered in the How do I FAQ

    [quote:42ubn5bz]How do I open a recent project in an older release - LINK

    Newt already answered with the same in your previous topic though.

    Also, you should simply update to the most recent release, as long as the education subscription you are using is still valid, the new release will work with your license.

    You should at least update your r233 to the latest stable r239.

  • Because likely you do have an archive uploaded that you forgot about.

    Go ahead and complete the details, with a specific game name that you can then delete, if needed, once completed.

    Check out if then you are able to upload other archives later on and let us know.

    Otherwise, consider sending a mail to the support.

  • Overall I'm pretty confused and less and less sure about the product you are willing to offer.

    At worst, if you already do own a seller account, just go ahead and propose your product for approval and we will see what to do with it after testing during the review process.

    If you do not have a seller account yet, consider possibly sending a working copy of your demo to scirra's support and you'll get a definitive answer from there as to whether it would fit in the store and/or arcade.

  • You'll have to wait for Tom to confirm, but I would say it's not something that would get approved.

    The store is there to sell complete items, not a demo you pay for and then have to pay again to have complete use of (kind of defeats the purpose of a demo, doesn't it ?).

    The store does not allow you to set "items for free" either as far as I'm aware.

  • When you duplicate a layout, you are making copies of the instances of object types that are present in that layout.

    So it is natural that renaming an instance of the object type in the duplicated layout ends up renaming the object type in the original layout since it is a single object type all along.

    And referring to the name of instances in the event sheet is all fine and one of the strengths of Construct 2.

    When using an event sheet applied to a layout, the events only apply to the instances of that layout.

    The interest of duplicating layout is to be able to use a common event sheet.

    Generally, you will have a "Common" event sheet containing mechanics that are common to all your layouts.

    For example, clicking on a button and possibly having a callBack from there.

    Then, specific event sheet for each layout will be created (containing the specific callBack for each layout) and including the common event sheet.

    At last r241 is a beta release the link of which can be found at the bottom of any page of the website and in this page.

    See this example made in r241.