Scoremonger's Forum Posts

  • Love your art style - the player's character blending into the background so invisibly is so cool. It's super-inspiring and motivating to see these kinds of projects being built with Construct!

  • You might also look into the Anchor behavior as it was made to assist with problems just like this one. Docs here:

    construct.net/make-games/manuals/construct-3/behavior-reference/anchor

    It sounds like you already have a good solution, but Anchor may prove useful for you at some point.

  • Yes, exactly - I want some kind of idiot-proof drop down allowing me to populate variable values in the object properties using constants I've defined. I think in Unity such drop-downs are accomplished with enums, for example, but it's been awhile.

    I can see how your suggestion for setting variables using event sheet logic works for objects that all need to be initialized the same way - I am actually doing that in one case. But I'm referring to a bunch of object instances of the same type that need to be initialized with different values at design time. Another hypothetical example that's hopefully clearer:

    I have a bunch of doors in a building layout, and I want some of them to start locked, others to be open, others to be closed, and they are all based on a single "Door" object. I implement their open/locked/closed states by giving the Door object a string variable called "State", and using "open", "locked", "closed" strings as my state values. In my layout I then select the doors one by one and type whatever state I want into each of them. If I could set those variables using string constants (instead of repeatedly hand-typing them), they'd be less error-prone and easier to rename/refactor later on. Basically the exact same reason constants are used in event sheets, but applied to object properties at design time.

    Anyway this is a pipe dream for now, unless there's a really elegant workaround I'm overlooking.

  • Thanks for the suggestion dop2000, but I'm looking for a way to initialize instances of the same object with arbitrary values on an instance-by-instance basis, which can really only be done by setting their properties directly. I think it's time for me to write up a feature request!

  • klkev I'd add to what — said that C3 is just all-around easier to use. At a glance the two are very similar, but there are so many small improvements throughout C3 that they add up to a much smoother workflow. Plus any new major features like the timeline tool will only be coming to C3.

  • Hi all, I'd like to use a constant to set a variable's value at design time. For example, say I have a bunch of state names, like:

    STATE_IDLE = "idle"

    STATE_RUN = "run"

    STATE_BADLY_NAMED = "fred"

    and in my character objects I have a variable called "State" that I want to set to one of these at design time. Currently I have to manually enter the State strings into the object properties by typing them in - I can't use the constant. So if I decide to change my constant for STATE_BADLY_NAMED from "fred" to "asdf", I have to remember to go through my objects and manually change all the "fred"s to "asdf"s in their properties too, which makes for errors. I also don't know a way to search through all object properties for a string inside the editor. It can be done in Windows, but it's a bit of a hassle.

    Does anyone know a trick to use constants in object properties, or a way to search object properties for a string from inside Construct?

    Thanks!

  • NetOne Thank you, those were many of my thoughts as well - this mostly sounds like an organization issue to me. But with any luck the needed documentation will be made available so the author can port his plugin to the new runtime for those who want to use it. Perhaps an appeal to Scirra to get that documentation would be an easier path than trying to have this officially added to the editor. Improved documentation helps the whole community and doesn't leave Scirra with another plugin to test and support.

  • I'd like to have a plugin that automatically rewrites forum posts to be polite and respectful. I could have used that myself a few times.

  • you dont need to use include event sheet to call functions from other sheets o_o

    If you haven't included the event sheet containing the function you're calling, it won't work. So if I have declared a function called "TEST" in "Event Sheet 2", and in Event Sheet 1 I try to call TEST, it will not work unless I've also included Event Sheet 2 in Event Sheet 1.

    That said, I have no idea how or why this suggestion could have gotten 106 votes in just a few days (and most of those votes are coming from egg accounts which makes me suspect foul play, haha). I wouldn't complain if that many people really want this feature and Scirra thinks it's a good idea or easy to implement. I personally have yet to encounter a case in my own projects where I needed this sort of thing, but I suppose it comes down to how people want to organize their event sheets and name their functions.

    I just keep thinking I"d rather have that effort go into a scene graph, animation timeline, and event sheet-authored behaviors that we can share between projects. Those are things that would be widely useful and I find myself wishing for them on every single project.

  • You already have a thread going on this, why start another?

  • Thank you so much for this. I haven't yet attempted to set it up, but it sounds perfect. Awhile back I set up a local WAMP https server and hated every minute of getting that thing configured. It eventually worked, but since then I've needed to uninstall it, and because I didn't have any pressing need for a custom C3 plugin, I put aside even tinkering with them because the https server setup was so annoying. This inspires me to give it another try, thank you.

  • I notice in that tutorial there is nothing that tells the monster which detector to use, so I guess what's happening is the logic sees that a detector is failing to collide with the ground, and then issues a command to turn around to ALL monsters. The tutorial seems to assume you only ever have one monster and one detector, but since I didn't try building it myself I might be mistaken about something here.

    You could try using a Container to automatically spawn the monster and a detector at the same time. That way each monster instance will have its own detector instance. It should be easy to try out, and might just work without further changes to your events. If you haven't used containers before, they are explained in the manual here:

    https://www.construct.net/make-games/ma ... containers

    There are some tutorials out there for them too, I'm sure. Good luck!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Cool, glad you settled on a solution that worked.

    Personally I think if there was just a checkbox next to each object in a container which said 'Maintain Relative Position' and possibly more claririty on parent child relationships (like Unity) this would do.

    I also think that the 'Pin' behavior should have a 'Automatically Pin on Start Of Layout' checkbox so we didn't require separate actions for this all the time.

    I love the simplicity and ease of use of your container suggestion. It has the disadvantage (which is really a disadvantage of containers, not your suggestion) that one would still need to create a set of unique object for every single combination of objects, even if some of the sub-objects look and behave identically. So if you have a bunch of slightly differently designed dialog boxes like the one you are making, and they all use mostly identical elements, like a text object, you'd need to make a different text object for every single container rather than having a single text object that can be reused all over the place. This is one place where containers fall apart compared to more sophisticated implementations like Unity has. All that said, I'd still kill to get what you just suggested.

    Unfortunately there is no parent child relationship in Construct per se right now, but you can however fake it a bit with pins and instance variables. The Pin behavior has "Pin.PinnedUID", which will return the UID of the object the Pin is attached to. So in a condition you could do something like Button -> PickByUniqueID -> Button.Pin.PinnedUID, and that will pick your frame. For the "parent" storing references to its children, you'd have to use an instance variable to store the child's UID. So you'd add "ButtonUID" number variable, and then when your button is being set up, either at runtime or design time, you'd do something like Frame -> Set Instance Variable -> Set ButtonUID to Button.UID. Then in the future you could use Frame.ButtonUID to pick the button if you needed to.

    And yeah, setting Pins at design time would be pretty handy for some situations. I found it confusing that this wasn't possible when I first started playing with Construct.

  • Yeah, this is one of Construct's biggest limitations imo - the inability to build prefabs beyond containers. Workflows in Flash, Godot, Unity and Unreal lean heavily on this concept. I'm desperately hoping Scirra will implement a scene graph once the C3 runtime is up to snuff. The suggestion for that is already logged and has a ton of support from the community, and it sounds like they plan to look into it, but a few more votes wouldn't hurt... <img src="{SMILIES_PATH}/icon_e_wink.gif" alt=";)" title="Wink">

    https://construct3.ideas.aha.io/ideas/C3-I-12

    In the meantime I have been looking into various ways to deal with this problem in my own project, which requires quite a few composite objects of the type you're describing. The suggestion to hard-code each one is the simplest and if you're fairly new to Construct or if you don't have many of these object groups that's what I'd suggest too.

    Another (considerably more complicated) method to consider if you want to push things further would be to build an object editor for your project. Basically you'd create a level editor, but for objects. The short and incomplete version is you'll loop through the objects in your group, then save the data for each object into an array or dictionary using a combination of the objects' names and the asJSON system expression. Then you'll write the array or dictionary to a file (you will need to export to NWjs for this). Then at runtime you can recreate the object(s) from the file(s) using AJAX to load the file, create object by name to grab each object name from your array, and loadfromJSON to set all their properties like position, etc. Finally you pin them together, if that's needed - this also requires you to track some kind of pin target uid when you create the objects.

    I would suggest using families for all this to make such things easier - for example, I'm using a "Serializable" family with an "ObjectType" variable to store the object names, and a "Pinnable" family with a Pin behavior for all the things that need to be pinned. This way you can use functions to simply get "Serializable.ObjectType" for every single object in your group, and loop through them more easily. I'm currently hard-coding what things in a group get pinned to based on their object types, but there is probably some good way to abstract this further with yet another family ("PinTarget" or something).

    Anyway, it's a little complicated and difficult to explain fully in a short paragraph like this, and it's probably overkill for your problem, but that's the basic idea.

  • And one question from me: will the old Construct 3(or maybe construct 2) projects be compatible with the new c3 runtime?

    Near the beginning of the blog post:

    And we've even managed to keep it highly compatible, allowing many existing projects to opt-in to the new runtime with few or no changes.

    It would be nice to learn what the details are, but it seems like compatibility is an important consideration for them already.