~emojisourcehut

Recent activity

[PATCH] Allow boarding wagons with irregular width from the platform 2 months ago

From 1F616EMO to ~gpcf/advtrains-devel

(i.e. width ~= 3)

Extends detection to the whole span of the wagon's width (to be consistent with previous behaviors, the middle is only included if width = 1).
---
 advtrains/wagons.lua | 36 ++++++++++++++++++++++--------------
 1 file changed, 22 insertions(+), 14 deletions(-)

diff --git a/advtrains/wagons.lua b/advtrains/wagons.lua
index cf15871..9912172 100644
--- a/advtrains/wagons.lua
+++ b/advtrains/wagons.lua
@@ -461,26 +461,34 @@ function wagon:on_step(dtime)
		--needs to know index and path
		if train.velocity==0 and self.door_entry and train.door_open and train.door_open~=0 then
[message trimmed]

Re: Thoughts on running Advanced Trains in async environment 4 months ago

From 1F616EMO to ~gpcf/advtrains-discuss

Perhaps my concern was caused by my poor hardware. I plan to upgrade my server on Black Friday, and I’ll see how things goes after that.

> gpcf <gpcf@gpcf.eu>於2024年10月28日 03:15寫道:
> 
> 
> "Y. Wang" <y5nw@protonmail.com> writes:
>> This would be doable, especially given that serialize_lib can be
>> improved to, among other things, use core.safe_file_write instead of
>> writing to the file directly (which also makes unittests easier; we can
>> then use string comparison instead of writing to temporary files and
>> reading from there). The same goes for serialization of the node database.
> 
> btw, has anyone checked the performance of serialize_lib vs the minetest
> json serializer?

Thoughts on running Advanced Trains in async environment 4 months ago

From 1F616EMO to ~gpcf/advtrains-discuss

I am thinking of running the main logic of advtrains in the async 
thread. Random thoughts:

Run all logic (i.e. path calculation, interlocking, train movement, 
train collision) in the async environment, and every time it returns to 
the main thread, sync the calculated results with the world (i.e. 
spawn/move train entities, sync passive component states), perform 
sync-only actions (e.g. detect/damage collided entities, halt trains 
colliding with walls), and sync data back into async (i.e. apply node DB 
changes).

This would be a challenging and compatibility-breaking change (e.g. some 
on_step calls such as texture changes are async-friendly, but some 
others such as vacuuming items up are not). But by doing this, we no

[PATCH v5] De-hardcode the speed limit of 20 m/s 4 months ago

From 1F616EMO to ~gpcf/advtrains-devel

About Ks speed indicators: I’ve not yet investigated backward compatibility problems of them, so I left them as is until I have time to check.

> Y. Wang <y5nw@protonmail.com>於2024年10月22日 20:02寫道:
> 
> (Code review only. I have not tested this myself, but I assume it works
> given that you seem to have this patch applied on your server.)
> 
>> diff --git a/advtrains/trainhud.lua b/advtrains/trainhud.lua
>> index f9f4876..731ad6d 100644
>> --- a/advtrains/trainhud.lua
>> +++ b/advtrains/trainhud.lua
> 
> The HUD definitely needs another rework even at its current state
> (without dehardcoding the speed limit). I am not sure whether it should

[PATCH v10] Wagon iterator, lookup by id, and use them in code 4 months ago

From 1F616EMO to ~gpcf/advtrains-devel

---
Fixed return index problem

 advtrains/trainlogic.lua |  19 +++----
 advtrains/wagons.lua     | 108 +++++++++++++++++++++++++--------------
 2 files changed, 75 insertions(+), 52 deletions(-)

diff --git a/advtrains/trainlogic.lua b/advtrains/trainlogic.lua
index f136577..ce646da 100644
--- a/advtrains/trainlogic.lua
+++ b/advtrains/trainlogic.lua
@@ -142,13 +142,8 @@ minetest.register_on_joinplayer(function(player)
		local pname = player:get_player_name()
		local id=advtrains.player_to_train_mapping[pname]
[message trimmed]

[PATCH v5] De-hardcode the speed limit of 20 m/s 5 months ago

From 1F616EMO to ~gpcf/advtrains-devel

This patch de-hardcodes that speed limit. To adapt the changes,
the following changes are made:

1. Added a setting key: advtrains_max_speed, acceppting integers from 1 to 99.
   Any values beyond the limit wil be capped. This setting is marked experimental
2. Added signal signs from 24 to 40 m/s.
3. Added max_speed = 20 m/s to the wagon metatable, so wagons not specifying a
   maximum speed continues to use 20 m/s.
4. Adjusted the train HUD so trains with maximum speed more than 20 m/s
   uses each segment to represent max / 20 m/s.
5. Adjusted speed target / limit / LZB indicators so they work well on the new
   segment bar
6. (Not so related) Out-of-bound LZB limitations are marked with a
   red arrow pointing right at where 20 m/s were.
[message trimmed]

[PATCH v4] De-hardcode the speed limit of 20 m/s 5 months ago

From 1F616EMO to ~gpcf/advtrains-devel

From: 1F616EMO <root@1f616emo.xyz>

This patch de-hardcodes that speed limit. To adapt the changes,
the following changes are made:

1. Added a setting key: advtrains_max_speed, acceppting integers from 1 to 99.
   Any values beyond the limit wil be capped. This setting is marked experimental
2. Added signal signs from 24 to 40 m/s.
3. Added max_speed = 20 m/s to the wagon metatable, so wagons not specifying a
   maximum speed continues to use 20 m/s.
4. Adjusted the train HUD so trains with maximum speed more than 20 m/s
   uses each segment to represent max / 20 m/s.
5. Adjusted speed target / limit / LZB indicators so they work well on the new
   segment bar
[message trimmed]

[PATCH v3] De-hardcode the speed limit of 20 m/s 5 months ago

From 1F616EMO to ~gpcf/advtrains-devel

From: 1F616EMO <root@1f616emo.xyz>

This patch de-hardcodes that speed limit. To adapt the changes,
the following changes are made:

1. Added a setting key: advtrains_max_speed, acceppting integers from 1 to 99.
   Any values beyond the limit wil be capped.
2. Added max_speed = 20 m/s to the wagon metatable, so wagons not specifying a
   maximum speed continues to use 20 m/s.
3. Adjusted the train HUD so trains with maximum speed more than 20 m/s
   uses each segment to represent max / 20 m/s.
4. Adjusted speed target / limit / LZB indicators so they work well on the new
   segment bar
5. (Not so related) Out-of-bound LZB limitations are marked with a
[message trimmed]

[PATCH v9] Wagon iterator, lookup by id, and use them in code 5 months ago

From 1F616EMO to ~gpcf/advtrains-devel

From: 1F616EMO <root@1f616emo.xyz>

---
This patch applied a change suggested by  Y. Wang <y5nw@protonmail.com> 

 advtrains/trainlogic.lua |  19 +++----
 advtrains/wagons.lua     | 108 +++++++++++++++++++++++++--------------
 2 files changed, 75 insertions(+), 52 deletions(-)

diff --git a/advtrains/trainlogic.lua b/advtrains/trainlogic.lua
index f136577..ce646da 100644
--- a/advtrains/trainlogic.lua
+++ b/advtrains/trainlogic.lua
@@ -142,13 +142,8 @@ minetest.register_on_joinplayer(function(player)
[message trimmed]

[PATCH v2] De-hardcode the speed limit of 20 m/s 5 months ago

From 1F616EMO to ~gpcf/advtrains-devel

From: 1F616EMO <root@1f616emo.xyz>

This patch de-hardcodes that speed limit. To adapt the changes,
the following changes are made:

1. Added a setting key: advtrains_max_speed, acceppting integers from 1 to 99.
   Any values beyond the limit wil be capped.
2. Added max_speed = 20 m/s to the wagon metatable, so wagons not specifying a
   maximum speed continues to use 20 m/s.
3. Adjusted the train HUD so trains with maximum speed more than 20 m/s
   uses each segment to represent max / 20 m/s.
4. Adjusted speed target / limit / LZB indicators so they work well on the new
   segment bar
5. (Not so related) Out-of-bound LZB limitations are marked with a
[message trimmed]