From: Marc C. <mar...@gm...> - 2014-04-02 16:26:19
|
In that case I will go for what you proposed: only checking this in custom GPs. > Hi, > > you can't know you're in story mode, at least not when the challenge > is started (we do not keep track of from where you started the > challenge). So while this is a good idea, it is not currently possible > > -- Auria > > > > On Tue, Apr 1, 2014 at 12:19 PM, Marc Coll > <mar...@gm... <mailto:mar...@gm...>> > wrote: > > Using it only for custom GPs is easy to do, but there's another > possibility: the good thing about my change is that we can > actually choose if we want to get all the tracks from a GP, or > just the ones that have already been unlocked. So, while we are in > story mode we just need to get all of them, and that's pretty much > it, except that we will probably need to put back the Fort Magma > special case. My only doubt is: is there a way to know if we are > in story mode? If so, it should be easy to implement what I'm saying. > >> Hi, >> >> I'm not totally sure about your change. I think this should apply >> only to custom GPs, because when challenges were designed, it was >> intended that you could play a track through a GP before the >> track is actually unlocked. For instance, the overworld from >> story mode lets you play a GP before all of its tracks are >> unlocked, and the point system is tweaked for this. So your >> change may actually shorten GPs during story mode, which >> negatively affects the challenge system :( >> >> As such I'm not too sure what to make of this. For now my idea >> would be to use that only for custom GPs >> >> -- Auria >> >> >> On Mon, Mar 31, 2014 at 2:18 PM, Marc Coll >> <mar...@gm... >> <mailto:mar...@gm...>> wrote: >> >> OK, here are the modifications I promised. The change is not >> that big, and it seems to work pretty well. Let me know what >> do you think. >> >>> Hi, >>> >>> first of all I'm not sure we really care about "cheating", >>> the goal of locking is just to make things exciting, if >>> someone doesn't want to play challenges we never attempt to >>> force them to >>> >>> Perhaps a simpler option would be that on the GP selection >>> screen, you could lock any custom GP that contains locked tracks >>> >>> The fort magma special case is because in story mode, you >>> play all 4 GPs before unlocking Fort Magma. So if you play >>> the last GP before finishing the game, Fort Magma will not >>> be there, but after you beat the game, FM will appear in the >>> last GP >>> >>> -- Auria >>> >>> >>> >>> On Sat, Mar 29, 2014 at 4:42 PM, Marc Coll >>> <mar...@gm... >>> <mailto:mar...@gm...>> wrote: >>> >>> Today I realized that the new grand prix editor offers a >>> way for the >>> user to bypass the lock/unlock mechanism on tracks. If a >>> track is still >>> locked, the user only needs to create a grand prix >>> containing that track >>> and he can play it as if it was unlocked. I guess there >>> was no need to >>> check this before because all the tracks got unlocked >>> before the >>> corresponding GP. But now that the users can create >>> their own, the game >>> should verify this sort of things. >>> >>> So I modified the GrandPrixData class in a way that lets >>> the programmer >>> decide if he wants all of the tracks of the grand prix, >>> or just the >>> unlocked ones. That way the user can still edit his own >>> grand prix with >>> locked tracks if he likes, but won't be able to play in >>> those tracks >>> unless he has actually unlocked them. >>> >>> I'm almost finished with the changes, but I have a doubt >>> about the >>> GrandPrixData::isTrackAvailable() function. Apparently, >>> it's there to >>> handle some sort of special case with the FortMagma >>> track, but I'm not >>> sure why. I suspect that my modifications will make this >>> special case go >>> away, since now we will have to check every track. But >>> just in case, can >>> anyone explain this to me, so that I don't mess things up? >>> >>> Marc Coll >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Supertuxkart-devel mailing list >>> Sup...@li... >>> <mailto:Sup...@li...> >>> https://lists.sourceforge.net/lists/listinfo/supertuxkart-devel >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> >>> _______________________________________________ >>> Supertuxkart-devel mailing list >>> Sup...@li... <mailto:Sup...@li...> >>> https://lists.sourceforge.net/lists/listinfo/supertuxkart-devel >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Supertuxkart-devel mailing list >> Sup...@li... >> <mailto:Sup...@li...> >> https://lists.sourceforge.net/lists/listinfo/supertuxkart-devel >> >> >> >> >> ------------------------------------------------------------------------------ >> >> >> _______________________________________________ >> Supertuxkart-devel mailing list >> Sup...@li... <mailto:Sup...@li...> >> https://lists.sourceforge.net/lists/listinfo/supertuxkart-devel > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Supertuxkart-devel mailing list > Sup...@li... > <mailto:Sup...@li...> > https://lists.sourceforge.net/lists/listinfo/supertuxkart-devel > > > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > Supertuxkart-devel mailing list > Sup...@li... > https://lists.sourceforge.net/lists/listinfo/supertuxkart-devel |