text:
Definition of variables for email

Description
I want to set the variables so that the boxes "Require Email Conformation to Register" and "Enable Email Notifications" are checked automatically.
I defined in a .env file in docker the following:
GITEA__service__REGISTER_EMAIL_CONFIRM="true" -> Is "Require Email Confirmation to Register" ?
GITEA__service__ENABLE_NOTIFY_MAIL="true" -> Is "Enable Email Notifications" ?
Screenshots
Checkboxes:

Gitea Version
Docker image: gitea/gitea:1.17.3-rootless
Can you reproduce the bug on the Gitea demo site?
No
Operating System
Host Docker: Ubuntu 22.04
Browser Version
Mozilla Firefox 106.0.1 (64 Bits) e Google Chrome 106.0.5249.103 (64 Bits)

To understand you better
This is on the install page?
If yes, then why not just use a default app.ini and then there is no install step needed
If no, I don't know what you mean with this
I'm not by any means a member of the team or something, I'm just curios to know the problem

authors: cairoapcampos zokkis


text:
The link of org people/member page

Feature Description
Org people page's link is domain/org/{OrgName}/members.
Maybe domain/org/{OrgName}/people is better or just change the tab name from People to Members?
Screenshots
No response

I prefer renaming People to Memers, it's always Memers in the code.
BTW, if somebody can help rename it, please change the icon too, it looks like buildings.

source: gharchive/issue

repo: go-gitea/gitea

license: MIT

license_type: permissive

license_source: github-api


text:
Gitea backup / dump operation is confusing to use

Description
I wasn't sure if I should classify this as a bug, feature request, or simply a request for clarification in the documentation. I'm going to just outline my expectations wrt using the backup / dump tool, and then describe various things I tried which did not work.
Expectation:
I expected that the gitea dump command would do one of two things: create a dump file in the current working folder, or create a dump file in a specific folder of my choosing based on a command line parameter, something like gitea dump --outputfile=/path/to/file.zip)
Actual:
Running gitea dump with no command line arguments resulted in a "permission denied" error. I then realized that I was running the command from a local users home folder, which likely wasn't accessible to gitea or the default user the app is configured use (ie: git in my case).
So then I tried creating a new folder will full write permission, and owned by the git user:
sudo mkdir /test
sudo chown git:git /test
sudo chmod 777 /test
cd /test
gitea dump

This also resulted in a permission denied error
Given that I had previously experienced some unusual permission issues with the app before, I thought maybe I was hitting something similar here, so I decided to switch to the system /tmp folder and rerun my test:
cd /tmp
gitea dump

To which I was happy to see a successful result: 2023/10/04 00:50:33 cmd/dump.go:423:runDump() [I] Finish dumping in file gitea-dump-1696380633.zip. Then I decided to take a closer look at the generated output file:
$/tmp ls -alh gitea-dump-1696380633.zip
ls: cannot access 'gitea-dump-1696380633.zip': No such file or directory

Ok - so this is weird. First thought: where did the dump file go? I then try sudo find . -name "gitea-dump-1696380633.zip" 2>/dev/null and I find ./snap-private-tmp/snap.gitea/tmp/gitea-dump-1696380633.zip. Ok - this is weird, but still at least it sort of worked. But I'd rather have the file placed in a folder of my choosing, and maybe even named something that I can find more easily.
So next I start looking at the command line parameters for the dump command - maybe there's something in there I can use. I see two options that look like potential candidates: --file and --tempdir.
So I start by testing out the --tempdir option. For kicks I change directories back into my home folder for this test, and do:
cd ~
gitea dump --tempdir /test

and again, more permission errors.... ... so then I try the --file option, as in:
gitea dump --file=/test/output.zip

for which I get yet another permission error: 2023/10/04 01:09:15 cmd/dump.go:166:fatal() [F] Unable to open /test/output.zip: open /est/output.zip: no such file or directory.... Ok - I'm about to give up by now.
Working Solution
For now I've managed to get my backup script sort of working by using the "-" option to redirect the output from the dump operation to stdout, which then allows me to store the output anywhere I want, as in:
gitea dump --file - > /path/to/my/backup.zip

Suggestion
I'd recommend one of the following two courses of action:

make the dump command more intuitive to use so it "just works"
update the documentation to better explain what the various options are for the dump command, and provide examples of how they are intended to work.

Gitea Version
Gitea version 1.20.5 built with GNU Make 4.3, go1.21.1 : bindata, sqlite, sqlite_unlock_notify, pam, cert
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
No response
Screenshots
No response
Git Version
git version 2.34.1
Operating System
Ubuntu 22.04.3 LTS
How are you running Gitea?
Command line
Database
SQLite

Actually, the command is intuitive if the Gitea is built from the source. The problem is about the snap package and its security model. I would recommend installing Gitea from binary, source, or docker. And I agree the doc should be updated.

So, last night I tried downloading the binary package for Gitea and installing it manually, and pretty much all of my issues disappeared, including those I've described above. So the root cause of many of my problems were directly related to ridiculous permission problems with the snap package.
Given how many problems seem to be specific to that particular package, maybe it would be prudent to have an entire section in the users docs just for snap, warning people about all the things that don't work using that config. :p
Either way, I appreciate the prompt replies and keep up the great work on the project!

see https://github.com/go-gitea/gitea/issues/27420#issuecomment-1775338951


text:
Create a file with too many lines from web ui will get Invalid CSRF token. error

Description
Reproduce:
Create a new file in browser, then input some texts, and copy paste them, if there's several million lines, it maybe very slow, but you can click commit. then you will see Invalid CSRF token. error
Gitea Version
latest
Can you reproduce the bug on the Gitea demo site?
No
Log Gist
No response
Screenshots
No response
Git Version
No response
Operating System
No response
How are you running Gitea?
build
Database
None

error log:

Well, does it make sense? If there were billions or even more of lines, your browser could also crash, your disk could be full-filled, your OS could stop responding, etc.

I can not find out what happened, as the dev tools crashed. So, for recording it, I created this issue.
Is it a way to improve or can we do something better. e.g. limit the max lines?

Most likely that the form is too big (or corrupted) then backend fails to parse it correctly to get csrf.

Most code in Gitea doesn't work with large form, because the default limit of a form size is 32M

Anything need to keep this issue open?


text:
[docs] Enhance container selection in docker dump

The problem with the previous query was, that it sometimes selected multiple containers, which make the command respond with a hard to understand error message.
With this regular expression only the container is selected with the exact name.

Codecov Report

Merging #14292 (5d0cf17) into master (d989247) will decrease coverage by 0.00%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master   #14292      +/-   ##
==========================================
- Coverage   41.78%   41.78%   -0.01%
==========================================
  Files         743      743
  Lines       79464    79464
==========================================
- Hits        33207    33206       -1
- Misses      40792    40794       +2
+ Partials     5465     5464       -1

Impacted Files
Coverage Δ

modules/git/tree_nogogit.go
60.86% <0.00%> (-8.70%)
:arrow_down:

modules/charset/charset.go
68.53% <0.00%> (-4.50%)
:arrow_down:

modules/git/repo_language_stats_nogogit.go
57.44% <0.00%> (-4.26%)
:arrow_down:

modules/indexer/stats/db.go
56.00% <0.00%> (-4.00%)
:arrow_down:

models/unit.go
46.57% <0.00%> (-2.74%)
:arrow_down:

services/pull/pull.go
43.06% <0.00%> (+0.49%)
:arrow_up:

modules/queue/workerpool.go
60.00% <0.00%> (+1.22%)
:arrow_up:

modules/process/manager.go
75.00% <0.00%> (+2.50%)
:arrow_up:

modules/git/utils.go
80.55% <0.00%> (+2.77%)
:arrow_up:

modules/git/repo_base_nogogit.go
72.72% <0.00%> (+9.09%)
: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 d989247...5d0cf17. Read the comment docs.

Codecov Report

Merging #14292 (5d0cf17) into master (d989247) will decrease coverage by 0.00%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master   #14292      +/-   ##
==========================================
- Coverage   41.78%   41.78%   -0.01%
==========================================
  Files         743      743
  Lines       79464    79464
==========================================
- Hits        33207    33206       -1
- Misses      40792    40794       +2
+ Partials     5465     5464       -1

Impacted Files
Coverage Δ

modules/git/tree_nogogit.go
60.86% <0.00%> (-8.70%)
:arrow_down:

modules/charset/charset.go
68.53% <0.00%> (-4.50%)
:arrow_down:

modules/git/repo_language_stats_nogogit.go
57.44% <0.00%> (-4.26%)
:arrow_down:

modules/indexer/stats/db.go
56.00% <0.00%> (-4.00%)
:arrow_down:

models/unit.go
46.57% <0.00%> (-2.74%)
:arrow_down:

services/pull/pull.go
43.06% <0.00%> (+0.49%)
:arrow_up:

modules/queue/workerpool.go
60.00% <0.00%> (+1.22%)
:arrow_up:

modules/process/manager.go
75.00% <0.00%> (+2.50%)
:arrow_up:

modules/git/utils.go
80.55% <0.00%> (+2.77%)
:arrow_up:

modules/git/repo_base_nogogit.go
72.72% <0.00%> (+9.09%)
: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 d989247...5d0cf17. Read the comment docs.

@openscript Any update?

@lunny I'll check it today and give some feedback :)

@lunny I can verify that it works without the quotes. This is I usually do my backups:

Create a new backup  docker exec -u git -it -w /tmp $(docker ps -qf name=^/gitea$) bash -c '/app/gitea/gitea dump -c /data/gitea/conf/app.ini -f gitea-backup.zip'
Copy backup  docker cp $(docker ps -qf name=^/gitea$):/tmp/gitea-backup.zip .
Rename backup file  mv gitea-backup.zip gitea-backup-$(date "+%Y%m%d-%H%M%S").zip

Maybe this section in the documentation can be enhanced further. When no file name for the dump is specified, a timestamp will be used. So you need to go into the container to find the actual file name.

Without quotes it is shell dependent. Bash works fine but zsh definitely will not.

I think @delvh 's suggestion is pretty good. So, approve and move on?

source: gharchive/pull-request

authors: codecov-io lunny openscript wxiaoguang zeripath


text:
Allow custom default merge message with .gitea/default_merge_message/<merge_style>_TEMPLATE.md

Fix #11089

Just my two cents here:
Would it not be better to move these to a .gitea/merge_message subfolder?  This allows for less clutter in the main .gitea subdirectory and also allows for a common prefix to become a subfolder thereby making the system more usable.
Again, I'm not qualified to make this decision, I'm just taking inspiration from how GitHub handles their files (.github/workflows/*.yml instead of .github/workflow_*.yml and .github/issue_template/*.yml instead of .github/issue_template_*.yml)

LGTM please!

If I understand the changes correct, then this is a per repo option, not an instance wide option like zeripath suggested right?

@MarkusAmshove correct.

I think all review requests have been resolved. Please review again. @zeripath

CI failure is related.
The problem is occurring because the HeadRepo can be deleted at the time of merging.

[E] [6276b3d1-274] GetDefaultMergeMessage: repository does not exist [id: 91, uid: 0, owner_name: , name: ]
integration tests ...

make L-G-T-M work.

authors: 6543 MarkusAmshove delvh lunny redstonedesigner sprnza zeripath


text:
Use own Go version instead of hardcoded 1.17 for make fmt

We should make sure we're using the same version across the codebase.

We upgraded in #19918 but forgot about the following line https://github.com/go-gitea/gitea/blob/6bb6a108e0c03b323402b452fc05c6845f7d00df/build/code-batch-process.go#L273

This whole code-batch-process.go thing seems rather insane to me. I'd rather have us run gofumpt directly which is should work much better in regards to editor integrations and such.
The canonical way of gofumpt of specifying go version to gofumpt is through -lang, so I would replicate that. SeeMIN_GO_VERSION in the Makefile.
go run mvdan.cc/gofumpt@latest --help |& grep lang
  -lang       str    target Go version in the form "1.X" (default from go.mod)

I do not like the code-batch-process.go either, but at that time it's needed for Windows developers to run make fmt.
Not sure whether the situation (eco-system) has been better now, if the code-batch-process.go is unnecessary any more, remove it.

https://github.com/go-gitea/gitea/pull/20952#issuecomment-1226863706

well i dont understand why one would programm on windows, but there are always the one who are forced to do so ... :/

Sounds good to me, until then we can land thia

🚀

It seems that the only need for the code-batch-process is misspell, which still takes a file list as arguments.

It also runs the gitea import formatter.

It seems that the only need for the code-batch-process is misspell, which still takes a file list as arguments.

It also runs the gitea import formatter.

Yup, I meant "which still takes a file list as arguments.", only the old misspell command needs it.
For gitea import formatter, it could be simplified to scan the source directory directly, no need for the code-batch-process wrapper anymore.
I think it's time to drop the code-batch-process wrapper (I will take the work)

--> Remove code-batch-process https://github.com/go-gitea/gitea/pull/21471

authors: 6543 silverwind wxiaoguang yardenshoham zeripath


text:
Fix author name alignment in commits table

Fixes https://github.com/go-gitea/gitea/issues/30129 by introducing a wrapper div with flexbox that collapses any inter-tag whitespace within. View diff with whitespace hidden.
Author names aligned:

Vertically centered on expand:

Ellipsis works:

I was unable to create a backport for 1.22. @silverwind, please send one manually. :tea:
go run ./contrib/backport 30396
...  // fix git conflicts if any
go run ./contrib/backport --continue

authors: GiteaBot silverwind


text:
How to JOIN with a table which have a reserved word as its table name?

Your Question
I can't JOIN that table. When I use Joins("`lines`"), it still generate as JOIN lines. It ate the ` . So it always gives an error.
The document you expected this should be explained
There is no words about this.
Expected answer
I can do that.

I found out that I got the documentation wrong, I initially thought it would automatically associate foreign keys.

repo: go-gorm/gorm


text:
[需求]backend支持https代理

现在版本只支持http代理转发，希望支持https转发。谢谢

+1

repo: go-kratos/gateway


text:
Refactor TUI

Check for existing issues
检查是否已存在相同issue

[X] Completed/已检查

Describe the feature
描述你的新功能
在现有架构下，无论是#248 还是 #247 都无法轻易实现，因为各个模块之间耦合较强。请问如果我帮助重写UI并且采用BubbleTea的严格MVC架构，作者会接受PR吗？

上游库也是自己维护的，加个判断就完了...
不使用bubbletea的render是为了避免全屏刷新，一方面是减少太多无用刷新，另一方面全屏刷新可能会导致一些终端出现闪烁
至于daemon，我觉得更重要的是server和client的通信协议设计，代码只是小头，之前没实现只是我确实没有这个使用场景，引入的代价远大于使用价值

但是似乎所有UI相关的功能都可能要改写上游库吧……

authors: anhoder glyh

repo: go-musicfox/go-musicfox


text:
Step is scrubbed when status is used in ruleset without "pending"

When you define a step with ruleset such as:
ruleset:
  status: [success, failure]

the step is scrubbed from ever running.
Currently, you have to supply pending as a status for it to not get scrubbed at compile time, like:
ruleset:
  status: [success, failure, pending]

Consider dropping the need to supply pending since it really works a bit differently conceptually than the other values.
Possible solutions:

don't check status for scrubbing
add pending automagically
others?

This PR contains this fix so users no longer need to provide "pending" in the status to have the ruleset not be scrubbed.
https://github.com/go-vela/types/pull/59

repo: go-vela/worker


text:
engine.Insert can not autocommit

engine.Insert can not autocommit
//test case:
package main
import (
	_ "github.com/pingcap/tidb"
	_ "github.com/go-xorm/tidb"
	"github.com/go-xorm/xorm"
	"fmt"
)

type A struct {
	Id   int
	Name string
	Pv   int64 `xorm:"default 1"`
}

type B struct {
	Id   int
	Name string
	Pv   int `xorm:"default 1"`
}

func main() {
	engine, err := xorm.NewEngine("tidb", "goleveldb://test/tidb")
	if err != nil {
		panic(err)
	}
	//create table
	engine.Sync2(new(A))
	engine.Sync2(new(B))

	//query data
	fmt.Println("-------begin query------")
	//should be 0 if the first run---but every time you run the code, it still 1(it only autocommit when db created)
	fmt.Println(engine.Count(new(A)))
	fmt.Println(engine.Count(new(B)))
	//adding data

	fmt.Println("-------adding data------")
	a := &A{Name:"ElvizLai"}
	b := &B{Name:"ElvizLai"}

	engine.Insert(a)
	engine.Insert(b)

	return
	sess := engine.NewSession()
	sess.Begin()
	sess.InsertOne(a)
	sess.InsertOne(b)
	fmt.Println(sess.Commit())
}

Hi, I have copied the code and run in my macbook.
-------begin query------
0 <nil>
0 <nil>
-------adding data------

I think there is no error occupied this time.

@lunny every time the code runs, it inserted a and b to database. But it only succeed for the first run. From TiDB log, it show's the second time run missing autocommit

I open the tidb's log. It seems it's ok.
2015/11/20 09:17:49 kv.go:80: [info] New store test/tidb
2015/11/20 09:17:49 kv.go:115: [debug] Begin txn:1
2015/11/20 09:17:49 txn.go:138: [debug] seek mDB: txn:1
2015/11/20 09:17:49 txn.go:213: [info] commit txn 1
2015/11/20 09:17:49 tidb.go:88: [debug] compiling use tidb
2015/11/20 09:17:49 tidb.go:101: [debug] compiling prepared SELECT `TABLE_NAME`, `ENGINE`, `TABLE_ROWS`, `AUTO_INCREMENT` from `INFORMATION_SCHEMA`.`TABLES` WHERE `TABLE_SCHEMA`=? AND (`ENGINE`='MyISAM' OR `ENGINE` = 'InnoDB')
2015/11/20 09:17:49 select.go:209: [info] SelectStmt trx:
[xorm] [info]  2015/11/20 09:17:49.881813 [sql] SELECT `TABLE_NAME`, `ENGINE`, `TABLE_ROWS`, `AUTO_INCREMENT` from `INFORMATION_SCHEMA`.`TABLES` WHERE `TABLE_SCHEMA`=? AND (`ENGINE`='MyISAM' OR `ENGINE` = 'InnoDB') [tidb]
2015/11/20 09:17:49 tidb.go:101: [debug] compiling prepared SELECT `COLUMN_NAME`, `IS_NULLABLE`, `COLUMN_DEFAULT`, `COLUMN_TYPE`, `COLUMN_KEY`, `EXTRA` FROM `INFORMATION_SCHEMA`.`COLUMNS` WHERE `TABLE_SCHEMA` = ? AND `TABLE_NAME` = ?
2015/11/20 09:17:49 select.go:209: [info] SelectStmt trx:
[xorm] [info]  2015/11/20 09:17:49.883490 [sql] SELECT `COLUMN_NAME`, `IS_NULLABLE`, `COLUMN_DEFAULT`, `COLUMN_TYPE`, `COLUMN_KEY`, `EXTRA` FROM `INFORMATION_SCHEMA`.`COLUMNS` WHERE `TABLE_SCHEMA` = ? AND `TABLE_NAME` = ? [tidb a]
2015/11/20 09:17:49 tidb.go:101: [debug] compiling prepared SELECT `INDEX_NAME`, `NON_UNIQUE`, `COLUMN_NAME` FROM `INFORMATION_SCHEMA`.`STATISTICS` WHERE `TABLE_SCHEMA` = ? AND `TABLE_NAME` = ?
2015/11/20 09:17:49 select.go:209: [info] SelectStmt trx:
[xorm] [info]  2015/11/20 09:17:49.883976 [sql] SELECT `INDEX_NAME`, `NON_UNIQUE`, `COLUMN_NAME` FROM `INFORMATION_SCHEMA`.`STATISTICS` WHERE `TABLE_SCHEMA` = ? AND `TABLE_NAME` = ? [tidb a]
2015/11/20 09:17:49 select.go:209: [info] SelectStmt trx:
[xorm] [info]  2015/11/20 09:17:49.884139 [sql] SELECT `COLUMN_NAME`, `IS_NULLABLE`, `COLUMN_DEFAULT`, `COLUMN_TYPE`, `COLUMN_KEY`, `EXTRA` FROM `INFORMATION_SCHEMA`.`COLUMNS` WHERE `TABLE_SCHEMA` = ? AND `TABLE_NAME` = ? [tidb b]
2015/11/20 09:17:49 select.go:209: [info] SelectStmt trx:
[xorm] [info]  2015/11/20 09:17:49.884405 [sql] SELECT `INDEX_NAME`, `NON_UNIQUE`, `COLUMN_NAME` FROM `INFORMATION_SCHEMA`.`STATISTICS` WHERE `TABLE_SCHEMA` = ? AND `TABLE_NAME` = ? [tidb b]
2015/11/20 09:17:49 select.go:209: [info] SelectStmt trx:
[xorm] [info]  2015/11/20 09:17:49.884669 [sql] SELECT `TABLE_NAME`, `ENGINE`, `TABLE_ROWS`, `AUTO_INCREMENT` from `INFORMATION_SCHEMA`.`TABLES` WHERE `TABLE_SCHEMA`=? AND (`ENGINE`='MyISAM' OR `ENGINE` = 'InnoDB') [tidb]
2015/11/20 09:17:49 select.go:209: [info] SelectStmt trx:
[xorm] [info]  2015/11/20 09:17:49.884912 [sql] SELECT `COLUMN_NAME`, `IS_NULLABLE`, `COLUMN_DEFAULT`, `COLUMN_TYPE`, `COLUMN_KEY`, `EXTRA` FROM `INFORMATION_SCHEMA`.`COLUMNS` WHERE `TABLE_SCHEMA` = ? AND `TABLE_NAME` = ? [tidb a]
2015/11/20 09:17:49 select.go:209: [info] SelectStmt trx:
[xorm] [info]  2015/11/20 09:17:49.885152 [sql] SELECT `INDEX_NAME`, `NON_UNIQUE`, `COLUMN_NAME` FROM `INFORMATION_SCHEMA`.`STATISTICS` WHERE `TABLE_SCHEMA` = ? AND `TABLE_NAME` = ? [tidb a]
2015/11/20 09:17:49 select.go:209: [info] SelectStmt trx:
[xorm] [info]  2015/11/20 09:17:49.885315 [sql] SELECT `COLUMN_NAME`, `IS_NULLABLE`, `COLUMN_DEFAULT`, `COLUMN_TYPE`, `COLUMN_KEY`, `EXTRA` FROM `INFORMATION_SCHEMA`.`COLUMNS` WHERE `TABLE_SCHEMA` = ? AND `TABLE_NAME` = ? [tidb b]
2015/11/20 09:17:49 select.go:209: [info] SelectStmt trx:
[xorm] [info]  2015/11/20 09:17:49.885625 [sql] SELECT `INDEX_NAME`, `NON_UNIQUE`, `COLUMN_NAME` FROM `INFORMATION_SCHEMA`.`STATISTICS` WHERE `TABLE_SCHEMA` = ? AND `TABLE_NAME` = ? [tidb b]
-------begin query------
2015/11/20 09:17:49 tidb.go:101: [debug] compiling prepared SELECT count(*) FROM `a`
2015/11/20 09:17:49 select.go:209: [info] SelectStmt trx:
2015/11/20 09:17:49 kv.go:115: [debug] Begin txn:2
2015/11/20 09:17:49 session.go:319: [warning] New txn:2 in session:1
2015/11/20 09:17:49 txn.go:138: [debug] seek 5_rsd txn:2
2015/11/20 09:17:49 txn.go:108: [debug] get key:5_rsdd, txn:2
2015/11/20 09:17:49 txn.go:108: [debug] get key:5_rsdd, txn:2
2015/11/20 09:17:49 txn.go:108: [debug] get key:5_rsdd, txn:2
2015/11/20 09:17:49 txn.go:213: [info] commit txn 2
1 <nil>
2015/11/20 09:17:49 tidb.go:101: [debug] compiling prepared SELECT count(*) FROM `b`
2015/11/20 09:17:49 select.go:209: [info] SelectStmt trx:
2015/11/20 09:17:49 kv.go:115: [debug] Begin txn:3
2015/11/20 09:17:49 session.go:319: [warning] New txn:3 in session:1
2015/11/20 09:17:49 txn.go:138: [debug] seek 9_rsd txn:3
2015/11/20 09:17:49 txn.go:108: [debug] get key:9_rsdd, txn:3
2015/11/20 09:17:49 txn.go:108: [debug] get key:9_rsdd, txn:3
2015/11/20 09:17:49 txn.go:108: [debug] get key:9_sdd, txn:3
2015/11/20 09:17:49 txn.go:213: [info] commit txn 3
1 <nil>
-------adding data------
2015/11/20 09:17:49 tidb.go:101: [debug] compiling prepared INSERT INTO `a` (`id`, `name`, `pv`) VALUES (?, ?, ?)
2015/11/20 09:17:49 kv.go:115: [debug] Begin txn:4
2015/11/20 09:17:49 txn.go:69: [debug] Inc mTable::5_autoID, step 1000 txn:4
2015/11/20 09:17:49 txn.go:213: [info] commit txn 4
2015/11/20 09:17:49 autoid.go:70: [info] Alloc id 1001, table ID:5, from 0xc820666cc0, store ID:98d9a00b-2120-46b2-a037-41045c4efd7d
2015/11/20 09:17:49 kv.go:115: [debug] Begin txn:5
2015/11/20 09:17:49 session.go:319: [warning] New txn:5 in session:1
2015/11/20 09:17:49 txn.go:132: [debug] set key:5_r�sd, txn:5
2015/11/20 09:17:49 txn.go:132: [debug] set key:5_r�sdd, txn:5
2015/11/20 09:17:49 txn.go:132: [debug] set key:5_r�sdd, txn:5
2015/11/20 09:17:49 txn.go:132: [debug] set key:5_r�sdd, txn:5
2015/11/20 09:17:49 txn.go:213: [info] commit txn 5
2015/11/20 09:17:49 tidb.go:101: [debug] compiling prepared INSERT INTO `b` (`id`, `name`, `pv`) VALUES (?, ?, ?)
2015/11/20 09:17:49 kv.go:115: [debug] Begin txn:6
2015/11/20 09:17:49 txn.go:69: [debug] Inc mTable::9_autoID, step 1000 txn:6
2015/11/20 09:17:49 txn.go:213: [info] commit txn 6
2015/11/20 09:17:49 autoid.go:70: [info] Alloc id 1001, table ID:9, from 0xc820666cf0, store ID:98d9a00b-2120-46b2-a037-41045c4efd7d
2015/11/20 09:17:49 kv.go:115: [debug] Begin txn:7
2015/11/20 09:17:49 session.go:319: [warning] New txn:7 in session:1
2015/11/20 09:17:49 txn.go:132: [debug] set key:9_r�sd, txn:7
2015/11/20 09:17:49 txn.go:132: [debug] set key:9_r�sdd, txn:7
2015/11/20 09:17:49 txn.go:132: [debug] set key:9_r�sdd, txn:7
2015/11/20 09:17:49 txn.go:132: [debug] set key:9_rsdd, txn:7
2015/11/20 09:17:49 txn.go:213: [info] commit txn 7

And @ngaut, What's the Engine column's value on INFORMATION_SCHEMA.TABLES, 'MyISAM' OR  'InnoDB' or others?

@lunny
check your log, there are not autocommit, it just insert to memory,but not commit.
2015/11/20 10:15:14 tidb.go:148: [debug] compiling prepared INSERT INTO `b` (`id`, `name`, `pv`) VALUES (?, ?, ?)
2015/11/20 10:15:14 kv.go:162: [debug] Begin txn:379580767087624194
2015/11/20 10:15:14 txn.go:109: [debug] get key:"\x00mDBs\x00\x01\x11hmDB:60\x00\x01", txn:379580767087624194
2015/11/20 10:15:14 txn.go:109: [debug] get key:"\x00mDB:60\x00\x01\x11hmTable:68\x00\x01", txn:379580767087624194
2015/11/20 10:15:14 txn.go:109: [debug] get key:"\x00mDB:60\x00\x01\x11hmTID:68\x00\x01", txn:379580767087624194
2015/11/20 10:15:14 txn.go:146: [debug] set key:"\x00mDB:60\x00\x01\x11hmTID:68\x00\x01", txn:379580767087624194
2015/11/20 10:15:14 txn.go:109: [debug] get key:"\x00mDB:60\x00\x01\x11H", txn:379580767087624194
2015/11/20 10:15:14 txn.go:146: [debug] set key:"\x00mDB:60\x00\x01\x11H", txn:379580767087624194
2015/11/20 10:15:14 txn.go:244: [info] commit txn 379580767087624194
2015/11/20 10:15:14 autoid.go:71: [info] Alloc id 1, table ID:68, from 0xc820209a40, database ID:60
2015/11/20 10:15:14 kv.go:162: [debug] Begin txn:379580767087886336
2015/11/20 10:15:14 tidb.go:125: [debug] compiling SELECT VARIABLE_VALUE FROM mysql.GLOBAL_VARIABLES WHERE VARIABLE_NAME="autocommit";
2015/11/20 10:15:14 session.go:267: [debug] Executing SELECT VARIABLE_VALUE FROM mysql.GLOBAL_VARIABLES WHERE VARIABLE_NAME="autocommit"; [SELECT VARIABLE_VALUE FROM mysql.GLOBAL_VARIABLES WHERE VARIABLE_NAME="autocommit";]

So that maybe it's a driver's problem? @ngaut

Thanks @lunny
I will take a look.

Fixed! Thanks @lunny  @ElvizLai
Please update tidb and try again

I think maybe we can close this issue. @ElvizLai

Done

authors: ElvizLai lunny ngaut

repo: go-xorm/tidb


text:
xorm - 4.3 - panic: gob: registering duplicate names for models

I am getting the below exception with xorm - 4.3 and golang 1.4.2. Any idea what could be going wrong? Is this some known issue xorm - 4.3 or some thing other going wrong?
panic: gob: registering duplicate names for models.SalesOrderItemAttribute: "*models.SalesOrderItemAttribute" != "order-subscriber/models.SalesOrderItemAttribute"

goroutine 71 [running]:
encoding/gob.RegisterName(0xc208120750, 0x2f, 0x9d0cc0, 0xc2084dafc0)
	/usr/local/go/src/encoding/gob/type.go:832 +0x568
encoding/gob.Register(0x9d0cc0, 0xc2084dafc0)
	/usr/local/go/src/encoding/gob/type.go:884 +0x20f
github.com/go-xorm/xorm.(*Engine).GobRegister(0xc20856e3f0, 0x9d0cc0, 0xc2084dafc0, 0x9d0cc0)
	/home/jabong-release/go/src/github.com/go-xorm/xorm/engine.go:679 +0x32
github.com/go-xorm/xorm.(*Engine).autoMapType(0xc20856e3f0, 0x9d0cc0, 0xc2084dafc0, 0x59, 0x59)
	/home/jabong-release/go/src/github.com/go-xorm/xorm/engine.go:670 +0x290
github.com/go-xorm/xorm.(*Session).innerInsertMulti(0xc208606fc0, 0x86d0c0, 0xc2081f5e80, 0x8, 0x0, 0x0)
	/home/jabong-release/go/src/github.com/go-xorm/xorm/session.go:2071 +0x30c
github.com/go-xorm/xorm.(*Session).Insert(0xc208606fc0, 0xc2086153a0, 0x1, 0x1, 0x0, 0x0, 0x0)
	/home/jabong-release/go/src/github.com/go-xorm/xorm/session.go:2034 +0x260
github.com/go-xorm/xorm.(*Engine).Insert(0xc20856e3f0, 0xc2086153a0, 0x1, 0x1, 0x0, 0x0, 0x0)
	/home/jabong-release/go/src/github.com/go-xorm/xorm/engine.go:1284 +0x99
order-subscriber/dao.InsertItemAttributes(0xc208223180, 0x8, 0xa, 0x0, 0x0, 0xd5a938, 0x0, 0xd5a938, 0x0, 0xd5a938, ...)
	/var/lib/jenkins/jobs/CI_order-subscriber_pkg_creation/workspace/src/order-subscriber/dao/dao.go:236 +0x35d

The code that is throwing that error looks something like below:-
func InsertItemAttributes(data []Model.SalesOrderItemAttribute, rc utilhttp.RequestContext, logKey string) error {
	prf := logger.NewProfiler()
	dataDogAgent := monitor.GetInstance()
	logger.StartProfile(prf, "insert_order_item_attributes")
	xEngine, _ := utils.GetInstance().Orm(true)
	//	xEngine.ShowSQL = true

	logger.InfoSpecific(logKey, "Trying to insert item attributes : ", data)
	_, err := xEngine.Insert(&data)
...

The structure SalesOrderItemAttribute looks something like below:-
type SalesOrderItemAttribute struct {
	IdSalesOrderItemAttribute int       `xorm:"not null pk autoincr INT(10)"`
	FkSalesOrderAttributeSet  int       `xorm:"not null index INT(10)"`
	FkSalesOrderItem          int       `xorm:"not null index INT(10)"`
	Value                     string    `xorm:"not null VARCHAR(255)"`
	CreatedAt                 time.Time `xorm:"index DATETIME"`
	UpdatedAt                 time.Time `xorm:"not null default 'CURRENT_TIMESTAMP' TIMESTAMP"`
}

Hi, this is because xorm will register the struct to gob automatically for cache use. If you have register it on the same application, gob will panic.

Can you please explain a bit more? I did not register it in gob again on the same application. The code that is throwing the error is the above.

Is the issue related to the below issue:-
https://groups.google.com/forum/#!topic/golang-nuts/VnFs2Cv0_UY
If yes how can I get around this?

OK. I see, maybe your problem is "*models.SalesOrderItemAttribute" != "order-subscriber/models.SalesOrderItemAttribute".
You imported the same struct from different code copy or path.

Hmm ... I checked the code path but that is not the case. Also if that is the issue then the issue would have come every time.
Is the issue related to this because when it is failing  * SalesOrderItemAttribute.IdSalesOrderItemAttribute is also having value 0.

authors: debraj-manna debraj-manna-jabong lunny

repo: go-xorm/xorm

license_source: bigquery


text:
Case insensitive match?

I asked in the lefthook project about case insensitivity and was pointed here.
Is it possible to do a case insensitive match?

It's easy to case fold / lowercase the pattern and match string before matching.

Ah, ok. So it's not supported in the match string somehow - it would require code changes to lefthook.
Thanks!

authors: asmaloney calmh

repo: gobwas/glob

license: mit


text:
perf: General optimizations and parameter tuning research

Background
Following PR #35, there has been room for optimization. This PR contains the research needed in order to subsequently introduce some of those optimizations
Change List

A new notebook
code used in notebook to compare performance before and after optimization

I'm not sure what the best course of action for the SonarCloud check is. It's yelling because I've duplicated parts of the current version into the notebooks/ directory in order to make a before and after comparison of performance.
Perhaps I should instead include the diff? I can continue to use the CSVs to populate the results of the notebook (will complicate reproducibility, though

Besides, can we keep the performance comparison as an internal PDR?

I think the parameter tuning should be included here, but I can live without including the other stuff. The reason the rest of the optimizations were included was because it would have been impractical to tune those parameters without faster code. I'll just close the PR and we can return to the parameter after it's merged

I'll just put out a regular PR for the numpy optimizations, and we can circle back to the notebook after that's merged to justify the choice of parameters

repo: godaddy/sample-size


text:
Query is returning null

3.2.2 Godot
windows10
payment.queryPurchases() is returning null.
Although purchased_updated do return the info with token

Hi!
Can you post the code you're using to query purchases please?

IAP
extends Node

var payment

signal query_completed
signal purchases_success
signal consume_success
signal buy_error

func _ready():
	if Engine.has_singleton("GodotGooglePlayBilling"):
		payment = Engine.get_singleton("GodotGooglePlayBilling")

	 # These are all signals supported by the API
		# You can drop some of these based on your needs
		payment.connect("connected", self, "_on_connected") # No params
		payment.connect("disconnected", self, "_on_disconnected") # No params
#		payment.connect("connect_error", self, "_on_connect_error") # Response ID (int), Debug message (string)
		payment.connect("purchases_updated", self, "_on_purchases_updated") # Purchases (Dictionary[])
		payment.connect("purchase_error", self, "_on_purchase_error") # Response ID (int), Debug message (string)
		payment.connect("sku_details_query_completed", self, "_on_sku_details_query_completed") # SKUs (Dictionary[])
		payment.connect("sku_details_query_error", self, "_on_sku_details_query_error") # Response ID (int), Debug message (string), Queried SKUs (string[])
#		payment.connect("purchase_acknowledged", self, "_on_purchase_acknowledged") # Purchase token (string)
#		payment.connect("purchase_acknowledgement_error", self, "_on_purchase_acknowledgement_error") # Response ID (int), Debug message (string), Purchase token (string)
		payment.connect("purchase_consumed", self, "_on_purchase_consumed") # Purchase token (string)
		payment.connect("purchase_consumption_error", self, "_on_purchase_consumption_error") # Response ID (int), Debug message (string), Purchase token (string)

		payment.startConnection()
	else:
		print("Android IAP support is not enabled. Make sure you have enabled 'Custom Build' and the GodotGooglePlayBilling plugin in your Android export settings! IAP will not work.")

func purchase(item_name):
	if payment:
		# transaction_id could be any string that used for validation internally in java
		payment.purchase(item_name)
		print("purchased")

func _on_purchase_error():
	print("purchase error")
	emit_signal("buy_error")

func _on_purchases_updated(list):
	print(list)
	print("purchase updated")
	emit_signal("purchases_success")

func _on_consume_consumed():
	print("purchase consumed")
	emit_signal("consume_success")

func consume(item_name):
	var query = payment.queryPurchases()
	print(query)
	if query.status == OK:
		for purchase in query.purchases:
			if purchase.sku == String(item_name):
				if !purchase.is_acknowledged:
					payment.consumePurchase(purchase.purchase_token)
# Check the _on_purchase_consumed callback and give the user what they bought

func _on_purchase_consumption_error():
	print("consume error")

var sku_details:Dictionary = {}

func _on_connected():
	payment.querySkuDetails(["2000", "5000","9000","15000"], "inapp") # "subs" for subscriptions

func _on_sku_details_query_completed(sku_details_result):
	emit_signal("query_completed")
	for i in sku_details_result.size():

		match sku_details_result[i].sku :
			"2000": sku_details["2000"] = sku_details_result[i]
			"5000":sku_details["5000"] = sku_details_result[i]
			"9000":sku_details["9000"] = sku_details_result[i]
			"15000":sku_details["15000"] = sku_details_result[i]

It appears that I made a mistake while writing the docs: queryPurchases also takes a parameter like querySkuDetails that has to be either "inapp" or "subs". Going to fix that...

Fixed with https://github.com/godotengine/godot-docs/pull/3738

authors: gamergamesz timoschwarzer

repo: godotengine/godot-google-play-billing


text:
Crash while iterating on empty dict

Commit c937b1f5f9cdc50d109f78d8e039520c0dc60cad (from @karroffe ) has changed a lot of things within the Dictionary class (to make it ordered).
It seems since this, calling ->next() over an empty dict cause a crash:
* thread #1: tid = 3145, 0x0000000000ecef88 godot.x11.tools.64`PluginScript::reload(this=0x0000000008ccea70, p_keep_state=false) + 1452 at pluginscript_script.cpp:238, name = 'godot.x11.tools', stop reason = breakpoint 1.1
    frame #0: 0x0000000000ecef88 godot.x11.tools.64`PluginScript::reload(this=0x0000000008ccea70, p_keep_state=false) + 1452 at pluginscript_script.cpp:238
   235 		}
   236
   237 		Dictionary *members = (Dictionary *)&manifest.member_lines;
-> 238 		for (const Variant *key = members->next(); key != NULL; key = members->next(key)) {
   239 			_member_lines[*key] = (*members)[key];
   240 		}
   241 		Array *methods = (Array *)&manifest.methods;
(lldb) p members->size()
(int) $10 = 0
(lldb) n

   At: core/ordered_hash_map.h:108.
Process 3145 stopped
* thread #1: tid = 3145, 0x0000000002781ae4 godot.x11.tools.64`OrderedHashMap<Variant, Variant, _DictionaryVariantHash, HashMapComparatorDefault<Variant>, (unsigned char)3, (unsigned char)8>::Element::key(this=0x00007fffffffc720) const + 64 at ordered_hash_map.h:108, name = 'godot.x11.tools', stop reason = signal SIGILL: illegal instruction operand
    frame #0: 0x0000000002781ae4 godot.x11.tools.64`OrderedHashMap<Variant, Variant, _DictionaryVariantHash, HashMapComparatorDefault<Variant>, (unsigned char)3, (unsigned char)8>::Element::key(this=0x00007fffffffc720) const + 64 at ordered_hash_map.h:108
   105 			}
   106
   107 			const K &key() const {
-> 108 				CRASH_COND(!list_element);
   109 				return *(list_element->get().first);
   110 			};
   111
(lldb) n
handle_crash: Program crashed with signal 4
Dumping the backtrace. Please include this when reporting the bug on https://github.com/godotengine/godot/issues
Process 3145 stopped and restarted: thread 1 received signal: SIGCHLD
[1] /lib/x86_64-linux-gnu/libc.so.6(+0x354b0) [0x7ffff4cd14b0] (??:0)
Process 3145 stopped and restarted: thread 1 received signal: SIGCHLD
[2] OrderedHashMap<Variant, Variant, _DictionaryVariantHash, HashMapComparatorDefault<Variant>, (unsigned char)3, (unsigned char)8>::Element::key() const (/home/emmanuel/projects/godot-python/godot/core/ordered_hash_map.h:108 (discriminator 1))
Process 3145 stopped and restarted: thread 1 received signal: SIGCHLD
[3] Dictionary::next(Variant const*) const (/home/emmanuel/projects/godot-python/godot/core/dictionary.cpp:207)
Process 3145 stopped and restarted: thread 1 received signal: SIGCHLD
[4] PluginScript::reload(bool) (/home/emmanuel/projects/godot-python/godot/modules/gdnative/pluginscript/pluginscript_script.cpp:238)
Process 3145 stopped and restarted: thread 1 received signal: SIGCHLD
[5] ResourceFormatLoaderPluginScript::load(String const&, String const&, Error*) (/home/emmanuel/projects/godot-python/godot/modules/gdnative/pluginscript/pluginscript_loader.cpp:58)
Process 3145 stopped and restarted: thread 1 received signal: SIGCHLD
[6] ResourceLoader::_load(String const&, String const&, String const&, bool, Error*) (/home/emmanuel/projects/godot-python/godot/core/io/resource_loader.cpp:171 (discriminator 7))
Process 3145 stopped and restarted: thread 1 received signal: SIGCHLD
[7] ResourceLoader::load(String const&, String const&, bool, Error*) (/home/emmanuel/projects/godot-python/godot/core/io/resource_loader.cpp:217)
Process 3145 stopped and restarted: thread 1 received signal: SIGCHLD
[8] ScriptEditor::set_window_layout(Ref<ConfigFile>) (/home/emmanuel/projects/godot-python/godot/editor/plugins/script_editor_plugin.cpp:2226 (discriminator 2))
Process 3145 stopped and restarted: thread 1 received signal: SIGCHLD
[9] ScriptEditorPlugin::set_window_layout(Ref<ConfigFile>) (/home/emmanuel/projects/godot-python/godot/editor/plugins/script_editor_plugin.cpp:2865 (discriminator 2))
Process 3145 stopped and restarted: thread 1 received signal: SIGCHLD
[10] EditorData::set_plugin_window_layout(Ref<ConfigFile>) (/home/emmanuel/projects/godot-python/godot/editor/editor_data.cpp:766 (discriminator 2))
Process 3145 stopped and restarted: thread 1 received signal: SIGCHLD
[11] EditorNode::_load_docks() (/home/emmanuel/projects/godot-python/godot/editor/editor_node.cpp:3750 (discriminator 3))
Process 3145 stopped and restarted: thread 1 received signal: SIGCHLD
[12] EditorNode::_notification(int) (/home/emmanuel/projects/godot-python/godot/editor/editor_node.cpp:295)
Process 3145 stopped and restarted: thread 1 received signal: SIGCHLD
[13] EditorNode::_notificationv(int, bool) (/home/emmanuel/projects/godot-python/godot/editor/editor_node.h:95 (discriminator 14))
Process 3145 stopped and restarted: thread 1 received signal: SIGCHLD
[14] Object::notification(int, bool) (/home/emmanuel/projects/godot-python/godot/core/object.cpp:925)
Process 3145 stopped and restarted: thread 1 received signal: SIGCHLD
[15] Node::_propagate_ready() (/home/emmanuel/projects/godot-python/godot/scene/main/node.cpp:181)
Process 3145 stopped and restarted: thread 1 received signal: SIGCHLD
[16] Node::_propagate_ready() (/home/emmanuel/projects/godot-python/godot/scene/main/node.cpp:174 (discriminator 2))
Process 3145 stopped and restarted: thread 1 received signal: SIGCHLD
[17] Node::_set_tree(SceneTree*) (/home/emmanuel/projects/godot-python/godot/scene/main/node.cpp:2615)
Process 3145 stopped and restarted: thread 1 received signal: SIGCHLD
[18] SceneTree::init() (/home/emmanuel/projects/godot-python/godot/scene/main/scene_tree.cpp:442)
Process 3145 stopped and restarted: thread 1 received signal: SIGCHLD
[19] OS_X11::run() (/home/emmanuel/projects/godot-python/godot/platform/x11/os_x11.cpp:2120)
Process 3145 stopped and restarted: thread 1 received signal: SIGCHLD
[20] ../../godot/bin/godot.x11.tools.64(main+0xd3) [0xe32749] (/home/emmanuel/projects/godot-python/godot/platform/x11/godot_x11.cpp:55)
Process 3145 stopped and restarted: thread 1 received signal: SIGCHLD
[21] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0) [0x7ffff4cbc830] (??:0)
Process 3145 stopped and restarted: thread 1 received signal: SIGCHLD
[22] ../../godot/bin/godot.x11.tools.64(_start+0x29) [0xe325a9] (??:?)
-- END OF BACKTRACE --
Process 3145 stopped
* thread #1: tid = 3145, 0x00007ffff4cd1428 libc.so.6`__GI_raise(sig=6) + 56 at raise.c:54, name = 'godot.x11.tools', stop reason = signal SIGABRT
    frame #0: 0x00007ffff4cd1428 libc.so.6`__GI_raise(sig=6) + 56 at raise.c:54

Okay, looking into that

@karroffel any news?

Oh oops. Should be an easy fix, I just forgot about it. Will open PR any moment

authors: karroffel reduz touilleMan

repo: godotengine/godot


text:
Poor performance using Bullet on Godot_FPS_Tutorial

Godot version:
fac0120521f1bf37dc7a8b86e67eb0754baee931
OS/device including version:
Linux 4.16.11 / Win10
CPU: i5-4460 @ 3.20GHz
GPU: GeForce GTX 970
GPU Driver: 396.24 (Proprietary)
RAM: 8 GB
Issue description:
Testing this demo Godot_FPS_Tutorial, I had a very bad performance caused by physics.
Steps to reproduce:

Level 1: runs with both physics engines with good performance.
Level 2: if I remove "Other_Objects", GodotPhysics run with 60fps but Bullet doesn't.
Level 3: only GodotPhysics run with 60fps.

Minimal reproduction project:
https://github.com/TwistedTwigleg/Godot_FPS_Tutorial

@guilhermefelipecgs What hardware (AMD/NVIDIA/Intel HD), driver are you using (propritary/opensource), and the driver version.

Description updated with my specs.

@AndreaCatania This looks like something that you might want to give a check / benchmark

@kubecz3k Yep thanks you. I'll check it soon

This is really interesting.
Level 2: When I remove the node other object as you said I'm able to run the scene with both engines without lag, I've also notices that with Godot physics when I go near the yellow lamps the game start to lag a lot when I go away from it the game runs again correctly.
Can you please confirm it?
The lamp collision shape should be a capsule shape in order to optimize the process. I'm investigating more on that

I've checked more closely the collision shapes of few object and this is the result:

Computer static: 3097 points ---> For this object a box is enough
Pilar static 828 points ---> for tis object a capsule is enough
etc...

You should use primitive collision shape and if it's not possible you should use a really optimize collision shape. This rule is true for both engines

Can you please confirm it?

Same here.
Indeed, this demo is very poorly optimized and I already knew that. I just found it strange that Godot Physics had more performance than Bullet (Bullet should be faster right?), so I thought it might be a bug somehow and maybe could be improved, but if there's nothing to do then we can close it.

Bullet is well optimized and from what I saw it handle better the  Pilar
shape, but this doesn't mean that it can handle multiple instance of this
shape... 3000 point for each collision shape is really too much.
If you notice the same behavior with these shapes "optimized" please open
an issue and tag me
On Sun, Jun 3, 2018, 17:02 Guilherme Felipe de C. G. da Silva <
notifications@github.com> wrote:

Can you please confirm it?
Same here.
Indeed, this demo is very poorly optimized and I already knew that. I just
found it strange that Godot Physics had more performance than Bullet
(Bullet should be faster right?), so I thought it might be a bug somehow
and maybe could be improved, but if there's nothing to do then we can close
it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/19222#issuecomment-394168297,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AH9MR-KI9yibTl6ljc-4bGUMM7oiScffks5t4_p6gaJpZM4UQUFk
.

@AndreaCatania Ok, thanks.

authors: AndreaCatania Supatier guilhermefelipecgs kubecz3k


text:
Global rotation can return opposite sign of expected.

When you have a node belonging to a parent using scaling with a negative X (or Y), the global rotation seems to be putting out the wrong sign and flipping the rotation.
When both scaling X and Y are the same sign (positive or negative) it will appear correct, but when only one component of the parent's scaling is negative the global rotation of the children will have the opposite sign of that scaling.
The canvas item will render with no issue, but the global rotation value it returns will give the following:

Red is what happens in the SceneTree, the Green arrow is using the global rotation value given by the Red arrow.  The Green Arrow is not parented to the Red and isn't inheriting any rotations, see the sample project for more details.
I don't know if this is something intentional, but looking at the output of the global transform's scaling, I wonder why the Y component has a negative value rather than the X.  Maybe the scaling is flipped up somewhere?

Is this behavior intended, expected, or is it actually a bug?  It tripped me up quite seriously.  I assumed this far that the point of global xform references were that they would be taking into account all the transformations of the parents.
This is from a master branch build (3.1) I compiled yesterday, and I'm running everything in the context of Windows 10 with 64 bit versions.
It also seems to be present in previous versions.
Does it have anything to do with the problems seen here?:  https://github.com/godotengine/godot/issues/20966
A 3.1 sample project:
Neg X Scale Global Rotation.zip

I have encountered this before, it has to do with the way the values are stored in the transform matrix.
See #17405

@DualMatrix Thanks for sharing that.  I agree, that it would be nice if the global_rotation (scale as well?) would handle the extra step.  It isn't so intuitive when you run into this thinking you'll save some coding time with managing rotating parts belonging to a character that relies on flipping its scaling.  The testing starts out fine when going in positive X direction, but when you turn around all hell breaks loose.  XD

@poke1024
No , it has to do with the way the rotation, scale and position are being stored in a Transform matrix, and since a negative scale + rotation is mathimatically identical to a postive scale + another rotation so the code can't distinguish the two.

@poke1024 The orientation in the example project I believe is correct.  It's more of an issue with the rotation being flipped and not taking into account the scaling of the parent when it's negative.  Was wondering if it may have been related to your issue, since you were having problems with inverted transforms.
I'm not very well versed in the matrix math, but for now I'm using a work around that goes something like this (though it may be naive):
func global_rotation():

	var s = get_global_transform().get_scale()
	return global_rotation * sign(s.x) * sign(s.y)

@avencherus Ok, this is a different issue from mine then, and not one of orientation, as @DualMatrix notes. As composition, both scale-rotations are identical and correct, it's a matter of convention which to choose, and Godot's convention doesn't match with the convention you need in your use case.
This code might be related:
real_t Transform2D::get_rotation() const {
	real_t det = basis_determinant();
	Transform2D m = orthonormalized();
	if (det < 0) {
		m.scale_basis(Size2(1, -1)); // convention to separate rotation and reflection for 2D is to absorb a flip along y into scaling.
	}
	return Math::atan2(m[0].y, m[0].x);
}

You could try to skip the flip in the implementation above, extract the rotation yourself, i.e. do a atan2(yourtransform.x.y, yourtransform.x.x) in GDScript (not tested).

Any updates?

This is a duplicate of #17405. The symptoms are different, but the cause is the same: Negative X scales can't be decomposed from a transformation matrix, and negative X scales get encoded in the transformation matrix as a rotation, therefore negative X scales have problems like these and should be discouraged or disallowed.

authors: Anutrix DualMatrix aaronfranke avencherus poke1024


text:
GLES2: Color parameter of CPUParticles dont work

Godot version:
Godot 3.1 c9868faa88b938432d23a4b047b4d4942b632edb
OS/device including version:
Windows 10
Issue description:
Predefined COLOR parameter of spatial shader for CPUParticles dont work in GLES2 mode.
For example this shader works fine for GLES3:
shader_type spatial;
render_mode blend_mix,depth_draw_never,cull_back,unshaded;

void fragment() {
	ALBEDO = COLOR.rgb;
	ALPHA = COLOR.a;
}

Minimal reproduction project:
godot-particle-test2.zip

CC @karroffel


text:
Clicking "Occlusion" in the TileSet editor crashes the editor

Godot version:
6b10e37
Issue description:
@MarianoGnu
ERROR: get_polygon: Index p_idx=0 out of size (polygons.size()=0)
   At: scene/2d/navigation_polygon.cpp:148.
ERROR: canvas_item_add_polygon: Condition ' pointcount < 3 ' is true.
   At: servers/visual/visual_server_canvas.cpp:668.
ERROR: canvas_item_add_polygon: Condition ' pointcount < 3 ' is true.
   At: servers/visual/visual_server_canvas.cpp:668.
ERROR: operator[]: FATAL: Index p_index=0 out of size (size()=0)
   At: ./core/dvector.h:505.
handle_crash: Program crashed with signal 4
Dumping the backtrace. Please include this when reporting the bug on https://github.com/godotengine/godot/issues
[1] /usr/lib/libc.so.6(+0x37e00) [0x7f0a6142ae00] (??:0)
[2] PoolVector<Vector2>::operator[](int) const (??:0)
[3] TileSetEditor::draw_polygon_shapes() (??:0)
[4] TileSetEditor::_on_workspace_draw() (??:0)
[5] MethodBind0::call(Object*, Variant const**, int, Variant::CallError&) (??:0)
[6] Object::call(StringName const&, Variant const**, int, Variant::CallError&) (??:0)
[7] Object::emit_signal(StringName const&, Variant const**, int) (??:0)
[8] Object::emit_signal(StringName const&, Variant const&, Variant const&, Variant const&, Variant const&, Variant const&) (??:0)
[9] CanvasItem::_update_callback() (??:0)
[10] MethodBind0::call(Object*, Variant const**, int, Variant::CallError&) (??:0)
[11] Object::call(StringName const&, Variant const**, int, Variant::CallError&) (??:0)
[12] MessageQueue::_call_function(Object*, StringName const&, Variant const*, int, bool) (??:0)
[13] MessageQueue::flush() (??:0)
[14] SceneTree::idle(float) (??:0)
[15] Main::iteration() (??:0)
[16] OS_X11::run() (??:0)
[17] /home/michael/git/godot/bin/godot.x11.tools.64(main+0xd5) [0x55dd218413fe] (??:0)
[18] /usr/lib/libc.so.6(__libc_start_main+0xf3) [0x7f0a61417223] (??:0)
[19] /home/michael/git/godot/bin/godot.x11.tools.64(_start+0x2e) [0x55dd2184125e] (??:0)
-- END OF BACKTRACE --

CC @MarianoGnu

Issue description:
@MarianoGnu

Me: Okay 😿

This might be related, but when I've been trying to add colliders to tiles in the TileSet editor, sometimes the Godot Editor crashes. Here's the output from my most previous crash.
OpenGL ES 3.0 Renderer: AMD Radeon HD 86
50C:\godot\godot\bin>G
WARNING: Control::grab_focus: This control can't grab focus. Use set_focus_mode() to allow a control to get focus.
     At: scene\gui\control.cpp:2067
WARNING: FileAccessWindows::_open: Case mismatch opening requested file 'code.CMD', stored as 'code.cmd' in the filesystem. This file will not open when exported to other case-sensitive platforms.
     At: drivers\windows\file_access_windows.cpp:104
ERROR: TileSet::tile_get_tile_mode: Condition ' !tile_map.has(p_id) ' is true. returned: SINGLE_TILE
   At: scene\resources\tile_set.cpp:412
ERROR: TileSet::tile_get_region: Condition ' !tile_map.has(p_id) ' is true. returned: Rect2()
   At: scene\resources\tile_set.cpp:399
ERROR: TileSet::tile_get_tile_mode: Condition ' !tile_map.has(p_id) ' is true. returned: SINGLE_TILE
   At: scene\resources\tile_set.cpp:412
ERROR: TileSet::tile_get_shape: Condition ' !tile_map.has(p_id) ' is true. returned: Ref<Shape2D>()
   At: scene\resources\tile_set.cpp:610
ERROR: TileSet::tile_get_light_occluder: Condition ' !tile_map.has(p_id) ' is true. returned: Ref<OccluderPolygon2D>()
   At: scene\resources\tile_set.cpp:671
ERROR: TileSet::tile_get_navigation_polygon: Condition ' !tile_map.has(p_id) ' is true. returned: Ref<NavigationPolygon>()
   At: scene\resources\tile_set.cpp:715
ERROR: TileSet::tile_get_region: Condition ' !tile_map.has(p_id) ' is true. returned: Rect2()
   At: scene\resources\tile_set.cpp:399
ERROR: TileSet::tile_get_tile_mode: Condition ' !tile_map.has(p_id) ' is true. returned: SINGLE_TILE
   At: scene\resources\tile_set.cpp:412
ERROR: TileSet::tile_get_shape: Condition ' !tile_map.has(p_id) ' is true. returned: Ref<Shape2D>()
   At: scene\resources\tile_set.cpp:610
ERROR: TileSet::tile_get_light_occluder: Condition ' !tile_map.has(p_id) ' is true. returned: Ref<OccluderPolygon2D>()
   At: scene\resources\tile_set.cpp:671
ERROR: TileSet::tile_get_navigation_polygon: Condition ' !tile_map.has(p_id) ' is true. returned: Ref<NavigationPolygon>()
   At: scene\resources\tile_set.cpp:715
ERROR: PoolVector<struct Vector2>::operator []: FATAL: Index p_index=-1 out of size (size()=0)
   At: C:\godot\godot\core/dvector.h:505
CrashHandlerException: Program crashed
Dumping the backtrace. Please include this when reporting the bug on https://github.com/godotengine/godot/issues
[0] PoolVector<Vector2>::operator[] (c:\godot\godot\core\dvector.h:505)
[1] TileSetEditor::draw_polygon_shapes (c:\godot\godot\editor\plugins\tile_set_editor_plugin.cpp:1870)
[2] TileSetEditor::_on_workspace_draw (c:\godot\godot\editor\plugins\tile_set_editor_plugin.cpp:780)
[3] MethodBind0<TileSetEditor>::call (c:\godot\godot\core\method_bind.gen.inc:140)
[4] Object::call (c:\godot\godot\core\object.cpp:968)
[5] Object::emit_signal (c:\godot\godot\core\object.cpp:1254)
[6] Object::emit_signal (c:\godot\godot\core\object.cpp:1308)
[7] CanvasItem::_update_callback (c:\godot\godot\scene\2d\canvas_item.cpp:340)
[8] MethodBind0<CanvasItem>::call (c:\godot\godot\core\method_bind.gen.inc:140)
[9] Object::call (c:\godot\godot\core\object.cpp:968)
[10] MessageQueue::_call_function (c:\godot\godot\core\message_queue.cpp:256)
[11] MessageQueue::flush (c:\godot\godot\core\message_queue.cpp:302)
[12] SceneTree::iteration (c:\godot\godot\scene\main\scene_tree.cpp:477)
[13] Main::iteration (c:\godot\godot\main\main.cpp:1770)
[14] OS_Windows::run (c:\godot\godot\platform\windows\os_windows.cpp:2736)
[15] widechar_main (c:\godot\godot\platform\windows\godot_win.cpp:150)
[16] _main (c:\godot\godot\platform\windows\godot_win.cpp:174)
[17] main (c:\godot\godot\platform\windows\godot_win.cpp:184)
[18] __scrt_common_main_seh (f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:288)
[19] BaseThreadInitThunk
-- END OF BACKTRACE --

This has been fixed. Closing it.

I am still having this crash in Godot alpha2 3.1 with mono Support 😭

authors: DocoDan MarianoGnu YeldhamDev akien-mga drako0812


text:
Inconsistent generation of Area body_entered/body_exited signals

Godot version:
0063ba9
EDIT:
Partially fixed by #25180  see comment below
Issue description:
Area entered/exited signal appears invalid, compared to GodotPhysics
StaticBody enters an Area, a body_exited is generated right after a body_entered.
KinematicBody same thing, as soon as it stops moving.
RigidBody looks like it works ok, maybe because its always moving (in the sample)
In godotphysics disabling a shape doesnt trigger body_exited
Steps to reproduce:
See sample project:

move the blue "character" with arrows keys
the button list on the right enables/disables the collision shapes
check the console messages
try the same with GodotPhysics

Minimal reproduction project:
bug_area_exit.zip
Note
Other stuff observed in the sample, outside the scope of the Issue:

I mentioned in another issue that this problem was also in godotphysics but looks like its working ok
sometimes the initial rigidbody velocity setted in editor doesn't get applied and the ball was "stuck in air" until something interacted with it (this also happened in other projects but i can't reliably repro it)
the character now pushes the rigidbody, even with infinite_inertia==false, but i'm pretty sure it didnt before, while creating the sample?! feel free to disregard this lol
Made that overly complex sample... but forgot to test Area vs Area signals...

The remaining issue is that when the blue character overlaps the green area, if you disable the area's collision shapes, the exited/entered signals are not called (BOTH in godotphysics and bullet)

Tested in the current master branch, and it seems like the exitered and entered signals are properly called when you disable/enable the collision shapes, but only once the character moves, thus updating the collision checks. I'd tend to say that it's OK as is, WDYT?

The current behavior is kinda unintuitive, but technically understandable
For example, sleeping rigidbodies are behaving similarly: the callbacks are not called until they wake
So we could think of a KinematicBody that is not move_and_colliding as if it was in a "sleeping" state
Nothing a little documentation can't solve
Still, Godot is about usability and intuitiveness: if I were a beginner I would expect signals to be fired,
even when my characters and movers are not moving, since I see them standing in the right spot
I guess its better to close this, and later formalize all the expected physics behaviors for the planned physics rewrite

According to @reduz this sounds like a bug more than intended design:
14:43 <reduz> thats odd, if collision is disabled it should trigger it almost immediately
14:44 <reduz> well, at least in the next physics iteration

authors: akien-mga muiroc


text:
Latest dev snapshot not keeping session state

Godot version: Godot 3.1beta9official

OS/device including version: Linux x64 Solus Gnome

Issue description:

When closing the editor and opening again it doesnt keep the layout and previously opened scripts.

This is already fixed on master branch. The fix just didn't make it into this beta.

Duplicate of https://github.com/godotengine/godot/issues/26359.

My bad, sorry

authors: Calinou KoBeWi henriiquecampos


text:
ConvexPolygonShape2D::set_point_cloud is empty

As seen in the current master branch and noted by @Ovnuniarchos in 1155ac8 (btw please open a bug report when you see something like that, it's a bug):
void ConvexPolygonShape2D::set_point_cloud(const Vector<Vector2>& p_points) {

}

void ConvexPolygonShape2D::set_points(const Vector<Vector2>& p_points) {

	points=p_points;
	_update_shape();
}

https://github.com/godotengine/godot/blob/0b05739/scene/resources/convex_polygon_shape_2d.cpp#L40-L44

need to write a convex hull function for that :P

authors: akien-mga reduz


text:
Unable to set HBoxContainer/VBoxContainer Separation Custom Constant to 0 without changing first

Godot version:
3.1.1 (Mono)
Issue description:
When creating a new HBoxContainer/VBoxContainer (and maybe GridContainer but I haven't confirmed), there is a default Separation value that is not shown in the editor, and instead the value 0 is shown. There is an outstanding issue already to display the correct value #27947. In addition to this, if you actually want to set the Separation value to 0 you can't unless you set it to another value and then set it back. This likely applies to all Custom Constants that don't have a value, and where the editor shows an unassigned default value.
Steps to reproduce:

Add an HBoxContainer or VBoxContainer
Set the Separation value under Custom Constants to 0. Nothing will happen. The container will still be using the default Separation value.
Set the Separation to 1
Set the Separation value back to 0. The container will now have 0 Separation.

related to #27947

Yep, fighting with this in GDScript right now, supposedly the separation is a theme property/constant, but the documentation is not at all useful for figuring out how to set it.

Seems to be working correctly in 3.2.1

Or is the issue about something else?

@KoBeWi Yes, the checkbox setting fixes the issue I originally opened. I will close.
Not sure how long this has been fixed for. I haven't needed to use that setting since I opened the issue.

authors: KoBeWi Megalomaniak andy-noisyduck volzhs


text:
Error while compiling Godot "'strcasecmp'/'strncasecmp' has not been declared; did you mean 'strcasestr'/'wcsncasecmp'?"

Solus 4.0 Fortitude

@RevoluPowered Is this related to your recent Assimp work?

@clayjohn @RevoluPowered
Few weeks ago I make install mingw-64 (cross compiler) on my machine.
In short libraries created by make install messed everything up.
After hours, I deleted them and now I can build Godot easily.
Thanks.

@clayjohn I have not changed that part of the library directly but, I however did update the library to the latest master. After upgrading the library I had to do a full rebuild using scons due to global defines added to scons.
@Vikram1323 did you just delete assimp from modules or are you still unable to build with this included?

@RevoluPowered
Before, figuring out what is real problem* I build after deleting assimp but now I can build with assimp.

Solus (GNU/Linux) has no package for mingw-64(cross-compiler). So I tried to build it. What  up happening in my opinion was libraries with same names was causing this problem. So I deleted them one by one.

That's good to hear! thanks for clearing that up

authors: RevoluPowered Vikram1323 clayjohn


text:
Merge from scene confusion (maybe bug)

maybe this same like this, my less complicated https://github.com/godotengine/godot/issues/31744
Godot version:
3.1.1 stable
OS/device including version:
Editor Linux
Issue description:
On Merge from scene, created in editor resources shared only for current session, reopening editor unlink them all from each other.
Steps to reproduce:
Create Root Node: 2D scene (two scene, two editor tabs), save them.
first tab(scene1): create Sprite, on first scene, create new Gradient texture->new Gradient, save
second Tab(scene2): press Merge from scene, select scene1, Sprite
now editing(change any color) Gradient on Sprite in any of tabs(Scenes) make it same change to second Sprite Gradient.
Save everything, close Editor.
Reopen Editor: now changing Gradient do not set same value to other Sprite in other scene.
The problem is - it exist in all materials(particle material/spatial material/other), Gradient and Curve
Copying objects form scene to scene with material that has saved local created elements, global editing does not work after Editor restart.(I did not knew that and now need to remake 6 scenes with 6 copyes on each 2 material per object to make it work again in my project)
Minimal reproduction project:
not needed

Yep, this is a bug. It should always behave like after reloading. The fact that editing seemingly built-in resource on one scene edits the resource on the another one leads to unwitting lose of changes. It happened to me few times actually, and it's especially terrible with scripts :/

This is still valid in d70a17d
This is not really a bug, but the way how resources work. Though this behavior is unexpected and might lead to data loss and other bad stuff. Fixing it would require making a deep copy on the merged nodes. My copy-paste PR has the same problem when you copy nodes across scenes.

authors: KoBeWi danilw


text:
audio import error

im using latest godot and im unable to import audio as it shows me this error
editor/editor_file_system.cpp:1783 - Error importing 'res://game bgm.ogg'

We need more information to be able to diagnose this issue. Please include all information as requested in the bug report template: https://github.com/godotengine/godot/blob/master/.github/ISSUE_TEMPLATE/bug_report.md

Yeah, unfortunately, we can't help you without more information. Your file may probably be corrupted because OGG files seem correctly playing, for example: (https://file-examples.com/index.php/sample-audio-files/sample-ogg-download/). Closed.

authors: Calinou Chaosus mashmawsh


text:
Gradient editor displays bright magenta background instead of checker background for transparent colors

Godot version: Git https://github.com/godotengine/godot/commit/7a62b94bcae4da685144ce11aa6f1c8ad19b7c71
OS/device including version: Fedora 31, GeForce GTX 1080 (NVIDIA 440.100)
Issue description:
The Gradient editor fails to display its checker background for transparent colors and will display a bright magenta color instead.

This GUI component is drawn by scene/gui/gradient_edit.cpp.
Steps to reproduce: Create a Gradient resource in the Inspector dock by using the New Resource button, then edit one of its points to have an alpha value lower than 1.0.
Minimal reproduction project: N/A

Hey there,
I'd like to take a crack a this no one minds?
I've got a potential fix in place but I'm not sure if it's exactly what is wanted:

I assume it would better if it matched the color picker sample area?

@callumW That's a good start, but it ideally, it should display a repeating checkerboard like this:

That's how it looks in 3.2.3.

Cool, I think that would look better too. I'll take a look 😀
It looks like the color picker is a little broken too as it doesn't repeat like that, rather it displays stretched out as shown above.
Should that be raised as a separate issue or fixed in this one?

@callumW What do you mean by the color picker being broken? Other than the "pick" icon being offset, I don't see any differences.
If you meant the checkerboard texture stretched instead of repeating, that's something you need to reimplement in your PR.

authors: Calinou callumW


text:
GLTF files with vertex colors fail on import

Godot version
ad8a2b3d527f821d1a0b061811661d49d0920967
System information
Windows 10, Vulkan, Nvidia GTX 1080 (471.11)
Issue description
Attempting to load a GLTF file with vertex colours no longer works. Produces errors like:
ERROR: Size of attribute data provided (48) does not match expected (96)
   at: (servers\rendering\renderer_rd\renderer_storage_rd.cpp:2502)
ERROR: Index (uint32_t)p_surface = 0 is out of bounds (mesh->surface_count = 0).
   at: RendererStorageRD::mesh_surface_set_material (servers\rendering\renderer_rd\renderer_storage_rd.cpp:2693)
ERROR: Size of attribute data provided (72) does not match expected (144)
   at: (servers\rendering\renderer_rd\renderer_storage_rd.cpp:2502)
ERROR: Index (uint32_t)p_surface = 0 is out of bounds (mesh->surface_count = 0).
   at: RendererStorageRD::mesh_surface_set_material (servers\rendering\renderer_rd\renderer_storage_rd.cpp:2693)
ERROR: Size of attribute data provided (6400) does not match expected (12800)
   at: (servers\rendering\renderer_rd\renderer_storage_rd.cpp:2502)
ERROR: Index (uint32_t)p_surface = 0 is out of bounds (mesh->surface_count = 0).
   at: RendererStorageRD::mesh_surface_set_material (servers\rendering\renderer_rd\renderer_storage_rd.cpp:2693)
ERROR: Size of attribute data provided (6400) does not match expected (12800)
   at: (servers\rendering\renderer_rd\renderer_storage_rd.cpp:2502)
ERROR: Index (uint32_t)p_surface = 0 is out of bounds (mesh->surface_count = 0).
   at: RendererStorageRD::mesh_surface_set_material (servers\rendering\renderer_rd\renderer_storage_rd.cpp:2693)
ERROR: Size of attribute data provided (6400) does not match expected (12800)
   at: (servers\rendering\renderer_rd\renderer_storage_rd.cpp:2502)
ERROR: Index (uint32_t)p_surface = 0 is out of bounds (mesh->surface_count = 0).
   at: RendererStorageRD::mesh_surface_set_material (servers\rendering\renderer_rd\renderer_storage_rd.cpp:2693)
ERROR: Size of attribute data provided (6400) does not match expected (12800)
   at: (servers\rendering\renderer_rd\renderer_storage_rd.cpp:2502)
ERROR: Index (uint32_t)p_surface = 0 is out of bounds (mesh->surface_count = 0).
   at: RendererStorageRD::mesh_surface_set_material (servers\rendering\renderer_rd\renderer_storage_rd.cpp:2693)
ERROR: Size of attribute data provided (288) does not match expected (384)
   at: (servers\rendering\renderer_rd\renderer_storage_rd.cpp:2502)
ERROR: Index (uint32_t)p_surface = 0 is out of bounds (mesh->surface_count = 0).
   at: RendererStorageRD::mesh_surface_set_material (servers\rendering\renderer_rd\renderer_storage_rd.cpp:2693)
ERROR: Index (uint32_t)p_surface = 0 is out of bounds (mesh->surface_count = 0).
   at: RendererStorageRD::mesh_get_surface (servers\rendering\renderer_rd\renderer_storage_rd.cpp:2711)
ERROR: Index (uint32_t)p_surface = 0 is out of bounds (mesh->surface_count = 0).
   at: RendererStorageRD::mesh_get_surface (servers\rendering\renderer_rd\renderer_storage_rd.cpp:2711)
ERROR: Condition "!importer.is_valid()" is true. Continuing.
   at: EditorFileSystem::reimport_files (editor\editor_file_system.cpp:1980)
ERROR: Size of attribute data provided (6400) does not match expected (12800)
   at: (servers\rendering\renderer_rd\renderer_storage_rd.cpp:2502)
ERROR: Index (uint32_t)p_surface = 0 is out of bounds (mesh->surface_count = 0).
   at: RendererStorageRD::mesh_surface_set_material (servers\rendering\renderer_rd\renderer_storage_rd.cpp:2693)
ERROR: Can't create buffer of size: 0, error -1000011001.
   at: (drivers\vulkan\rendering_device_vulkan.cpp:1394)
WARNING: Couldn't load resource (no cache): res://import/cube_test.gltf::3
     at: ResourceLoaderBinary::parse_variant (core\io\resource_format_binary.cpp:318)

Bisecting the issue indicates that this commit introduced the regression (9ad0c6cde708ad4fb31da78fb1a450a219a610d6). Although the commit does indicate that it breaks backwards compatibility and can be fixed by deleting the model from the import cache, this does not appear to work and the model still fails to load from an empty project.
Steps to reproduce
Simply load a project and attempt to import a new GLTF file with vertex colours.
Minimal reproduction project
model_import.zip

I think it's resolved by this #50058. Should be okay to close.


text:
Unfolding inspector sections doesn't work consistently

Godot version
28174d531b7128f0281fc2b88da2f4962fd3513e
System information
W10
Issue description
This functionality was present in #41138 (see gif further down). Not sure what has changed since then. In the case of the video, I attempt to drop a ShaderMaterial on an unfolded Material tab. Inside is a material property that accepts this resource, but unfolding doesn't work. The problem is in editor_inspector.cpp:L1264. It checks whether any property can accept the dragged resource, but for some reason it doesn't detect it.
https://user-images.githubusercontent.com/25907608/147367910-6bdca1f8-99f4-45e0-90e6-560d7dea5c5e.mp4
Not sure if this is something specific to ShaderMaterial, couldn't find other resources in folded sections.
Steps to reproduce

Select Node2D (or any CanvasItem)
Create new ShaderMaterial resource.
Drag resource over Material tab.

Minimal reproduction project
No response

For some reason the feature doesn't work for me at all.

The feature doesn't work for me on 3.4 either. Maybe it was broken sometime between 3.4 and https://github.com/godotengine/godot/pull/41138 and no one noticed until now.

Seems #52277 broke the feature at EditorInspectorSection::_notification
https://github.com/godotengine/godot/blob/28174d531b7128f0281fc2b88da2f4962fd3513e/editor/editor_inspector.cpp#L1255-L1272
This code tries to check if there is any property inside the section that can be drag-dropped. However, most kinds of EditorProperty* are not covered yet, and sub-property are not considered (like property in EditorPropertyResource).

authors: KoBeWi fire540 hinlopen zaevi


text:
On Quit To Project Manager Dialogues Don't Go To Home Directory

Operating system or device - Godot version:
Ubuntu MATE 15.10, Godot 2.1-rc1
Issue description (what happened, and what was expected):
Upon going to the Project Manager from the editor (hitting CTRL + SHIFT + Q) the New Project and Import dialogues don't go back to the home directory like they do if you'd just launched it from the executable. Instead the New Project and Import dialogues go to the directory where the Godot executable is. It's inconvienant because my Godot is in "/opt/" (although others might put it in /usr/bin) and my Godot projects are in "/home."
Steps to reproduce:
Place Godot some where other than in "/home" and from the editor hit CTRL + SHIFT + Q.
Link to minimal example project (optional but very welcome):

Confirmed in the current master and 2.1 branches. It should be quite easy to fix.

You can set your default project path, this way it will always be open on the project manager.
Godot 2.1
Settings -> Editor Settings -> Global -> Default Project Path
Godot 3
Editor -> Editor Settings -> Filesystem -> Directories -> Default Project Path

@Shin-NiL Thank you so much!

This doesn't seem to be valid anymore as of c2c82a6ea. At least under Linux.

It's indeed fixed in 3.0/the master branch (always defaults to $HOME regardless of $pwd), and still valid in 2.1 (defaults to $pwd initially, then after going back to project manager, defaults to executable directory).

At this stage I doubt we'll work on fixing this in the 2.1 branch as it's quite minor, so closing as fixed in 3.0.

authors: Shin-NiL akien-mga ivodopiviz toliaferrode


text:
RayCast2d won't collide with TileMap tiles' on ready

Godot version
4.0 beta 2
System information
Ubuntu 22.04.1 LTS 64 bit
Issue description
The RayCast2d node in Godot does not seem to collide with any TileMap collision on ready. However, it does collide with TileMap collision after waiting for a few frames. The RayCast2d node also will collide with normal PhysicsBody2d nodes (i.e. StaticBody2d) on ready, just not TileMap tiles with collision.
Steps to reproduce

Launch Godot 4.0 beta 2
Make a new 2d scene
Add a RayCast2d node and a TileMap node
Give the TileMap node a tile that has collision via Physics Layers
Place a tile in the scene
Point a RayCast2d node at the tile so that the ray will collide with it
Add a script to RayCast2d
Copy and paste the following code into the script:

extends RayCast2D
func _ready() -> void:
print_debug("On ready collision point: %s" % get_collision_point())
await get_tree().create_timer(1.0).timeout
print_debug("After timer collision point: %s" % get_collision_point())

Run the current scene. The RayCast2d will return (0, 0) as its collision point (visible in first print). After waiting 1 second, it will return the actual collision point (visible in second print)

Minimal reproduction project
RayCast2dBug.zip

See here that explains/discusses this for GridMap and the rational why this _ready() / first frame collision checks does not work for "Mega-Nodes" like TileMap/GridMap.
The gist is that collision objects simply do not exist when a TileMap/GridMap claims to be "ready" cause the only thing that is ready is the node, but not the potentialy thousands of sub objects like collision that are just created and still in the server sync queues.
A single StaticBody node can only ever hold a single physics object so they can create their single physics object in advance in the constructor. The "Mega-Nodes" are creating their physics objects when they join the SceneTree so they physics objects only exist after the first phsics sync.

This is a HUGE issue in my case, as it makes it impossible to determine if the player starts in the air or on ground. I have some code that I want to run when the player lands on the ground, but this makes it always run on the start of the level since this makes the player always start mid air.

This is a HUGE issue in my case, as it makes it impossible to determine if the player starts in the air or on ground. I have some code that I want to run when the player lands on the ground, but this makes it always run on the start of the level since this makes the player always start mid air. There are no easy workarounds for this I can find either.

If you are using Godot version 4.x, try writing:
await get_tree().process_frame
in your ready function before the check for if the player is touching the ground. This should wait for a single frame, allowing the TileMap to generate. Then you can continue the rest of your code as needed.

If you are using Godot version 4.x, try writing:
await get_tree().process_frame
in your ready function before the check for if the player is touching the ground. This should wait for a single frame, allowing the TileMap to generate. Then you can continue the rest of your code as needed.

I'm just realizing i might have ran into a different (but closely related) issue, that the first two _physics_process() frames also miss collision on TileMaps.
This is the workaround i found for this.
var frame_number: int = 0

func _physics_process():
    if frame_number < 2:
        frame_number += 1
        move_and_slide()
        return
    [actual code below]

Might be material for a separate bug report?

Sorry, I was unaware that it took two physics frames for TileMaps to become truly ready; this is likely still the same issue.
Here is alternative code that should have the same effect but takes up less unnecessary space in the _physics_process function, and is more readable:
var is_ready: bool = false

func _ready() -> void:

        # Wait two frames before ready
        for i in 2:
                await get_tree().physics_frame
        is_ready = true

func _physics_process(delta: float) -> void:
        if not is_ready:
                move_and_slide()
                return

        [actual code below]

I encountered this problem today as well in C#. For those who need it, here's what I came up with in _Ready()
// Wait for tilemap to be ready for physics
int i = 0;
Action waitForPhysicsHandler = null;
waitForPhysicsHandler = () =>
{
    i++;
    if (i > 2)
    {
        _physicsActive = true;
        GetTree().PhysicsFrame -= waitForPhysicsHandler;
    }
};

GetTree().PhysicsFrame += waitForPhysicsHandler;

Thank you for this!
In case it helps anyone, I used this to fix is_on_floor giving an incorrect result for the first 2 physics frames (based on @OddThornDuck's solution):
const _PHYSICS_STARTUP_DELAY = 2
const _SPAWN_FLOOR_TEST_DISTANCE = 5.0

func _ready() -> void:
	call_deferred("_deferred_ready")

func _deferred_ready() -> void:
	# Wait a while before enabling physics, to allow TileMap initialization.
	# See: https://github.com/godotengine/godot/issues/67679
	# We do this in a deferred callback so as not to stall the `ready` function.
	set_physics_process(false)
	for i in _PHYSICS_STARTUP_DELAY:
		await get_tree().physics_frame
	set_physics_process(true)
	_post_spawn_physics()

func _post_spawn_physics():
	# If we are spawning on a floor then we should snap to it, to prevent any
	# extraneous "landed" events being fired later.
	var floor_test_vector := Vector2.DOWN * _SPAWN_FLOOR_TEST_DISTANCE
	var collision := move_and_collide(floor_test_vector, true, 0.08, true)
	if collision:
		# We are on a floor!
		# It is necessary to call `move_and_slide` at least once in order for
		# `is_on_floor` to return the correct result.
		velocity = floor_test_vector
		move_and_slide()


text:
get_stream_playback() of AudioStreamPlayer always returns null.

Godot version
v4.0.beta15.official [4fa6edc88]
System information
Windows 10, Vulkan, RTX3080
Issue description
The get_stream_playback() function introduced in beta15 (#71855) always returns null instead of an object of type AudioStreamPlaybackPolyphonic.
Steps to reproduce
Run the included sample project and look at the console.
Minimal reproduction project
PlaybackBug.zip

Also encountering this issue on my project, it returns null along with the error
E 0:00:00:0949   _ready: Player is inactive. Call play() before requesting get_stream_playback().
  <C++ Error>    Condition "stream_playbacks.is_empty()" is true. Returning: Ref<AudioStreamPlayback>()
  <C++ Source>   scene/3d/audio_stream_player_3d.cpp:787 @ get_stream_playback()

Following the advice of the error, I tried running play() immediately before get_stream_playback(), to no avail. Although, waiting a frame before getting stream playback does appear to work, i.e.:
stream_player.play()
await get_tree().process_frame
var playback = stream_player.get_stream_playback() as AudioStreamPlaybackPolyphonic

The original code sample provided in #71855 doesn't seem to be working anymore due to this.

In AudioStreamPlayer, audio_stream_playback is activated immediately after play(), but in AudioStreamPlayer2D and 3D, it is activated in the next physics_process(), so an empty reference was returned immediately after play(). It is fixed by #72233.

authors: TokageItLab kobligo the-sink


text:
Clicking Override All in the Theme Editor with no Type selected crashes the editor

Godot version
4.1 beta 3
System information
Godot v4.1.beta3 - Windows 10.0.19045 - Vulkan (Compatibility) - NVIDIA GeForce GTX 1060 6GB (NVIDIA; 31.0.15.2824) - AMD Ryzen 7 2700X Eight-Core Processor (16 Threads)
Issue description
This is a pretty specific reproduction but one that can accidentally happen (as happened to me). Clicking Override All on Theme Editor with no category selected will cause the editor to crash. Opening the project back up shows no Types in the dropdown (despite the theme resource looking fine upon cursory inspection) and attempting to add any new types will crash the editor again. Also important to note that in the first project I had this on the theme was applied as the default theme to my project and it's still visible on elements in the project (fonts and panels and such), but attempting to edit the theme will crash the editor. This is actually because the theme editor is showing my theme but does not have a reference to it somehow. Selecting the theme again fixes this
This shouldn't normally happen under normal operation but it is still something that does, as it requires the Override All button to be available but no Type to be selected - as far as I know, the only condition which causes this is if you open up a project after having last edited a Theme. Then the button should be available, but no Type is selected by default.
Steps to reproduce

Create a new Theme
Add some Type, doesn't matter what
Close project
Reopen Project, Theme editor should be open
Click Override All
Enjoy

Minimal reproduction project
N/A

This may be the same as https://github.com/godotengine/godot/issues/78281, which should be fixed in 4.1 RC1. Though the case that you describe in the reproduction steps may still be a problem.

👀 lookin forward to that RC1 - though I also wanted to correct myself and say that the theme isn't corrupted, I'm just a silly goose who did not realize that the currently edited theme was not actually pointing to anything, and the subsequent crashes were solved by actually selecting the theme. I'll try building from the latest master to see what comes up

Looks like [2930fbeec] will simply not open the Theme Editor by default when reopening a project, which solves that issue. The bottom tray is still expanded but the only way I can tell to be able to edit any theme is to have one selected, so I think we can call this closed!

Thanks, confirming as duplicate of https://github.com/godotengine/godot/issues/78281.

authors: YuriSizov akien-mga twobitadder


text:
.blend files do not import textures when "Unpack Enabled" is off.

Godot version
4.1.1
System information
Windows 11, Blender 3.6.1
Issue description
When importing a .blend file into godot, unchecking the blender/materials/unpack_enabled option in the import settings, and setting gltf/embedded_image_handling to embed as basis universal, the textures do not import to the model. I would expect you to be able to use the textures embedded inside, similar to what you can do with gltf files, but unless I'm missing something about the import process (entirely possible), I don't see how.
Steps to reproduce
Create a blender file with a texture material, and save it to your godot project. In the import settings, turn blender/materials/unpack_enabled off. The textures do not import, no matter what the gltf /embedded _image_handling settings are.
Minimal reproduction project
N/A

At some point we had a philosophy that we required blender to unpack, and if you don't unpack the blender gives you placeholder textures.
Then we added basis universal.
Maybe the two features collided.

authors: fire liabilityluke


text:
Game exported to android with Immersive mode enabled is not hiding status bar

Godot version
v4.2.dev5.official [e3e2528ba]
System information
Godot v4.2.dev5 - Windows 10.0.19045 - GLES3 (Compatibility) - NVIDIA GeForce RTX 3060 Laptop GPU (NVIDIA; 31.0.15.3699) - 11th Gen Intel(R) Core(TM) i5-11400H @ 2.70GHz (12 Threads)
Issue description
I have immersive mode enabled, but the game is still not fullscreen on android device ( Redmi Note 9 )

The same project exported from Godot 4.1.1_stable works fine ( it hides the status bar )
Steps to reproduce

Create any project with literally nothing and export it to android ( immersive mode is enabled by default )
Game runs with status bar shown, and should be otherwise. Disabling the immersive mode also shows the status bar but this is correct.

Minimal reproduction project
Empty project, you can see that gray background doesn't cover whole screen, and the status bar with clock is shown when the immersive mode is enabled ( it is by default )

Thanks for the report! Consolidating in https://github.com/godotengine/godot/issues/80574.

authors: Calinou rmichaluszek


text:
OpenGL ANGLE Mode Isn't Automatically Switched to "ON" on Some Devices [Second Section of #72944]

Godot version
4.2 beta 1~4
System information
Windows 11, GLES3, x86_64, AMD APU A4-7210 with AMD R3 Graphics and AMD R5 M330
Issue description
Previous one: #72944
This is the extending section of that issue, see the last few comments in that post.
On some devices, when the exe is opened without parameter --rendering-driver opengl3_angle, the project manager is rendered still with glitches because the OpenGL ANGLE mode isn't turned on automatically on some devices, which includes mine.
Steps to reproduce

Open the exe without --rendering-driver opengl3_angle param and wait for the project manager displaying
Click any button on the gui and the glitche happens(on the specific devices)

(Note: See #72944 to get more details and background about this issue posted today)
Minimal reproduction project
Nope

Currently, it's auto switching only if device reports OpenGL support lower than 3.3, or OpenGL init fail. There's also a list of devices (vendor, name pairs) to always use ANGLE, but the list is empty. Not sure if it's possible to detect buggy driver or which source can be used to populate the list.


text:
Certain UI elements not showing in 2d editor

Tested versions
Bug exists:
4.2.1-stable, 4.2-stable, 4.1.3-stable, 4.1.2-stable, 4.1.1-stable, 4.1-stable, 4.0.4-stable, 4.0.3-stable, 4.0.2-stable, 4.0.1-stable, 4.0-stable
Bug does not exist:
3.5.3-stable
System information
Godot v4.2.1.stable - Windows 10.0.22621 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3060 (NVIDIA; 31.0.15.4617) - Intel(R) Core(TM) i7-10700K CPU @ 3.80GHz (16 Threads)
Issue description
When a popup node is selected, the bounding box is not displayed, as well as any other children of the popup node
They are also not directly editable except through the inspector
However when you remove the child from the parent object (popup), it works fine
Steps to reproduce
Create a new UI scene

It will look like this, and you can drag the edges

Add a popup node

The popup node will not be interactable

Any children also created are not interactable
Minimal reproduction project (MRP)
N/A

Popups are not Control nodes and they aren't editable outside the inspector. Not being able to move children is a known issue (#20619). I remember there was a proposal to make Window nodes editable in the editor, but I can't find it 🤔

I understand if it isn't intended behavior, but in 3.5.3 you can edit popups within the editor or the inspector

Because popups were Controls before, but they were changed for multiple windows support.

Got it, thank you, I'll find another way to do what I want


text:
Area3D inconsistent with Jolt Physics

Tested versions

Reproductible in 4.2.1 Mono with Jolt Physics as 3D physics

System information
Godot v4.2.1.stable.mono - Windows 10.0.22631 - Vulkan (Forward+) - dedicated AMD Radeon RX 6800 (Advanced Micro Devices, Inc.; 31.0.23013.1023) - AMD Ryzen 7 5800X 8-Core Processor (16 Threads)
Issue description
When using Jolt Physics, when a CharacterBody3D enters an Area3D both "Entered" and "Exited" signals are triggered at the same time making it impossible to use Area3D correctly.
The same thing happens with "AreaEntered" and "AreaExited" signals when trying with an Area3D.
Didn't test with RigidBody3D and StaticBody3D
If you move the animatable body that is the parent of the Area3D the characters is detected as exiting and entering multiple times even if it doesn't move and stays stuck on the platform
Steps to reproduce
-Create an Area3D with a CollisionShape
-Create a moving CharacterBody3D (or Area3D)
-Connect "on_body_entered" and "on_body_exited" signals to a script on the Area3D that trigger a print on debug console
-Playtest, enter the Area3D with the CharacterBody3D
-You'll see both signals triggered at the same time, it considers that your CharacterBody3D is already out of the Area even if it isn't
Minimal reproduction project (MRP)
https://we.tl/t-4Q5NMSWdq1
Download link (ZIP was more that 25 MB)

Jolt is not an official plugin so this should be reported with Godot Jolt

Oups my bad, I was too hasty when opening the issue, gonna open it on the right repo sorry :)

Superseded by:

https://github.com/godot-jolt/godot-jolt/issues/787

authors: AThousandShips Vityy


text:
EditorUndoRedo returned UndoRedo doesn't commit the action

Tested versions
v4.3.stable.official [77dcf97d8]
Works in v4.2.2.stable.official [15073afe3]
System information
Godot v4.3.stable - Manjaro Linux #1 SMP PREEMPT_DYNAMIC Wed Aug  7 16:19:28 UTC 2024 - X11 - GLES3 (Compatibility) - Mesa Intel(R) UHD Graphics 600 (GLK 2) - Intel(R) Celeron(R) N4020 CPU @ 1.10GHz (2 Threads)
Issue description
In working in a custom editor for custom resources in runtime and in editor. I wanted to hook edit operations to godot global history when is in editor, so I used editor_undoredo.get_history_undo_redo(editor_undoredo.get_object_history_id(...)). It always used 0 (GLOBAL) or higher numbers.
Before 4.3, the plugin editing operations worked without issues and operations were added to global history. Now it uses id 1 and doesn't apply the operation.
Steps to reproduce
Try to use UndoRedo operations directly, not EditorUndoRedo, for custom objects.
My specific case was https://github.com/AnidemDex/Blockflow/pull/172 , but I managed to replicate it with a single plugin script applying a single operation to a dummy resource created in runtime. In my specific case I use resources that are already saved in file system, so EditorUndoRedo should at least return the global undoredo and commit the action there
Minimal reproduction project (MRP)
Create a new plugin and paste this code. Enable it after that, you should see a new dock with a Do button. Click the button, color should change.

It does change in godot 4.2
It doesn't change in godot 4.3 (unless you modify the script, forcing the global history. Even then, operation is not added to global history)

I don't care about the action being added to history (because this mrp will probably not add something to that history), I'm worried that it doesn't even commit the action.
@tool
extends EditorPlugin

class FakeResource extends Resource:
	var color:Color:
		set(value):
			color = value
			emit_changed()

var fake_dock:Control
var fake_resource:FakeResource

var color_rect: ColorRect

func _enter_tree() -> void:
	add_control_to_dock(EditorPlugin.DOCK_SLOT_RIGHT_BL, fake_dock)

func _exit_tree() -> void:
	remove_control_from_docks(fake_dock)

func button_do() -> void:
	var editor_undoredo := get_undo_redo()
	var undo_redo = editor_undoredo.get_history_undo_redo(editor_undoredo.get_object_history_id(fake_resource))
	#undo_redo = editor_undoredo.get_history_undo_redo(0) #<- Force global history
	#print("using ID:%s UndoRedo"%editor_undoredo.get_object_history_id(fake_resource))

	undo_redo.create_action("Change Color")
	undo_redo.add_do_method(change_color.bind(Color(randf(), randf(), randf())))
	undo_redo.add_undo_method(change_color.bind(fake_resource.color))
	undo_redo.commit_action()

func change_color(with)->void:
	fake_resource.color = with

func _fake_resource_changed() -> void:
	color_rect.color = fake_resource.color

func _init() -> void:
	var hb = HBoxContainer.new()

	color_rect = ColorRect.new()

	var do_button = Button.new()
	do_button.text = "Do"
	do_button.pressed.connect(button_do)

	hb.add_child(color_rect)
	hb.add_child(do_button)
	hb.propagate_call("set", ["size_flags_horizontal",Control.SIZE_EXPAND_FILL])
	hb.propagate_call("set", ["size_flags_vertical",Control.SIZE_EXPAND_FILL])
	hb.propagate_call("set", ["custom_minimum_size", Vector2(16,16)])

	tree_exiting.connect(hb.queue_free)

	fake_resource = FakeResource.new()
	fake_resource.changed.connect(_fake_resource_changed)
	fake_dock = hb

Can confirm this issue is present on Windows 10 as well.

Can't reproduce. The color changes when using the provided script:
https://github.com/user-attachments/assets/9abae497-3b96-4811-87ed-dc5395604ca5
Any reason why you are using UndoRedo instead of EditorUndoRedoManager? When integrating with editor undo history, the latter should be always used.

Any reason why you are using UndoRedo instead of EditorUndoRedoManager?

Editor* classes doesn't exist in runtime, my use case is an editor that work both in editor and in game, so it uses UndoRedo.
I'll experiment a little to see if I can make a more precise project with the bug, if I can't replicate it I'll close the issue, maybe is something that worked in 4.2 due a bug and now in 4.3 was fixed

Well you can't make it work the same in editor and in game, unless you handle UndoRedo yourself. Hooking up into editor's history is not possible without EditorUndoRedoManager.
The script will break only if you refer to the class. You can use the object without specifying its type. EditorUndoRedoManager and UndoRedo have almost the same API, so you can even use them interchangeably.

For some reason I can't replicate it now even using this script :melting_face:
Gonna close it for now, thank you for taking a look at the issue, kobewi

authors: AnidemDex Crystalwarrior KoBeWi