Add Event sequences & "cutscenes"

-Please note this is currently a draft PR and will be updated when ready for review.-
I'm anticipating two review cycles: one to verify preliminary event design (see comment at the relevant issue and another to verify the full change list implemented by this PR.
Please check if the PR fulfills these requirements:

[ ] The commit message follows our guidelines.:
[ ] You tested the changes.

Related issue: 211
What kind of change does this PR introduce?

Added Events, objects easily extended with Godot's node/script system that allow modifying the field game state. Examples include dialogue, adding an NPC, changing map tiles, etc. I'm planning on two specialized types of Event:

Triggers, which are objects placed directly on the gameboard that are "triggered" by a collision object (Gamepiece) moving onto them. Explicitly tracks which gamepiece triggered the event.
Interactions, which are Events attached directly to a Gamepiece that are activated by "interacting" (for example, press space or the A button) with the gamepiece from a neighbouring cell. Explicitly tracks the parent and interacting gamepieces.

Added a simple MusicPlayer that makes it easier to play a given background track.
Documentation: small updates & new features

** TODO: remaining features before PR **

[ ] Popup icons (illustrate important NPCs/Events, etc.)
[ ] MusicPlayer::crossfade()
[ ] Dialogue via Dialogic2
[ ] "Cinematic" events that pause input/controllers while they're executing (to prevent wandering off). Only one at a time. Event queue needed?
[ ] After a review, full documentation and a demo scene incorporating more complex events.

Does this PR introduce a breaking change?
No, should be focused on adding functionality.

Thanks so much once more for your work! Regarding review, you mention needing a round on the events system code. Would you like it at this stage already or would you like to do some more work before we give you feedback?

Sure! Note taken, we'll wait for you to tell us when you'd like a review.

Good day,
I think I have a little scene that should suitably demo events now. The demo scene itself is hacky; it is just meant to demo the event scripts. In particular I'm looking for feedback on the event objects, though feedback on everything else is welcome also.
The flow of the demo is as follows: click (or move up to and then press 'SPACE' to interact) the guy blocking the road and he'll move out of the way. Walk over the key to pick it up and then walk up to and interact with (via WASD and the SPACE bar) the locked fence. Once that's out of the way, you can move over to the exit.
What I'm trying to demonstrate is how events are nothing more than fancy physics objects that can and should be extended by scenario designers to perform more complex tasks. With this in mind, an event is designed to be Godot-y and GDQuest-y as it is nothing more than a scene that can be attached to Gamepieces, TileMaps, nothing at all, etc. The various events in the demo make use of Godot nodes to control the flow of the map.
There are two subclasses of events: interactions (which can be interacted with via SPACE or clicks/touches) and triggers (which are triggered by Gamepieces walking over).
Please let me know what you think. Once we've got this wrapped up I'll try to finish off the milestone with Dialogic 2 support. Also, I'll come up with a cleaner demo scene to show off events in a more polished fashion.
Thanks again.

Just so you know we are going to an industry event on Sunday so we are busy preparing for it but I took note of your progress and added the review to my to-do list. We will do it as soon as possible.

Very good work! I like the demo; I found it a bit difficult to understand the level of feedback required at this stage. Is the demo representative of the kind of interactions desired in the end result? If yes, it seems to me that your implementation could be simplified.
A few generic impressions and questions:

Naming is a bit confusing. I kept looking for how an Event replaces a Signal, and it took me a minute before realizing that was not it. By Event, you mean an EventObserver or an EventListener.  Something that, under the correct circumstances, will trigger an event. Similarly, what you call an Interaction is something that will trigger an interaction, etc. This is a bit confusing. The names we landed upon internally for those things are Interactable, Trigger, and Pickable . An event is something that "happens" when an Interactable triggers. "Interactable" is a bit of a mouthful, for certain, but it does get the meaning across.
Are we considering the case where a key to a door is in a different scene (and therefore the key has no access to the door)?
Are we considering the case where a key can open any door of a certain type, but then gets consumed (Zelda-like)?
Are we considering cases with multiple potential interactions, or will we always pick the one the player is turned towards?
Why is "CinematicEvent" part of the Interactable? It seems like it should be part of an autoload or the board manager. I'm not clear on why calling cinematic_mode_enabled can't be something called from an interactable on the GlobalFieldEvents, when needed. I'm also not clear on the need for the intermediary CinematicEventHelper object. Is this object only for awaiting for all pieces to reach their destination? If yes, then I would propose it should be a generic "await_all_pieces" function attached to GlobalFieldEvents, or be renamed to something suggesting the function better than "helper".
What are interaction groups for? Do you see them serving a later purpose?
Why can Interactables be turned off and on? Do you envision a need for this?

I can follow up with more feedback depending on the answers, especially of 2, 3, and 4.
It seems to me that you can simplify the way you do the interactions and still check all the same goals you currently have (but maybe not if there are future goals not demonstrated).
I've written a quick example here https://github.com/GDQuest/godot-open-rpg/tree/temp-branch-for-demonstration
You might want to look at this repository, written by a collaborator for a yet unreleased demo: https://github.com/Ryan-Mirch/Interactables-Demo, which tackles the same area of problems.

Is the demo representative of the kind of interactions desired in the end result?

My apologies, I have probably caused some confusion. My intention is to create the groundwork needed for any "kind" of interaction that would be implemented down the road. I wanted to keep it as simple as possible, so most of the interaction code

A few generic impressions and questions:

Naming is a bit confusing.

Noted, I'll run with these. I'm not a huge fan of the alternatives but I can't think of anything better that doesn't overlap engine features/programming paradigms.

Are we considering the case where a key to a door is in a different scene (and therefore the key has no access to the door)?
Are we considering the case where a key can open any door of a certain type, but then gets consumed (Zelda-like)?

No, not yet. In my mind that is outside the scope of this demo. I think it's application specific and its implementation is left to the designer. The only point of the key/lock relationship was that I wanted to demonstrate how scene-based interactions can easily communicate and change one another's state.

Are we considering cases with multiple potential interactions, or will we always pick the one the player is turned towards?

In my mind it makes most sense to search for the top pickable interaction that the player is facing. I think that is expected behaviour with a gamepad/keyboard. Touch may be a little different, but that would require minor changes work correctly. That functionality should be included in this particular release.

Why is "CinematicEvent" part of the Interactable? It seems like it should be part of an autoload or the board manager. I'm not clear on why calling cinematic_mode_enabled can't be something called from an interactable on the GlobalFieldEvents, when needed. I'm also not clear on the need for the intermediary CinematicEventHelper object. Is this object only for awaiting for all pieces to reach their destination? If yes, then I would propose it should be a generic "await_all_pieces" function attached to GlobalFieldEvents, or be renamed to something suggesting the function better than "helper".
What are interaction groups for? Do you see them serving a later purpose?

The main point here is that it seemed good to me to have some interactions that "take control" of the application and some that keep happily on their way in the background. This may introduce complexity we don't want, since it implies concurrent interactions.  I would hesitate to make the "cinematic mode" capability global, as only interactions should be doing so, in my mind.
The point of the groups was that I had been thinking active interactions will need to be paused when combat starts and resumed when it finishes. We would need a way to grab active interactions and pause/resume them and groups seemed the easiest way to do so.
It may be a better idea to have an event queue and only allow one event to run at a time. Thoughts?

Why can Interactables be turned off and on? Do you envision a need for this?

I think this would be useful. Consider a designer wanting to drop a "spawn point" into a scene but it shouldn't activate until later in the game. You could either create the node at runtime and have it appear when you need it or you could drop it in during map design, disable it, and activate it when the time comes. I prefer the latter for a few reasons:

I think it enables elegant design. In my mind adding nodes at runtime is more complex (error prone) than baking it into the structure. I don't think that the designer shouldn't have to keep track of what will appear down the road.
The interaction is visible in-editor. In my mind this helps with blocking out a map.
It makes re-using events easier. Just toggle them on/off rather than freeing/new-ing similar interactables. They certainly don't have to be reused, but think that I can think of interactions that would benefit from it.
There may be drawbacks or other perks I haven't thought of. What are your thoughts on the matter?

It seems to me that you can simplify the way you do the interactions...
You might want to look at this repository, written by a collaborator for a yet unreleased demo: https://github.com/Ryan-Mirch/Interactables-Demo, which tackles the same area of problems.
I can follow up with more feedback depending on the answers, especially of 2, 3, and 4.

Thanks. I'm going to revisit this ASAP, so I'll take a look through the other projects and, if you had any more features/ideas to simplify things I would love to incorporate them at that time.
Thanks for the review, this is what I was looking for.

[...] My intention is to create the groundwork needed for any "kind" of interaction that would be implemented down the road.

That doesn't really work well imho.
Warning: pontificating paragraph with Strong Opinions:registered: ahead.
There are two ways of making something modular:
The first is implementing provisions for hypothetical future requirements. The proper way of doing this is by defining an extremely solid API with enough flexibility to allow for novel usages, and enough discoverability so people can use it. In practice, this often means a few hundred lines of code for sorting items by arbitrary values can be replaced in your specific game with items.sort_custom(func (a, b) -> a.weight < b.weight). There may be many occasions where the framework, no matter how flexible, does not allow exactly what you need even.
In other words, in this first option, you're accruing an enormous amount of complexity, maintenance burden, tech debt, code branching, bugs, innefficiency. Its very rarely worth it. It's worth it when you're either abstracting very complex code (physics engine), or offering new data structures that can be plugged into each other (a hashmap).
But often, it's better to consider the code itself as your API. Godot is already providing you with a very versatile framework. Giving a user items.sort_custom(... is many times easier for them to understand and change than a 200 LOC framework. It is objectively more flexible too.
So, the second way of making something modular is to make it strictly as inflexible as conceivable. Through simplicity, modularity is achieved; rewriting a line of idiomatic code is many times simpler than understanding a newish use-once-and-throw spec.
This was a long preamble (sorry) to say: I would much rather you define a narrow set of behaviors you actually do want to implement, and write the simplest code that achieves that.

I'm not a huge fan of the alternatives but I can't think of anything better [...]

Same here! You're welcome to propose something.

The main point here is that it seemed good to me to have some interactions that "take control" of the application [...]

Fine, that sounds fair. I agree with your take.

The point of the groups was that I had been thinking active interactions will need to be paused when combat starts and resumed when it finishes. We would need a way to grab active interactions and pause/resume them and groups seemed the easiest way to do so.

I feel like this is premature. I suggest crossing that bridge when we get to it. My reasoning is:

We might never have combat while an interaction is happening (in most traditional games, those two things are in areas that don't intersect)
We might have combat as an interactable (even if randomly spawned). In this case, there may be a general need for waiting for interactables to finish, which may happen by registering to some global manager so no two events can overlap ("event queue", as you suggest).

I don't mind too much the groups, they aren't adding that much complexity; I just don't think they are necessarily the best way of tackling this (as of yet, hypothetical) problem.
Instead of an event queue, we might just register and deregister one event when it starts and ends, and if the player tries to trigger another, we display a "no" icon or play a bleep sound. Not all events would consult that registry (for example, pickups maybe don't need to and can continue running).

Consider a designer wanting to drop a "spawn point" into a scene but it shouldn't activate until later in the game

Yup, good call. I'm down for enabling/disabling.

the main difference in architecture at the moment is that the demo handles management/picking via autoload whereas the OpenRPG delegates that to the player controller.

From experience, having a global handler to delegate interactions to often ends up being a better option because there's often external, global information you'd want to know in order to know what to trigger. Examples:

Overlapping Interactables (which one to pick?)
Triggering the interactable the player clearly meant, because it's an important one, over the one they're turned towards, even if it'd be the correct action
Needing to access other globals (eg, UI timer when switch is triggered, tutorial prompt "press X to interact")
Needing to access some global state to know if an interaction is valid or not (are we in a cinematic mode?), and maybe act differently depending on that state (show a UI "skip" prompt)

I'm not suggesting it's the only solution or even appropriate for the current demo, but just to consider the option going forward.

I had been thinking that the CinematicEventHelper would handle the actual implementation of cinematic event. Now that I think about it that's probably what you were thinking would become an autoload. Is that correct?

It really depends on what kind of cinematic event you're envisioning and how they are implemented tbh, so I will not expand on this before having a better idea of what you're aiming for.

In reference to my opening paragraph, I would suggest to determine a scenario for the MVP, in bullet point format. Something like:

Player picks a key
Player enters a fight (fight can be auto-resolved and implemented later)
Player opens a chest and gets a key
Player enters a house; cinematic event is triggered and we see two characters arguing
...

Trying to nail all the basic interactions that are necessary. The interactions, dialogues, graphics, etc, can be implemented as simply as possible, but the list should be relatively comprehensive and demonstrate all the interactions.
We don't need to go ahead and implement all, or maybe any of them; but they will guide the decisions regarding how to slice this cake (who has the responsibility to do what; autoload vs instance; etc).

I'd like to do two things here. I'll write a response and then write a second post to try to shape the MVP.

That doesn't really work well imho...
...This was a long preamble (sorry) to say: I would much rather you define a narrow set of behaviors you actually do want to implement, and write the simplest code that achieves that.

Makes sense to me, I think my initial struggle is understanding what particular elements should be simpler (i.e. the whole system? The 'cinematic mode'? The reliance on a PlayerController?). I'm still trying to wrap my head around that slightly, so I'll do a rework based on your above writeup as well as the demo(s).
How ready is Ryan Mirch's interactable demo? If the GDQuest team is relatively happy with where it stands, I would consider porting the "inheritance" model to 2D and add any attribution required and requested. I'm perfectly happy to let someone else's code solve the issue.

We might never have combat while an interaction is happening (in most traditional games, those two things are in areas that don't intersect)

There are a couple of options. At this point I'm not sure what is best:

End active interactions on combat start. This is probably the simplest. Interaction execution would need to know to break when starting combat. I think you would then want the combat object (whatever that looks like) to have an on_loss/on_victory script/interaction that picks up afterwards, if necessary.
Pause currently active interactions on combat start. This is (much?) more complicated but allows for persistent, concurrent interactions.

We might have combat as an interactable (even if randomly spawned). In this case, there may be a general need for waiting for interactables to finish, which may happen by registering to some global manager so no two events can overlap ("event queue", as you suggest).

That's an interesting idea. I had originally been thinking that combat itself would be a scene and the designer could be a scene per enemy formation/background. I presume a combat interaction would just hold "combat data".

Instead of an event queue, we might just register and deregister one event when it starts and ends, and if the player tries to trigger another, we display a "no" icon or play a bleep sound. Not all events would consult that registry (for example, pickups maybe don't need to and can continue running).

This is probably the answer for 'cinematic_mode'. I might rename that to just cutscene, as I think that's less wordy and more ubiquitous in the industry. At any rate, you only want one running at a time, though it is conceivable that two or more could activate at the same time and we would need to either queue each or drop all but the first. I'm still on the fence here.

... but just to consider the option going forward.

It really depends on what kind of cinematic event you're envisioning and how they are implemented tbh, so I will not expand on this before having a better idea of what you're aiming for.

The only criteria for a cutscene in my head is:
a) exterior stimuli (controllers, signals, etc.) are ignored
b) has a definitive start and endpoint.

In reference to my opening paragraph, I would suggest to determine a scenario for the MVP, in bullet point format.

I'll do this in the post below.

Regarding the MVP, I'm not entirely sure about scope, but I would like to try to capture a handful of basic (polished!) features expected in a JRPG. I feel that some of these are typically overlooked in tutorials since they involve game state and persistence.
MVP rough outline:

Brief intro (text, maybe pictures over black screen) to scenario
Reveal screen, characters walk in, quick line of text introducing character to scenario.
Player finds a chest with a key inside
Player uses key in lock to travel through door.
Player travels to the next area.
Player finds a 'monster' blocking the exit. Has a brief conversation before entering a mock combat/victory state.
Player can now walk through path to exit.
After player exits, run an event BEFORE screen fades to wrap up scenario.

I'm assuming that interactions will still be physics-based components as already designed. There are a few "interaction types" going on here:

Interactable, run when clicking or pressing the interact key
Trigger, run when a corresponding CollisionObject2D arrives at its cell.
Script (of some sort) that can be run when entering or exiting an area, losing or winning combat, etc.

Probably should be able to call these arbitrarily, event from other interactions. As in scripted_event.run().
Probably should be able to be cutscene/exclusive, also.
Probably should be scenes in order to build the same way as Triggers/Interactables. Do NOT need to be derived from Area2D. Therefore, if these are all related. Triggers and Interactables could derive from here and have collision info added in their own scenes. The advantage to this is that any common functionality needed by interactions (e.g. change music, get player character, start combat, etc. etc.) could then be applied to the base class rather.

I anticipate a few often-used subclasses:

Lootable extends Interactable: treasure chests!
Pickup extends Trigger: adds item to inventory and disappears.
MapExit extends Trigger: fade out, move to destination area, probably have an on_exit script that can be run before the transition

Changing the map scene is a significant chunk of code. I don't see any reason to wait to implement it however.
Changing to and from the combat state is also pretty major. This isn't a bad time to add in the system structure, but it would be quickly auto-resolved.
As mentioned, we might not get to all of the features at the moment. I would anticipate two pull requests here: one with the interaction implementation and some simple interactions and one with changing maps/demo combat. I would like to wrap up the interaction implementation next. We can always discuss game state next.
Would you change any of this? Thanks so much for your time, I hope that I can get this in good shape without bothering you too much more.

I think it's a very good next step.
I am not bothered at all, it's a pleasure working with you, no worries and feel free to ping as many times as you like.

How ready for use is Ryan Mirch's interactable demo?

This demo is part of a new resource we're developing with recipes; the principle isn't to use the demos as they are (though it's certainly possible) but to get inspired and implement something more specific. That's why we provide different competing implementations for each mechanic.
To answer the question more directly, I've reviewed the code and I am personally satisfied with it, but it was written in a nebulous vague context that isn't specific to any game, so I'd invite you to be inspired, rather than use outright; maybe scavenge some parts.
At the moment, if there's no issue with centralizing the interactions in the player, then there's no issue, so I'd say to keep it as it is. I only showed this repo to compare and contrast details. Feel free to use any amount of it, including none.

I presume a combat interaction would just hold "combat data".

It could remain a scene, yea, but we need some sort of trigger. I figure, some combat scenes (story ones) will be triggered by conversations or entering rooms anyway, so we'll need the CombatTriggerer interactable either way, even if random encounters are based on a timer/probability per step or something.
I personally also prefer visible encounters that can be avoided (which would be interactables too) but that really depends on the type of game you have in mind.
Since your scenario includes a visible, triggerable encounter, I think we're on the same general wavelengths.

Script (of some sort)

I've never tried this pattern, but do consider that you can have an expression in a textfield and/or a "runscript" field in which you could directly write some GDScript.

(Quick Pseudocode example)
var _expression := Expression.new()
@export var expression_str := "":
	set(value):
		var error := _expression.parse(value, ["arg_a", "arg_b"])
		if error != OK:
			print(_expression.get_error_text())
			return
		expression_str = value

func exec_expression():
	var result = _expression.execute("foo", "bar")
	if not _expression.has_execute_failed():
    print(result)

# or with a script

var _script := GDScript.new()
@export var script_str := "":
	set(value):
    var lines := ["func run(arg_a, arg_b):", "  var result = null"]
	  lines.append_array(Array(value.split("\n")).map(
			func (line: String) -> String:
				return "  "+line
		))
    lines.append("  return result")
		_script.source_code = "\n".join(lines)

func exec_script():
  var instance = _script.new();
  if not instance.has_method("run"):
    pusherr("oh noes")
  var result = instance.run("foo", "bar")
  print(result)

@NathanLovato did you ever try something like this? I imagine it ends up being problematic at scale but maybe a lot of ad-hoc scripts gets also unyieldy.
At first sight I don't like this but it may be worth considering if you intend to have ad-hoc specific one-off triggers. I'm not sure if that is what you meant.

In general, I think your scenario and plans to implement changing scenes and combat sound and appropriate. Feel free to go ahead, and thank you for the excellent work!

@NathanLovato did you ever try something like this?

No but I wouldn't attempt this either, letting users input a string in a field. Note that Expression only supports basic math operations, it's not related to GDScript.
For this project, I'd say just let people write a GDScript file for every event sequence. If something comes up a lot and is too tedious to repeat with GDScript, then I'd say you can have predefined nodes, scenes, or resources with a couple of exported variables.

Regarding node naming, would Trigger (base class), ContactTrigger (triggered by movement), and InteractionTrigger (triggered by 'interact') make sense? The idea with "trigger" is that it is usually "triggered" via some kind of external stimulus.
Or perhaps something like Triggerable (base class), Contactable (movement), Interactable (interaction)?
Clear and unique enough? Too verbose? I wasn't sure if they should be unified (as in, KinematicBody -> KinematicBody2D). I'm probably overthinking this.

Regarding node naming, would Trigger [...] or perhaps something like Triggerable [...]

I think both are fine yea, they seem to explain adequately the purpose for me.

Another quick question, do you have any experience with Dialogue Manager? Do you have a preference between that and Dialogic?
The reason I ask is that Dialogic 2 is still in alpha and some of the core features are changing while I'm putting the demo together. It would be nice to have something stable.
The other issue I gather is that Dialogue Manager is simpler. From a quick playing around with the plugins I get the impression that it would be easier to move Dialogue Manager -> Dialogic 2 than the other way around (if Dialogue Manager was deemed inadequate someday down the road).

I don't personally have a very strong preference towards one or the other.
I tend to think that if you want to diverge from natural/native systems to the framework, going Dialogic, which is expansive enough to be its own framework, is better than doing something half-half, that limits you somewhat for the benefit of a relatively small increase in readability.  "Go big or go home", etc.
But I'm ok with either, it's fine also to experiment a bit with each before choosing.

I'll comment a little bit about Dialogue Manager and similar approaches
For an RPG I worked on, I similarly created a DSL for dialogues that designers could use. It was so similar to what's shown in the screenshot of Dialogue Manager that I had a moment of disbelief when I opened the repo, "wait, did I release this and forgot?" kind of moment.
(I found a very early iteration of the language design story_examples.pdf)
But, it turns out, dialogue ties into everything in the game. As the designers worked, they asked for more and more functionality; being able to pop up an inventory; being able to give an item to the player; giving an item, but only if the player doesn't already have it; check if the player has enough encumbrance to accept the item, and if not drop it to the ground; start combat mode; start combat mode if some quest isn't done; trigger quests; trigger achievements...
As I added all those things, my DSL was starting to not be so small anymore, and becoming more and more generic. Taking a step back and squinting, I realized I had made Lisp all over once again (but with whitespace instead of parenthesis).
TL,DR: in the end, capturing this DSL in GDScript directly without the parsing and tokenizing step made things easier on everyone. Here's how it looks:
extends Dialog

var merchant := make_actor("merchant")
var wolf := make_actor("wolf")

func start_merchant() -> void:
	acting(merchant)
	say("hello, what do you want to buy?")
	say("I've got weares if you have the coin")
	if visits("start_wolf") > 1:
		say("I see you met the wolf, I'll make you a price")
		merchant.set_meta("special_price", true)
	say("do you want to talk, or buy?")
	choice("buy", "see_merchant_wares")
	choice("talk a bit", "merchant_talk")

From experiences, non-coders designers who used this had no trouble at all. They made less mistakes thanks to statistical analysis and overall worked just as productively.
The way it works is: declarative functions send out signals. UI captures those signals and displays the appropriate elements. Each visited function increments a counter, so things like visits("start_wolf") checks if the counter for the method "start_wolf" is higher than 0.
The benefits over a DSL:

not having to maintain a parser/tokenizer/error messages/etc
full access to everything: node tree, autoloads, UI, etc without any wiring
you get in-editor autocomplete for game classes and objects
can easily be extended to add new functionality, just subclass
you get statistical errors in case of typos
you can reach in and call any method of the dialogue if you need it for any reason (trigger a quest marker through alternate solutions; play a demo; ...)

I don't have access to that source anymore, but here's one old iteration packaged as a plugin (for Godot 3.1):
godoversation.zip
As a side note, this also implements my architecture for quests, which was stolen inspired by This talk by one of Inkle's co-founders. The way it works is as such:
Every time a node is visited, its counter is augmented by one. And that's it! That's the whole framework.

Want to check if the player heard about the dragon? Check if nodes_cache.heard_about_dragon > 0.
Want to know if the player harassed the merchant? Check if nodes_cache.merchant_start_conversation > 50.
Want to track if such and such quest is on? for quest in quests: if nodes_cache["quest_"+quest]: ...
Same for subquests

Each node also dispatches a signal when visited, so you can use that to pop toasters ("started quest so-and-so") or track achievements, etc.
Since a dialog is just a resource with methods, you can also create non-dialogue nodes to track events; eg, visit the node "wolf_killed" upon killing the wolf.
Finally my TL, DR about Dialogue Manager is: yea, why not, but I find this a little bit more cumbersome than just GDScript. Whereas Dialogic is very cumbersome, but is more balanced because it also offers an actual divergent way of treating dialogues.
Last note: If the GDScript API for dialogues works well, it's possible to imagine a simple regex-replace transpiler from something close to GDScript; eg:
# start_merchant → func start_merchant() -> void:
@merchant: "hello, what do you wanna buy?" →   acting(merchant)\n  say("hello, what do you want to buy?")
I'm not insisting on anything though, specially in the context of making a smallish demo, so if you feel comfortable with Dialogue Manager, by all means go for that.

Thanks for putting the time into writing that, I really appreciate it. That's a goldmine of info. I enjoyed the example and the talk as well.
Sorry that I've been so slow, school's much busier than I had expected. I am still working on it all, though!

I’m excited to see this get merged in eventually. If you need any help with this, let me know!

I’m excited to see this get merged in eventually. If you need any help with this, let me know!

Thanks! I've just wrapped up an intensive two months' sprint, so I'm hoping to get back at this on Tuesday. I also am excited to see the final product!

The Turn base Project is Replaced?

The Turn base Project is Replaced?

up

@mhuelreyes it's difficult to answer without context, but this is a Godot 4 remake of open RPG. Any other code or project you might be referring to is likely open-source thus will always be available. And this is a new open-source demo, for Godot 4.

@mhuelreyes it's difficult to answer without context, but this is a Godot 4 remake of open RPG. Any other code or project you might be referring to is likely open-source thus will always be available. And this is a new open-source demo, for Godot 4.

Im confused too. when I click the turn-base link in your YTvid its always redired it to this gitproject :(

@mhuelreyes videos can end up really outdated. You likely clicked a video that's several years old, and if so, the video is likely obsolete by now.

yhea,.. hopefully you will make an update godot 4 turn-base some day god bless thanks for your time :)

Just a quick update because I'm having fun with working dialogue:
https://github.com/gdquest-demos/godot-open-rpg/assets/112480409/99d258d3-29d7-4a93-b9f7-614d3b1753f5

Thanks for sharing! Great progress there :)

I've updated the OP with a revised feature list and continue making very slow (but sure) progress. Hopefully it's not too ambitious.
A quick question on design philosophy: I've got a series of objects (for example, battle results, interactions, various shops, etc.) that want to modify the player's inventory. Or perhaps it's a set of objects (for example, the combat state or an interaction) that want to change the music. In these cases there is a MusicPlayer or PlayerInventory somewhere far off in the scene tree. How would you propose going about this?
I could use an "inventory/music signal bus", except then ANYTHING could change the music/inventory. Which could be interesting or messy. I could also look at injecting dependencies but then you naturally have more tangled code. Should I be thinking of another approach?

All methods are good, as long as they are clear and fulfill the contract! Go with whatever you feel more comfortable with.
I'll still have a few thoughts below:
I personally do not have issues with "everything having access to data". My experience with that is that private/public and other methods to limit access are a hindrance.

(open for more personal thoughts here)

I like pseudo-private variables with a starting underscore (like in Godot), which tell you "you probably shouldn't be using this, but hey, maybe you need it".
I understand that in very large organizations with many developers, one may feel the need to force people to not access some piece of data, but to my eyes, needing this at all is endemic and a sign you lack both documentation and code review (it also slows development tremendously while a developer waits a week for a higher-up to "unlock" the data they need through a PR).
I am also not against having globals, when they need to be globals. If everything needs access to a data blob (e.g, the inventory) and that blob is indeed always there, then I have no philosophical qualms with that.
I am however not in favor of putting layers of indirection between dependencies and "pretending" the inventory isn't global, when it is indeed accessed by many objects that do expect it to exist and to be accessible. That is essentially a global, but obscured and made less clear only to make it look like it is not one.
For example, having a signal bus that talks to a single inventory is potentially just a global with extra steps.
Good reasons for not making something global:

It is not guaranteed to be present (then making it a global would be making a false promise)
There are more than one of it (then it would be easy to mistake it with another)
Only few items have access to it (then making it global could be implying many things have access to it)
Logistics (for example, we want to be able to run a scene with a specific inventory for testing)

TL,DR: I try to only think of systems in terms of pragmatic use, with two main operational questions: What does this architecture "say" about itself? and: Is my current tooling requiring me to use such and such architecture for technical reasons?
I reject all "best practices" and "rule of the thumb" other than textbook cases. They apply in a lot of cases, but there are even more cases where they don't; in conjunction with other parameters (other systems with different requirements), they end up never applying at all.

In your case, would simply have globals and let systems talk to them.

For everything that does not require access to the tree and no signals: I would use a class with static variables and functions

In Godot 4.2, classes can be static and have variables, so true static classes are possible.
class_name GameData

static var PROFILE_NAME = "default"
static var player_name := ""
static var health := 10

static func save() -> void:
    var file := FileAccess.open(get_profile_path(), FileAccess.WRITE)
    file.store_var({
      player_name = player_name
      health = health
    })

static func load() -> void:
    if FileAccess.file_exists(get_profile_path()):
        var file = FileAccess.open(get_profile_path(), FileAccess.READ)
        data = file.get_var()
        player_name = data.player_name
        health = data.health

static func change_profile(profile_name: String) -> void:
	if PROFILE_NAME == profile_name:
		return
	PROFILE_NAME = profile_name:
	load()

static func get_profile_path() -> String:
    return "user://profile-%s.data"%[PROFILE_NAME]

caveat: no signals can be dispatched from static classes

For everything that requires access to the tree (such as music player): I would use an Autoload

If I have multiple autoloads that depend on each other, I would nest them inside a parent Autoload (it's difficult to control the loading order of autoloads, but not that of an autoload's children).

For everything that requires serialization (such as inventory): I would use a resource

I like to use resources instead of global classes whenever convenient, because they give me serialization for free, but also because I can explicitly require it in all items that require it
Like:
class_name GameData extends Resource

static var PROFILE_NAME = "default"

signal health_changed()
signal died()

@export var player_name := "":
    set(value):
        player_name = value
        save()
        emit_changed()

@export var health := 10:
    set(value):
        health = max(0, value)
        save()
        emit_changed()
        health_changed.emit()
        if health == 0: died.emit()

## Saves the current resource to disk
func save() -> void:
    ResourceSaver.save(self, ProfileData.get_profile_path())

static func get_profile_path() -> String:
    return "user://profile-%s.tres"%[PROFILE_NAME]

## Loads the resource. Godot caches calls, so this can be used every time needed.
## This function will create a new profile if one wasn't found
static func restore() -> GameData:
    if not FileAccess.file_exists(GameData.get_profile_path()):
        var new_data := GameData.new()
        new_data.player_name = "Player"
        new_data.save()
        return new_data
    var data := ResourceLoader.load(GameData.get_profile_path())
    return data

Then, in Player.gd, I can do:
class_name Player

var data := GameData.restore()

func take_damage() -> void:
  data.health -= 1

func _ready() -> void:
  data.died.connect(do_something_about_it)

Or in UI:
class_name HealthUI

func _ready() -> void:
  GameData.restore().health_changed.connect(do_something_about_it)

But, if you prefer not using globals, and passing dependencies explicitly, it doesn't need to be very tangled. You can export Node types, or Resources. For example:
@export inventory: Inventory

You can then either the player inventory to all items that need it.
If a node is created at runtime, then the factory would have an exported similar value, that it passes to the instances it creates.
The benefit of explicit declaration is no magic identifiers (though you do also get that with the Resource pattern described above), and easier to test (it's easy to pass a different instance, or to test an enemy on their own without having to also load the global).

Thanks @Xananax for the response, as always. I am helped by both the philosophy and implementations.

Hello, I would like to assist and help out however I can.
Currently I have been looking over the latest commit on the repository and see a few things I can implement, but I also see in this pull request you have a few more things implemented that I can't access.
Would it be best to start on something tangential to your efforts or would you be open to collaborating on getting the event system done?

@cantdoright please note that there has been a long conversation to align vision and goals before getting to this PR, so it might not be so easy jumping in. Therefore, answering your question is difficult without more information. If you disclose details, it will help @food-please and me assess if your contribution would fit contextually.
I would favor you opening either:

An issue explaining your goals and intents
A PR based on this one (create a branch from this branch)

1 is better than 2 so you avoid doing any heavy work that wouldn't be pulled in.
Alternatively, if your changes are explained in a short text, feel free to comment here directly.

1 is better than 2 so you avoid doing any heavy work that wouldn't be pulled in.

Just wanted to echo that this could be helpful. I'm hopefully on the tail end of this iteration of the milestone (which will, ideally, see aligned vision, etc.) but I'm waiting for a break from classes to wrap it up.

I think that I've mentioned this before, but this update is a handful of re-usable scripts that are easily extended to create the different in-game events. I have a few things left to wrap up before submission, since I'll probably put off cleaning until later. I'm expecting to have a fake area transition and a puzzle, and that should be the demo.
My goal is to show off how easy it is to create puzzles/dialogue/etc., which I think was sorta buried in the previous demo.

Well, this is kind of exciting.
After ~6 months and dozens of hours of work I think this is ready for review. I have done a complete rewrite since this point, since I wasn't happy with the direction things were heading and the demo needed more context to make sense, I think.
I want to emphasize that this release serves to demo Cutscenes, and so the scenario would probably change to something a little more serious (and coherent?) for the final demo. I've tried to incorporate the feedback in the above conversations to produce code that is much more independent and maintainable and I'm pretty happy with how it's coming together.
What is this release?
Cutscenes!

3 main classes: Cutscenes (see OpeningCutscene at the bottom of the scene tree), Interactions (i.e. press space to chat/open chest/whatever), and Triggers (such as transitioning to a new game area).

Please note that I've approached these with the philosophy of Cutscenes plopping into the scene tree (and interacting with other nodes) in as "Godot-y" a manner as possible.

5 commonly used template cutscenes:

Conversations, implemented via Dialogic 2
Simple pickups, which the player receives in their inventory when moving onto the same cell.
Treasure chests. They can be closed afterwards, which I'm pretty happy about.
Area transitions, which smoothly transport the character to a new game area. Please note that this currently happens within the same scene. I expect that we will want a "world" update of some sort that deals with loading/freeing areas and moving the player to matching "portals".
Lockable doors, which are a complex scene created from a variety of triggers and interactions.

A variety of inherited scenes to show how specific game behaviour may be derived from Cutscene/Interaction/Trigger and implemented quickly. See, for example, the StrangeTree in the town or the WandPedestals in the house.

3 small areas to explore! Please see the note under "area transitions" above. This model will change in future releases.
A variety of small classes:

A WIP inventory. The overarching model (and manner of accessing the inventory via code) will probably stay the same, even as the implementation changes. At the moment, it serves to demo Cutscenes and so I thought it made sense to include it as a "first pass".
A simple music player
Screen transitions (both simple fade and texture based)

There are a few minor tasks to be done before merging with main: I would like to change the app icon, mouse input may need to be adjusted slightly, and I thought I would add a few comments where there is confusion. I'll be able to better do these things after review, however.
I know that you're all crazy busy, but I hope that you enjoy playing through the demo and that there is not too much code to go over. I'm looking forward to the combat update, and I think this gives a really good launching point.

Very nice! I played the demo, the dialogues are fun. It could stay like this, with the 2nd degree and programmer in-jokes, I think it works perfectly well for a demo.
From a quick overview it seems like I wouldn't have much to change, I'm mostly asking questions as you'll see.
There are areas that I might ask you to change structurally, mostly for the sake of simplification, but I am not sure the simplification is truly simpler without having a more complete picture, so doing it now may hinder progress or force roundabout solutions. I would rather do a simplification pass at the end.

Very nice! I played the demo, the dialogues are fun. It could stay like this, with the 2nd degree and programmer in-jokes, I think it works perfectly well for a demo.

Thanks! I had fun filling out the little town. I think I would like to make it more JRPG-like for a future demo, but that's a bridge to cross when we get there (hopefully before Godot 5).

From a quick overview it seems like I wouldn't have much to change...
There are areas that I might ask you to change structurally, mostly for the sake of simplification... I would rather do a simplification pass at the end.

Feel free to let me know whatever you think could be simplified. I find that, more often than not, when I explain myself I find out that my reasoning wasn't very good. I've really enjoyed some of the more simple paradigms that have come out of this project (I like the way the inventory works! Looking forward to a save/load update).

Note: I couldn't make Dialogic work in the editor (it ran in the game without problems). I'm not sure why. It isn't very important for now, but there may be subtleties I missed because of that.

That's a deal breaker. I check it before writing you here and it works on my end. I clone the project and open the project file once. It throws a pile of errors. Once it's fully loaded I close it, wait a sec, and reopen the project. This time there should be no errors (though there is this pesky rid bug that I haven't been able to get rid of quite yet), and if you look in the project manager the Dialogic plugin should be enabled. At that point, I can see the "Dialogic" tab in the tab group at the top (i.e. "2d" "3d" "Script"... "Dialogic"), and clicking that opens up the Dialogic manager. I haven't fully figured out all of Dialogic's features yet. Hopefully this is a good start.
I think that I've resolved all the points above, so I'll wait to hear back from you on how to go forward.
Thanks, appreciate all the feedback.
One question: I'm not sure that mouse/touch input works well for this project. I find navigating the field to be a little clunky. This kind of movement seems, to me, to best suit controllers/keyboard. Do you think we should try to maintain mouse support?

One question: I'm not sure that mouse/touch input works well for this project. I find navigating the field to be a little clunky. This kind of movement seems, to me, to best suit controllers/keyboard. Do you think we should try to maintain mouse support?

Mouse and touch can work very well for this kind of game, it's just a matter of adding a couple little things. You can leave it as-is for now and we can take care of adding the missing bits later if you'd like.
Regarding Dialogic, same issue as always with many Godot plugins: on first load of a project they fail to run as their code runs before project resources have been imported. It's okay, it's a Godot limitation, and it's going to be an issue with any dialogue editor you would use. It can be worked around, but it's generally not worth it.
I tested and everything's working really well, great job! As Jad took care of the last code review, I'll let him check your changes and merge, unless either of you would like me to dive into the code.

Mouse and touch can work very well for this kind of game, it's just a matter of adding a couple little things. You can leave it as-is for now and we can take care of adding the missing bits later if you'd like.

Sounds good, I've got it pretty much working for the moment. I think that I would prefer to iron out the mouse related bugs (there are a couple, one of which stems from Dialogic's input handling) in a later pull request, since many of these are related to the current demo. I expect the scenario to change between now and the "final" demo, making some of these disappear.

I tested and everything's working really well, great job! As Jad took care of the last code review, I'll let him check your changes and merge, unless either of you would like me to dive into the code.

Thanks. I'm in no particular rush, so please don't be inconvenienced on my account. I'm more than happy to wait.

Our launch has been hectic, so as much as I wanted to review this PR, I haven't had the time. I'm sorry for the delay. I'll try to get to it by the end of the weekend.

I could finally get to it! Great job overall, everything is clear and seems pretty composable and flexible already, perfectly adapted to this kind of game demo.
This is good to merge for me. Like Jad said, it would make more sense to do a review and refactoring pass at the end, when all systems are in place and all requirements and interactions between every system are settled (field code may need some additions and tweaks when adding character stats and abilities, for example). Otherwise, we might end up doing some unnecessary work. And I find the code pretty easy to change and refactor, so I'm not worried about that.
Thank you so much for your contributions!


Load Balancing 16 chargers

Hello,
Will it be possible to reach 16 chargers with balancing?
Just change the maximum from 8 to 16 and it will work? or will more structural changes to the code be required?
Thanks a lot for the help. Greetings

No that is currently not possible. address 1-8 are reserved for controllers, 9 is the 'broadcast' address 10 is the Sensorbox, so that would mean you have to rewrite the code.
And there is another problem. Polling the controllers takes time, irc it takes about 0.2 sec per controller. so at 8 controllers that's 1.6 sec. excluding any Energy meters that are configured for each node. which also have to be read.
The max time is 2 sec. above that and timeouts will occur.


chore: fix typo

I'll take your work for it! (I don't know Spanish spelling 😬).

¡ay caramba!
that one was my fault 🤦

Ok this is out in 4.0.0


chore: style-dictionary v4

Current headache:
/home/bennyp/Developer/redhat-ux/red-hat-design-tokens/node_modules/json5/lib/parse.js:1110
    const err = new SyntaxError(message)
                ^

SyntaxError: Failed to load or parse JSON or JS Object: JSON5: invalid character 'a' at 1:1
    at syntaxError (/home/bennyp/Developer/redhat-ux/red-hat-design-tokens/node_modules/json5/lib/parse.js:1110:17)
    at invalidChar (/home/bennyp/Developer/redhat-ux/red-hat-design-tokens/node_modules/json5/lib/parse.js:1055:12)
    at Object.value (/home/bennyp/Developer/redhat-ux/red-hat-design-tokens/node_modules/json5/lib/parse.js:309:15)
    at lex (/home/bennyp/Developer/redhat-ux/red-hat-design-tokens/node_modules/json5/lib/parse.js:100:42)
    at Object.parse (/home/bennyp/Developer/redhat-ux/red-hat-design-tokens/node_modules/json5/lib/parse.js:25:17)
    at combineJSON (file:///home/bennyp/Developer/redhat-ux/red-hat-design-tokens/node_modules/style-dictionary/lib/utils/combineJSON.js:111:32)
    at StyleDictionary.extend (file:///home/bennyp/Developer/redhat-ux/red-hat-design-tokens/node_modules/style-dictionary/lib/StyleDictionary.js:293:28) {
  lineNumber: 1,
  columnNumber: 1
}

Node.js v22.6.0

@bennypowers - Do we know if this will result in different output for the rhds.tokens.json file or are we thinking the updates are mostly in the transformers layer?

if i do this right there shouldn't be any changes to the outputs

@brianferry I used a package called pkdiff to compare tarballs from main branch with this one
❯ git checkout chore/sdv4
  nvm use
  npm ci
  npm run build
  npm pack
  mv rhds-tokens-2.0.1.tgz rhds-tokens-sdv4.tgz
  git checkout main
  nvm use
  npm ci
  npm run build
  npm pack
  mv rhds-tokens-2.0.1.tgz rhds-tokens-main.tgz
  nvm use v14
  npx pkdiff rhds-tokens-sdv4.tgz rhds-tokens-main.tgz
  nvm use

And the result was that the packages are exactly the same :muscle:


Remove transaction patch in firestore mock

To create the Transaction unit tests I had to monkey patch the library fireorm uses to mock firestore in unit tests.
Last week I created a PR in that library adding the runTransaction method. Let's replace our local implementation with the one provided by the library.
Acceptance Criteria:

Update mock-cloud-firestore to last version
Remove monkeyPatchFirestoreTransaction.ts file
Use runTransaction function provided by Firestore constructor directly from mock-cloud-firestore

closed in #87


[CSL-269] Test script transactions

@neongreen
Off the top of my head, some test cases that should be added:

First transaction's output uses a {PK address | SH address}; second transaction supplies a {script witness | signature witness}. The second transaction can't spend the first transaction (as they're incompatible).

First transaction's output uses a SH address; second transaction supplies a script witness with a wrong hash. The second transaction can't spend the first transaction.

Failing validation cases:

Validating script isn't a validator
Redeeming script isn't a redeemer
Redeeming script is a redeemer but redeemer >>= validator doesn't typecheck
Redeemer and validator define same names (e.g. there's blah exported by both scripts) and that's bad
Everything is good but redeemer >>= validator outputs failure (e.g. tfValidator combined with badTfRedeemer)

A case where everything works (goodTfRedeemer + tfValidator).

@georgeee
Please estimate


Puppet 4 support?

Do you have in mind adding support for Puppet version 4.X?
Thanks in advance!

I use this module day in and out with 4.2. Is there something not working?

Oh! Great! I didn't try to install it in my new Puppet 4.2 environment.
I was just asking because in "Compatibility" tab there is just Puppet 3.X (Enterprise or not).
Did you try using it with Debian 8 too?
Thanks @jfryman.

@apazga absolutely! Works with Debian 8. Let me know if you run into issues. Cheers!


ci: add script to check git commits

Recently, there were multiple occasions where the git commits were not following the expected standards. Add a github action that will check every commit in all pull requests.

The actual conventions are written up here:
https://git.sr.ht/~rjarry/aerc/tree/master/item/CONTRIBUTING.md
https://github.com/DPDK/grout/blob/main/CONTRIBUTING.md


Update PEER_WHITELIST for the proposer nodes.

Updated to include node 7~9

Please wait for the test :)


rootcomponentbehavior : missing information on which component can contain which subcomponent

Hi,
rootcomponentbehavior  inform us on how a component is contained in a solution.
But in case of "Include Subcomponents", there is no information, on  which component can contain which subcomponent
Thanks for advance to add this information in the page, or if the information already exist in another page, please provide a link.
Regards
Sybaris
[Enter feedback here]

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 3dcc41ca-d9a6-0e2d-35ee-892b9b57389a
Version Independent ID: cd5f5759-9cb7-9f5a-e9f9-d543e50f0909
Content: SolutionComponent entity reference (Dynamics 365 Customer Engagement)
Content Source: ce/customerengagement/on-premises/developer/entities/solutioncomponent.md
Service: d365ce-op
GitHub Login: @KumarVivek
Microsoft Alias: kvivek

Thanks for your comment, @sybaris. This issue has been assigned to the doc author for review.


Could not handle POST operation

Hello,
the API that get a Service Principal or a Group works but I am not able to use the POST one that "Add a service principal" (I am connected with a Service Principal that is owner of the Resource Group that contains the Databricks workspace resource).
Could you please have a look on the following screenshot and check if everything is ok?

Thanks,
James

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: e79973de-ae25-ad05-bfda-b3540fcefc91
Version Independent ID: ec967cea-c1a7-ef77-a40e-ae7c41493b47
Content: SCIM API (ServicePrincipals) - Azure Databricks
Content Source: databricks/dev-tools/api/latest/scim/scim-sp.md
Service: azure-databricks
GitHub Login: @mamccrea
Microsoft Alias: mamccrea

Thank you for your detailed feedback.  We are looking into the issue, and we will respond when we have more information.

@JamesDLD Since this issue is not related directly to the doc, I would recommend you to create a thread on the forums - MSDN or Stackoverflow
Once you post your issue on forums, it will have visibility across the community which is a better suited audience for such types of issues.


Reroll error

Hello,
I'm using version 4.4.2, I have a problem with the reroll command.
When I reroll several times the author of the message is also put in the winners.
Big mistake, if you put several participants and only one person checks the message an error this product in the console.
(node:18) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'id' of undefined
at Giveaway.checkWinnerEntry (/home/container/node_modules/discord-giveaways/src/Giveaway.js:302:42)
at Giveaway.roll (/home/container/node_modules/discord-giveaways/src/Giveaway.js:333:45)
at processTicksAndRejections (internal/process/task_queues.js:97:5)
at async /home/container/node_modules/discord-giveaways/src/Giveaway.js:442:29
(node:18) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag --unhandled-rejections=strict (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 2)
(node:18) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
(node:18) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'id' of undefined
at Giveaway.checkWinnerEntry (/home/container/node_modules/discord-giveaways/src/Giveaway.js:302:42)
at Giveaway.roll (/home/container/node_modules/discord-giveaways/src/Giveaway.js:333:45)
at processTicksAndRejections (internal/process/task_queues.js:97:5)
at async /home/container/node_modules/discord-giveaways/src/Giveaway.js:442:29
(node:18) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag --unhandled-rejections=strict (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 4)
(node:18) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'id' of undefined
at Giveaway.checkWinnerEntry (/home/container/node_modules/discord-giveaways/src/Giveaway.js:302:42)
at Giveaway.roll (/home/container/node_modules/discord-giveaways/src/Giveaway.js:333:45)
at processTicksAndRejections (internal/process/task_queues.js:97:5)
at async /home/container/node_modules/discord-giveaways/src/Giveaway.js:442:29
(node:18) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag --unhandled-rejections=strict (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 6)

this has been fixed


Deprecate AzureDataFactoryPipelineRunStatusSensorAsync

Deprecate AzureDataFactoryPipelineRunStatusSensorAsync and proxy it
to its Airflow OSS provider's counterpart
related: #1412

Successful sensor run post proxying


Trying to Integrate xio API Onto Custom Embedded Board

I have been trying to integrate the IMU API onto my custom board and am having trouble getting the data to show up in the GUI. My implementation writes the "Euler angles message" to the serial port at 20 Hz. The angles are computed from the Fusion library and are good. Below is a sample of the output information:
A,1075887198,-0.0458,2.5299,-124.4267
A,1075941199,-0.0470,2.4980,-124.6745
A,1075995199,-0.0449,2.4367,-124.9043
A,1076049199,-0.0435,2.3313,-125.1606
A,1076103199,-0.0460,2.2200,-125.3819
A,1076157199,-0.0500,2.0731,-125.5776
A,1076211199,-0.0540,1.9971,-125.7597
A,1076265199,-0.0547,1.9035,-125.9520
A,1076319199,-0.0610,1.7915,-126.1387
A,1076378183,-0.0665,1.6960,-126.3233
A,1076432199,-0.0700,1.6098,-126.4728
A,1076486199,-0.0681,1.5323,-126.6172
A,1076540199,-0.0690,1.4572,-126.8056
A,1076594199,-0.0731,1.3591,-126.9686
A,1076648199,-0.0755,1.2729,-127.0300
A,1076702199,-0.0840,1.1683,-127.1952
A,1076756199,-0.0879,1.0820,-127.2724
A,1076810199,-0.0886,1.0126,-127.3917
A,1076864199,-0.0942,0.9440,-127.5378

Note that each line is followed with \r\n, it is just not displayed in the terminal output.
Is there an implementation issue on my end, or does the GUI require a handshake before it can start displaying data?

No handshaking is required.  The stream you have shown is all that is needed for the x-IMU3 GUI to receive Euler angle messages.  If your stream is not working then I expect there is an issue with the \r\n.

Interesting. I also tried with the ping command. The command and response as captured by CoolTerm as follows:
{"ping":"\0"}
{"ping":{"interface":"USB","deviceName":"Thetis-F5","serialNumber":"001"}}

I verified the hex values of the characters in the terminal and they align with the specified message ESC character.

For the interface on the GUI is it using 8 data bits, no parity, and 1 stop bit by default?

is it using 8 data bits, no parity, and 1 stop bit by default

Yes
I think you may have misunderstood how the ping works.  The GUI will send {"ping":null} to the device during Searching For Connections, and the device would respond with {"ping":{"interface":"USB","deviceName":"Thetis-F5","serialNumber":"001"}}.  You may want to replace "USB" with "Serial" if that is more accurate for your device.
null is a JSON keyword.  "\0" is invalid JSON because 0 cannot follow the escape character \ in a JSON string.  You seem to be mixing C and JSON.  JSON is easy to understand and has beautiful documentation.

Ah. Gotcha. I'll keep that in mind. Issue still stands though that the GUI
is not communicating with my board 🤷♂
I'll keep trying with it tomorrow.
On Thu, May 18, 2023, 17:20 x-io Technologies @.***>
wrote:

is it using 8 data bits, no parity, and 1 stop bit by default
Yes
I think you may have misunderstood how the ping works. The GUI will send
{"ping":null} to the device during Searching For Connections, and the
device would respond with
{"ping":{"interface":"USB","deviceName":"Thetis-F5","serialNumber":"001"}}.
You may want to replace "USB" with "Serial" if that is more accurate for
your device.
null is a JSON keyword. "\0" is invalid JSON because 0 cannot follow the
escape character \ in a JSON string. You seem to be mixing C and JSON.
JSON is easy to understand and has beautiful documentation
https://www.json.org/json-en.html.
—
Reply to this email directly, view it on GitHub
https://github.com/xioTechnologies/x-IMU3-Software/issues/193#issuecomment-1553660448,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB5UA4SYETBBFQF6A2XOSZTXG2HCPANCNFSM6AAAAAAYGVBAQA
.
You are receiving this because you authored the thread.Message ID:
@.***>

I have tested the x-IMU3 GUI and found no issue.  The following screenshot shows the working serial stream logged using Tera Term and then opened in Notepad++ with Show All Characters enabled to confirm the \r\n termination.  I suggest you confirm your termination in a similar way.

My results from testing just now. Same process you described.

I do not see a issue with those ASCII lines.  Please can you log several seconds of that stream using Tera Term and share the file with me.

I do not see a issue with those ASCII lines. Please can you log several seconds of that stream using Tera Term and share the file with me.

See attached. Thanks for looking into this.
thetis_log.txt

Is your device using RTS/CTS hardware flow control?  The current release (v1.1.4) permanently asserts RTS and so would inhibit device transmission.  This was fixed in 8d883ae64165503d35927222f337e75b3a685c7b but will not be available until the next release.  Until then, you should not use RTS/CTS hardware flow control.

I GOT IT!!!!!
I had to monitor the COM ports on my computer using a virtual serial port driver. That showed me that as soon as the GUI opened and started talking with the device, it stopped transmitting, hence our problem! I fixed it by continually flushing the Serial input buffer to the device. It seems that when that buffer is full, it crashes the device.

In a future update, could you add a serial port monitor or something into the GUI that spits out all of the traffic into a window? That would have made this easier and more streamlined.

I noticed that. But I mean like an actual serial port monitor where the data is written directly to the window. That would help in cases where the messages may not be properly parsed, but still being sent. Vice versa, it could also help figure out what messages are being sent from the GUI to a device.

Thank you for the suggestion.  I do not believe there is a strong use case for such a feature given the challenges and issues it would introduce, and given that there are already far more power and convenient tools available for debugging serial and socket streams.
In cases where messages may not be properly parsed, the connection will generate a decode error.  This is demonstrated in the examples and is on the GUI feature roadmap.

Fair enough. Thanks for the help looking into this issue through the past couple of days. Closing this now.

Leaving this here for future Braidan.
Steps to get x-IMU3 GUI to work with Thetis as of 06/02/2023:

Create two split virtual COM ports from the real COM port using Virtual Serial Port Driver Pro (or similar)
Connect Tera Term to the main virtual COM port
Connect the GUI to the secondary virtual COM port
Profit.

Unfortunately, as of right now the GUI cannot talk directly with Thetis, it needs this medium of virtual COM ports. I believe it has something to do with the USB handshake? I'm not entirely certain right now.

Please can you test if the issue is solved with the latest x-IMU3 GUI release, v1.2.0.

Please can you test if the issue is solved with the latest x-IMU3 GUI release, v1.2.0.

It absolutely works! That's awesome. What changes did you make to the serial interface that could have fixed it?

I believe the issue is as a described above.  My previous comment was mistaken in that it is the DTR line that is permanently asserted, not the RTS.  I believe you are using an ESP32 with a USB-UART converter that uses the DTR line to control the ESP32 reset/boot signals.  Your hardware would therefore be held in reset whenever the x-IMU3 Software opens the serial port.

I notice that your 3D model has no colour.  If you want to include colour then you should provide an .mtl file in the same location, and with the same name as the .obj file.  I have added instructions for generating these files.


What if no npm?

Hey! Love this cheesy effect. However, I don't use npm on my website. I feel like this should be doable on core js, or maybe even in css alone.
Thoughts?

Hi!
Thanks for the question! You're absolutely right, it's so much easier to do it in plain js+css without any packagemanager, or typescript. Actually it's my first package and I did it only for the sake of practice and just to try it out.
Do you think I should open a new repo for plain js implementation? Or do you have something in mind?

I think it makes sense to stay in one repo, just making the plain js and/or css available in the repo and point to it in the readme would be enough!

@petya0927 Close enough! At least for me to finalize it a little. Functionally, the only thing I really changed was the parameter for realDarkMode, as plain js didn't like it before. Otherwise, I wrapped it in an object for a simple form of namespace.
In PR #5 for your review :)


[Feature] Automating the conversion of CrownLabs VM Images

This feature request proposes to implement a mechanism to automate and simplify the creation of new VM images for CrownLabs, as well as the subsequent conversion and upload to the target Docker registry.
Workflow overview
The workflow currently envisioned for the creation of a new VM image (originated as a trade-off, hence not yet optimal) involves the following steps:

The final user (e.g. professor) downloads to his own PC a ready-to-customize base image available on the CrownLabs website (with all the tools required for CrownLabs already installed).
The final user executes the VM in VirtualBox to customize the base image and install additional software required for his needs.
The final user uploads the resulting VM image to a public location (e.g. Google Drive).
The final user logs into the CrownLabs dashboard and creates a new ImageConversionRequest, specifying the URL the VM can be downloaded from and the name to be assigned to the resulting image.
A Kubernetes operator reacts to the creation of a new ImageConversionRequest, creating a Job to download, convert and push  the specified image to the Docker registry.  The image name must be prepended by an identifier of the creator, to prevent name overlapping.
The final user is notified about the success or the failure of the conversion task through his dashboard.

Practical tasks to perform
In order to implement the steps 4 to 6, the tasks currently identified involve the following.
Back-end

[ ] Define the ImageConversionRequest CRD.
[ ] Define a Job to download, process and upload the VM image to the Docker Registry. Essentially, the tasks to be performed are those implemented by this script. Possible containers composing the job are:

curlimages/curl, to download the image from the url specified in the ImageConversionRequest;
diraimondo/virt-sparsify or equivalent, to convert the image in the qcow2 format;
kanico, to build the docker image and push it to the registry;

[ ] Develop an operator which, upon creation of an ImageConversionRequest resource, creates a new Job according to the previous specifications to process the CrownLabs VM image. The operator should also update the status of the resource, to provide feedback regarding how the conversion is proceeding. It is proposed to use kopf to develop the operator using python. An example of the usage of python to interact with Kubernetes resources is provided by this script.
[ ] Define the different resources necessary to run the operator, including the permissions to access ImageConversionRequest resources (both by the operator and a subset of end-users).
[ ] Write a README file describing the operator and the overall approach.

Front-end

[ ] Develop a form to create a new ImageConversionRequest, specifying the URL the image can be downloaded from and the destination name.
[ ] Track the status of existing ImageConversionRequest resources, to provide feedback regarding how the conversion is proceeding and whether it succeeded or failed.

Possible Follow-ups

[ ] Integrate the available object storage to prevent the users from being required to upload the images to a third-party service.

Closing, as #434 adopts a better approach to address the same problem.


Allow overriding docker-compose.yml path using ENV

This PR allows developers to override the docker-compose.yml file path; thus supporting different environments e.g. docker-compose.dev.yml.
Fixes https://github.com/laravel/sail/issues/348
The file path can be overridden by setting the SAIL_DOCKER_COMPOSER_YAML env var in the .env file (or at the terminal level).
Additionally, this PR also adds IntelliJ related workspace/project files to the .gitignore list.

I don't seem to have permission to edit this PR. Also please do not change the gitignore - those things should be in your local machine's global gitignore.

@taylorotwell Thanks for the tip about the gitignore. Regarding you being able to change the PR, do you want me to give you access or will you do this fix from your side?

@prageeth please re-send the PR with edit permissions and without the gitignore additions.


[SPARK-47508][PYTHON] Update black to 24.3.0

What changes were proposed in this pull request?
Update black from 23.9.1 to 24.3.0
Why are the changes needed?
Fix thrue https://github.com/psf/black/pull/4278
Does this PR introduce any user-facing change?
No.
How was this patch tested?
Pass GA
Was this patch authored or co-authored using generative AI tooling?
No.

FYI, I closed the same dependabot PR yesterday due to the same reasons.

https://github.com/apache/spark/pull/45617

ah.. ok.
Thank you @dongjoon-hyun


perf(dynamic): 移除动态组件

:tada: This PR is included in version 1.13.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


[feature request] Change VIP/Fav behavior and other ideas

I just recently started using VRCX and from the get go, I don't quite understand how the vip list works?
It would be nice to be able to add players to said list arbitrarily, instead of basing it on what I presume are the vrc fav lists.
On top of that, having a feature for infinite local fav lists would be nice. Grouping different friend groups together for easier organization. Maybe even go so far as to adding locally stored tags, like assigning a player as part of group A and group B etc.
One last thing- It would be nice if you could filter the big friends list by online status.
Just some random ideas or whatever. Thanks for your time <3

Custom friend groups is something I have had planed for a while now but have yet to implement because it will take a long time to do.
I had sorting by status during testing but removed it because only online/cached users have their status visible.
I have since added an option to sort aside list to move all users in private instances to the bottom, this will be in next release.


Inconsistent multiplication of sparse and compressed sparse arrays with np.inf's

Description
The results of multiplication of sparse and compressed sparse array with np.inf's are mx.nd.array([np.inf]) are inconsistent with corresponding results in numpy.
Environment info (Required)
Any Environment

Build info (Required if built from source)
MXNet commit hash:
b6972bb055fc44481b072db3abb90e26ee27c787
Steps to reproduce:

Expected (produced by numpy) results would be the arrays consisted of nan's:

>>>a = np.array([0, 0])
>>> np.inf * a; a * np.inf
array([ nan,  nan])
array([ nan,  nan])
>>> np.array([np.inf]) * a; a * np.array([np.inf])
array([ nan,  nan])
array([ nan,  nan])

Unexpected results for both sparse and compressed sparse arrays when they are multiplied by np.inf:

>>>a = mx.nd.zeros(2).reshape(1,2).tostype('row_sparse')
>>>b = mx.nd.zeros(2).reshape(1,2).tostype('csr')
>>> (np.inf * a).asnumpy(); (a * np.inf).asnumpy()
array([[ 0.,  0.]], dtype=float32)
array([[ 0.,  0.]], dtype=float32)

>>> (np.inf * b).asnumpy(); (b * np.inf).asnumpy()
array([[ 0.,  0.]], dtype=float32)
array([[ 0.,  0.]], dtype=float32)

Unexpected result for compressed sparse array multiplied by mx.nd.array([np.inf]) from right side:

>>>b = mx.nd.zeros(2).reshape(1,2).tostype('csr')
>>> (b * mx.nd.array([np.inf])).asnumpy()
array([[ 0.,  0.]], dtype=float32)

NOTE: for sparse array and for multiplication of crs array from left side everything looks fine.

@eric-haibin-lin FYI

We follow the scipy semantics for sparse arrays:
>>> import scipy
>>> import scipy.sparse as spsp
>>> a = spsp.rand(2,2,density=0)
>>> a
<2x2 sparse matrix of type '<class 'numpy.float64'>'
        with 0 stored elements in COOrdinate format>

>>> import numpy as np
>>> (a * np.inf).todense()
matrix([[0., 0.],
        [0., 0.]])

Is this intentional though (on both our and scipy side)?


Highlighter in painter

As per our discussion - https://discord.com/channels/601130461678272522/855886335980994600/860066323819003924

@sherubthakur - I think this looks good. Some recent changes look like they conflict. Once those are fixed I think this one is good

@jonathandturner done


Faster staticMap and Filter

staticMap
There are a few separate optimisations here:

make staticMapImpl , meaning that the template you're instantiating a lot of doesn't have to take the F every time. Improvement: only ~1-2% but very stable, I suspect this approach might be more rewarding elsewhere.
expand out many small cases (150). Any more than 3 was slower if done inline with static if chains, but combined with the following you can really crank it
generate the small cases as an AliasSeq of strings, so no static if chains, just an O(1) lookup (at least I hope so). This is the big one, enabling the expansion to work cheaply.
in the binary split branch immediately do what work you can. Combined with the rest this is an extra ~20% speedup and 10% memory reduction

Overall, this was ~2.5x faster and ~4x less RAM in my tests.
My tests were all biased towards very long Args and simple Fs.
Filter
Armed with this nice basic tool, Filter can be attacked, I saw ~4x speedup and ~3x memory reduction
I'm sure a combination of either implementing in terms of this faster staticMap or using same techniques could be done across a lot of std.meta
Todo:

[ ] Proper benchmarks across different scales. I heavily tested with large synthetic AliasSeqs and then did some tweaks for a large codebase mostly using small ones.

Tests on a large internal codebase suggest in practice low single-digit % reductions in overall compile times and compiler memory usage.

FYI I've been holding off on reviewing this under the impression that you still intend to perform more benchmarking.

FYI I've been holding off on reviewing this under the impression that you still intend to perform more benchmarking.

I'm just not going to have time for this right now, sorry.

More than 72 hours has passed. What is the hold up?


Scheduled code regeneration test

Triggered from branch: main

API change check
API changes are not detected in this pull request.


Updated Danish translations

Closes #258. @1ec5
Updated Danish translations and fixed some abbreviations.

And translations should be updated on https://www.transifex.com/project-osrm/osrm-text-instructions/language/da/ first not directly in languages/translations/da.json file

@yuryleb I see. The problem with translating on Transifex is that I cannot add modifiers as separate strings. See this for example:
https://github.com/Project-OSRM/osrm-text-instructions/pull/286/files#diff-2c8beca969ab6776d6f6d01bc61ea58aR208-R211
I cannot use the default modifier. It may work in English, but it doesn't work in Danish. The same goes for sharp/slight left/right. It's just not possible in Danish.
What would you suggest instead?

@yuryleb I've updated the Transifex translations to the best of my ability, but the issues above are still present.

Thank you. Could you please now update files again but from Transifex (and don't forget ChangeLog 😉) and point me some fixture files with these incorrect sharp/slight left/right strings and comment what should be there instead - this allows me to understand the issue more completely. IMHO this could be fixed with post-processing by new grammar rules for Danish but I need more info yet.

So let's try to reduce total number of incorrect phrases in fixures with Transifex first:

Move til inside modifier values
Update left/right words in sharp/slight modifiers
Use most common phrases beginnings (will solve different beginnings for straight/u-turn after)

@yuryleb I've updated Transifex and pushed the changes, I'm gonna go through the tests now and note any incorrect translations.

@cmahopper, actually I already prepared a commit to push initial grammar rules right into your branch here but has no permissions to do this 😞 Maybe you could try to give me write access while we're waiting @1ec5 for approval?

@yuryleb You should be added as a collaborator now :)

Thanks! Please review proposed grammar rules and resulting fixtures. I didn't add special grammar tests so as all results are controlled with them.

@yuryleb The test results look perfect!
There's a final thing that still results in a weird speak, but I'm not sure if it can be fixed in the same way. I wrote it in this comment: https://github.com/Project-OSRM/osrm-text-instructions/pull/286#discussion_r317909524
The arrival string that starts with "Du vil ..." should be the only case where the first two words need to be switched. Would you be able to take a look at it?

Currently I has no idea how to fix this - current grammar rules implementation may not help in this case 😞 IMHO it's better to create separate issue specially for this to keep it in backlog at least.
@1ec5, we're ready to merge and to close #258 :wink:

@yuryleb Alright, thanks for the help anyway :)


FetchTaskThread bug -- fix #1515

Codecov Report

Merging #1516 into dev will not change coverage.
The diff coverage is 0%.

@@          Coverage Diff          @@
##             dev   #1516   +/-   ##
=====================================
  Coverage   6.75%   6.75%
=====================================
  Files        272     272
  Lines      13612   13612
  Branches    2165    2165
=====================================
  Hits         920     920
  Misses     12628   12628
  Partials      64      64

Impacted Files
Coverage Δ

...cheduler/server/worker/runner/FetchTaskThread.java
0% <0%> (ø)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 38b0765...947d804. Read the comment docs.


build(): First version of using SauceLabs and BrowserStack on travis.

@jelbourn Just rerunning the build this morning was enough to make it pass. Yesterday's last test was a flake. Not 100% sure how I feel about that. Build 37 is the previous one that passed this morning.

@hansl We can go with it for now and see if it continues to be flaky. Can you squash your commits?
cc @mlaval: Marc, if you have a few minutes to take a look that would be much appreciated.

Also FYI @IgorMinar @juliemr

LGTM, but I'd wait a couple hours in case someone else wants to comment on something.

Found the problem with the last few updates; the browserStack didn't properly start a tunnel and one was needed. I set the startTunnel var to true in the karma config for browserStack and it works.
Now, angular2 has a script to manually start a tunnel. I'm not 100% what the advantage of having this kind of control for us would be, but I'll consider it in a future update.
For now, I consider this PR done and working and will rebase and merge tomorrow morning, unless @jelbourn wants to put this on hold to review.

We start tunnel via a script because we want to reuse one tunnel across
many invocations of karma within the same build job.
Additionally since the tunnel takes a while to start we start initiating it
at the beginning of the job, then build stuff and by the time karma needs
to run the tunnel is ready.
I suggest you stick to the same setup as A2
On Mon, Jan 18, 2016 at 10:11 PM Hans<EMAIL_ADDRESS>wrote:

Found the problem with the last few updates; the browserStack didn't
properly start a tunnel and one was needed. I set the startTunnel var to
true in the karma config for browserStack and it works.
Now, angular2 has a script to manually start a tunnel. I'm not 100% what
the advantage of having this kind of control for us would be, but I'll
consider it in a future update.
For now, I consider this PR done and working and will rebase and merge
tomorrow morning, unless @jelbourn https://github.com/jelbourn wants to
put this on hold to review.
—
Reply to this email directly or view it on GitHub
https://github.com/angular/material2/pull/12#issuecomment-172751046.

LGTM once you get the rebasing resolved

:+1: got the rebasing. Submitting once travis gives me the :green_heart:


can't delete note

Just tried the spell checker and I like it
I love it's offline and the dictionary is customisable
But I can't figure out how to delete notes
I cleared data for the app to get rid of a bunch of test notes
I did.. But that is not very feasible is I want to use it to create
On a regular basis.
I would love it if this app could be found on fdroid also
Add I use that the update most of my open source software

Dear user,
You can just swipe the item to the left and click on the "trash button".
Please see attached some screenshots that explain how to delete a document.
You can find the source-code on github. The link is in the "about" section of the app.
Thanks for feedback.
If you have any questions please don't hesitate to ask.
Best regards,
XPN Inc.
On Wed, Apr 20, 2016 at 8:47 PM, nutpantz <<EMAIL_ADDRESS><EMAIL_ADDRESS>> wrote:
Just tried the spell checker and I like it
I love it's offline and the dictionary is customisable
But I can't figure out how to delete notes
I cleared data for the app to get rid of a bunch of test notes
I did.. But that is not very feasible is I want to use it to create
On a regular basis.
I would love it if this app could be found on fdroid also
Add I use that the update most of my open source software
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub [https://github.com/MartinXPN/ProCorrector/issues/1]


Missing helper line(s)

The code you posted would not run, here are the lines that caused me trouble

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. We will now review your pull request.
Thanks,
Microsoft Pull Request Bot

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/rest/ruby-tutorial.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Interesting. My code doesn't have those lines and it worked, though I haven't tried it recently. Let me test on my side.

Just retried this, and it runs fine for me without having include AuthHelper in the auth_controller.rb file. Adding it doesn't seem to break anything though, so maybe that's the safest approach.
@thewruck I'm curious as to why it works for me and not for you. Maybe this is a version thing? What version of Ruby and Rails are you running? Here's mine (on Windows):
C:\Source\Repos\o365-tutorial>ruby -v
ruby 2.3.3p222 (2016-11-21 revision 56859) [i386-mingw32]

C:\Source\Repos\o365-tutorial>rails -v
Rails 5.0.4

Ok, I think I figured this out. I have some old code that includes AuthHelper in the base class (https://github.com/jasonjoh/o365-tutorial/blob/aa409d64487d7107c7042e7ae24ea94bd7fb2239/app/controllers/application_controller.rb#L6).
When I refactored this tutorial, I didn't include that in the write up.
I'm removing that old code and accepting this PR.


docs: add fireblocks signer

lints are fixed in https://github.com/OMGWINNING/aa-sdk-staging/pull/90


Run checks for external contributions

Problem
In case an external contributor opens a pull request, no checks on GitHub are running. However, checks are running for pull-requests from SecHub/Mercedes-Benz contributors.
Solution
Run checks (tests, build etc.) for internal and external contributors. The workflow should not be different.

:+1:
So a pull request from external needs to be approved with button "Approve and run".
We should do this next time before merging.

We tried out and it did not work with external PRs.
Reading
https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions,
https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#onpull_requestpull_request_targetbranchesbranches-ignore
and also
https://wildwolf.name/github-actions-how-to-avoid-running-the-same-workflow-multiple-times/
It looks like we need to add not only "on push" but also "on pull_request". to have the workflow actions running  - see
https://github.com/mercedes-benz/sechub/blob/develop/.github/workflows/gradle.yml#L4-L14


feat/docs-integration

Codecov Report

Merging #23 (11df1ec) into main (7234caf) will decrease coverage by 0.26%.
The diff coverage is 55.55%.

@@            Coverage Diff             @@
##             main      #23      +/-   ##
==========================================
- Coverage   81.45%   81.18%   -0.27%
==========================================
  Files          53       54       +1
  Lines         717      723       +6
  Branches      115      116       +1
==========================================
+ Hits          584      587       +3
- Misses        133      136       +3

Flag
Coverage Δ

unittests
81.18% <55.55%> (-0.27%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

src/pages/docs.page.tsx
0.00% <0.00%> (ø)

src/utils/geo.ts
100.00% <ø> (ø)

src/components/nav/drawer/drawer.tsx
100.00% <100.00%> (ø)

src/components/typography/retro-title.tsx
100.00% <100.00%> (ø)

src/redux/position/thunks.ts
100.00% <0.00%> (+2.94%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7234caf...11df1ec. Read the comment docs.


Use contiguous table when deserializing columnar batch

Fixes #849.
This was straightforward to implement, as @revans2 detailed it so excellently in the feature request.
I verified with a profile on a query that the contig splits have been removed after a shuffle.  This cut the wall-clock time on a test query in local mode from over 32 seconds to under 25.
This also removes the unused numFields parameter from GpuColumnarBatchSerializer since I stumbled across it while doing this PR.  Happy to move that to a separate PR if desired.

build

Just FYI: numFields came from the original spark serializer code where an UnsafeRow needs to know how many fields there will be when it initializes so it can allocate that amount of memory. I kept it when I first started to port over the code but should have dropped it a long time ago.  Thanks.


[Feat] Add options to override the directory

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Enable cookies popup

Issue summary
I'm build app using this new API but still getting Enable cookies popup  error whenever app make auth call and reload whole app;  I've checked so many times official doc and code but not able to find any trace at my end. Even if I'm hitting Enable cookies button then also it's keep asking whenever it's make auth call and reload whole app.
Then weird part is that it's appear for few time when whole app get reload then it's disappear and app start to behave normally.

Expected behavior
It should not ask every time at least once we hit Enable cookie button.
Actual behavior
What actually happens?
P.S: Every time I restarting my node server it's asking same as well
Please check this video which I recorded with voice  Enable cookie popup issue video
Steps to reproduce the problem

I have simply followed steps what we have on official documents like [Build a Shopify App with Node and React](https://shopify.dev/tutorials/build-a-shopify-app-with-node-and-react and) & Shopify App CLI

Specifications

Browser: Chrome 89.0.4389.114 (Official Build) (64-bit)
Device: Desktop
Operating System:
Edition Windows 10 Pro
Version 20H2
OS build 19042.867
Experience Windows Feature Experience Pack 120.2212.551.0

Same issue for me happens

@kasrakhosravi  the link you shared as known issue it's explain about safari but I'm getting this issue in chrome, windows as well and also I'm using @shopify/koa-shopify-auth": "^4.1.2

The issue started with safari, but now it has reached other browsers as well. They mention that in the final pages of the thread if you keep reading.
I think the solution for this would be to use this approach: https://shopify.dev/tutorials/authenticate-your-app-using-session-tokens

I think as more and more browsers are Blocking third-party cookies, solving this problem using the session tokens is a very clean and stable solution. I got it working on my app.
The link I posted above mainly focuses on ruby on rails; so I found this article really useful in solving the problem: https://blog.mixlogue.jp/posts/2020/20201209141909/
But in short, I persist the accessToken in my Postgress DB rather than relying on cookies. And that change requires several changes in server.js as well as app.js

@kasrakhosravi  I've created my custom app skeleton from official Shopify CLI in which primary level operations come as written already so if you go here https://github.com/Shopify/shopify-app-node/blob/master/server/server.js this is how exact my code is lookalike because I'm using it's clone. I've checked your thread as where in which you are using koa-shopify-auth-cookiless but it should come with shopify's koa-shopify-auth as I think of it; I don't know more on it yet but the link you shared of shopify tutorial in that they mentioned if you're using shopify ruby or node api then middleware and other utilities  for decoding session tokens coming in built and I'm facing issue with that in built functions.

Having the same issue at the moment, if anyone has a code sample of the cookiless from it would be amazing to take a look

https://github.com/taketsu/shopify-demo-app-node-react

Having the same issue at the moment, if anyone has a code sample of the cookiless from it would be amazing to take a look

Here is a more up to date sample that I've tried to put up.

Did anyone find a solution for this?

@smamessier unfortunately not yet...!!

@nikwebinopoly I ended up switching to https://github.com/TheSecurityDev/simple-koa-shopify-auth which was mentioned in another post. it now works like a charm. Just had to manually create the host hash like
   server.use(
          createShopifyAuth({
              accessMode: "online",
              authPath: "/auth",
              async afterAuth(ctx) {
                  const { shop, scope } = ctx.state.shopify;
                  console.log(ctx.state.shopify);
                  ACTIVE_SHOPIFY_SHOPS[shop] = scope;
                  const host = Buffer.from(shop + "/admin").toString("base64");
                  ctx.redirect(`/?shop=${shop}&host=${host}`);
              },
            })
      );

hello @smamessier  mine have prefix: "", instead of authPath: "/auth",
any idea why ??


feat: #678 - added bottom navigation bar to product page

The previous bottom navigation bottom bar was refactored, in order to be reused anywhere.
Then it was added to the product page.
Deleted files:

home_page.dart
smooth_ui_library/smooth_bottom_navigation_bar.dart
smooth_ui_library/smooth_bottom_navigation_bar_item.dart

New file:

smooth_bottom_navigation_bar.dart

Impacted files:

continuous_scan_page.dart: added an explicit bottom navigation bar (was implicit through HomePage)
main.dart: not using HomePage anymore; asking the bottom navigation bar who's the current page instead
new_product_page.dart: added an explicit bottom navigation bar (was not there)
product_list_page.dart: added an explicit bottom navigation bar (was implicit through HomePage)
product_page.dart: added an explicit bottom navigation bar (was not there)
smooth_ui_library.dart: removed "UI" version of smooth bottom navigation bar
user_preferences.dart: added a preference for tab index
user_preferences_page.dart: added an explicit bottom navigation bar (was implicit through HomePage)

Thank you @jasmeet0817 for the code review. I guess the next step is about "Make tabs stateful". I'm going to create the issue, but I will probably not code it.


fix: move schemas to their own directory and add to dist

The actual schema JSON files should now be included in the distribution on npm
Fixes #1511

Running npm publish --dry-run shows that the schemas/config.json and schemas/manifest.json are included in the tarball.