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)

At this point it's mainly about keeping doors open for future additions or changes. If you take a non-zero value for both AREA settings as the only activator, then you make any new uses of the OOB AREA impossible. We might not have a good second use for it yet, but it is a door worth keeping open. As I said; I'm not advocating for my code, I'm against Riidefi's code. It tries to squish too much information in too little space, that's not easy to use, and is next to impossible to improve beyond this point. The ctgpr chat consists of a majority of people who have limited or no experience with track creation, and almost no-one with coding experience and should not be seen as an authority in this case. Leseratte and I came to the agreement that it is the best call to reserve the "Route" byte of AREAs as activator. Once you do that; it no longer matters what implementation you take, since they will all work in all track distributions.

kHacker35000vr (talk) 14:55, 13 July 2020 (UTC)

So you guys now using 6 bytes now is better than Riidefis 4? I told you before it is easy to use as people have agreed with and even Leseratte did. You are the only one who disagrees. With Riidefis Code there are 5 additional bytes that could be changed to add additional features and as you guys said before we can even add additional AREA types for it.

Also why invalidate both codes? Why not make 0xFF the default value to load Riidefis code?

Also you already broke 2 additional conventions with your update. You did not 0xFF the camera ID and you also did not 0xFF the ENPT ID so in the future your update might break new codes.

Tock (talk) 15:08, 13 July 2020 (UTC)

The concensus is to use one single byte to determine how the AREA point is handled. In my case this means that my code will only run if the byte is set to 0x01 (although I did make an error which I'm fixing atm). Other values are not important; both 0xFF and 0x00 will not trigger the code and will make the area act like a regular one. If CTGP decides to use Riidefi's code, then it would be directly compatible with tracks that use this additional byte to tell how the settings should be behaving. The same will be true for my code and any other code that might follow in the future. I don't know where Leseratte said that; I know what we have discussed in a private conversation, which is what I just described.

0xFF and 0x00 should not be used as activator for exactly the reason you describe; it will be incompatible with possible existing tracks and is not entirely future-proof. All other values are available; something even Riidefi could make use of.

kHacker35000vr (talk) 15:22, 13 July 2020 (UTC)

That "consensus" was between you and someone who had nothing to do with both codes. If CTGPR decides to use Riidefis code over yours, tracks which support your inferior code will break since Riidefis code currently does not waste the route byte to enable his code.

0x00 is only not compatible because of you or bad KMP Editors that default to 0x00 instead of the correct value.

I still don't see you stating a reason why your code should still exist. All I see is you insulting the track creators in the ctgpr chat and your "I'm not advocating for my code, I'm against Riidefi's code." shows that you only do this discussion to annoy the community.

Tock (talk) 15:38, 13 July 2020 (UTC)

The consensus was between me and someone who has been a leading figure in file format expansion for a long time and is a wiki admin. Riidefi could have been part of it, but decided not to.

Why should my code exist? The most important factor of my code is that it does contain an activator, which allows future expansion without too much hassle. It also does support all kinds of parallel roads, there will be cases where using checkpoint ids does not work if they don't follow specific rules.

What's wrong with keeping standards flexible? It's the one and only thing I'm advocating for, don't forget that I have been through the process of comparing possible solutions all by myself while I was developing my code. It's not like I just spun the wheel and decided to root for what I have, riidefi's solution did pass my mind as well.

I'm trying to help everyone here, by preventing a mistake from a programmer point of view. The way you're talking about me absolutely saddens me, if you want a good conversation about this, you know where to go.

kHacker35000vr (talk) 16:00, 13 July 2020 (UTC)

Leseratte is not a wiki admin. You also were quite vehemently against them expanding the KMP File format before.

Your code also clearly breaks when people use split paths since you should not use key checkpoints in them.

If you can not come up with one reason why your code is better than Riidefis code why don't you agree to remove your code if Riidefi adds the activator for possible future expansion?

Tock (talk) 16:10, 13 July 2020 (UTC)

You can place a key checkpoint before a path splits up, and after it. Key checkpoints will naturally be placed in such a way that they will always work, because the lap count depends on them. However, if you have a track with a split path that contains checkpoints 15-19 and 32-36, then you are forced to change that order.

And other than that issue, and the simplicity, there's indeed no other advantage of using kcps instead. Kcps could even have the opposite problem on split paths, if the trigger depends on the path you took. Does that mean you should take away the option? There may be more cases where either solution can't be used.

kHacker35000vr (talk) 16:30, 13 July 2020 (UTC)

You are not forced to change that order. If you are bad you add another AREA and if you are good you see this as a feature to enable / disable checkpoints on a split path to reduce the amount of AREAs needed. I am thinking of a track with a split path that has two separate overlapping jumps.

I still don't see using key checkpoints as simpler than "activate checkpoint id setting" and "deactivate checkpoint id setting".

Tock (talk) 16:55, 13 July 2020 (UTC)