Scenario: Multiple objects (soldier units) of the same type have loop linked detectors and health bars. IDs for each are updated on creation of a new unit. So far so good, units have separate collision detectors and health bars.
Problem: When a unit is killed (and hence destroyed) all ids get totally muddled and generally weird stuff happens.
On Loop ("Dead Soldier")
ID (Soldier) = Loopindex ("Dead Soldier")
+ Health of (Soldier) = 0
+ ID of (Detector) = Loopindex ("Soldier Health") //or// ID of (Soldier)
+ ID of (Health Bar) = Loopindex ("Soldier Health") //or// ID of (Soldier)
--> Destroy Soldier, Detector and Health Bar
What is the problem?
I am really getting sick of MMF2 and object instance handling. Much need of a parent/child system!! Construct - here we come
Thanks for any help! It should be obvious that there is more to the code than just the above, standard stuff really and no issues there, ie. on creation of new unit, spread values in all objects etc.
There's nothing wrong with that event. You've gone wrong somewhere else - most likely, you haven't spread the values properly (eg. you tried to spread a value in the same line as creating a new object, which obviously won't work). It's easy enough to check using the debugger.
However, you should NOT be using fastloops or spread values for this at all (or separate detector objects either, for that matter) - you're just trying to make life difficult for yourself. Use MMF2's automatic object matching - it's so much simpler and more efficient.
Values are only spread when Soldier ID = 0 (ie a new soldier is created). But when one is destroyed, all hell breaks loose. Detectors are necessary for good collision detection - i want my units evenly spaced when they get to the target point.
Auto object matching? You mean just let mmf do it's thing? Dunno if that will work, units also have bounding boxes when selected as per nivram's RTS Movement tute.
Yes, letting MMF2 "just do its thing" will work, if you do it right.
If you're determined not to do that, then you'd still be better off using the ForEach extension (much more efficient when you have a lot of objects), and instead of spreading values you could just set the value to the value of a counter/global/etc, and add 1 to that each time you create a new object.
I'm guessing the previous problem might have been that you ran a fastloop according to the number of objects, but didn't re-spread values when an object was destroyed. So if you had three objects, with values 0, 1 and 2 - and then deleted the first one, the next time you would only run the loop twice (two objects) so the loopindex would stop at 1 and the object with a value of 2 would be ignored.
MMF's automatch system actually works quite good. It just finds the right object without searching IDs. Not sure how your system works, but something with a value for HP in an object and when HP reaches 0 that object will be destroyed.
And now I see your problem, you're arranging HUD elements relative to the position of the object and you want to have the HUD elements to display the information of that object. And the IDs will do this job for the HUD and the object. So when the object is destroyed, the HUD should be destroyed too.
By using MMF's automatch system you could destroy healthbars when they reach zero or less health, no need for IDs in this case. And object the detector, if that detector is just overlapping a little part of the object you could use this condition to test for. So when the object is destroyed, the detector isn't overlapping it anymore and the detector can be destroyed too.
Advertisement
Post Reply
jenswa.neocities.org