faggatron's Forum Posts

  • Fagatron after seeing your op420 game you at a rave is no surprise lol

    lol

  • make me editor plz - faggatron

  • <img src="http://img399.imageshack.us/img399/9269/gurnjk3.png">

    me gurning at a rave

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I think the best solution would possibly be to have an option which causes the plasma to scroll with the screen.

    So if you had a 640x480 screen, you could have a 640x480 plasma object, (either on a layer above that doesn't scroll, or always setting position to be on the screen) which, when you move about, translates the visible plasma pattern in the opposite direction. That way the plasma object doesn't have to be absurdly big, so there shouldn't be lag, but it would be able to have plasma effects anywhere that is being displayed on the screen.

    I guess this could be achieved by adding a "shift plasma pattern" option which literally shifts everything happening on the plasma by however much you specify, then you could set it to shift the difference of the last scrolled point and the current one.

    I don't know if this is currently possible or not, I think it sounds like a plausible solution for future though at least.

  • Is there a way to use the plasma object on large levels, so that there isn't absurd lag?

    I'd like to be able to use plasma effects on a whole level (scrolling about), for guns or whatever but the only way that works seems to be to just make a giant plasma over the whole level, which predictably causes lag.

    It's not that important but I was just wondering if there was a clever way of making one the size of the screen move about with you or something.

    I've also tried putting it on a layer above everything and giving that layer scroll rate 0, but it only works properly in the top left corner.

    I guess its probably not designed for this.

  • I think physics would be a lot more useful if you could change all the settings at runtime, such as immovable, no rotation, contact friction etc, although you can already change some of them I can think of uses for the others. (Ice weapons, turn floors slippery, ie change contact friction).

    You should also be able to retrieve all these values in the expression editor.

    Also it'd be really nice if you could apply more types of constraints, as well as hinge, you could have weld, rope, slider, hydraulic, spring, etc. (look at garry's mod for ideas heh).

    It'd be cool if you could name these constraints when you add them, then you could enable, disable and change their parameters by name.

  • http://www.quotecats.com/what/gravplat1.cap

    In that cap, the last event is the damage one.

    controls are W A D Q and E.

    If you run down a hill it hurts you still, none of the formula changes help that. It's why I think it must need to be resolved in the direction of the collision or something, but I have no idea really.

    I'd like to make it hurt you from falling and when other physics objects bash into you. Running along a floor shouldn't hurt you though.

    While I've posted this, any ideas why, when the display is rotated, and you click, the effect isnt at the mouse. (It sets position to mousex("Main") mousey("Main"), seems to bug out when rotated, large possibility I just messed it up though.)

    oh and also, may as well ask, how do I timedeltaify the scrolling//rotating events?

  • Even if it only damages if over a certain value (k), you still get that problem. If the object is moving along the floor at some speed over k, it damages it like before.

    I guess its to do with the change of energy before and after the collision???

    In this situation when using the physics behaviour and on collision event, will retrieving the velocity give me the velocity after the collision?

  • I'm using the physics behaviour and basically want one of my objects to be damaged on impact with other objects, where the amount of damage is proportional to the force of the impact.

    I guess my problem is that I don't really know what I mean by force of impact. My best guess is either the change in momentum of the object or the change in energy, before and after the collision.

    I can't get it to act the way I want, for example, one problem I've had every time was that if, say, I wanted an object to be hurt when it fell from a big height, then a lot of the time when it was pushed along the floor it got hurt just as much. (usually when the floor was a downward slope).

    I can see the reason for this happening but can't think of a way around it,

    my event was an attempt at the kinetic energy (1/2 mv^2):

    on collision -> subtract (sprite1.mass+sprite2.mass)*((sprite1.xvel-sprite2.xvel)^2+(sprite1.yvel-sprite2.yvel)^2) from health

    So here when the object was moving fast along the floor it wasn't slowing down and kept losing health proportional to speed. (there sprite1 was the object and sprite2 the floor).

    I'm guessing I need some way of resolving the angle of the collision, not sure how to go about this either though.

    any ideas?

  • Sorry maybe I should've done some more experimenting before I posted this. It does work, I thought it would delete it for ALL my families though.

    Thanks for clearing it up though.

  • I'm posting this here, because I don't know if it is a bug or not; or if there are already any plans to change it. Also it's more of a change than a feature request.

    The issue I have with family variables is as follows:

    If you have 2 sprite objects for example; and you give one a private variable; then you give this object a family, say blue; then you make the second object part of the blue family; construct makes you give the second object the private variable of the first object. This variable now counts as a family variable.

    This seems badly organised. What I'd like is an object to be able to have it's own values, and the values of its families all separate.

    The problem really arises when you need lots of Families with variables, and some objects belong to multiple families. In this case all the objects would end up having all the same values, most of which would be completely redundant. Not to mention that none of these objects can even have their own private variables.

    So you have an enemy in the enemies family, and he has private variables telling him when he can move//whatever, then ALL enemies have to have these values assigned to them, whether they move in the same way or not. Also if he is in the takes damage family, EVERYTHING that takes damage, not only has all the variables attached to it that an enemy does, but also all the variables for the original enemy that moves about.

    Family variables should be listed in the properties tree, either under the family name, OR, the family name and its variables should be listed under private variables.

    Basically what I'm saying is that family variables should be tied to a specific family, and not just be counted as a family variable when one of the objects in a family has that variable.

    I just don't want all my objects to have about 50 variables when they only need 5.

    It's quite a subtle point so I hope I've explained it well enough heh.

  • This already exists: FormatDecimal(Value, # of decimal places)

  • The fruityloops were annoying.

    Also it's really hard, you should order the level selection by difficulty or at least give them some difficulty rating or something.

    Would be cool if you made it save your time for each level too.

    It's pretty cool though.

  • do you want an object with a higher Z to always be on top of one with a lower Z regardless of Y value, and only sort it by Y value if Z is equal

    surely you can just do (pretty much what Ashley said)

    for each object ordered by .y+.z*9999999999999999999999999

  • Yeah sorry that example won't really help you if the code is the same, I kindof assumed the lag was all down to 360000 iterations, not actually testing it at 600. Turns out it's still laggy at that many.