Talk:Conditional Out of Bounds

Two conflicting codes for the same thing

I am already talking to Riidefi and Kevin over Discord, but I think this is better suited here.

Both Riidefi and Kevin released a "conditional OOB" code today/yesterday, probably mainly for the track CTR N. Gin Labs. Now, sadly, both of these codes are completely incompatible with one another, since they use the parameters differently. Given that the point of these codes is to become widespread, and eventually get implemented into distributions like CTGP and LE-CODE distributions so that tracks can take advantage of that, I think that that is a bad idea.

There are now two competing cheat codes, for the same thing, and A) distribution creators can only support one of them, and B) track creators can only support one of them either. I think the unofficial update for [CTR N. Gin Labs]] made by Riidefi (which apparently the author of that track doesn't like in its current form and didn't give permission for) was a bad idea, while there are two conflicing cheat codes, and both of them are still being tested and updated.

Now I know that I can't force anyone to do anything, but I'd say that making a cheat code for a custom feature, then releasing a track update that requires that particular feature, with the author NOT liking the implementation of that particular feature (as I've been told by Kevin) is a bad idea.

I would recommend removing the unofficial 1.3 update from the CTR N. Gin Labs page again (if the author aggrees), then for Kevin and Riidefi and potentially others from the community to come to a conclusion about which of the two cheat code variants would be better suited for that case, and then having ONE type of conditional OOB code in the Wiki and update the track to work with that one.

The current situation (two different cheat codes, incompatible with another, no distribution can use both, no track can support both) is only going to cause trouble in the future.

-- Leseratte (talk) 19:19, 9 July 2020 (UTC)

Well, I'll just start with saying that the fact that I'm advocating for a single solution for everyone led to having this discussion in the first place, so obviously I'm not walking away until we have a final solution.

As for my personal preference, the decision to use key checkpoint regions is not one I just took without giving it much thought or thinking about alternatives, it took longer to come up with a good solid activator than actually writing the code itself. For me as track creator I'd like to have something as easy and clear as it can be. I don't want to have to look up how something works or what id I gave that specific checkpoint in order to place the AREA. This is why I have chosen for this solution. Key checkpoint regions are very clearly visible in the most used kmp editors, and the precision needed to activate or deactivate the fall boundary is not on a checkpoint level at all. I have done tests on three different tracks, and neither of the three required checkpoint changes because they gave issues. As long as there are no key checkpoints on intersections (which is something that I strongly discourage in any case), or between the two crossings of an intersection (which again is not the best idea for a track), just the key regions are all you need.

Because this also leaves one AREA setting free for something else, there is not just room for a deactivator as I included in the code (active as long as you're not inside a certain region), but also for completely different features in the future.

kHacker35000vr (talk) 19:40, 9 July 2020 (UTC)

Personally, I think it should depend on who wants to sacrifice their cheat code first and/or which cheat code the general opinion prefers. As with the track update Riidefi made, I see it more as an alternative version, even if it is unofficial, than a fully-fledged update – some people prefer the cannon, others prefer the ramp. --KantoEpic (talk) 19:48, 9 July 2020 (UTC)

I'm not saying the track update itself is bad. I'm saying that maybe it would have been better to FIRST decide on a cheat code that everyone agrees with, THEN make track updates to use that cheat code... -- Leseratte (talk) 19:51, 9 July 2020 (UTC)

Now I see. Again, I think it should come down to the general consensus. --KantoEpic (talk) 19:57, 9 July 2020 (UTC)

So since Leseratte doesn't answer me I will ask here: What is the reason to add Kevins Code besides making him happy? Riidefis code can do everything Kevins can do and more. It is also easier to use according to not only me but multiple people in the ctgpr chat. There is no reason to make a useless code that incorporates both and invalidates both old versions.

Tock (talk) 14:30, 13 July 2020 (UTC)