so-rose/oscillode
1
0
Fork 0
Code Issues 50 Pull requests Projects Releases Packages Wiki Activity

Partially altered loose sockets have non-deterministic ordering #28

New issue
Closed
opened 2024-05-04 18:06:32 +02:00 by so-rose · 1 comment
so-rose commented 2024-05-04 18:06:32 +02:00
Owner
Copy link

When setting loose sockets, we expect that order is preserved from the definition. This is currently not the case, if there is overlap, since the existing "already made (by name)" sockets are simply kept and not removed, whilst sockets that maybe "should" come before are now made after (all in node base.py).

The answer lies within the Blender Python API's ability to reorder sockets (I think it was a move() method or something). self.loose_input_sockets already has the correct ordering; all we need is an algorithm to construct a series of move operations to match that ordering.

When setting loose sockets, we expect that order is preserved from the definition. This is currently not the case, if there is overlap, since the existing "already made (by name)" sockets are simply kept and not removed, whilst sockets that maybe "should" come before are now made after (all in node `base.py`). The answer lies within the Blender Python API's ability to reorder sockets (I think it was a `move()` method or something). `self.loose_input_sockets` already has the correct ordering; all we need is an algorithm to construct a series of move operations to match that ordering.
so-rose commented 2024-05-28 12:56:15 +02:00
Author
Owner
Copy link

Fixed using .move() after each sync_sockets. Elegant, non-destructive, and seemingly devoice of FOUC.

Fixed using `.move()` after each `sync_sockets`. Elegant, non-destructive, and seemingly devoice of FOUC.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
uv-refactor
No results found.
Labels
Clear labels   
abstractions

Related to the functionality of the abstractions used to make node/socket design tolerable.

  
architecture

Related to the internal approach / structuring of functionality.

  
bug

Something that isn't working.

  
distribution

Related to processes that gets the software into the hands of users.

  
docs

Related to the documentation, both reference and user-facing.

  
duplicate

An issue that already exists.

  
enhancement

Something to improve existing functionality.

  
feature

A feature to implement ex. node, socket, etc. .

  
physical

Related to the physical correctness or modelling of the tool.

  
proposal

A proposal for a large/radical feature or change, to explain the why/how/status.

  
question

A question for a more qualified person.

  
simulation

A particular simulation-based test, benchmark, or project of real-world significance.

  
tooling

Related to the developer tooling that keeps the developer's mind sane and happy.

  
tracker

Aggregating tracker for other Issues.

  
unconfirmed

Don't know exactly what's going on yet - ideal for ex. user reports.

  
ux

Related to the user experience, visual communication, etc. .

  
wontfix

Something that doesn't work that won't be fixed, on purpose.

No labels
abstractions
architecture
bug
distribution
docs
duplicate
enhancement
feature
physical
proposal
question
simulation
tooling
tracker
unconfirmed
ux
wontfix
Milestone
Clear milestone
No items
No milestone
Robust Simulation
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Blocks
#29 BoundConds socket set injects axes in strange order
so-rose/oscillode
Reference: so-rose/oscillode#28
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?