Scrolling Game Development Kit Forum

SGDK Version 2 => Help, Errors, FAQ => Topic started by: durnurd on 2007-03-24, 12:36:42 PM

Title: Switching Rule types doesn't work well
Post by: durnurd on 2007-03-24, 12:36:42 PM
When I switch rule types so that the number of arguments changes, or I change to a function that doesn't have a return type, SGDK2 doesn't seem to update it's data, because when I compile the program, it comes up with errors like 'No overload takes '3' arguments'.  when I delete the rule and remake it, it works fine.
Title: Re: Switching Rule types doesn't work well
Post by: durnurd on 2007-03-24, 02:06:04 PM
Among other things that don't work well yet include setting priority level for plans, and creating new frames/tiles/graphics and seeing those changes propogate through to other editors.

(as an aside, what does priority do?  Do plans with higher priority get executed first, presumably, or later? How do plans with the same priority play out?)
Title: Re: Switching Rule types doesn't work well
Post by: bluemonkmn on 2007-03-25, 08:47:04 AM
OK,  I think I fixed the problem so changing rule types will synchronize things so the project can compile right away, assuming you have some valid values.  Hopefully this also resolves the problem of disappearing parameters I thought I was observing while creating the tutorial.

Priority on plans is there in case you have a plan whose rules care about being executed before those in another plan.  Usually this shouldn't be an issue, but I thought I'd better add priority just to be covered.  It seems to be working as designed, which is plans with lower priority numbers execute their rules first (priority 1 is first, 2 is next, etc).  Having plans with identical priority values executes them in some order which you might be able to define, but I'm just calling "undefined".  In most cases my hope is that priority an be ignored and all your plans can execute with the same priority number in any arbitrary order (shouldn't have to care).  This is how special functions behaved in version 1, and you didn't have control over the priority there.  But there were a few cases where it would have been nice to control the priority.  I think those cases have gone away now since you can add the rules to the same plan (and rules definitely have a specific sequence) instead of creating a separate plan for every piece of functionality you want.  But in case there are still some cases (where you need to involve multiple sets of coordinates somehow?) it's there.

BTW, have you started your UI design class yet?
Title: Re: Switching Rule types doesn't work well
Post by: durnurd on 2007-03-25, 10:53:05 AM
My UI design class isn't until next (Fall) semester, so no.  Actually, I haven't registered yet, but it's a class that I will take with high probability.