if you can't select them by just going "ctrl + a", they must be objects you create via events. You could just create an object of each type like this and then delete them once its moved. Personally I always keep them on the side of my frame editor with "do not create at start" ticked
I started doing what Pixelthief mentioned by keeping everything on the side of the frame with do not create at start ticked. It seems to cut down on the problems I had in the past such as things like you brought up.
Actually, objects which existence that rely on creation events is a design mistake in MMF2 and you should never have that. Even having objects rely on that an instance is in a frame is a design mistake too, and the way it would normally be done in middleware and any other software is that an object can exist on its own without needing a reference. Apart from being more logical and consistent with other software, it'd probably also be a lot more easy to deal with in the MMF code itself (which would probably prevent problems like this).
An acceptable solution solution is to always have an instance of every object in the frame and uncheck "create at start" in the runtime options. That way, you don't have to be worried about objects suddenly disappearing when you cut/paste events.
It's a good idea in as far as you can make the level transplantable in two steps; objects and events.
But it's only a "design mistake" in as far as MMF2 doesn't support its own feature altogether reliably.
Otherwise, what is the point of MMF displaying a library of present objects in the frame editor? Otherwise you'd only be able to duplicate what you had in the frame by using the objects' right-click menus.
When you make a mistake cutting and pasting in the event editor, you press Ctrl+Z to fix it.
The dev software should be sufficiently robust not to generate objects that can never be deleted. Better that than turning around and blaming it on the users
Crash86, I agree with your last paragraph, but we are trying to help. It is not my intent to upset you, if I did. Let's just explore all the possibilities.
Marv
458 TGF to CTF 2.5+ Examples and games
http://www.castles-of-britain.com/mmf2examples.htm
No, you didn't, I'm right there with you. - I think Nifflas has the right approach.
I'm sure it does stop undeletable objects altogether from what I've seen. It's just that it's not a 'mistake' on the part of the user for using the software in that way.
I didn't blame the users for one second. I mean this as a "design mistake", a feature that is designed wrong in MMF2 itself. A "bug" is when a feature doesn't work as intended. Even if the bugs with unremovable objects wouldn't exist, it's still be a design flaw that MMF2 binds an object's existences to creation events or the presence of an instance a frame. It's not an optimal solution. Then, from an user point of view, even if there's no bug, you should avoid letting an object's existance rely on "creation" events because it's designed more wrong in MMF2 itself.But it's only a "design mistake" in as far as MMF2 doesn't support its own feature altogether reliably.
Remove the wrong event and you lose an entire object and its events. Remove the wrong object and you lose a whole bunch of events, and if you notice it quickly enough you undo. Essentially, this result in very strange workarounds. If you rely on creation events and need to cut and paste a certain event you might need to keep a "dummy" to not lose the object and associated events. If you rely on an object's precense in the frame and wish to remove the last instance of an object to then later add it back to the frame, you must keep a dummy around to not lose events. In most design environments, things like this can never happen.
There should be no library of "objects present in the frame editor". The object list should be its own container; objects which you can place in a frame if you want to (but they can continue to exist even without being in a single frame or event). This is how most middleware work, and it's a much more functional solution. I don't want the object list to be removed. The object should be the true container for objects, as the frame is a container for instances. If an object is in the project's object list, it shouldn't disappear from there even if you remove it from a frame or a creation event.Otherwise, what is the point of MMF displaying a library of present objects in the frame editor? Otherwise you'd only be able to duplicate what you had in the frame by using the objects' right-click menus.
Ahhh, I read your message completely wrong. I apologise, sorry Nifflas.
I just meant that the list acts as a 'library' of objects which you have at your disposal. It was just a way of describing it that occurred to me.
Infact, now that you mention it, I agree that it would be preferable if things didn't disappear when a create action was removed. You could delete the object manually and thereby your 'undeleteable object' problem would vanish because MMF2 would never need to ask itself "do I still need this thing?". That's a clever thought. I'm sorry for the misunderstanding.
Posting Permissions
Reply With Quote