Prominent's Forum Posts

  • This has been argued a lot in the past, and scirra did not do enough to improve it. I feel that importing and managing spritesheets is one of the worst things about construct.

    You also forgot to mention that you have to recreate the collision polygons and image points when you reimport them.

    And, they won't be adding any new features to C2 now, anyways.

    They may have reasons why they don't want to improve/change it, but that doesn't change the fact that the current way sucks and is inefficient.

  • I’d be interested in a simple tool to create 3D games. There are unlimited features that could be added to a 3D engine, so I’m curious what minimal feature set could be to still be fun and enjoyable to use.

    Lately I’ve been less interested in flashy special case features, and more interested in simple core features that could be used to build those special case features.

    So what would such a program have? I’m sure we all have a varying list of things we would want.

    * object types: camera, 3D mesh

    * A level editor to place, size, orient said objects

    * a way to get keyboard input as a minimum

    * an event/simple scripting system to move stuff about.

    * we’d want functions and some kind of arrays at least.

    If we could access all the mesh data with expressions, even better.

    After that I have a cascading list of ideas. Lol. But those basics could be enjoyable. In that base state there would be lots of math to do stuff, but I don’t think it too bad. Simpler helper functions could be made to hide the math.

    Of course there would always be things to optimize and improve.

    The dream feature list would be:

    * editor built with same engine for ease of adding editor features.

    * a simple way to make shaders in the editor without using glsl.

    Ahh it’s fun to dream and design in your head. Kudos to anyone that takes such a dream and try’s to make such a thing for fun.

    If I had the time and was more confident in my programming, I'd probably make an attempt at building some kind of game tool. I built my own 3d editor using the three.js library in the past: http://www.crocotile3d.com

    I made that because I wanted something simpler than all the generic 3d editors out there that are bloated with features. It's difficult to visually focus in programs that throw everything at the user, it becomes overwhelming. So that was my attempt at a simpler concept of building 3d models using 2d tiles. I like the pixel-art aesthetic too.

    As for a basic 3d game tool-

    What I would want is at least the ability to load .obj models and texture them. With ability to control/edit UV values so that you can have animated billboarded sprites- and also ability to change textures.

    Also ability to move, rotate the models, and scale.. x,y,z axis separate from each other.

    Also would need to be able to set the "Alpha Test" values, along with transparency, so that objects behind sprites can be seen through the transparent parts.

    Also ability to set opacity, hide/show objects. Maybe also the ability to Tint the objects.

    Some other helpful things would be stuff like setting the Up vector of objects, and having helper functions to make objects look towards a position. Maybe some simple collision/intersection checks, and raytracing.

    I like to remove some of the complexity when developing 3d games by using billboarded sprites instead of animated 3d models. I also like to remove lighting and other effects and go for a more clean pixel-art style.

    A 3d game can be simpler than developing a 2d game that uses a lot of complex animation and effects.

  • I think some people are being a bit too critical here, due to their preconceptions.

    The original post simply raised something to think about as far as making 3D games via a construct-esque program. It never suggested that construct should incorporate 3d into it.. It didn't suggest that scirra make a 3d program either.. It didn't put any limitation on how a program like that could be, yet some people are adamant that it must be a specific way or it won't work- and then saying it can't be that way because of such and such reason, and so there's no point discussing, etc. That's just being close-minded, and basically saying that you're not interested in discussing things further.

  • There are currently some attempts being made to add eventsheet style programming to Godot

    github.com/godotengine/godot/issues/17795

    If you are interested in an eventsheet capable 3d engine, I would suggest you go and encourage them on that github issue, and maybe it will help motivate them further. The github post is rather long, but as you can see at the end, there are attempts being made to include an eventsheet style way of programming in Godot.

  • ok.. I kinda figured that'd be the case.

    I'll just have to wait until I get new specs.

  • Which browser and version are you using? It correctly detects support for me in the latest Chrome, Firefox and Edge.

    Chrome, Version 49.0.2623.112

    I can't run newer versions of chrome and nw.js

    Why would changing how the Edge support is indicated mess up the compatibility with Chrome versions? Doesn't seem like you'd have to remove compatibility with old chrome versions to fix the Edge indication, or am I mistaken?

  • I was on r250, and updated to 262.. tried the default multiplayer example, and it said multiplayer not available.. I downgraded to 261, 259, 255, and 252.. it worked again for 252.

    I also tested an exported game from 250, while testing 255, and the 250 worked while the 255 didn't, so it is NOT an issue of servers being down.

    There's something wrong with the new versions of C2 (after 252) that prevents connecting to multiplayer server.

    I'm guessing it's related to the bug fix in 253 (Multiplayer: false indication of support on Edge)

  • What's the word on a possible C3 update?

    I won't be able to do anything with it until I update my computer (can't run c3).. which could be early next year.. c3 plugin system seems very confusing to me though.

    also, at the moment i dont have any incentive to use c3, considering there are other options more appealing to me.

  • Thanks R0J0hound ! That's interesting about the input blocking the events, and that execute js code seems to solve my problem.

    The capx is also interesting, though would be more work to incorporate I think, considering it doesn't have other user-friendly things like selecting text,etc.

    I'm going to use the execjs method!

  • I believe it's mainly an issue of how the keydown events are implemented in construct- they don't account for this scenario and cancel appropriately like they ought to.

  • I posted a bug about an issue Im having with key is down events.

    If you hold a key down, and then click an input box, the key is down will continue to think that the key is being held down.

    construct.net/forum/construct-2/bugs-21/key-is-down-bug-137376

    Does anyone have any workaround for this?

    I need a way to cancel the key is down event so that it stops firing- and to cancel it when an input gains focus. :\</p>

  • Problem Description

    when a form element gain focus, the key is down events continue to fire if the button was being pressed.

    Attach a Capx

    Capx: 1drv.ms/u/s!AhHSZHEulqh_ghe9x15zH6Z6WcoJ

    Description of Capx

    key is down events change text, a form input box to click while key is down.

    When you hold spacebar and click the inputbox, then release spacebar, it continues to fire the key is down event.

    Only when you click off the input and then press spacebar again and release it will it stop firing.

    Expected Result

    the key is down should stop firing if button is released while a form element is focused.

    Affected Browsers

    all

    vista

    r250

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • You can do it easily with the Chipmunk physics behavior. For example, you can do a on pre collide, check if the normal of the collision is pointing down(or maybe up?), and then ignore the collision. So you wouldn't collide if hitting it from a specific side.

    You can't do that sort of thing with the built in physics in construct. Chipmunk also has other useful features too.

  • I'd say they are relatively the same.

    The more conditions you add, the more it will have to process before running the actions.

    You can also have an event without any conditions, which will run every tick (you don't have to put the every tick condition).

  • Edit:

    I noticed that objects were still appearing and disappearing even though I was updating the synced variables, but the way I was updating them was by setting their variable with Self.variable (without any picking).

    I had a suspicion that some objects weren't setting their variable, So I put it into a for each loop to make sure each one was getting set, and this seems to fix the issue. There are sometimes rare cases when the latency is over 900 (when the browser of the host is minimized), but for the most part the objects stay.

    It also seems to only matter if the host is changing the variable, since peers set their values to the host's.

    I still added code to compensate for recreated objects, just in-case it does happen, since it can reset any un-synced variables and settings. On the host side, the objects will never randomly disappear (since it is the host).