QuaziGNRLnose's Forum Posts

  • fuego

    cool! Its fun to zoom around

    cjbruce

    I like it! I did a lot of highschool robotics and had to be driver a lot, so I think its a great idea to make a little "training room"

  • Hmm, weird. The physics objects don't like being re-positioned/rotated outside of torques and forces / velocity because this forces the engine to do extra updates and triggers a lot of things behind the scenes. I'm not entirely sure why objects aren't rotating though, it seems to work for me. Can u send a .capx?

  • cjbruce

    Parenting should work fine, you just have to be careful with the transformations because it gets complicated! There's no need to manually shift things like that and it is quite expensive. I see you've fixed it already though

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • cjbruce

    I suggest doing away with the physics based wheels entirely, and making the cars spheres/blocks instead. This should significantly boost performance and is how most video-game cars are implemented. Im assuming you made the wheels invisible because they were acting strangely? I realize this is probably a big change to make but my experience tells me its the best way to go.

  • cjbruce

    The issue seems to be with the use of physics more than with the rendering of objects. A scene without physics should take many many objects before it slows on any okay CPU.

    It's probably a better idea to fake the movement by considering the entire car a single rigidbody and applying torques to that to emulate wheels. Using hinges on cylinders will lead to trouble getting a good contact patch and make the controls poor, as well as open up the possibility of wheels getting out of alignment. This will also be much less costly

  • fuego

    Q3D Wasn't really designed with nested objects in .obj's in mind, Since this doesn't really fit with the workflow of Construct's picking system. Really you should have one Q3DModel for every static geometry. There's kind of no point working without constructs picking inside construct, and the advantage of using Q3D+C2 over javascript alone quickly disappears with lots of added overhead. Some Q3D things are redesigned from three.js to give speedup / avoid bad practices that would quickly ruin performance. I

    cjbruce

    What do you mean by instancing?

  • DKinGer

    You should have gotten an email when you purchased the plugins, where you can download the files from. You unzip the download and follow : https://www.scirra.com/manual/69/plugins

  • DKinGer

    Did you download the plugin files and install them in the plugin and behavior folders (the standard procedure for any third party plugins)

  • Check the manual. It doesn't cover all the capabilities but it should familiarize you with basics.

    https://www.dropbox.com/s/vpn0mbh4m7lo9 ... .docx?dl=0

  • X3M

    Any Idea why it got pulled/deleted? seems strange.

    tunepunk

    People understand, they just aren't going to buy the product. Making C3 a service is alienating a huge chunk of the userbase, and largely seems to be done as a step to get more money from schools.

  • cjbruce

    If Q3D master is not global aswell that might lead to the issue, since you're destroying the scene the objects are linked to, but they can persist in that scene, while another scene is created that they are not a part of.

  • cjbruce

    I'm not sure what you mean, its unclear. Even if it's in the debugger it might not exist in the same scene, but there are too many factors for me to understand whats going wrong. Send me a Capx that demonstrates the problem.

  • imothep85

    No, it's not at all that simple. Qfx shaders aren't a complete feature, and shadertoy doesn't use some kind of standard format anyway.

    I think a subscription model just doesn't fit with the use case of a game engine. You work on a game for potentially *years* at a time without releasing it, and need to maintain your ability to work on the project, save old versions of the engine so you have at least some semblance of version control, and have a static work environment that wont change in any way so that you can always make updates, access source files etc.

    Being browser based already opens up construct 3 to all kinds of issues with the browser engine misbehaving and potentially screwing up potentially years of work, but to have to pay just for the privilege of working on your project is really not something a serious developer would consider acceptable. The idea of being locked out from your tools is something anyone using Construct 3 will become aware of, even if they aren't right now. Construct 3 isn't enterprise software, yet you're expecting individual persons to throw money at it as if they're businesses who can afford the fixed cost and write it off as an operational fee.

    I cant afford to pay the subscription fee. I might potentially use the product once every few months, it's just not justifiable. I think a lot of users who would have gotten Construct 3 as a 'toy' were it another normal piece of software they could install and open from time to time, wont anymore. 100$ to play around every couple of months is too much, and the subscription model makes you reluctant to work on anything that you might wanna get back to at a later date.

    And as someone who STILL uses construct classic, I feel kind of burned that Construct 3 is moving further and further from what made Construct good in the first place. Construct 2, and now 3, still lack core usability features that would improve the engine significantly for serious developers such as storing object references, lists , SOL's, Arrays, in object variables, and building prefabs of objects in a general class based system rather than having to rely on the botched container and family features that always wind up requiring weird work arounds when structural changes have to be made. Instead we're encumbered with the overhead of storing UID's in other objects and having to a search over N objects every-time we want to make an object reference, so even building prefabs, constructors/destructors in events carries a severe overhead. The event engine/SOL system is great, it can be used for rapid prototyping and really quick development, but it needs improvements to actually be usable for performant code in a large game. The same issues that were in construct classic are largely unaddressed even in Construct 3. There needs to be more types than just string and numbers, and more control and object oriented paradigms implemented into the core workflow.

    Construct 3 seems to want to be professional development software with a fee that's even steeper than Unity's, yet the features that have been added are largely unimportant to anyone using the tool as a professional developer. dictionary/array editors, the "real equation" expression feature that makes things more unreadable, the "work anywhere on any device" (really who will be able to code with any capability on the subway on a tablet/phone without a mouse or keyboard?), the useless cloud integration, all feel like additions that are meant to make the software appealing to the most novice of users, yet the pricing is set so that only serious professional users will pay it. It kind of feels patronizing to your own user base.

    Why wasn't more done to actually appeal to advanced users if that's the audience the pricing targets? If that's not the audience you wanted, a subscription model, especially at such a high cost, is really not the right way to go.