Animmaniac's Recent Forum Activity

  • It's great to know that it's possible to load a geometry from the master. I guess I missed it from the changelog.

    Thanks for the support, it was very useful!

  • Hmm, I was trying to avoid having duplicate textures for the C2 Sprite (for polygon collision testing) and again for Q3D rendering. But if it's not possible to pass a sprite texture I guess there's no way around that. The idea is to detect a rough 3D collision with Q3D and then get a more accurate test by positioning equivalent C2 Sprites outside the screen and use the 2d polygons for precision. *Imagine a tree placed on a quad and detecting only where the trunk and branches are as solid.

    So if I understand correctly you are suggesting to use a Q3D Model that has support for animation, right?

    I was previously creating planes by using just the master. So is there a way to set a Q3D Model to a plane primitive or the only way is to create and load a plane model?

    Also it seems the Q3D Sprite would be more appropriate for what I'm trying to achieve, but it always face the camera. Is there a possibility to add an option to make it render in it's 3D orientation?

  • Is there any way that I could link a sprite from C2 to a diffuse texture?

    I want to have some animated textures on planes and would be so convenient if I could use C2's animation system instead of eventing my own.

    I'm also planning to reuse the sprites for a more precise collision system, so if I could link those it would be perfect.

  • You do not have permission to view this post

  • You do not have permission to view this post

  • I think the problem with simply deleting events is that when the project gains some complexity, it's practically impossible to know where all the events were and what they used to do. Sometimes crucial complex events disappear, and you simply can't perceive they are missing and spend ours trying to find what's wrong. It's even worse when there's lots of events scattered in various places (and/or different event sheets) and they all disappear at once, without leaving any trace of their existence.

    In my opinion a far better way to handle this is to color red the events with invalid references, and make them act like disabled events: they simply don't exist during runtime, only in the editor (under the hood they are commented, or simply not included). This allows to run the game without any annoying errors hindering it's execution.

    An alert icon could then appear at the status bar (or other places) indicating there are broken events. You can choose to fix those events by replacing it's references or leave to fix later if it doesn't interfere with what you are currently testing.

    If a new object/variable/... is created with the same name as a broken reference, the user can be prompted to automatically replace the references in those events or not (obviously only if it's of the same object type). If it's not desired, the bad references are given a new name like "reference2".

    The big advantage of this is that you can see exactly what those events where doing, and replace the bad references with proper ones. It would also help a lot in importing objects from other projects, or even merging projects, since you can have some time to analyze those broken events and figure what variables/behaviors/effects... you need to add to make those objects valid to replace those events again.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • You do not have permission to view this post

  • There's a way to avoid the bleed. Put your tilemap on a layer, place another tilemap over it with the color masks and apply the effect to it. Then enable "Force Own Texture" to the layer.

    Here's an example.

  • The easiest way to do this is to create a new layer containing the color areas, then apply a modified version of the effect to function as a "mask" shader (it uses the layer texture to modify the background). It's quite easy to do.

    Just for curiosity, what's your use case?

  • You do not have permission to view this post

  • Animmaniac: The UID is already visible in the properties for any selected instance of most non global plugins in the editor.

    Yeah, but only when selected and not very visible among other information. The idea is to have it visible at all times in the editor. A small blue box at the corner of the bounding box so you can see it at a glance without the need to fight layers to select an object.

  • Since you are now an expert at edit side rendering, how about a simple behavior that displays the UID and/or IID of objects in the editor so you can more easily reference them in code?

    I don't know how feasible is to render text in the editor, but if it's possible this would be very useful for trigger zones, managing multiple cameras, dummy colliders and the like. If it had a field for a custom ID that you could set like "cam01", "triggerZone02", etc... that was displayed in the editor and could be referenced like a variable in events it would be supper handy as well. Other ideas are the ability to display the collision polygon per object, bounding box, hotspot, angle, and action points.

    It would be basically a helper behavior.

Animmaniac's avatar

Animmaniac

Member since 18 Mar, 2010

Twitter
Animmaniac has 1 followers

Trophy Case

  • 14-Year Club

Progress

14/44
How to earn trophies