Devs: What would happen if...

adadoadado Member Posts: 219
edited November -1 in Tech Support
...you just removed *all* the code in the GS editor application that pertains to remembering information about the state of the UI (i.e. where it left off, what rules/behaviors where open/closed, screen push/pop stack, etc.)?

I believe that code is possibly buggy as well as causing some of the delays in presenting actor rules/behaviors when you switch from actor to scene to actor.

Also, why can I be in any of home/scene/actor/preview modes, "save" the project and then without editing *anything*, I switch to one of the other modes and all of a sudden, my project is deemed dirty and needs saving (according to the GS editor). I think something in there may be contributing to some of the corruption issues that periodically plague us (just happened to me again...couple hour's work since I was on a role and lost track of time). Everytime the project gets in an iffy state, it is usually when I switch from one mode to another (and I save before switching modes religiously in addition to the periodic restarts like all others are doing).

I would rather all rules be open when an actor opens if it meant speeding up actor presentation in the editor. The time save there could then be spent scrolling to where I want to edit.

Also, drag-n-drop of behaviors in an actor is dangerous as I have seen odd results as well as just plain crazy results (i.e. rules disappearing or rules that were not there suddenly appearing...usually a rotation). I have learned to just cut (or copy) a rule, move to where I want it, highlight a rule there to establish a reference point and then paste. That seems to be much safer.

The eventual slow down of the GS editor app I think is also attributable to the UI code. It is almost as if something is being cached and not released or something and it builds up over time (unless it is a memory leak maybe related to such). The browser-esque forward and back buttons don't really make a bunch of sense given the other ways you can navigate within GS and I think they may be creating a "push/pop" stack that may be the culprit using more and more memory and not being released once the user "gets lost" going here and there.

Thanks for reading this.

Comments

  • jonmulcahyjonmulcahy Member, Sous Chef Posts: 10,408
    Hi Adado,

    I've had some similar problems with the UI. I've got a rule that has 54 subrules, and it takes forever to open and close each one when it loads.

    Since we've got a nice iPad release, I'd love for the GS team to really focus on improving the engine for the next release above all else, both for programming and for playing.

    Send and Receive Data using your own Server Tutorial! | Vote for A Long Way Home on Steam Greenlight! | Ten Years Left

  • adadoadado Member Posts: 219
    Instead of saving the full state. Maybe they could leave all behaviors open and just remember the vertical position of where we were within the actor's behaviors. Sort of like an HTML anchor hash (#) tag in an HTML page. Then add "Top of Behaviors" and "Bottom of Behaviors" buttons. I think that would make navigating much easier and less to manage by the app. Then they wouldn't need that very ugly and cumbersome XML file with the UI state saved in it.
  • adadoadado Member Posts: 219
    Bumping as it's on page three already and there is a lot of Dev action in the forum currently.
  • adadoadado Member Posts: 219
    There is definitely something funky with the changing between scenes/views and them becoming dirty without any edits taking place since the last save. If I've been working in GS for a bit (i.e. close to the time to exit and re-run the GS app) when I change scenes/views, it "goes dirty" with the "red" indicator in the upper-left going from solid to having a dot in it. Then if I save (Command-S) real quick, sometimes it comes back stating that "something else" has saved and do I want to overwrite. It is at this time where I am at a loss what to do. Seems if I say "no" and just exit GS, things are fine. If I say "yes" and overwrite, it is when corruption of the gameproj file occurs.

    Not sure if that will help you guys debug what is going on.
  • ORBZORBZ Member Posts: 1,304
    i agree

    watch what happens to the memory pool if you attach xcode instruments to GameSalad... leak leak leak

    odd since ObjC 2.0 has garbage collection.
  • bladeolsonbladeolson Member Posts: 295
    Adado, thanks for showing me this thread. I am definitely interested in seeing this fixed. I feel we would be so much more productive if this issue were resolved. It is by far the # 1 thing that needs to be improved. I agree the remembering of UI state is not important if that is the actual reason. I can't tell you how many times I have waited and the forgot what I was trying to do because it took so long. I have to not only save every time I do something, I have to write it all down too! Sorry If I sound like a complainer today about this, but this is really getting to me today. I can resolve what i need to do to complete my app very simply conceptually but the tool is really stopping me from finishing.

    Maybe at the least if they could shut off the UI memory stuff as a preference or something.....
  • ORBZORBZ Member Posts: 1,304
    restart GS often... apple-Q, apple-spacebar, type: gamesalad, enter
  • bladeolsonbladeolson Member Posts: 295
    the text on my q key is getting worn out. ( not joking )
  • rebumprebump Member Posts: 1,058
    Restarting helps but it does not help if you have moved some blocks of behaviors around in an actor.

    So I guess we must now quit the tool often (as we have been doing) AND don't move behaviors around but rather re-create them and then delete the old location of them.

    Real handy tool we are hedging our bets on here.

    Really kills the drive for new parts/components of your game if you have to spend hours re-creating things the editor loses for you.
  • ckck Member Posts: 224
    ANY word on 0.8.6.1? Out of sheer fear of getting 86ed, been waiting weeks before starting a new project. Running out of time... Gendai folks?
  • dandan Inactive, Chef Emeritus Posts: 28
    Thank you all for your patience. There are a handful of issues being discussed here, I'll see if I can address them all:

    • Memory Leaks: There are a few leaks that show up in instruments. GameSalad does use garbage collection; however, most of these leaks happen in 3rd party C or C++ code that GameSalad calls to. We will continue to fix or replace code that leaks memory. However, these leaks typically do not add up to very much, and are not the main cause of the slowdown.

    • Memory Growth: Memory usage increases, but it doesn't show up as a leak in instruments. This is caused by several objects that do not get freed under certain circumstances, and is responsible for the slowdowns after switching editors. This problem is worse in OSX 10.5, and has been significantly improved (but not totally fixed) in OSX 10.6. We will continue to work to find solutions to this. In the meantime, for the best GameSalad experience, I recommend running the latest version of OSX (10.6.3).

    • View State Saving: We've heard your reports, and plan to work on the view state saving, while separating it from the game saving system so that it doesn't get in the way of your game data.

    • Saving 'dirty' state: GameSalad does track when edits are made, and it knows when a document is modified or not. However, we decided to err on the side of safety, and mark the document as needing a save after every editor switch, just to make sure none of your data got lost. Its better to save too often, than not enough. As we introduce stable saving and loading, with validation, we intend to phase this out.

    • Drag and drop problems: Thank you adado for reporting this. This is one of those intermittent issues that doesn't always show up in testing. I will make sure this is a priority.
Sign In or Register to comment.

© Vanilla Keystone Theme 2024