R0J0hound's Forum Posts

  • You can still use those ideas. For instance you can take the second one and after you make sure the two objects aren't overlapping you can use overlaps at offset for a similar effect.

    Using the bullet's bounce is an interesting idea, but the bounce is inconsistent.

    You can however correct the angle by utilizing the equation for a bounce:

    angleOut = 2*agleSurface - angleIn

    So if you set rotateAngle to (Sprite3.Bullet.AngleOfMotion+90)/2-90

    You can also use your original idea of using detectors at the corners. To make it instant use a loop. To make it less jittery, move them by smaller steps.

    here's a wip of that I had laying around:

    https://dl.dropboxusercontent.com/u/542 ... 0_wip.capx

  • I think you can change it by changing the png in the Sprite plugin's folder.

    Edit:

    If you change the defaultImage.png in C2's install directory that will change it.

  • You could keep the player on a layer that doesn't rotate.

  • There are a couple ways to do this.

    One is to take the locations of the points of the collision polygon and calculating the point of collision and angle of the surface in contact by using the Separating Axis Theorem. It's a bit more technical to do but it gives exact results:

    Another simpler way is to check for collisions around an object and averaging out the offsets to get a angle. Here's one that does that when one object is a ball:

  • The angle() expression is what you're looking for.

    angle(sun.x, sun.y, self.x, self.y)

  • The bounce action of the bullet behavior should bounce according to the shape of both objects, aka their collision polygons.

    You can approximate it with events like this:

    In the case of a ray of light, you only need the angle on the object that's hit then the reflected angle would be 2*AngleOfSurface-angleOfMotion.

  • If you end up re-writing it in something else it may not be that bad, since you've already figured out the game mechanics and just need to port it over. It would mainly be busy work, and maybe having to implement some features here and there that only CC has.

    Actually re-building from scratch has worked for others in the past, but I guess it's not guaranteed to fix it.

    If you want to build CC from the source you'll need:

    For the editor:

    Visual Studio 2005

    DirectX SDK from 2008 (I forget which month, but that's indicated somewhere on the forum)

    profuis284.lib (This is the main snag, since this is not free, and even if someone has it they aren't supposed to share it)

    For the runtime however, you'll need:

    visual studio 2008

    DirectX SDK from 2008

    So the runtime doesn't use profuis, so I can be built easier.

    Plugins are by far the easiest to build. Their requirements are similar to the runtime, but the express versions of Visual Studio can be used, and I've seen 2005, 2008, and 2010 work. I've built the runtime with the express version of VS2008, and posted how on some older topics. There is a problem with that however, with C++ there is a thing called abi, which is the binary interface between compiled programs. The issue is it's different per compiler and can lead to errors sometimes. Also if you change compilers you need to make changes to the code to get it to work.

    Apart from actually getting things to compile there's the matter of fixing the bugs. If it crashes in the editor and it can't be solved by fixing plugins then building the editor is required. If it crashes at runtime and the plugins aren't causing it then either the runtime needs to be fixed or the export code from the editor needs to be fixed. Most of the simple typos have been fixed, so all that's left are the more complex bugs, which require rewrites of bigger parts of the code. Those rewrites are the main reason CC is retired. You can find a sticky on this in the CC section of the forum but basically things are at the point where re-writing the whole thing from scratch is easier than fixing it, which is where C2 came in.

    Now as far as the history of who has been able to build the runtime and editor, I think the number of people is less than 10. There where the three main devs, then I think pre 2007 there were a few more that where able to build the runtime and make a sdl instead of directx backend. More recently I think I've been the only person who's managed to build the editor, other than some douche on the net who likes to take free software and change it a little and try to take credit for the entire source. The runtime has been built by maybe two other people as I recall, but I don't think they shared any changes. Basically there has been no work on the CC's code since the last release.

    The idea of re-writing CC from scatch has appealed to me in the past, but there simply isn't enough time. A more doable idea has been to port a CC project to something else. I made the capreader python library to access everything in a cap file to assist with this. It works but some things like events are stored in a obscure way. Early on in C2's life I had a simple cap to capx converter, but it's currently way out of date and abandoned.

    Also it's hardly all down the toilet. You have all the art, level design and logic figured out already. It's just a matter of copying it over to something else. The main time lost is in fine tuning I suppose.

    Click on the "forum" link on the top of the page, then scroll all the way down and you'll see a graph of the number of posts per day. Most questions are answered by other members of the forum in their free time. You aren't guaranteed an answer, but in general most questions are answered within a day or two? There are also stickied topics in most of the sections with guidelines on how to make your questions easier for someone to help with.

    The install issue you posted probably will be looked at by Scirra's staff after their work week starts. If the file is messed up on scirra's server, it will likely be fixed quickly.

  • You mean this topic?

    I can't verify the file currently, but it worked when I downloaded it before. If the download is indeed corrupted on Scirra's servers you could try the torrent download of it instead. Alternatively you can try the latest beta instead, and see if that works.

    Also that topic was posted during the weekend, so if something went wrong with the servers it will probably have to wait till a weekday I'd imagine before Scirra's staff sees it and fixes it.

  • You asked the same question before here with normal physics, which you marked as solved after someone posted an example:

    You then asked a question similar to your op here, and got an example:

    You even already asked this in the chipmunk forum, where I responded with a general suggestion, since you weren't specific about what what was wrong other than it doesn't work.

    So in general you're just looking for a completed working example I guess. Applying forces are one of the simplest things to do with physics, and is about the same in chipmunk. The swipe direction I guess could be trickier, but it's just a matter of checking where you first touched to where you're currently touching.

    How do you know where you're currently touching? There's the Touch.x, touch.y expressions.

    How do you know where you first touched? Save the touch location to variables under a "on touch" condition.

    How do you compare the two directions to find a direction? Something simple like a "system compare" with the current touch position and where you first touched.

    I won't make a capx, but you can do events like this:

    global number firstTouchX=0

    on touch:

    --- set firstTouchX to touch.x

    is touching

    touch.x < firstTouchX

    --- apply force (-100,0)

    is touching

    touch.x > firstTouchX

    --- apply force (100,0)

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • "RUNTIME ERROR" is a catch all for crashes. I've thought of some common ways that I've encountered them before, but the cause could be anything. Unfortunately I'm out of ideas.

    If CC was still being developed the crash could be hopefully debugged and fixed, but currently no one is developing it and no one is set up to debug it. The best that can be done is to figure out what is causing the crash and avoiding it. Unfortunately that can be impossible for some more obscure bugs.

  • seven

    The original code in that capx is from taking the code in the effect itself and reversing it. The only snag was in the effect the positions are relative to either the screen or object, in the range of 0 to 1. So 0,0 would be the top left and 1,1 would be the bottom right. So as I recall multiplying by the sprite size was to switch between that and pixels.

    Beyond that I don't have anything helpful to say. If I was to do it I'd probably need to derive the math again so I understand what's what. But I've no time to do that.

  • You'll probably want to make a plugin to do this, or at least modify the one you use. C2 only handles strings or numbers, so the expression as is wont do it.

  • If AirConsole.Message is "{ touch: 999 }" then you could do this the get the value of "touch"

    Browser.ExecJS("var a="&AirConsole.Message&";a.touch")

  • The runtime errors are generally due to the events, not the objects. At this point I guess it can be assumed that the fixer cap does nothing, at least for your cap. You can start disabling events until you identify the offending event, but my money is on the "or" condition. Don't ever use it, it causes crashes. The only other common issue is with instance variables causing runtime errors, but this is less common and there is no fix.