The best ways are to put it in a group which you then disable, to put it in a subevent of a function, or the subevent of an event which will only trigger once.

Something else which may change to be aware of; 0.98 introduced tagged animations, so in 0.98.3 hopefully there platform behavior will automatically change the character's animations (if you tag them).

May be worth changing to that and explaining it briefly in the first tutorial .

This should patch up everything (and fix the old families bug).

Any problems, put them on the tracker, don't post them here or they'll get lost.

I got some colorful socks I didn't expect .

You need to replace Group and Item with strings like "GroupName" and "ItemName".

There's only like two styles of building there and they're massive when compared to the small sprites you linked in the other post. To clarify, I was rather looking for some small buildings, maybe 96 pixels wide and 32/64 in height.

Going to bump this because I'm desperate for some building sprites .

I definitely thought the dropping through platforms with down was a bit strange, so a toggle there will be added. Jumping through sides should be fixed for 0.98.2 also.

Blah, always problems with a huge new build.

Okay, delete/edit action muddled up is fixed, and creating objects by index now has a correct offset (it was off by one).

I can't reproduce any custom family issue however; is there any extra steps needed in that one?

There'll be a new 0.98 tonight to fix those two issues above, and hopefully that's the end of the new introduced problems. Post quickly if there's other teething ones.

Bone movement behavior problems that are known of

• Clicking animation/resource properties will get you stuck in the editor
• Hitting delete while editing a limb will remove it and cause a crash exiting the bone editor

Any others there? These probably won't be fixed till 0.98.2, but both can safely and easily be avoided so it's not really a problem.

1. Serialization order

Let's say I've fields: myVal1, myVal2 in EditObj, and fields: myFirst, mySecond in RuntimeObj. How should I do serialization stuff in code (serialization.cpp). Is this solution correct (treating 'ar' as stack):

/////////////////////////////
// RUNTIME serialization
void ExtObject::Serialize(bin& ar)
{
	if (ar.loading) 
	{
		ar >> mySecond;
		ar >> myFirst;
	}
	else 
	{
		ar << myFirst;
		ar << mySecond;
	}
}[/code:1xb4pd11]
[code:1xb4pd11]/////////////////////////////
// EDITTIME serialization
void EditExt::Serialize(bin& ar)
{
	int Version = 1;
	SerializeVersion(ar, Version);

	if (ar.loading) 
	{
		ar >> myVal2;
		ar >> myVal1;
	}
	else 
	{
		ar << myVal1;
		ar << myVal2;
	}
}[/code:1xb4pd11]

If you save myVal1 first, then you should load it first, instead of loading myVal2 first. That'd mix up the data.

2. Passing values from EditObj to RuntimeObj

Created RuntimeObj stores handle to EditObj to have access to its data and stuff. Let's say I've two values in EditObj: myVal1 and myVal2. I want to make use of them during Runtime as well (by ACE Methods). Do I need to make fields "myVal1, myVal2" in RuntimeObj as well and duplicate data from EditObj in method "void ExtObject::OnCreate()", or maybe I can access EditObj fields from ACE Methods and not worry about making fields at RunTime Object?

Data which is serialized at edittime can then be loaded similarly in OnCreate, like this:

void ExtObject::OnCreate()
{
	// Load settings
	bin ar;
	ar.attach(info.editObject->eData, info.editObject->eSize);

	int Version = 0;
	ar >> Version;

	ar >> tile_width >> tile_height >> speed >> play_if_stopped;
	ar.detach();
[/code:1xb4pd11]

Two important things to note:  you must load a blank version number (as the edittime saves one), and you must call ar.detach() after you've loaded your data.  It's up to you whether you store the loaded variables (as above) or just define them locally in the function for using when creating the object.

For objects which don't show in the layout.

Before, if you inserted these they were liable to get deleted when you removed other layers, which was a big problem.

When a talented Linux developer decides to help us out .