Description

• Bug Report or UX flaw

I did not expect:

1. that empty pedestals between pedestals with delivered boxes would be causing wrong markings
2. that an empty pedestal at the low end of numbers would cause a wrong marking

Neither the description, nor the tutorial/help screen indicated this.

Screenshot “in between”:

Screenshot “at the beginning”:

Steps to reproduce the issue

1. start games/sortit
2. play so that the stated conditions are met

Context

• OS: Ubuntu 22.04 LTS
• Software versions: Godot 3.4

How do you like your files, Sir?
It's important to have consistency in “bigger” projects. (Especially in open source projects.)
Code style, folder structure and focus of this issue: file names.

Do we want to force a file naming convention?
What are your thoughts?

Description

Bug Report

The physics of the boxes in the game SortIt are behaving chaotically when interacting with the pedestals in Godot version 3.5, but were previously not behaving that way.

This does not make the game impossible to play, since this issue only occurs about 40% of the time, but it makes the game very annoying to play.

Failure Information

Steps to reproduce the issue

1. Run the SortIt game with Godot 3.5 (It works as intended in Godot 3.4.4)
2. Pick up a box and bring it near the pedestals
3. Try to place the boxes on the pedestals
4. Discover some boxes glitching into the ground or having way too much velocity

Context

• OS: Win 10
• Software versions: Godot 3.5.x

Another thing to note is that the sounds seem to be worse in Godot 3.5 too (extremely loud, but also more distorted). I also feel that the snake speed seems to be slightly faster in Godot 3.5, making the game harder.

Description

• Bug Report

Gameover when changing direction to fast.

Steps to reproduce the issue

1. Open Snake
2. Collect at least one apple
3. Move right
4. Press fast up or down than left

If you start the game for the first time (or haven't played any round), the help screen is shown automatically.
It can be closed by clicking on it, but that's not necessary obvious.

Now if you have your hands on WASD anyway and hit any of those buttons, you're automatically adding "Player 1" without closing the help menu. You can see stuff is changing behind, though.

If you happen to click the now visible "Play" button trying to close the help screen, you'll launch the game, too.

Meine Frage wäre, ob GDNative in dem Projekt generell genutzt werden kann oder nicht (Also das Arbeiten mit C++/Rust/etc.).

Contra:

• GDScript ist da deutlich Anfänger freundlich
• GDScript ist besser in Godot integriert
• GDNative fügt eventuell unnütze Komplexität hinzu (aufspalten des Codes in viele Codebasses)
• Nicht jeder kann C++/Rust etc.

Pro:

• GDNative code ist deutlich schneller als GDScript
• GDNative ermöglicht das Benutzen von einer riesigen Menge an Bibliotheken
• Jeder kann in seiner Lieblingssprache Arbeiten → Codequalität wird höchstwahrscheinlich in der Lieblingssprache besser sein
• Kein Ausschluss von Godot featuren

Dieses Issue existiert, um darüber abzustimmen, mit welchem System, Merge requests oder anderen Veränderungen angenommen werden. Wie viele Daumen nach oben benötigt werden, um akzeptiert zu werden, wie lange gewartet werden muss, etc.

Description

We need to standardize the translation key names and usage because it is unclear where to use existing ones, when to make new ones and how to call them when you need new ones.

Description

• Bug Report

1. the background does not resize with the window
2. the upper/lower bounds seem to be fixed
3. the spawn/despawn of the pipes is visible when the window is resized

Steps to reproduce the issue

1. start games/flappybird
2. maximize the window
3. let the bird drop to the bottom, fly the bird to the top [2]

Context

• OS: Ubuntu 22.04 LTS
• Software versions: Godot 3.4

We should add Branch protection rules, to prevent future faulty PR merges!

You find the Branch protection rules under Repo > Settings > Branches > Add rule.

Which rules should be added?

• Require a pull request before merging
  • Require approvals
  • Required number of approvals before merging: 2
  • Dismiss stale pull request approvals when new commits are pushed
  • Require review from Code Owners
• Require status checks to pass before merging
  • Require branches to be up to date before merging
• Require conversation resolution before merging
• Require signed commits
• Require linear history
• Require deployments to succeed before merging
• Include administrators

Da wir hier mit einigen zusammen arbeiten und demokratisch Entscheidungen treffen wollen, ist es besonders wichtig dies transparent zu machen und die getroffenen Entscheidungen zu dokumentieren.

Mein Vorschlag hierfür wäre, dass man Abstimmungen zu einen Thema in einem separatem Issue bespricht und über die Emots als Umfrage abstimmen lässt. Eine Umfrage hat dann eine festgelegte Laufzeit (z.B. 12h, 24h etc.). Am Ende wird das Ergebnis dokumentiert. Hierfür würde ich die Wiki Funktion von GitHub bevorzugen. Das alles in der README zu machen, könnte die README etwas zu sehr aufblähen.

Bereits getroffene Entscheidungen würde ich dann mit diesem System noch mal bestätigen lassen (z.B. welche Sprache verwendet werden soll).

Was haltet ihr davon?

As PR #63 (together with the issue fixed in PR #78 and to some lesser extent PR #77) showed, it might be a good idea to have some way to fast-track critical changes that actively and directly fix issues preventing new changes (or whole PRs) to get created or properly merged.

• Just merging them straight away sounds wrong, contradicts the core idea of this project, and might introduce new bugs, if something is pushed too fast.
• With current rules in place, the project could remain broken up to 72 hours after an actual fix has been developed, since getting the necessary upvotes might still be tricky (and even then there's the initial 24 hours deadline). Keep in mind this might be way longer if a fix isn't a 5 minute change, so imagine having something blocking for a week, then wait even longer? Sounds wrong, too.

Unfortunately I have no clear solution to this whole issue, as seldomly as it might happen overall.

Bleiben wir bei MIT? Evtl. GPLv2? Vorschläge plis!

(Nach Anmerkung von DipDill im Discord)

Was meint ihr?

Description

Issue type: Bug Report

The snake color selection persists in the menu background after playing the snake game, but then going back to the menu before selecting a snake color.

Steps to reproduce the issue

1. Play the snake game
2. Immediately open the pause menu
3. Select "Back to menu"

Context

Description

Please select the type of issue you are reporting:

• [X ] Feature Request
• Bug Report

Ich habe durch Zufall das Repository hier entdeckt und wollte einmal nachfragen ob hier noch jemand mitmacht.
Es wurde ja bisher leider über ein Jahr kein neues Update Video mehr gemacht.

Ich hatte bis jetzt keine Möglichkeit in DC zu schauen.

Gruß
Fox

Ich fand es ja irgendwie schon interessant, wie hier gleich erstmal alle möglichen Sachen diskutiert werden, aber irgendwie ein Sprachenmischmasch herrscht anstatt das erst mal zu klären:

Aktuell sind ja einige Issues ganz Deutsch, andere haben englischen Titel mit deutschem Text darunter… Kraut und Rüben?

Sollten Commits, Pull Requests, usw. (von Deutschsprachigen) denn nun in Englisch oder Deutsch verfasst sein?

Damit keine Tendenzen durch die Emoji-Wahl aufkommen schreib ich hier gleich zwei Antworten. Reagiert einfach beliebig auf die Option, der ihr zustimmt.

Wie hier bereits angemerkt bräuchte es generell eine Idee, wo das Spiel überhaupt grob hingehen soll. Also her mit euren Ideen.

Tipps für den Pitch:

• KISS - Keep it Short and Simple. Im besten Fall knackig in wenigen Sätzen die Kernidee formulieren
• realistisch bleiben - Das hier wird recht sicher nicht das nächste GTA oder WoW
• zeige evtl. Beispiele - Gibt es schon Spiele / Filme / Kuchen die ähnlich zu deiner Idee sind?

Ja, ich bin Spaß auf Parties...
Einheitliche Code Styles sind wichtig, gerade bei Open Source Projekten mit vielen Contributors.

Daher der Vorschlag GDScript Toolkit für styles / linting zu verwenden und ggf. auch eine GitHub Action anzulegen, die automatisch bei neuen PRs auf die Styles checked und ggf. den PR automatisch als invalid flagged (bis der Autor eben nachgebessert hat und alles tutti ist)

Ich denke, Suffragium braucht einen einheitlichen Stil z.b. Pixelart mit vordefinierter Pixelgröße und Farbpalette.

Godot wird, so habe ich das Gefühl, für seine 3D fähigkeiten eher belächelt.
Aber vielleicht könnte das ja ein Ziel sein. Anderen zu zeigen wie schön Godot auch in 3D sein kann.

Webhooktest

webhooktest