Sup with that?'s Forum Posts

  • You can try putting Destroy Outside Layout behavior for all the objects and simply have them start outside the layout on start. That way they will be immediately destroyed when you run the layout.

    Not sure what you're asking in the second part though?

  • Are you changing the bullet speed through events? It stands to reason that if older monsters aren't affected by those events (e.g. if events only run for when a new monster is spawned) then they'll remain unchanged. Can't really say for certain without seeing how the events are set up, though.

  • Well, short of looking at your .capx to try and find it, I'd suggest plugging "speed" into the event sheet search box so it'll isolate any events to do with speed.

    It sounds like the game might be treating the speed increase as a one-off event instead of continuous, so it'll increase the speed of one object, but as another one spawns it sets speed back to its original. Only guessing though.

  • If I'm understanding the situation correctly you can simply try using a variable or something to check which weapon is currently equipped, so if shoot+variable=1 -> shoot weapon type 1; if shoot+variable=2 -> shoot weapon type 2, etc.

  • An ambitious project indeed

    1. I guess you'd have to ask every single C2 developer ever and see what their map sizes are! More realistically, just play around with the layout to see what works best for your project. I've had maps spanning ~20,000 pixels, which may have been overkill for my project. Also, unless you're shooting for one big continuous map, remember you can always have several layouts for different parts of the map to make the game world larger.

    2. You can try using Pathfinder behavior to make zombies chase players around obstacles, and Line of Sight behavior to make it possible for the player to hide behind things.

    3. Don't know unfortunately. You can try looking through http://opengameart.org/, see what they have.

  • Disabling rotation in the turret's setting shouldn't disable any of its other parameters, so it should still be tracking targets and counting down its shoot timer, etc. If I had to guess I'd say something else must be interfering with the behavior.

  • You can probably just recreate the Example: Lighting file but with your screen.

    Basically, try setting the screen's blend mode to Destination Out, then make the layer the screen is on opaque and turn on Force Own Textures for it.

  • Am I understanding currently that the ball merges with the hill when it tries to go back up? Can rex's Push Out of Solid behavior possibly be used as a quick fix in this situation, if you were to designate the hill as solid?

  • You can try using Pin behavior to make the sprites trail each other, then turning on their own locomotor when the sprite they were pinned to is destroyed.

  • Well, the expression seems accurate enough, the only thing I can think of is if you have multiple of the same sprite from the get go, only the variable of (IIRC) the oldest one will be taken into account. So if you have 2 sprites and the initial value of the first one is level=1, and the second one is level=2, the expression will calculate as 2*10*1. This shouldn't be a problem if you're changing the value through events.

    I *think*.

  • On that I'm not 100% sure, I think may just default to white. Perhaps you can use additional translucent objects and layers to give things a colored tint?

  • From that video it looks like you can probably do this with blend modes for objects/layers. There's actually a ready example in C2 you can have a look at, just go to File > New > Example: Lighting

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Oh, I assumed that the nodes themselves would be objects that do the moving, while the units simply trail along. I was thinking to have the unit use Pin behavior to stick to a node, then while node is stationary have it slowly rotate, thus making the unit orbit around it. When a node moves, unpin the unit and have it move after the node, then re-pin once its within a small distance of the node. Though, I would probably use Bullet behavior to achieve this (and Pathfinding behavior if there's any pathfinding required).

  • Perhaps a year or so ago I would've totally been all over this testing it out. I was using CC and in my random-map-generating-rogue-like phase (part of me is still bent on making an actual game like that). Alas, .cap files aren't compatible with C2.

    Good work, it'll surely come in useful for someone.

  • Most behaviors do have an option to disable/enable them which you can access through conditions, but unfortunately Destroy Outside Layout is one of the ones that doesn't. AFAIK it has no properties whatsoever.