that sounds excellent then, and the if pressed isnāt an issue as it can just be abstracted to a number value with a few extra blocks anyway
annnnd rawrbear you have put into words what my mind was missing :P
this would be amazing and i want to make stuff in this vein too
sidenote: secretblocks.htn appears to have a small typo on line 5, is set_opacitiy spelled as such on purpose lol?
nope lol
I expect there are many such typos, Iāve already fixed like five in the past few days working on connect the pipes
Would totally love to collab with you on that actually 
Once we plan this out of course. :D
@Petrichor would you like me to some up with some more designs for the Hopscript syntax? Or maybe like a list of API features? Iād love to help, but at the moment Iām limited to top-level design because of my lack of JSON project format knowledge
well hey active development is an effective debugging tool lol
100%! and yes, we do need to get there first haha :)
The most helpful at this moment would probably be thinking of features for the api for interacting with json, and then we can focus on the syntax of hopscript itself once the backend for codegen is good.
Your inexperience with the format of a hopscotch project is probably helpful, since ideally it will be easy to use without needing to understand much about the low-level json format. Iāve started refactoring my hopscotchification code and thatāll include a first draft implementation of the library, but itāll basically just be a refactored form of what I have now which is very low level compared to what Iād wnt.
Thatās why I made connect the pipes in the first place!
Letās start with a plan. We need to know who weāre making this for and exactly why weāre making it.
Since now weāve started a concept for a whole new lower-level layer, maybe we could design from the lowest level and work up. So we plan out HSAPI first, and then from there once we have full API coverage we can design the language on top of that, right?
I think the concept is there, we just need some planning and (a tiny bit of) structure to make progress on the final product.
Yep, thatās pretty much what Iām thinking.
Ideally the HSAPI would not influence the design of hopscript too much, that should focus on the experience of writing code with it, and the HSAPI should be flexible enough to be able to do what is needed for that.
The only issue with working backwards with Hopscript is that we might accidentally plan HSAPI features around the limitations we (intentionally or unintentionally) introduce in Hopscript.
HSAPI should be a whole separate thing disconnected from Hopscript and all other projects that stem from it. We shouldnāt affiliate Hopscript with it because that implies some requirements for HSAPI that come from the design constraints Hopscript creates, if that makes sense.
I might be making a bigger deal out of this than usual, but itās important to place a boundary between these projects since Hopscript was the original idea lol. We design around the possibilities which the API brings at the base level, and everything else comes after
And another example of something to use this hsapi for that Iāve been planning is adding things such as while loops ā there would be a processing step to go through every block and expand while loops into custom blocks.
this would be very helpful for hopscrpit, yes.
this is a must for once the base language is designed. One idea for this that I am considering at the moment but havenāt really thought too much about is similar to my idea earlier in the post about processing projects to add more features not in the app, but to make it integrate more with hopscript specifically call the code when a specific block is generated (although probably different, since some times we want to call it without generating code ie if it can cause some sort of error that should be warned in an ide extension) adn it does its work then. The specific use case I am wanting most for this is string interpolation, so I could write something like
show_popup(message: interpolate("The current time is \(User.hour):\(User.minute)"))
and it would automatically expand into a bunch of join blocks during hopscotchification.
Oh yes, thatās definitely true. I meant more that we shouldnāt do it the other way around ā any limitations in HSAPI limiting hopscript should be fixed. So neither project should constrain the design of the other. It should definitely be separate from hopscript though, we donāt want to make some super-specialized tool that only helps one specific type of project. Of course any limitations in hopscript should also definitely not influence the hsapi.
you both keep answering my questions as i write them, well done, i like the idea of actions that are interpreted from a readable format into a block code equivalent when hopscotchified
I think we should probably split up HSAPI into multiple subprojects for this kinda thing, just for people who donāt need those extra features. Maybe something like HSAPI.Core for all the regular blocks, and then an extension lib HSAPI.Extensions for all the extra stuff.
I like your idea. It seems like codegen is going to be a big part of these extra features. Code can be generated in different ways depending on the programmerās needs (ie. choosing to generate either a function or a macro, which essentially copy-pastes your code in a special way). So because of the complexity, we should tread carefully and decide what, where and how we implement specific codegen features.
Sublibraries are ok if code is to be organized, but the focus of HSAPI isnāt to be hyperspecific to Hopscript, just like you said. 
Iām gonna call this ātranspilingā or ātranspilationā for the sake of it having a term already 
I like Hopscotchification though, itās a funny word :D
these would be nice to add to the hsapi, both vanilla hopscotch actions and common actions that exist in other languages, as long as we donāt end up breaking compatibility for other types of access to that type. (i.e itās probably a bad idea to enforce all variables to be of a specific object class when hopscotchifying, instead have a generic handler that we can add more support for if needed)
@Petrichor, do you want me to make the HSAPI topic, or do you want to make it?
We could call it āHSAPI Planning Developmentā or something like that, with your leader approval of course @Temm! It could be put in the collabs category lol
We have great ideas, and should definitely start planning API features, though now we know this isnāt really the place to discuss that!
We could also rename this topic, but the OP was more of a pitch solely for Hopscript to be fair.
the topic is good, here in open source category or collabs category :]
i need to check the rules for github commits and whatnot but as along as you do so on an account that isnāt associated with non hopscotch stuff it should be alright
The extra stuff should be defined by the user. So the hsapi would provide ways to create a block with an arbitrary id, and a list of ids for blocks in hopscotch. If the user of hsapi wants to do something like, for example, replacing all wait milliseconds blocks with wait seconds blocks, they could do something like this:
project.forEachBlock(block => {
if (block.is(HSAPI.BlockTypes.waitMilliseconds)) {
block.setType(HSAPI.BlockTypes.wait)
const divisionBlock = project.newBlock(HSAPI.BlockTypes.divide, [block.parameters[0], 1000])
block.parameters[0] = divisionBlock
}
})
Or maybe the blocks wouldnāt be just mutable like that? Either way this is sort of what Iām thinking, where HSAPI just provides the low level access to the json in an easy-to-understand way and any actual special work like replacing blocks or adding blocks needs to be done by the user of it.
but thatās boring!
I donāt think we should add advanced features like that to the HSAPI itself ā that would be a different project built on top of the HSAPI, which should just be a base to build projects that interact with hopscotch projects with.
You go ahead
Itās probably a good idea to keep the topics separate, since not everyone interested in the HSAPI would be interested in hopscript and vice versa
yes rawrbear gave good points for that too, +1
indeed, plus itās nice for organizationsā sake
Not an issue for me! I already have a Hopscotch GitHub if you need to look over it:
Yeah, that sounds really nice. We should definitely do something like that with block iterators, it sounds immensely powerful in general!
Anyways, Iāll go ahead and make the topic then - will just outline a basic pitch with some ideas for people in the OP, since weāre still thinking about this API lol
Thisāll take maybe 10 minutes or so to write hopefully!
Yes definitely ā being able to iterate over every block in the project is exactly the kind of feature that would be very useful, but currently requires some more detailed understanding of the json format than it should
youre completely good, i just needed a minute to take a look at what had been done in the past on the forum and weāre well within the guidelines to my knowledge :)
@Petrichor you should totally add the hopscotchification tag to the topic once I make it :D