more freaking runtime errors

This forum is currently in read-only mode.
From the Asset Store
7 Errors
$12.75 USD
15% off
7 Errors is a game where you have to find the 7 mistakes before time runs out. Can you find all 7? Have fun looking.
  • So, I have been adding a title screen to my work in progress game..

    presently the layout order goes Title screen layout -> Character select layout ->main game layout

    I set up a skybox background with 6 1024x1024 textures, on the title screen and have 22 objects in the layout..

    I go to the next layout before the main game layout..(character select)

    that runs fine.. go to the main game layout

    RUNTIME ERROR

    I roll back to about 8 saves before with a minimal title screen and just add the basic menu sprites to start redoing the title screen again, thinking there was that duplicate sprite name issue, and begin with about 8 small sprites to create an absolute minimum of assets to make a selectable menu before adding everything else..

    main layout runs fine..

    add about 4 more small sprites..

    RUNTIME ERROR

    go back to my full version with the skybox, the 1024x1024 textures, and delete random non essential sprites one by one, running it each time getting runtime errors, and at 5 sprites deleted..

    character select -> main layout runs fine.. albeit with a sprite from the title screen appearing on screen (wtf)

    reload the file again and delete completely different small sprites, and again run it every time i delete one, getting runtime errors at the main game layout every time, until I remove 5 sprites..

    ..main layout runs fine..again , with a sprite from the title screen appearing on screen (wtff)

    reload the fully finished title screen version , try destroying a ton of objects before moving from title screen to pre- main loop layout..

    go to main game loop layout : RUNTIME ERROR

    reload it again, try unloading the title screen textures at the start of the next screen before the main layout..

    go to main game loop layout : RUNTIME ERROR

    half the size of all the skybox textures..

    go to main game loop layout : RUNTIME ERROR

    delete a ton of large graphics from the main game layout

    RUNTIME ERROR

    delete the whole skybox with 6 the 1024x1024 textures..

    RUNTIME ERROR

    can someone please tell me what the heck is happening?? I tried the repeat object name fixer cap and just got the same runtime error again

    is there anything I can check, or do?? I'm losing my mind here...why are a few small sprites addint a few Kb causing this, and not a skybox with 5MB of textures? why is it exactly 5 of them?? Why the main layout and not the one before it?? it was all fine until I started working on an innocuous title screen.. I'm not using transitions, although there was one loaded, but even with it deleted, its still give the error, and there's no OR's..

  • 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.

  • Thanks for the response Rojo, butsince i removed every OR last time I got runtime errors, as per your instructions, I never used them again... and its the title screen that is affecting other layouts.. everything ran fine until I started on this title screen, I rolled back and started the title screen layout again with a minimal set of sprites that used no variables, and only one sprite that contained 3-4 private variables that simply toggled some selection options..

    So to further test this, I deleted every event in the title screen layout, apart from 1 single button press on an xbox controller event to take me to the next layout..

    RUNTIME ERROR

    on the same stripped out title layout with the 1 event, I delete a load of objects..

    runs fine...but depending on what objects I delete , some end up hanging on the game layout screen when they aren't even global objects.. but again and again, after wiping the entire layout,deleting all the layers, wiping the event sheet and just adding objects with no variables, as soon as I add more than 15-16 objects, it gives me the runtime error without fail.

    even just previewing the main game layout alone gives me the error, but if i completely delete the title layout, it previews without issue.

    any help is appreciated.. I've spent literally years working on this...

  • "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.

  • So, my project is over? I've been over every possibility,probably over 100 times and the only thing that is repeatable is the "add more than 15 objects to another layout and stuff stops working". So avoiding the crash seems to be not add any more objects. Which means the end of the line.

    If I was to rebuild the entire thing from scratch, using my old cap as reference, would I end up in the same situation? I guess thats a rhetorical question, as I won't know until I try it.

    I have a pro game dev friend willing to look over the CC source if I could get the profUIS.dll but everyone who has posted on here saying they had a distribution license has ignored my PMs and mails..

    My only other option is to pay several hundred bucks in the hope PROFUIS will be able to give me an outdated DLL file.

    I really appreciate the assistance you and many others have given me over the years on this, but really, someone might wanna set up a sticky letting people know that there's a chance that people could be wasting their time and effort using CC to make something and end up in a situation as such as myself with an unknown and unfixable bug without being able to debug the CC source..

    Shame because it's still a beast of a 2D engine, so long as you're not taking anything seriously..

    8 years of work down the toilet.. and I was actually beginning to see the finish line.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • 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.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)