No script needed, just a field with the right value. If you want, you can make the field a calculation to "hard code" it to one specific filter setting.
Let's say you want all related records for the current customer but only if the value in a text field in the related table holds the text "red".
Two tables: Customer, and Widgets
Define a text field, RedKey, in Customer that holds the text "red". It can be a text calculation that returns this literal text or an auto-entered value.
Define your relationship to include the color fields in both tables:
Customer::CustomerID = Widgets::CustomerID AND
Customer::RedKey = Widgets::Color
Now a portal to widgets located on a Customer based layout will show all the related widgets record for the current customer, but only if the value in color is "red".
Sorry, i forgot to specify that the ultimate use for the related table would be a value list.
I was considering a conditional value list, but that got a bit tricky inside of a portal, and i found that a few portals would be a better solution for this form.
so, i plan to make a few different related tables for each type of "project" (which can be categorized by "segments"), and these related tables would serve as value lists. So i'd have related tables, "segment1" "segment2" etc... containing projects that belong to there respective segments.
Providing you define them correctly, conditional value lists perform in portals just as though the field is located outside the portal--this is by far a simpler approach to use.
Don't see why you need so many separate tables. It would appear you could load all the data in one table and use it in a conditional value list or use portal filtering to view different subgroups of the total table. The above technique can be used as you need, just make the "color" field a value list formatted field instead of making it a "hardwired" connection.