Last Legacy Suggestions

[CedarBranch]

Oh, ♥♥♥♥. That's what was throwing you off.
I haven't used LL in so long and I was referring to the Explanation of Triggers' vocabulary section for the terms because of how rusty I was, but I totally used the wrong terms.


Replace these words as I don't want to bother going through the trouble of editing those whole posts:

Triggers -> I meant "Functions"
Threads -> I meant "Triggers"

[JSlayerXero]

Hmm, to go back to your Bob and Derek example, I'm not entirely sure if that's possible or not. Assuming those two names are triggers, hit boxes or otherwise, a long, long, long list of branch if commands and a variable can theoretically allow you to skip to any given line in the code once the trigger starts. It is possible for a command/function to activate a different trigger and then another one to stop the current trigger, and again, assuming you make enough of them, you can have a string of branch ifs send the code right back to where it was if you build it right. I'm not sure if that's what you're asking for or not honestly, but that's a way you could do what I understand you're saying. Although trust me, I once tried to make a jukebox that would cycle through the entire soundtrack, something like that would require huge amounts of work.

[Dtroid]

Sorry if I phrased it entirely wrong,but-

So what you're saying is, we drop the incredibly useful system that we've been using for all this time, which every level already uses, and isn't actually that difficult to learn either, to entirely reprogram a whole new system that can't even do as many things, to make it "easier" to use, even though it's actually the exact same thing with checkboxes instead of menu options?

No,no,no. I'm not saying we drop the system now. It's like an alternative way of doing triggers for people who just don't understand the current one now-people can still switch to the original one.

I beg your pardon? How is that any different from the variable system(s)? You don't like variables, I get it, but this doesn't fix that. You want to know why? Because that very example of you making a sleep function uses a variable. When the editor gives you a blank box to insert a number, like enemy HP, sleep time, colors, or anything similar, that is a variable. Call me crazy if I'm wrong. The very definitions of a variable are, to quote dictionary.com

10. Mathematics, Computers.
a. a quantity or function that may assume any given value or set of values.
b. a symbol that represents this.

No,I'm not talking about filling up a blank with a value. I'm talking about (example: "player" or "g_dead")

To make it simpler for the player,instead of

1.if g_talk = 1 goto 4
2.Set "g_talk" = 1
3.Exit
4.Activate "destroy"

,it is

if var:g_talk = 1,then ☑trigger > ☑activate tag:destroy

[KABOOM]

That's not actually that much simpler. "Goto" commands are not that hard of a concept to grasp. You give it a number, and it goes to that number. Easy. And what if I want to make multiple commands dependent on one "branch if" without making an entirely new trigger? In the end, I don't think such a system would be worth programming...although, an "activate if" trigger command could be useful.

[Raz]

Still prefer the system we have now and I doubt runouw plans to change it.

[JSlayerXero]

No,I'm not talking about filling up a blank with a value. I'm talking about (example: "player" or "g_dead")

To make it simpler for the player,instead of

1.if g_talk = 1 goto 4
2.Set "g_talk" = 1
3.Exit
4.Activate "destroy"

,it is

if var:g_talk = 1,then ☑trigger > ☑activate tag:destroy

I fail to see how that's simpler. Say your command has 50 lines or more of code; a concept that's not exactly foreign to me. I've probably done worse While it's in progression, you want it to be able to go back to say, line 12, under 5 different circumstances. Under the current system, you just need to add branch if then make it go to line 12 if any of them are correct. On the other hand, your system would require adding the commands past line 12 in every instance. For example, if line 12-16 did a function. Then, lines 17-20, 25, 37, and 42 all gave reasons to go back to line 12 and continue from there. Your system simply moves forward and doesn't at any point have the ability to go backwards. Because of this, you would either have to write code for each function, which could go forever depending on how exactly this works, or take up more space both visually and in the code, would require you to remake lines 12-16 and beyond manually, and would consume more time. You might even have to find some other way to make loops that have any number of ways to continue or restart them. How would you pull this off? Frankly, I don't know if that would even be more user friendly that way. Also, what exactly does that "trigger" checkbox contain? If you're saying "trigger" instead of function there there is going to be a lot of mix ups with what I'm saying.

[Dtroid]

I don't understand what you're saying. "trigger" is just a general word I use to summarize functions such as the stopping of threads,the turn on/turn off/activate functions (or other things),and the "Exit" function.

EDIT:Wait,shouldn't "goto" be in "trigger"?

[JSlayerXero]

So basically you have your own set of key/code words. Marvelous. No, go to requires a specific line number to refer to. Your branch if phrase makes sense since it tells the game do function 1 or function 2 if condition is LRZ met or not met. Go to however, requires an exact numbered line. Unless your sentence phrases are numbered, then that go to command is useless absolutely useless. Furthermore, go to refers to lines in the current, active trigger/thread, and unlike your branch if phrase, would not be able to do anything else, making it utterly useless. Under the current system, go to, sleep and variants, and branch if all fall under flow control. I have no idea why you separated them, frankly.

[ChaosYoshi]

May I suggest, if it hasn't already, that the Checkpoints automatically heal you? What I'm getting at is that when you respawn, you start with full health, and because of that, you could hit a checkpoint, hit the Backspace button, and then be back at full health. In the end, it would only save a few seconds of someone's time, but I would like to throw it out there anyways.

Another thing I would like, if this does get implemented, is that the automatic heal would be optional. Maybe have it so that you can make checkpoints record what health you were at when you hit the checkpoint? I really hope that I don't confuse anyone with the way I worded it since I'm tired from staying up last night.

[Dtroid]

May I suggest, if it hasn't already, that the Checkpoints automatically heal you? What I'm getting at is that when you respawn, you start with full health, and because of that, you could hit a checkpoint, hit the Backspace button, and then be back at full health. In the end, it would only save a few seconds of someone's time, but I would like to throw it out there anyways.

Another thing I would like, if this does get implemented, is that the automatic heal would be optional. Maybe have it so that you can make checkpoints record what health you were at when you hit the checkpoint? I really hope that I don't confuse anyone with the way I worded it since I'm tired from staying up last night.

Optional automatic heal while going through respawn points?
Try this.

You could use a switch to determine whether the player wants automatic heal-for example,something like "if you would like it,then press the switch". You could do automatic heal by placing hearts on the respawn point.

The other things you want to be implemented should be able to be accomplished by variables and stuff.

Now to my suggestions-

How about a function about delta blocks? Like,if a delta block is being placed in that particular area,a trigger does something?

How about a function to change the background?

How about different delta orbs that would be discovered in Chapter 3 or something? *shot*

How about a Random Level Generator?

How about a tutorial,of course.

How about an ability to change the standard tiles/items in the level designer?

How about an ability to change the color of things that we can't?