inkBot's Forum Posts

  • I don't buy the whole "buy a new computer" argument because my PC is upgradable, and a Frankenstein of my own creations.

    All computers are upgradeable. Some to a much lesser extent (laptops, prebuilt boxes, media centers, etc). So that doesn't actually say anything.

    Seriously, Linux runs so smoothly on my system

    Linux runs smooth on freaking anything man.

    Like Jase00 pointed out. Did you check which BSOD you got?

  • I'd very much like to be able to develop for Ouya with C2, so I guess count me in.

    But you never explain what you mean with "YOPP"... >.>

  • Me and Hemul1 came up with a game idea based around pool (or billiards) and decided to pursue the game as a joint venture.

    What we're aiming to do is have a somewhat simple pool game, combined with another form of gameplay. Simple means that there'll be no way to strike the cue ball from different angles to create back or top spin.

    As such I started testing out ways to do the pool part of the game. Searching the forums I found an example using the physics behaviour.

    Thing is I can't work with the physics behaviour to save my life. Even back in CC I hated, hated, using physics, because I could never get it to work the way I want it to. Maybe I just suck at working with it, I don't know. The objects eventually always go into sleep and become completely immovable, etc.

    So I started looking at alternative solutions too.

    The way I see it, we have at least four different ways to approach it.

    1. We use physics anyway, and try to wrestle it to do what we want.

    2. We use bullet behaviour to handle ball movement and bouncing off walls. But we still have to handle ball-to-ball collision with events.

    Would involve some math.

    3. We use custom movement for the entire thing. Would involve WAY more math.

    4. We do everything with events, no behaviours. This obviously involves, like with custom movement, lots of heavy math.

    The upside to 1 and 2 is that we get a lot of the work done upfront. Downside would be that we have to work around the behaviours to get them to do what we want. A collision between the balls, using physics, is not accurate to how pool balls behave, and a collision between balls using bullet behaviour just straight up isn't.

    Upside to 3 and 4 is that we'd have much higher control over how the balls behave. Downside being, as stated, heavy(-ish) math. Neither of us are all that proficient with heavier math though, but that's something can be researched.

    So, which approach is best? I realize that there's not a clear answer to the question, but I'm kind of stumped currently.

  • <img src="http://th08.deviantart.net/fs70/PRE/i/2013/014/2/2/pinkie_drinks_your_milkshake__by_luzeke-d5ri2kq.png" border="0" />

  • 15k for 5 months is prettty spot on the salary for an entry level programmer over here afaik (I'm not a programmer so I don't really know exactly).

    But wouldn't it be neat if we could get a WiiU exporter for C2 eventually? Even though it's unlikely.

  • Congratz man.

  • Some new stuff:

    <img src="http://th06.deviantart.net/fs70/PRE/f/2012/345/6/5/crows_mock_up_cover_by_luzeke-d5nruzj.png" border="0" />

    <img src="http://media.tumblr.com/tumblr_mezw9q1FIp1rb1fbs.png" border="0" />

    <img src="http://24.media.tumblr.com/tumblr_me8rswZInq1rmp1mjo5_r1_500.png" border="0" />

    <img src="http://24.media.tumblr.com/tumblr_me8rswZInq1rmp1mjo1_1280.png" border="0" />

  • No facebook here either.

    :/

    Nice stickers though.

  • Made a new pic of my Recimir character. This one was fun to do.

    <img src="http://th04.deviantart.net/fs70/PRE/i/2012/329/4/b/recimir_mk_2_by_luzeke-d5m6s57.png" border="0">

    If you're interested in the process I also put up a stage by stage progression. Link.

  • http://videogamena.me/

    There. :P

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Psh, I played Quake 3 with a laptop touchpad and won.

    But in all seriousness. If you design your game around using the mouse for aiming, chances are people that want to play it either already have a mouse, or have the means to get one.

  • So are you saying that there's no way of setting the object back down?

    Nope, just that getting it to work will need some finagling. This issue hasn't come up for me personally, so I haven't tried to solve it for myself. So currently I have no real solution to give.

    Maybe I should look into destroying the object and spawning a duplicate where I want it set down. It might even be easier to attach a sprite object containing all of the objects you would carry to the player. That way I could just give the illusion of holding it. Thoughts?

    It's certainly something you could do. However, it would have the same problem as before, just replacing carrying/putting down with destroying/creating. The problem lies with the keyboard object running every event in sequence.

    There was a discussion not too long ago about a very similar subject, and I think Ramones had a solution to the issue. http://www.scirra.com/forum/using-one-button-and-variable-to-switch-states_topic58648.html?KW=

    Not sure if that capx is still available though.

  • Select the events you want and drag them into the group, or cut them and paste them in there. Whichever way works.

  • aruche that is AWESOME and exactly what I needed. Problem is that I'm trying to set the object down and any code I try to figure out isn't working. I'm trying to toggle the carrying off and have it end up at the player's image point and left there on the stage.

    If you're doing what I think you're doing, you have similar setups for the events for turning carrying on and off. Problem with this is that they will toggle in order.

    This order of events:

    + Player presses S

    + Carrying = false

    • Toggle Carrying

    + Player presses S

    + Carrying = true

    • Toggle Carrying

    It's first going to toggle the Carrying variable, but instantly afterwards it's going to toggle it again, because the conditions for that event have now become true. This will give the appearance that it doesn't work and you can't pick up the item, while in reality you're picking it up and immediately putting it down. If you reverse the order you'll have the opposite problem, you can pick the item up, but you can't put it down.

    I really appreciate the help. Also, if you could friefly explain what you did, that would help me learn it for next time. Thanks!He's effectively doing what I wrote in my post.

  • What the Pin behaviour does is pretty much just

    + Every Tick

    • Set [object] position to (X,Y)

    Except that the X, Y coordinates doesn't update after the object is pinned.

    If you need more precision, I suggest dropping the Pin behaviour and do it manually, using a boolean or a string value as a state machine to check when the object is grabbed or not.

    + [object] Grabbed = true

    + Every Tick (adding every tick here is not really necessary, but old habits die hard :P)

    • Set [object] position to (imagepoint.X, imagepoint.Y)

    You're doing almost the exact same thing as the Pin behaviour, but the object will follow the image point, since we are using the image point's coordinates directly.