Nepeo's Forum Posts

  • Legally ( but not technically ) you can only run macos in a VM if the host environment is running on Apple hardware, according to the EULA. EULAs are fairly soft but I would recommend staying on Apple's good side if your hoping to make money through their platform. Apple software is a shining example of a walled ecosystem...

    IIrc you can create a debug .ipa that only work on specific devices, not sure anymore if you get the actual file or have to deploy it via a beta-channel in the store.

    I thought you could only run it on a physical device if you had signed it? Certainly xcode wont let you build to device without a code signing identity.

  • Mmm yeah the dialog doesn't work if your outside the EU, I actually have a bug filed with them to allow it to be shown anywhere (as per user request) but they haven't responded yet.

    We don't have a condition for it yet, but we could add one. Stick a request on the feature tracker and so we can track the interest. It may have to be async due to the way we interact with the SDK.

    If I'm honest I don't know where they get the "is in EU" information from. We certainly don't request the location data permission from the device. Maybe they figure it out on the server side from network information?

  • Apple won't let you install unsigned applications onto an iOS device, and you need a developer account to sign an application. Which as WackyToaster said costs ~$100 a year.

    You also need a mac with xcode on to create applications, it can't be done on Windows or Linux. xcode is technically free, and you can build and run an unsigned application in the simulator without a developer account. But you cannot create an IPA.

    You might be able to find a 3rd party service that will do it, but you will have to pay I'm sure.

  • If you look at the debugger most of the time is spent in draw calls, presumably updating the tilemap buffers. 1.6 million quads is a lot to be shuffling around, and it'll be quite easy to use all your CPU time up. You may find it much faster to just update everything at once, or increase the area you generate per iteration. Although the obvious answer is to just reduce the tilemap size so your shuffling less data.

    Take a look at "procedural terrain generation" demo ( under advanced examples on the start page ) and you will see the terrain is generated in small chunks. Chunks are created lazily, and the tilemap content is switched around as the user moves by swapping chunk information in and out of a dictionary. This greatly reduces the size of your scene and the number of tiles that exist at any time. The downside of this approach is more complex generation code that relies on knowledge of neighbouring tiles is difficult ( neighbouring tiles might not be loaded ). The project has been optimised to keep a smooth framerate while reloading tilemap data and performing terrain generation, so the tiles may be larger than you would like. There's some things you can do to increase performance and allow for smaller tiles but may increase complexity and have other tradeoffs, such as:

    - using multiple tilemaps and moving them around ( updating less tiles per reload ).

    - limiting the horizontal or vertical size ( chunking can become 1 dimensional ).

    - using a transition to move between zones ( this allows you to use more of the loaded area, reduce the reload frequency and hide reload jank, but makes your game less seamless ).

    After saying all that... At the moment your only really drawing pixels, so as dop2000 says it would be faster to use the drawing canvas and pixel manipulation, but it has other downsides though.

    Another thought is that if your worried about generation time you can always generate the world ahead of time and pack it into your game as project files. Using procedural generation to create dozens of worlds, choosing the nicest and doing some editing is a pretty good technique for creating large spaces quickly. You can even create multiple ones and just randomly pick one at the start of the game.

  • Last I checked the limit was still 12, it was quite awhile a go but maintenance of the User consent SDK has been very lacking on Admobs part. No one on their is even looking at the bug tracker as far as I'm aware, so I would be surprised if anything had changed.

    I'd advise just to give it a go. There might be financial advantages to allowing adverts from other networks, but I don't have the experience to let you know. Other users might be able to tell you, or just a google search, there's probably people talking about it online.

  • Getting close to release :/

    Looks like your making great progress LukeW you can do it!!

  • Hey oosyrag thanks for your feedback. I fixed your GitHub bug this morning, and it should be resolved in today's beta release.

    When a ray passes directly through a corner it is touching the very end of the segment, which is quite improbable unless you actually point at that co-ordinate like you were trying! Due to floating point precision errors it was incorrectly testing as not intersecting, which is what I fixed. The rays C and A should behave correctly as collisions now.

    Looking at the redblob games article you probably wanted D and A to not count as collisions ( which they are ), but unfortunately that would make C always pass through the segment. I would advise checking the distance of the image point to the collision position, and if it's under a very small threshold then perform a second raycast from just past the hit position if you wanted to continue the ray past the corner.

    The 0 collision checks issue is because the raycast mechanism uses different ( new ) collision checks to the rest of the engine. We could add metrics for raycasting to the existing debug data, I will look into it.

    Looking at your example your probably having issues with self intersecting polygons, the polygon rendering algorithm doesn't support complex polygons like this as they are quite difficult and expensive to convert into triangles. You may find it easier to just draw a triangle per segment.

    We probably won't add another action for casting a ray at an angle, but we will consider it. Looking at your event sheet I wasn't sure why you were using angles and not the image points themselves? If you use the LOS between positions condition it will take into account the range, and will still give you the collision information like the RayCast action does. As you say it's easy enough to project the required vector anyway if you know the maths, and this is quite a math heavy behaviour anyway.

    Most of the expressions produce a default value of 0 if there was no hit, but for distance it could be because the ray was colliding with an object at it's origin position? More likely that there was no collision.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • There's quite a lot of posts here to read, so I might have missed something, but by the looks of it this isn't answered yet. It's possible (and quite easy) to import/export data to and from google sheets.

    You can select multiple cells by using shift click, then just cut/copy/paste. The copy format is the same as both excel and sheets ( TSV ). We don't support drag select at the moment, which I think has confused some people into thinking they cannot select multiple cells. It's not possible to directly import/export arrays as CSV because CSV can only hold 2D data, and arrays are always 3D.

    If your wanting to work with a custom data file I would recommend using JSON, which is a much nicer format to work in and with and is easily readable/writable using the JSON plugin. It doesn't directly map to a tabular format, but it's an easy format to work with by hand in a text editor and you can use whatever structure you like. Also it's properly standardised, and actually reasonably designed unlike CSV. CSV is a great lazy format if you want a program to dump some data, but that's about it...

  • No worries —

  • Both Phonegap build and our own build service are currently using cordova 8.x, which doesn't have official support for iOS 12. This is because cordova 9 only released a week ago, we are currently waiting to see how stable cordova 9 is before moving to it. I'm not sure when phonegap will swap over, I haven't seen any public comments from them.

    Through our own service we've seen some minor issues targeting 12.0, but nothing major. You should be able to change the target SDK in xcode fairly easily, which should resolve your problem.

  • It's not obvious what your asking for here? Do you mean localization or location??

    If your asking for localization of the user consent dialog... that's a bit of a pain. The dialog is provided by Admob, but only in English. So we would need to come up with some sort of translation system and modify their SDK.

    If your asking to enable location data for adverts, Admobs own advice is "You should never request location permissions from users for the sole purpose of advertising.". These adverts are location based not localized ( shops near to you etc. ).

    If your game needs location data for some reason, you can add a cordova plugin that supplies Android location APIs. It will ask permission for user location, and Admob will automatically apply the location data to requests once permission has been granted.

    I haven't been able to find any other documentation related to localization, was it something else you were referring to?

  • — no worries. I don't believe the examples or documentation have been updated yet.

    It works by passing a SDK.PluginProperty instance with a variable name when you create a CordovaPluginReference. Like so: 

    const property = new SDK.PluginProperty("integer", "test-property", 0);

this._info.SetProperties([
	property
]);

this._info.AddCordovaPluginReference({
	id: "cordova-plugin-inappbrowser",
	plugin: this,
	variables: [
		["MY_VAR", property]
	]
});

  • An APK doesn't specify an CPU platform (x86, ARM, etc. ), but it can include executable code for specific platforms. Check out my explanation here

  • "Test mode" is provided by the App/Play store here, if believe it requires registering a specific account to use for testing ( been quite awhile since I've needed to test it ). Then it will provide fake purchase flows for you. It requires more setup, but there isn't an equivalent setting for us just enable testing mode like admob.

    Scirra doesn't ever see purchase information, and it certainly isn't stored on our server. The App/Play store on the device keeps track of user purchases. Both stores are capable of telling you if the user "owns" a product, and if the product is available for purchase.

    On Android all products are "consumable". Users can only own one of each product, once a product has been consumed the user no longer owns the product. This is why you cannot check consumables and you must keep track of them.

    Admittedly they could probably change how this works, so that developers do not need to run a separate system for tracking purchases. But the developer doesn't really need to keep track of the consumable purchase, but what it represented ( gems, coins, power ups, etc. ). Hence it would need to be a more complicated system that allows the storage of something more generic and isn't necessarily tied to the store anymore.

    You can store that information any way you like, but there's a few questions you should ask before choosing somewhere to put it.

    1. If the user deletes the app, will their items persist?

    2. If the user has multiple devices with the app, will it work correctly?

    3. Can the user modify the data, possibly getting items for free or deleting other users items?

    As users will be paying for these goods, you should treat them like actual money. Any risk of them vanishing, or being copied is not good! I haven't used the Play Games Snapshot system, but it might work for you. You might have issues keeping data synced if an awkward user plays your game on 2 devices at the same time, as both devices can modify the items without the other knowing ( creating, using, exchanging items ). Even if you check before using an item, there's a chance that it will have been modified between your check and update ( look up "Atomic commit" ). There's a chance that the Snapshot feature has a solution to this built in, but I haven't looked through the documentation.