"IngeJones;15209648" wrote:
Well it would have to create_object of the one it returned (eg mine, or someone else's CC) not just a hardcoded value obviously, or it would defeat the object of the exercise. Of course the easier way all round would be for someone to volunteer to maintain the tuning file with the default bassinet list in it, and just update it every time someone lets them know they made a new CC bassinet! Why is this all so much harder than modding previous games? What sort of successes are you having with the new way?
It's replacing the bassinet object which you're selecting from the object array, then assigning the baby to the new one and placing it at the location of the first, so you'll have to create a corresponding definition of class 'object_Baby' - you may have done this already and I assumed that you were working with a single instance. For example, Empty Bassinet 23208 is replaced with object_Baby 20988, Empty Bassinet 57771 is replaced with object_Baby 57770, etc, therefore you'll have to create both instances or just migrate the baby to a custom instance and destroy the default when the function is called.
bassinet_definition = BabyTuning.get_corresponding_definition(bassinet.definition)
new_bassinet = create_object(bassinet_definition, obj_id=sim_info.sim_id)
With regard to success, I believe that editing of tuning is a waste of time for any reason other than to add new objects since the entire set of core functions and all data/object instances are fully accessible through the provided interface. Editing of text data and XML for extension of boundaries and interfaces is undesirable when I can create commands and controls for live tuning and instantiate sub-interfaces with custom parameters. If you want values or configurations to remain persistent then you can create an initialization routine which will likely never fail as the result of patching.