Now we can edit the main core.lvl!

[Giftheck]

http://www.gametoast.com/forums/viewtop ... =1&t=17595

Brilliant or what? BattleBelk extracted "chunks" from core.lvl and made it work properly!

[Radical_Pi]

meh. Maps can overload the main core.lvl already, so no need to change it

Also, since I'm not on GT, I'll say this here. It is ILLEGAL to decode shell.lvl. It contains the true source for the game (as in the menus and the maps loading and CP handling and almost anything you interact with ingame). The EULA specifically states that you are not allowed to derive source code or algorithms used by the game. So I would recommend not touching it without LucasArts' permission. Anyways, everything is in compiled LUA bytecodes in shell.lvl, so you need to manually run the bytecode viewer that is on the LUA compiler shipped, then manually type down the source code, assuming you can read assembly.

On the other hand, you could just use the SWBF2 semi-source that is shipped in the mod tools. for SWBF2. It has the commands for any ingame shell, so you might be able to figure out the API from that to do anything useful with ingame (ooh I just got an idea from that. See ya)

[vf501]

Shell.lvl is not the true source, you can touch it, and compile your own.  The real meat of the game is the Game Executable, which contains the game engine that runs all the other sources and the real time render engine (in this case ZeroEngine which is owned by Pandemic, LucasArts only owns the rights to all visual elements that contain any IP they own).  Shell.lvl only contains the Games UI, the menus and displays that are interacted with out of gameplay, it has nothing at all to do with how CPs are handled or how maps are loaded (its only point of interaction with maps is displaying them in the UI/Shell menus).

SWBF Mod Tools EULA contains nothing against decoding or hexediting .lvl chunks, only executable files.  Lvl files are basically a storage file that compiles all the given data into on location as 4-bit/8-bit information with each type of data segregated into chunks.  When the game is run, it loads each main .lvl and then from there looks for everything it needs to do what is instructed of it.  Once Common, Core, Shell, and Mission lvls are loaded it will use instructions from those to determine which .lvls to load next based upon what the user wants.

[Radical_Pi]

lol, I just realized that we blew past the EULA rules a LONG time ago

(4) reverse engineer the Software, derive source code, or otherwise attempt to reconstruct or discover any underlying source code, ideas, algorithms, file formats, programming or interoperability interfaces of the Software by any means whatsoever, except to the extent expressly permitted by law despite a contractual provision to the contrary, and then only after you have notified LucasArts in writing of your intended activities;

For example, 1 is decoding the LVL format (not very hard to figure out though), and even the Crosswalk MSH converter could be considered illegal. I don't think LucasArts is watching. Now, to brush up on LUA assembly

[Jedikiller]

Modding of any kind is against the EULA. So... it's not like we're doing anything more illegal than what we're already doing, apparently. But LA and Pandemic endorse modding, so no harm done.

Regardless, nice discovery.

[Radical_Pi]

Actually, if you read the mod tools EULA, they say nodding is allowed, but we still break it by not giving out our real name and address in the readme (seriously, it says that)

[vf501]

The Original SWBF EULA, prohibits any sort of modification of the game, however from a legal standpoint, certain provisions of the original SWBF EULA are overridden and made void by the SWBF Mod Tools EULA, as it is issued by the makers of the game.  Because the ModTools EULA was issued by the developers and has points that run counter to the original EULA, the ModTools EULA can be seen as a revision of the main EULA for SWBF, including the points that reinforce those already made in the original EULA.

TL:DR Version.

The ModTools EULA is basically a revision/addendum to the SWBF EULA and any aspects of it that overlap, override the original.

[Dresh]

Ok, this debate has been had on many occasions on many sites....you also need to check out the EULA distributed along with the mod tools....not just the one with the game.

[Giftheck]

EVERYTHING in the new core.lvl is already pre-munged so the only real thing that can be added would be localization. Here was the core.req posted:

Code Select Expand

ucft
{
REQN
{
"bnk"
"align=2048"
"global"
}

REQN
{
"config"
"global"
}

REQN
{
"font"
"gamefont_large"
"gamefont_medium"
"gamefont_small"
"gamefont_tiny"
"starwars_small"
"gamefont_super_tiny"
}

REQN
{
"loc"
"english"
"spanish"
"italian"
"french"
"german"
"uk_english"
}


REQN
{
"texture"
"cube_normalizationmap"
"hemisphere_normalizationmap"
"specularspot"
"attenuation_volume"
"linear_ramp"
"specularcubemap"
}

REQN
{
"shader"
"normal_shader"
"interface_shader"
"particle_shader"
"terrain_shader"
"sprite_shader"
"skyfog_shader"
"foliage_shader"
"lightbeam_shader"
"scroll_shader"
"flare_shader"
"sample_shader"
"rain_shader"
"normalmapadder_shader"
"prereflection_shader"
"water_shader"
"stencilshadow_shader"
"shadowquad_shader"
"specular_shader"
"detail_shader"
"ocean_shader"
"refraction_shader"
"decal_shader"
"filtercopy_shader"
"shield_shader"
"bump_shader"
"zprepass_shader"
}
}

It only contains fonts, shaders, and localizations, and menu sounds, nothing too heavy. And TBH if LA wanted no main-game-modding, or, indeed, BF2->BF1 porting (since if we're going by what The_Pi said, could be considered illegal since it modifies a BF2 level to work with BF1) we'd already be shut down here. Other sites would also be closed because of the BF2 hex-edit hacks to allow different players, before BF2 mod tools were released. So I think LA overlooks it. And besides, they're too busy with BF3 right now.

I believe about shell.lvl, Psych0Fred made his own a long time ago, with 7 units and everything.

[Napseeker]

> I believe about shell.lvl, Psych0Fred made his own a long time ago, with 7 units and
> everything.

In fact, if I recall there was no actual limit on how many units could be added to the selection screen.  You could've had more than 7 even, but the problem was anything more than 7 would be below the visible part of the screen and inaccessible to the mouse.  That said, while the shell allowed 7+ units, the game itself may only have reserved enough memory for 7 soldier units per team and no more, so it's likely anything more than 7 would crash BF1 anyway... or at least the multiplayer engine which seems fragile as heck to any major changes.

[Radical_Pi]

If the problem is memory, adding some extra units to the MemoryPool area could get around it.

[Napseeker]

That's true, hadn't thought of that... but was there actually a memory pool type for soldiers/units?  I don't think I ever used one myself, nor recall seeing it used in the sample mission LUAs.   I'm assuming it'd be something like EntitySoldier or EntityUnit.

[Radical_Pi]

Memory pool type is the same as the ClassLabel at the top of the ODF with entity at the beginning. Therefore, "entitysoldier" should handle it. However, the problem is you are overriding default values by doing that, so I'd take a look at figuring out the default value.

Alternatively, and I'm not sure if this would work since I don't know about the memory management, you could increase the value in some type that isn't used, but I'm not sure if the object can overrun into other object memory.