WackyToaster's Forum Posts

  • You can just directly put it into the JSON plugin from the script.

    construct.net/en/make-games/manuals/construct-3/scripting/scripting-reference/plugin-interfaces/json 

    	const data = your json data
	const c3json = runtime.objects.JSONobject.getFirstInstance();
	c3json.setJsonDataCopy(data);
	c3json.setJsonString(data); //use this if your json comes in the form of a string instead of object

  • Wouldn't you want to set the position just to Spaceship.X, spaceship.Y? I feel like that math doesn't make much sense.

    I've never used bumpmaps so maybe I'm misunderstanding something...

  • There's only one origin point, but I think you mean image points.

    I'm pretty sure there's no hard limit to it, I also don't think there's much of an issue with having 20. Maybe there will eventually be some performance impact since the position of these image points have to be tracked through all possible image manipulations (translation, rotation, mesh deform,...) which I'd assume adds some math overhead. But that overhead is probably very small so I'd not worry too much about it.

  • Are you using pixelart?

    When you create a new project there's a checkbox that says "optimize for pixelart" which sets a few settings.

    You can also adjust these settings later in the project propierties

    construct.net/en/make-games/manuals/construct-3/project-primitives/projects

    - Fullscreen mode: Letterbox integer scale

    - Fullscreen quality: Low

    - Sampling: Nearest

    - Pixel rounding: Set checked

  • Move to object is probably the most sensible choice, it lets you specify if you want the arm to be "in front" or "behind" the object. If you just set top/bottom it will work until you have other objects where the character goes behind or in front and the arm will end up at the top/below of ALL objects on the same layer.

    And yes, Z-Elevation is similar but does so within a 3D Space, which is why the arm gets larger or smaller.

  • All posts here come from a place of commitment and/or love for C3 and Scirra.

    Exactly.

    This does mean designing a new API in co-operation with the addon developer community

    This is honestly the best outcome for both sides I think.

  • Yeah as Ashley noted you are misunderstanding what the OR operator does. Here's a solution that (I think) should do what you intend it to do. 

    	Player.X+random(64,150)*choose(-1,1)

    EDIT: I should add that technically my solution isn't the "best" one since it requires a multiplication. I'd go with the one XHXIAIEIN posted: 

    Player.X + choose(random(-150, -64), random(64, 150))

  • It does not appear to be the case. But considering it's a spritefont, you probably can abuse some unused special characters to put an icon in that you then can use by just simply typing that special character (without needing any bbcode)

  • Another simpler way (and one I tend to prefer these days) is to use composition over inheritence - create a complex custom class that you want to be shared, and just add it as a property on multiple other classes.

    Just for clarification, you mean doing it like this? 

    	//inside subclass
this.plugin = new Plugin();

  • Thinking about UE/Unity model more...

    Ashley if you do take the big step and encapsulate everything except API in the future. There may be a business/revenue possibility for Scirra.

    Add a license to get an unecapsulated version of C3. This license could explicitly state that there is no additional support for licensees that work with undocumented features / API. So, it will be very explicit about where the responsibility lies. Also it will _limit_ the number of devs who actually have this type of access to ones that accept the responsibility and also show their commitment via a payment.

    Now to make this have real added value vs the situation we have today where addons can already use undocumented features and make it worth the extra license payment. With the above knowledge about licensees responsibility of using undocumented features and possible feature breakage. This additional license would also provide a C3 editor with code that is _not_ obfuscated. Which would allow advanced devs and addon makers to look at doing more advanced editor customization to improve their workflows.

    So, you would then have a limited subset of devs with the resources to both do / hire out for more involved customization than the SDK allows, ability to pay for the extra license and explicit knowledge from the license agreement about the possibility that they may need to freeze their C3 editor and runtime version due to the customization they have done.

    I actually like this idea, I feel like it solves the main issues at hand. Anyone willing to pay extra to tinker in the engine probably has the brain power to understand the ramifications. To pick up the car engine metaphor: A licenced mechanic can tinker with the engine and is expected to solve any issue that comes up alone.

    Obviously this still adds probably a good bunch of extra work for scirra, but it's still a solid solution.

  • Ashley I'm not gonna argue here because you are steadfast on your plan anyway. But as it stands right now there is no real benefit of this for us as users, at least I fail to see it if it exists.

    But since you go down this road... what would be important at the very least would be a quicker response time to API requests if within reason. Perhaps even separate from the current suggestions platform. And yes I know, small company etc. But you know, if a developer needs access to some aspect of the engine to achieve some goal, posting it into the void on the suggestion platform and then being effectively "ghosted" for half a year is also NOT a great option.

    I have personally experienced this btw. I'm not just guessing here. Usually I just put the project on ice and move on, which is easy for me since I don't have any requirements or contracts to fulfill.

  • The water reflection one is neat!

  • Can you post a project file where I can test this?

    I'd guess that the host communicates "destroy" before it communicates "move" so that the bullet for the peer gets destroyed before the final movement it should do. Maybe this can be adjusted by ordering your events in a different way or by delaying the destroy action for peers by a brief (1 tick?) delay.

  • There's no too many or too few. Just impressive as it's a quite big project. Easily one of the biggest ones I've seen, but I kinda remember one that had like 100k iirc :V

    We use JS for things which are now possible with events and to speed up processing of some big arrays.

    I see. Yeah arrays in general seem to be easier to handle in js.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 10000 Events is impressive. I'm curious what do you use the few lines of js code for?