kartoFlane wrote:sul wrote:made a branch event0-->event1 and event0-->event2, then regroups selected bifurcations in event1-->event3 and event2-->event3. This is actually what you SHOULDNT DO. Even if FTL will reluctantly accept this, it violates the xml structure so will consume a looot of memory, maybe even crash loading if xml tree is very big. A trick to avoid this is to create identical event3a and event3b, where now event1-->event3a and event2-->event3b.
Is it something you've tested and confirmed, or is it just personal theory? I don't recall there ever being any issues with multiple events linking to the same "closing" event, only loops are forbidden. As far as I'm aware, both vanilla game and CE use this extensively.
Also from a programmatic point of view, there's no reason (at least, no immediately obvious one) why the former approach would consume more memory than the latter (in fact your 'trick' would end up consuming marginally
more, as the game would have to create two separate intermediate event structures holding exact same data)
KartoFlane, this is all personal experimentation but quite confirmed by tests in many instances. It also makes sense with respect to the theoretical discussion we had. Here are some discussion points.
Rules:
Regrouping selected bifurcations (events from multiple choices) within a same xml tree needs to be avoided. It will be accepted by FTL without crash, however it can lead to important loading time issues for very large xml trees. Note that regrouping random bifurcations (events from eventList) is acceptable. In addition events that are from different xml trees (with different root events) can regroup to a same event. Each xml tree has an unique "root event", that can be a beacon on the star map or the result from a ship encounter like destroyed, deadCrew, etc.
With respect to your comments:
- From reading the data.dat files, I dont recall FTL Vanilla/AE using selected bifurcations regroupment, only random bifurcations regroupment. But even if it is the case there is no issues as the xml structures of those events remain small generally.
- A theoretical argument is that regrouping selected bifurcations violates the xml structure. If the events were nameless and regrouped in the classical form <event>..</event>, without using event load, it would appear obvious that regroupments are impossible. What is puzzling is that random bifurcations can still be regrouped seamlessly, but that is another issue.
Some Practical examples:
- Mod Testing Environment: This is a medium size menu, with a few selected bifurcation regroupments, that has loading time issues (as commented by TaxiDriver on this page). I am only speculating here, as it is not my mod and i didnt experiment on it but the coincidence makes sense. This is just one example I remember but you can find other mods where it also happens.
http://www.ftlgame.com/forum/viewtopic.php?t=22613
- FTL Scramble Menu: This is a very large menu, with no selected bifurcations regroupments, that loads seamlessly. Note that there is a trick to endlessly reopen the menu (ship hostile upon crew death), but i am diverging from the subject.
http://www.ftlgame.com/forum/viewtopic.php?t=29104
- FTL Scramble Battle Mod: This is menu with an extremely large chain of events (around 20Mb of text), with no selected bifurcations regroupment, that load seamlessly. In particular, the chain of event (called the "infinite random mode" in game) has a huge amount of random bifurcations regroupments: I checked that if only a SINGLE selected bifurcation regroupment is included in that chain the mod cannot load.
http://www.ftlgame.com/forum/viewtopic.php?t=29104
- Many other experimentations around this but it is hard to present examples. Before finding the trick to endlessly reopen the scramble menu, i had tested many types of xml tree structures to avoid selected bifurcations regroupments that would never load.
)
