Leftmost is irrelevant, the screens always start at 0,0, even if there's not CAM allocated for these. And sometimes the collision data overflows the actual size, and in other times there are some unallocated columns of screens in the end. It might be hard coded, but there might be some number that represents the width or height. I'll try to see if I can find something like that.
Edit: Using a tool I made to split and recombine BND files I've split MIPATH. It seems that the object array size cannot be changed. I believe we're missing something between the collision mask array to the object array. Also, after the object array come 440 bytes of data. I have no clue what they do, but it seems essential, despite being mostly FFs. Edit 2: Thanks to the knowledge of the games mechanics I've learned, I've found a funny bug! In the first level of AE, go to the second screen, say "Hello, fellow me" to the Mudokon, and move the the next screen (down). Continue in the usual path until you get to the "Hop" sign. Stand by it for a minute or two. Then, continue to the next screen (up). The Mudokon should be in the right side of the road blocker now. :) |
:
Let me guess, the game doesn't recognise road blocker as an obstacle when its not on part of level you're in, is that right? |
Actually, the road blocker doesn't exist before Abe visits its screen, so the Mudokon doesn't "know" it's there, so it simply walks through it. When Abe visits the screen, it's already loaded, so even if he leaves the screen, the Mudokon can't pass through it now.
|
Oh, that explains why I can't make him go back... well, saving Muds from SoulStorm Brewery is now up to him...
|
:
|
You've got me confused, what is that Index Array you're talking about? :P
|
An array of ints that tells you where the object list starts for each screen
|
Oh, I get it now! Thanks!
Edit: Notice how the index array has indexes for some screens without CAM files. These are used for pitfalls. There's a pitfall object that handles this. (Forgot its ID, but I've checked it, it exists on "screens" below pitfalls, and also has X and Y values) Edit 2: To demonstrate it, move left using DDCheat from MIP01C04. |
From the collision data how did you figure out how many units one screen is? I don't see any platforms that take up only one screen, so I'm not sure how you know this?
|
I had to calculate it myself using information from ddcheat.
Edit: Structure for LCD signs: short magic; short size=1C00; long id=3C00 0000 short xStart; //Left short yStart; //Top short xEnd; //Right short yEnd; //Bottom short messageIDGreen; //0 to display only red (joke) messages short unknown; short messageIDRed; //0 to display only green (instruction) messages Edit 2: Portals: short magic; short size=2400; long id=1C00 0000 //x%25=1 short x; short y; short x2=x+24; short y2=y+24; short direction; short unknown; short unknown; short unknown; short unknown; short background; short type; //0 is stay open, 1 is rescue, 2 is shrykull, everything else is glitchy (yet funny) short shrykull; //number of muds for shrykull short unknown; //these probably deal with stay open portals |
Hmm looks like the lowest index in the array is actually always zero :( Looks like heuristically detecting the end of the collision data is the only way to get the real start of it. Heuristically detecting the end of the screens array seems to work ok so far though.
|
Yeah I believe it's all hardcoded, including the level width in screens.
Anyway, the structure for Muds: Mudokon short magic; short size=3000; long id=3100 0000 //x%25=1 short x; short y; short x2=x+25; short y2=y+20; short unknown; short type; //0 Mining, 1 cleaning , 2 "Angry worker", 3 Red Ring Giver, 4 Yellow Ring Giver, short direction; short voicePitch; //Some values do not work are reset to default, I'll research more about it later. short unknown; short unknown; short unknown; short unknown; short mood; //0 normal, 1 angry, 2 sad, 3 crazy, 4 sick short blind; //0 is normal, 1 is blind; short mood2; //0 normal, 1 slapper short unknown; short unknown; short unknown; |
I've managed to get all the data of R1 from AO loading correctly :)
36 screens 77 collision items 283 objects I'm going to make my app draw out the collision objects like yours does to see if it all makes sense. Then I will see about editing the information of each object, only problem is that all AO objects seem to have different Id's and data :( |
Good job! :) It kind of makes sense considering the fact the AE has more features. Take Mudokons for examples, these values were only added in AE: voicePitch, mood, blind, mood2. I think we should focus on one game at a time, however.
|
So here is the collision map for R1, now then why are there massive gaps between screens? I can see that the layout is certainly correct though!
Also I've given every "type" the same colour for now. Edit: Here we have the collision map for MI of AE, no gaps in this one! |
Mmm, these gaps ARE weird. I've figured shadows though, they're defined as objects, not as collision data. I have no clue what the red rects in my map mean now.
|
Here is a coloured version with screen splits for AE MI. I'm thinking it will be a good idea to draw the map objects in here too (at least the ones we know about, unless they all have position data?).
Edit: I'm really disappointed that AO has some weird spaced collision data :( I hope there is an easy way to make sense of it. |
Most objects do have positions, as rectangles (left top right bottom), and they're stored in the same position. It'd be nice if you made them render too! (Expect some random rects from the few rare objects without position though)
Edit: More objects! Stats Monitor: short magic; short size=1800; long id=4000 0000; short x; short y; short x2=x+25; short y2=y+20; short inThisTunnel; short unknown; short unknown; Ledge (From top) short magic; short size=1800; long id=0200 0000 //x%25=0 short x; short y; short x2=x+24; short y2=y+24; short unknown; short direction; short unknown; short unknown; //When it is set to 1, not only the ledge is no longer working, you can't even press the down key on it. Shadow short magic; short size=2000; long id=0600 0000 short x; short y; short x2; short y2; short unknown; short unknown; //These are signed shorts. short red; short green short blue; short background; //0 to affect BOTH foreground and background, 1 to only background. SligAIData //These define how a Slig behaves (e.g. Never cross this from the left. Cross this from the left only if you're chasing Abe) short magic; short size=1400; long id=2E00 0000 //x%25=0 short x; short y; short x2=x+24; short y2=y+24; short unknown; short unknown; |
|
What happened to the positioning of everything?
|
Cause I screwed with the Animation files, check out this vid:
http://www.youtube.com/watch?v=xqH1ZWU3sR0 Extreme UBX's :D |
Mmm, that's actually pretty useful for seeing where objects are...
|
Do you have a current list of object Id's? I'm gonna make my app print the object names and add drawing to the map at some point. Maybe it will make it easier to see whats going on?
|
19 UBX
3C LCD Sign 1C Portal 55 Path Blocker (Slam Door) 31 Mud 40 Stats Monitor (Escapees etc) 02 Ledge (from top) 06 Shadow 2E SligAIData 32 Something related to ledges 11 Lever 58 Teleporter |
:
:
|
its in the path files, usualy (level)PATH.BND.
I actualy manage to get all mudokons to turn into bombs myself. |
It appears that level scripting isn't that hard coded!
For Mudokons, the value about voicePitch is rescueID. Not all Muds have it, most will have it as 0. The last value for Portals is a Mudokon rescueID too, and so is the value after background in Path Blockers (Slam Doors). When a Mudokon with a rescueID is rescued (No matter via which portal), portals sharing this ID will disappear (Will no longer reappear), and slam doors sharing this value will open. This is probably the same with many other objects. I believe levers work similarly. I might figure out teleporters soon. Edit: Solved levers and teleporters. Lever short magic; short size=2000; long id=1100 0000 short x; short y; short x2=x+24; short y2=y+24 short type; //Not really sure what it does though short background; short unknown; short soundEffect; short unknown; short objectID; //The object it operates Teleporter short magic; short size=2800; long id=5800 0000 short x; short y; short x2=x+24; short y2=y+24; short sameScreen; //Unsure short DestTeleporterID; //Teleporter number in the destination screen. 0 based. short DestCamID; //Whatever comes after C in the screen name short unknown; //might cause inivsibility short unknown; short objectID; //for levers short background; short reloadObjects; //? |
Hmm I think your naming of some of these is confusing.. is a teleporter the thing you stand on that teleports you, or a bird portal that you jump into?
Also as of yet do you know of a way of linking the screens up with the collision data? I want to overlay the collision rects into the screen images... Edit: So I've done it for MI, yay! However it looks like the images should be 240 in height, so maybe you've got screen units wrong?? |
I see. It so that means there are 20 invisible units for each screen. That explains some of the troubles I've been having with calculating the size. So for the Y axis, a unit equals a pixel.
All bird portals are called one object, called portal. If you look at the structure I wrote for the portal object, it has a flag that sets it type. (Rescue, stay open, and Shrykull). Teleporter are those red "doors" where you stand by them and pull a lever. |
Hmm I see, Im about to try making maps from *all* path files. Then I will try the same but put the objects in there too, also I noticed that the X offset of the collision map isn't quite right, so perhaps the width is slightly off too?
|