Adding New Maps

Captain_Murphy · Post by **Captain_Murphy** » Sat Nov 27, 2004 9:07 pm

Fred, I just ried to take mod1 to mod2. I renamed the level, changed the maplua and script into in addme, changed the script names and dc:MOD\mod1.lvl to mod2.lvl, and I get that same memory error. It's got to be something in the header, something before the NAME field.

Even if I remove mod1 from the addon folder, it crashes.

Captain_Murphy · Post by **Captain_Murphy** » Sat Nov 27, 2004 10:42 pm

Yeah mod1 worked.

Playing with it though, it was the moment I tried to change the name of the individual script mod1c to mod2c. I changed it in addme first, then ran and got the expected crash (GCW still works though) then I chaged mod1c to mod2c in mission.lvl, and the game crashed in the same way. For some reason it does not want to accept the changing of script names.

In the mission.lua what is the info contained in the "lvl_" and "scr_" fields because this is what is holding us up. Any chance of releasing the mission.lua? I'm afraid without this we won't be able to add fan-build maps until SDK tools.

Captain_Murphy · Post by **Captain_Murphy** » Sat Nov 27, 2004 11:12 pm

Well, this worked kinda......

Using mod1 as a template, i first changed the addme showstring to my own label. Then I pasted the tat1 stuff into mod1's mission.lvl file, keeping the names of the scripts as mod1a and mod1c and never touching the scr_ and lvl_ portions. Then I changed the map reference from TAT\tat1.lvl to dc:TAT\tat4.lvl.

It worked. Problem is, you can't change the mapluafile in addme from MOD1 or you get crashes. This means, thanks of course to Fred, we now have 1 slot for custom maps. The game will always see the last "MOD1" loaded as the real one and all before it get overrided.

Fred, if we had a way to make addme and mission files from scratch as you did with mod1 we would be up and running. Anyway the powers that be could let us at least have that?

DravinClaw · Post by **DravinClaw** » Sat Nov 27, 2004 11:37 pm

What can i use to open the lvl file (newbie here)? and is it possiable to open up the files with with the kit that came with jedi outcast?

Captain_Murphy · Post by **Captain_Murphy** » Sun Nov 28, 2004 1:57 am

dravinclaw, i've been using ultraedit-32 to open lvl files. And less than a week ago I was a newbie to this too. Now I'm a hardened veteran.

Fred, yeah I tried that.

And what i just said worked actually didn't, the way I thought anyway. It wasn't loading a map, going strait to victory countdown, which i thought was a good sign because i never put a map in the map folder. WHen i did, it still would not load the map. THings started getting screwed up, hex-wise, and nothign would work, so I started from a clean copy of mod1

Here's step-by-step what I did for everyone's benefit.

Renamed mod1 folder tat4

Edited addme.script
showstring = ALT DUNES (I wanted to keep the same file size)
Edited mission.lvl
Copied and pasted original tat1i script from NAME to right before the lvl_ statement of tat1i_h. Renamed script mod1a
Copied and pasted origianl tat1r script from NAME to right before the lvl_ statmentt of tat2i. Renamed script mod1c

Launched game. ALT DUNES succefully loads tat1 (because i never changed that)

Edited mission.lvl
Changed TAT\tat1.lvl to TAT\tat4.lvl in both scripts (I have my tat4.lvl in that folder from a while ago)

Launched game. ALT DUNES succesfully loads alternate version of Dune Sea map. YAY!

Edited mission.lvl
Changed TAT\tat4.lvl to dc:TAT\tat4.lvl in both scripts

Moved tat4.lvl to my addon folder, making sure directory structure matches what I put in script.

Launched game. ALT DUNES crashes before I ever sea loading screen. The hell?

Edited mission.lvl
Changed dc:TAT\tat4.lvl to dc:MOD\mod1.lvl

Renamed tat4.lvl to mod1.lvl and renamed folder TAT to MOD

Launched game. Same crash, never even got to loading screen, which is unusual.

Edited mission.lvl
Changed back to TAT\tat4.lvl and move map back to TAT folder in builtin maps directory. Change maps name back to tat4.lvl

Launched game. Works fine.

Edited mission.lvl
Changed TAT\tat4.lvl to ADD\tat4.lvl and created a new directory in the builtin maps directory, moving my map there.

Launched game. Works fine.

Edited mission.lvl
Changed ADD\tat4.lvl to ADD\TAT\tat4.lvl and create new directory in ADD folder, moving my map there.

Launched game. ALT DUNE produces quick crash.

I'm pretty sure it's a file size thing. Adding "dc:" or "TAT\" caused immediate crashes, as if the game didn't even try to look in the location, but just gave up right away. Hopefully this is some hex editing thing that reily can solve.

Fred, All the mission scripts start with a lvl_ field and a scr_ field. When I use your mod1 mission.lvl as the basis, I leave that stuff untouched and it works in the way that i just described. If I copy those fields from the tat1i and tat1r scripts and paste them into my altered mission.lvl i get crashes.

The Addme.script has a scr_ field but not a lvl_ field. This info is obviously very important and the level will not load unless the correct info is in it. Most of us here are starting to suspect that this info determines what a good mapluafile name is (TAT3, MOD1, or any of the builtins) and what a bad one is (Anything we want it to be).

Because you gave us mod1, we now effectivally have a slot for addon maps. Unfortunately each person can only have one addon because we are forced to sick with MOD1 as out mapluafile name. Any changes to the mapluafile name causes crashes. Any changes to the script names from good (mod1a, tat3c, etc) to the bad (anything else) also produce crashes. Somewhere in the mission or addme or both, the script names and mapluafile names are encoded and we cannot seem to crack this.

Captain_Murphy · Post by **Captain_Murphy** » Sun Nov 28, 2004 2:13 am

And to specifiaclly answer your question. the mod1 to mod2 test didn't work. This is essentailly the same test we attempted tyring to rename tat3 to tat4. We cannot seem to change the mapluafile and script names. We need a way to make a raw addme.script and mission.lvl that we can then compile ourselves. There's obviously some info we just cannot get at with hexediting.

I realize that you probably cannot release anything like that on your own, but I'm hopeing you can bring our concerns to your bosses and let them know of our delima.

As a stop-gap solution, if you could make, say, 9 more mods (mod2 - mod8 & mod0) that would give the modders here some slots to work with to make play-testing easier. By following what I did in here, they could then put up to ten custom maps into their selection screen. It's a lousy fix, but it's looking like that's all we've got.

Captain_Murphy · Post by **Captain_Murphy** » Sun Nov 28, 2004 3:04 am

Yeah, that rejection of the "dc:" part of the path is a file size thing (or string size?).

I put dc:TAT\t.lvl (I had to add three characters, so I removed three characters from the file name)

and it works. It loads the map from my addon folder.

This is annoying though. Does anyone know how to address this issue?

eddie · Post by **eddie** » Sun Nov 28, 2004 3:50 am

Fred:: "Eddie, I downloaded your test, renamed ..." You missed the whole point of the test, You should not rename folders but stuff inside addme to TAT4 and mission to TAT4 and if you get to victory screen GREAT (no matter there is no level file and core). We know how to reference stuff from there.

Murphy:: Can you post MOD1.zip somewhere. It seams that Freds link does not work anymore.

Also short names for game folder and level.lvl works also for my DS/DS.lvl as result of BES\BES1.lvl to dc:DS\DS.lvl (12 chars long) so this is not an issue. I think we will be fine adding/removing stuff from mission once we get main issue worked out (routing new levels)

I am glad you did get some progress. Maybe riley is rights. It has to have control code in that spot he hightlithed.

Riley can you compare (lets call it control code) control code from mod1 and tat3 and try to see difference. I was thinking maybe for TAT3 control code is 3x16, Tx32,Ax48, Tx64 or something similar.

And look control keys:
BA 96 CC 77 for tat3a
94 93 CC 75 for tat3c

kinda similar!?! (also it looks that tat3a and TAT3a as scr_name works so we have to take this into considiration also)

Edit* Experimenting more I think Riley is right lvl_ passes name of scr_ to be executed and BA 96 CC 77 probably means tat3a.

Also you know have have to have unique name same as script names within addme (TAT4 and TAT4a and TAT4c) so it must be in this control key. Riley did you compare control key with other levels control keys? They do not make much sense! EDIT* tried with couple of levels and copying only control key charshes the game. So it is more them just control key.

Murphy can you post control key of mod1a and mod1c from Freds level?

Also, is addme script of tat3 and mod1 the same (beside MOD1, MOD1a and MODc part)?

"Yeah, that rejection of the "dc:" part of the path is a file size thing (or string size?). " - dc (donwloadable content) is just a command for mission to look in local folder rather than on main game folders. It works for other stuff too.

-------

Finally got my hands on mod1.zip (thanx Howard!), so i wil get into this also. Good basic map. It can be a great starting point for making new maps once we crack this adding new levels thing.

More or less got the same results as Murphy.

Hmm, mod1 vs tat3: all different regarding important parts. I think the problem is (as Fred said) that when PS make a map it goes through 3 levels of compiling (maybe even 3 different compilers) so finished hex code is hard to decompile going back through 3 levels. Riley and/or Lucky are our last hope.

eddie · Post by **eddie** » Sun Nov 28, 2004 10:56 am

Going little bit off the subject. I started to change mod1 to new death star level to test what we can add to world.lvl.

You can get my first attempts at (mod1 remoded):

http://www.eline.ba/Default.aspx?tabid=155

Riley75 · Post by **Riley75** » Sun Nov 28, 2004 11:58 am

eddie, I've looked at many of the "lvl_" chunks, and those 4 bytes I've been talking about are generally always vastly different. I've been trying to say that I believe it's some kind of calculated or hashed value based on the name of the embedded *.lvl file. At the very least, I know it means something to the game, because if you try changing those 4 bytes, the game crashes when it tries loading the corresponding mission.

Some examples from the original mission.lvl file:
bes1a = 6B BD 18 86
bes1a_h = 7C 71 68 D4
bes1r = 2E D8 18 97
bes2a = 00 60 1F 76
and so on...

They are generally always vastly different, and there doesn't seem to be a pattern. And yet, as I said above, they definitely mean something to the game.

Fred, I don't suppose you'd be able to ask whoever wrote the code to compile embedded *.lvl files about this?

It's just frustrating, because I'm almost positive that if we can solve this one tiny issue of the chunk marker immediately inside the "lvl_" chunk, we'd solve the issue we've been talking about for several pages in this thread.

eddie · Post by **eddie** » Sun Nov 28, 2004 1:09 pm

I hope you are right that 4-byte is the only thing we should change in order to load let us say tat4 or mod2 levels.

I think Fred/his team are the only ones who can help us decoding this.

I also tryied to change some other stuff within header and some other stuff will crash your level (maybe they are size markers, but maybe they are not) like 66 on b0h address (tat3 mission) and stuff before and after lua in the same file.

HowardBusch · Post by **HowardBusch** » Sun Nov 28, 2004 3:08 pm

eddie wrote:I hope you are right that 4-byte is the only thing we should change in order to load let us say tat4 or mod2 levels.

I also tryied to change some other stuff within header and some other stuff will crash your level (maybe they are size markers, but maybe they are not) like 66 on b0h address (tat3 mission) and stuff before and after lua in the same file.

The 66 00 00 00 at B0h is the number of strings that follow.
Which other bytes do you have questions about?

Still cant figure out the algirithum for the checksum but it definitly exists.
look at the patterns.

tat1i A4 61 D2 4B
tat1i_h 0B 5B a2 89
tat1r F5 72 D2 56
tat2i Df 12 CA 4B
tat2i_h 18 59 01 f0
tat2r 3A 3A CA 64
tat3a BA 96 CC 77
tat3c 94 93 CC 75

kam1c 43 5A 3D 32
kam1c_h 7B 6A c8 16

kas1c 42 12 BD 13
kas1c_h BD 30 B8 CD
kas1i B4 1B BD 19
kas2c AD DC B4 23
kas2c_h DA 49 0F 24
kas2i EF CC B4 19

bes1a 6b BD 18 86
bes1a_h 7C 71 68 D4
bes1r 2E D8 18 97
bes2a 00 60 1F 76
bes2a_h 5F 76 d8 99
bes2r E9 7D 1F 89

eddie · Post by **eddie** » Sun Nov 28, 2004 3:39 pm

You see a pattern there?!?

Anyhow, how about bytes before and after lua on 40h?

If you find checksum that would be great!

Captain_Murphy · Post by **Captain_Murphy** » Sun Nov 28, 2004 4:10 pm

Looking at howards post I notice that 2nd to last bit for sibling scripts (ie, bes1a-bes1c, bes2a-bes2c) are identical. This pattern holds for tat3 and mod1.

Could this be the reference to mapulafile?

Edit: I just looked above and saw that edie figured this out.

Here's mod1 control keys.

mod1a F5 12 0A AD
mod1c CF 0F 0A AB

Riley75 · Post by **Riley75** » Sun Nov 28, 2004 4:12 pm

Everything after "BODY" and the 4-byte size marker -- starting at hex position 0x00000044 -- is Lua byte-code, as described here:
Lua Byte-Code Info

As for what you're calling checksums (which actually might make more sense than what I what saying earlier), I'm glad somebody sees a pattern in them. heh

That's a little out of my area of expertise.
*edit* Yeah, you're right about the 3rd byte, Murphy. Good catch!

eddie · Post by **eddie** » Sun Nov 28, 2004 4:23 pm

Did a little experiment for Howard: my death star map loads fine as BES1 (bes1a). And I have only DS folder in AddOn.

Then I changed BES1->BES2 and all other stuff bla bla, and put bes2a checksum = WORKS!

Tried with tat3a check sum (after changing everything to TAT3) = WORKS.

And that was all "a" scripts. Tried with "r" script and did not work. But this is not important, if he finds logic for "a" and "c" scripts we are set.

HowardBusch · Post by **HowardBusch** » Sun Nov 28, 2004 4:40 pm

Definite patterns
look at the ones that are 4 characters whare only the last letter changes, the 3rd byte is the same & the last byte is different by the differance in the letters. lots of patterns (I know Ive spent to much time working with data in hex)

at 40h the d1 12 00 00 is the lenth of the next chunk of data which runs to the next lvl_ or the end of the file if the last one. The data is padded to allign on an even double word boundry.
The 1B that follows appears to be constant.

Riley75 · Post by **Riley75** » Sun Nov 28, 2004 5:08 pm

Heh, I wish we could sticky a link to my site or something. Either that or if I could get feedback from people on whether any of it is useful and makes sense. People keep independently discovering the same things I've had posted on there a month ago.

the last byte is different by the differance in the letters

I'm not sure that's always true. Look at bes1a/r and bes2a/r; in one case they differ by 17, in the other by 20.

This is the script that sets up the mission lists before this tat3 add-on:
In shell.lvl, missionlist script

You can see what the a/c/i/r mean. They refer to the attacking (default) faction:
a = Alliance
c = Confederacy
i = Imperials
r = Republic

Captain_Murphy · Post by **Captain_Murphy** » Sun Nov 28, 2004 5:18 pm

Yeah, after each heading (ucfb, lvl_, scr_,BODY) the size of that particualar chunk is represented. I spent a while figuring this out last night as was quite proud of myself. With two bytes you can figure out the chunk byte size by xx + yy*255. The main mission.lvl ucfb represents a much larger chunk than any we routinely deal with. It has three bytes representing the size and it's xx + yy*255 + zz*255^2

Funny thing is, addon mission.lvls don'tt seem to care too much about these size markers. Before I figured this stuff out I used mod1, with unchaged size headers even though I added tons of bytes and it didn't mind. The only problem it had was when I failed to update all the headers, and so my chunk sizes were illogical. Still with all my chunk sizes updated and the size header for the map loading string bumped up the reqiered bytes, I cannot get BF to let me fit dc:TAT\tat4.lvl. I must truncate the map to t.lvl for it to work.

Also I have not been able to succefully edit the addme script to make it bigger to allow for a larger showstring than in is tat3 or mod1. Either the game crashes on boot or the map fails to appear in the list.

Captain_Murphy · Post by **Captain_Murphy** » Sun Nov 28, 2004 5:31 pm

A key to craking the control key could be in understanding why the 3rd byte in sibling scripts is the same and also why the 3rd byte of a corresponding historial script is different.

For example, according to the link riley just put up, the mapluafile for tat1i and tat1r is "TAT1" the mapluafile for the historial tat script is "tat1i_h"

tat1i A4 61 D2 4B
tat1r F5 72 D2 56
tat1i_h 0B 5B A2 89

What caused D2 to become A2?