MechWarrior: Living Legends Wiki - User contributions [en]

Madcat MKII

2025-09-01T19:12:21Z

Fire-hound: /* Variant A - "ER-BeatStick" */ 0.18.3 fluff update

{{Mech|
| Image = File:MKII.png
| ImageGif = File:Madcat_MKII_spin.gif
| Class = Assault
| Faction = Clan
| Tickets = 14
| Tier = 15
| Tonnage = 90
| Speed = 64
| Rotation = 170
| PitchStand = -25° to +40°
| PitchCrouch = -25° to +50°

| Price Prime = 119 900
| ArmorT Prime = 76 714
| Engine Prime = Type 79 360 Fusion XL
| Weapons Prime = <ul>
<li>2x [[CGauss]]
<li>2x [[CLRM10]]
<li>2x [[CERML]]
<li>2x [[CERSL]]
</ul>
| Equip Prime = <ul>
<li>[[EOptics]]
<li>[[iJJ]]
<li>3 [[DHS]]
<li>2 [[free tons]]
<li>16t [[Armor]]
</ul>

| Price A = 106 500
| ArmorT A = 84 237
| Engine A = Type 79 360 Fusion XL
| Weapons A = <ul>
<li>4x [[CERSL]]
<li>6x [[CLBX5]]
</ul>
| Equip A = <ul>
<li>[[EOptics]]
<li>[[iJJ]]
<li>2 [[DHS]]
<li>0 [[free tons]]
<li>17.5t [[Armor]]
</ul>

| Price B = 111 800
| ArmorT B = 80 226
| Engine B = Type 79 360 Fusion XL
| Weapons B = <ul>
<li>2x [[CUAC20]]
<li>2x [[CSRM6]]
<li>1x [[B-Pod]]
</ul>
| Equip B = <ul>
<li>[[iJJ]]
<li>5 [[DHS]]
<li>2 [[free tons]]
<li>16.5t [[Armor]]
</ul>

| Price C = 115 500
| ArmorT C = 74 710
| Engine C = Type 79 360 Fusion XL
| Weapons C = <ul>
<li>4x [[MG]]
<li>2x [[ArrowIV|CArrowIV]]
<li>2x [[CERLL]]
</ul>
| Equip C = <ul>
<li>[[EOptics]]
<li>[[JJ]]
<li>8 [[DHS]]
<li>4 [[free tons]]
<li>15.5t [[Armor]]
</ul>

| Price D = 115 200
| ArmorT D = 78 720
| Engine D = Type 79 360 Fusion XL
| Weapons D = <ul>
<li>2x [[CLPL]]
<li>2x [[ATM12#Standard|ATM12 (Std)]]
</ul>
| Equip D = <ul>
<li>[[EOptics]]
<li>[[iJJ]]
<li>[[BHP]]
<li>9 [[DHS]]
<li>2 [[free tons]]
<li>16t [[Armor]]
</ul>

| Price E = 114 300
| ArmorT E = 76 714
| Engine E = Type 79 360 Fusion XL
| Weapons E = <ul>
<li>4x [[RAC5]]
<li>4x [[MG]]
<li>2x [[ATM3#Standard|ATM3 (Std)]]
<li>1x [[B-Pod]]
</ul>
| Equip E = <ul>
<li>[[EOptics]]
<li>2 [[DHS]]
<li>4 [[free tons]]
<li>16t [[Armor]]
</ul>

| Price F = 129 400
| ArmorT F = 82 356
| Engine F = Type 79 360 Fusion XL
| Weapons F = <ul>
<li>4x [[MG]]
<li>2x [[CERPPC]]
<li>2x [[ATM9#Extended Range|ATM9 (ER)]]
</ul>
| Equip F = <ul>
<li>[[EOptics]]
<li>[[iJJ]]
<li>[[GECM]]
<li>[[C3]]
<li>12 [[DHS]]
<li>2 [[free tons]]
<li>17t [[Armor]]
</ul>

| Price G = 124 700
| ArmorT G = 76 714
| Engine G = Type 79 360 Fusion XL
| Weapons G = <ul>
<li>2x [[HML]]
<li>2x [[HSL]]
<li>2x [[CLRM10]]
<li>2x [[HAG20]]
</ul>
| Equip G = <ul>
<li>[[EOptics]]
<li>[[iJJ]]
<li>4 [[DHS]]
<li>4 [[free tons]]
<li>16t [[Armor]]
</ul>

| Pods = Both
| Armor H = 2760
| Armor LRT = 6245
| Armor CT = 11528
| Armor B = 5764
| Armor LRA = 7445
| Armor LE = 2882
| Armor RE = 2882
| Armor LRL = 7349
| Armor INT = 4410

| Version153 = 0.18.2
}}

The '''Madcat MKII''' is a well-armored [[Clan]] [[Assault Mech]] with [[Jump Jets]].

The MKII has a limited field of view - the large cockpit will partially obstruct your aim when looking down. Combined with the MKII's low max torso [[twist]] angle, it can be very vulnerable to [[Battle Armor]]. The MkII is among the fastest Assault Mechs on the field, boasting a top speed of 64 kph, and is one of two Clan Assault Class Mechs with Jump Jets, which provide it surprising maneuverability for its size and firepower. Its armor, while tough, is insufficient for extended brawling.

==Roles and Gameplay Hints==

===Prime===
The Mad Cat MkII Prime is one of the most versatile and deadly Assault Mechs available to the Clans. Its Primary weapons are a pair of [[CGauss]], able to strike out to 900 meters with precision and devastating firepower. Backing up this lethal pair are two [[CLRM10]], solidifying this Mech as a long-range skirmishing tool. It is, however, also fitted with two [[CERML]] and two [[CERSL]], giving it teeth for close range and some capability once out of ammo. Take advantage of this variant's speed and [[Improved Jump Jets]] to strike from unexpected directions, and keep your foes at arms reach if possible. When facing one, it is likely to be in a sniping position far from the front, so sneaking up on one is the most successful strategy. Its primary firepower is in the arms, so if in doubt, remove its guns! Unlike the Canon variant, it also packs 2 spare tons of ammo to provide some endurance on the field.

===Variant A - ''"ER-BeatStick"''===

The famous '''''"Beat Stick"''''' is one of toughest Mk II units to deal against. Wielding a formidable array of half a dozen (6!) [[CLBX5]]es, it has enough firepower to lay waste on any unit within 800 meters even in a single salvo. In addition the A variant also mounts four [[cERSL|ER Small Lasers]] to exploit any breaches from close up with pinpoint accuracy. This unit also sports an extra 1.5 tons of [[armor]]. While the unit is not equipped with spare ammo or any electronic counter measures they might not be missed much with the ideal roles this unit can excel at - a jump sniper, a skirmisher, it also has excellent ambush potential with the Assault class Improved [[Jump Jets]] allowing it to scale the most arduous obstacles. In and out of the fray. 
Still the units greatest advantage might not be as obvious on paper - it's dreaded array of Luballin Bore Autocanons is distributed over it's arms and torsos effectively making any hasted attempts to quickly disarm it futile and likely to fail - any single section rendered ineffective won't decrease the impeding salvo for any more but a third even if that. 
It seems worthy noting that the '''''"Beat Stick"''''' further stands out as the cheapest most for this chassis.

===Variant B===
This variant's simple loadout of two [[UAC20]] and two [[SRM6]] can unleash ''terrifying'' amounts of damage, obliterating anything that falls within 350m of your menacing presence. The (relatively) high mobility of the MKII chassis shines especially bright in this loadout, where you can always position yourself to be right where your enemies want you least- and have a fighting chance to slip away if you're caught out of position. Where its cousin ''"The Beatstick"'' boasts slightly higher damage numbers than the MKII B; the MKII B can operate without ever having to go [[radar|radar active]], and has all of its damage packed into two weapons, instead of having to manage three different ranges and reload times. The MKII B will suffer more if caught out of position, though- with an effective range of ~350m, and movespeed of 64kph; ''everything'' you face will have either a range or movespeed advantage over you- and ''will'' move to capitalize on it. Its up to a skilled pilot to use its [[Jump Jets|iJJ]] to trap your enemies within an 'event horizon' of this monster, and if successful- erase that sorry 'mech from the galaxy.

===Variant C===
The C variant is geared towards long- and extreme-range fire support, equipped with two [[CERLL]]s and two [[ArrowIV]] [[Missiles|Missile]] launchers. It is capable of dealing high damage at very long ranges and is also equipped with Jump Jets, which allow it some mobility and enable the use of [[Gameplay Tactics#Poptarting|poptarting]] tactics. Four Machine Guns provide some protection from [[Battle Armor]] or etching away at armor. Four extra tons allow this variant to maintain considerable ammo-independence. The MkII C's most glaring weakness, however, is that its main weapons generate a lot of heat and have long [[refire rate|refire rates]], making it highly ill-suited for short- to medium-range engagements. In addition to this, the MkII C cannot deal Alpha Strikes, at least not without inflicting significant damage to itself. When attacking a MkII C, it is well-advised to stay at range while moving behind cover, and then sneaking up to engage it at close range where it is nearly incapable of defending itself.

===Variant D===
A medium- to long-range brawler and support 'Mech, the D variant of the MKII trades out the pair of Gauss Rifles for a pair of [[CLPL|Clan Large Pulse Lasers]], somewhat lessening the Mech's ammo-dependence. Though the two Large Pulse Lasers are excellent for long-range damage, the main firepower of this variant comes from two Standard [[ATM12]]s, which are most effective at medium or intermediate range. Feeding these two rather ammo-hungry missile systems are an extra [[free tons|2 tons of ammunition]], giving the MkII D a little more battlefield endurance. Equipped with [[BHP|Bloodhound Active Probe]] which increases standard Radar detection range by 400m, [[iJJ|Improved Jump Jets]] and 9 [[DHS]], makes the D a very formidable foe on the battlefield.

===Variant E - ''"Siege Engine"''===
Known as the '''''"Siege Engine"''''', this behemoth will inflict massive damage up close. Group the four [[RAC5]]s and four [[MG]]s together to quickly tear through even the toughest opponents. Watch for counter fire that causes screenshake, it'll throw off your aim and spread your damage. The pair of [[ATM3]]s can be used as an opening salvo before closing into effective range (under 300m) for your [[RAC]]s. Though setting your radar to [[Radar#Passive_Radar|passive]] mode to help stay undetected while closing distance can be a massive payoff. The combined [[RAC]]s and [[MG]]s usually make quick work of [[Battle Armor]] but a [[B-Pod]] is provided to finish them off. The lack of Jump Jets means the MKII E is not nearly as mobile as most other MkII variants. Its arm mounted [[RAC]]s are prime targets to be shot off. Good positioning and team play is key for making this variant shine.

===Variant F===
A rather odd variant for a MkII base, the MkII F carries a wide array of weaponry, and is the only variant to mount any specialized electronics equipment. This equipment is the [[GECM]], which allows the Mech to engage in long- to medium-range attacks without being easily noticed. [[C3]] for distributing key information to teammates in range. [[EOptics]] for precision and long-distance aiming. At 1250m lock on to your victim, release a barrage of missiles to rain down on them. As they cross into 900 meter range open up with two [[CERPPC]] and at anytime let loose the four [[MG]],s.
Twelve [[DHS]] for heat dissipation, Two [[Free tons | Free tons]] supply the ATM9(ER) and 1 extra ton of Armor for staying power. Don't be bashful about letting your opponent know who's in charge.

Note: This asset has both [[C3]] and [[GECM]], meaning there is no benefit to using [[Radar#Passive Radar|passive radar]] except when covered by allied [[AECM]].

===Variant G===
Geared for long-range strikes, the MkII G can be a heavy hitter when its guns come into play. These guns include a twin [[HAG20 | Hyper-Assault Gauss 20]], and a pair of [[CLRM10|Clan LRM10]]s. The twin [[HAG20]]s are especially lethal when used in precision strikes, as the combination can easily shred through individual components on most light and medium assets. The two LRM10s offer long-range striking power, and can even be used in brawling at closer ranges due to the Clan LRMs having almost no [[minimum range]].
The inclusion of Improved Jump Jets and an 4 extra tons for ammunition - ideally for the [[HAG20]] - offer this variant some degree of maneuverability and endurance. Despite the high amounts of damage the MkII G can dish out at long range, its greatest weakness is the insufficient amount of [[DHS]] when G gets into a brawl, since 2 [[cHML]]s and 2 [[cHSL]]s generates a lot of heat.

==Canon==
The Mad Cat Mk II was in development for fifteen months by the time production began in 3061. The sole rationale for the Mad Cat Mk II was to increase profits for Clan Diamond Shark after war with the Inner Sphere in the 3050s. Designed to be sold to fellow Clans - and later sold to the Inner Sphere - this rebuild of the iconic Timber Wolf OmniMech carries thirteen tons of Ferro-Fibrous armor while being one of most nimble BattleMechs of its class, and still packs serious weaponry. The standard variant sports two Gauss Rifles and two LRM10s, which make for devastating long-range assaults, while four ER Medium Lasers provide adequate support at medium to short ranges. Other variants range from simple, unified long-range configurations, to more radical intermediate range monstrosities. On a limited basis, Clan Diamond Shark sold unmodified Mad Cat Mk IIs to a few Inner Sphere factions - most notably the Draconis Combine and Federated Commonwealth, and the Lyran Alliance would also buy an unknown amount.

Date Introduced 3062 during the Era known as "Civil War" (3062 - 3067) - Unit Role: Brawler

[http://www.sarna.net/wiki/Mad_Cat_Mk_II BattleTech Reference]

{{Template:Navbox Assets Clan}}

Factory Entities

2025-05-10T17:35:52Z

Fire-hound: typo found

{{ Stub }}
Our game mod's strongly depends on building assets ranging from weapons to assault class war machines that fly or crawl across the battlefields of 31st century. To facilitate this we use factories across the map.

== Factories ==

<div style="clear: both">
For any factory to even exist or function in the level it has to have the '''Factory Entity''' to begin with. 
[[File:Factory_Void_of_mesh_team_tan_Use_Entity_true_Helper_spawn_VAI61_.jpg|frameless|600px|left|Factory Setup details in Sandbox2 Editor]] 
</div>

<div style="clear: both">
This entity can optionally have an mesh assigned to it (the "model" property).
For said '''Entity''' to be usable at all it has to have at the very least the '''BuyArea''' defined ''and assigned'' to it.
[[File:Buy_Zone.jpg|frameless|600px|Buy Zone Area Shape Highlighted in Sandbox2 editor ]] [[File:Buy_Zone_Area_Shape_Link_Target.jpg|frameless|600px|Buy Zone Area Shape Target to link to ]]
</div>

<div style="clear: both">
Once said factory has ''a team'' assigned to it (by default '''property''' or by a designated '''Capture Point''') a player ''that is a member of that team'' can exchange c-bills for assets designated as available in that Factory.[[File:Capture_Point_Link_members.jpg|frameless|600px|Link list members for the Capture Point entity ]]
</div>

<div style="clear: both">
For said assets, once paid for and built, to appear at all on the map/level, the factory has to have a helper, typically called "spawn" or "spawn<number>" designated and assigned to a '''Factory Slot'''. 
Aforementioned Slot could potentially become crowded and further assets appearing in it could lead to damage, collisions or other unforeseen consequences - this is avoided by designating a '''Build Volume Trigger Area Shape''' that prevents further spawning of assets until vacated of any other similar entity. It lies upon the mapper to accordingly size and place the areas to help and facilitate those functions.
[[File:Vehicle_Trigger.jpg|frameless|600px|Vehicle Trigger Area Shape For the Factory in Sandbox 2 Editor]]
</div>

Historically there was one more Area Shape/Volume to be designated: the Kill Volume. It's role was to vacate the build area of players so that it appears the build process is both deadly to watch and never seen. This function is regarded obsolete in the mapper community of this mod since long time now. 

Aforementioned '''Spawn Helpers''' can be set up in the geometry of the factory mesh - in blender for instance, by making an Empty, that is a child of the main Empty that carries the same name of the Mesh/cgf file, so both the mesh and the empty are children to the parent-most empty. Those one or more Spawn_Helper_empty_entities are to be named "spawn<number>" and same names are to be assigned to the corresponding slots in the Sandbox2 Editor.

The other option is to use '''Basic Entity''' or '''Geom Entity''' for the spawn helper. The corresponding tick box is to be set and the ''Link Name'' is to be set accordingly to the Factory Slot - the name of the entity is irrelevant in this case.

[[File:Entity_Helper_Link_name_is_spawn.jpg|frameless|600px|Entity Spawn Helper Link name details ]] [[File:Basic_Entity_Void_of_mesh.jpg|frameless|600px|Basic Entity with no mash assigned to it at all ]] 
There seems to be indication that this later case can lead to unforeseen consequences - like the said entity to undergo state change upon nearby strong enough explosion during the game play - rendering the factory disabled until reload. This phenomena while well documented to occur seems to be ill understood and hard to avoid when using factories in this fashion. However it seems to be totally absent when the spawn helpers are embedded in the Factory mesh. There seems to be evidence that the mesh alone can be void of any other geometry aside the spawn helpers (examine the quad forward factory prefab).

One of the future proofing consideration for the mapper is to decide if to extract any prefab or to keep it "sealed":
Any Prefab that is not extracted will get due updates as the game changes down the road. 
Any extracted prefab is no longer a prefab and as the game changes there might be manual labor due to make the map/level function again. This is only possible to do when the map source is available to the mapper.

GeomEntities are to be used very sparingly, and only if it can't be avoided by any other way.
It seems that Basic Entities work as well.

There is a range of prefabs in '''MWLL''' that can be used both as readily available factories with an assigned team or, once extracted, can be set up to change the team when a point nearby is captured/freed by the competing teams during a match.

=== Simple spawn point ===
The simple infantry bunker. One Spawn group, few spawn entities and a single buy area. Only weapons can be bought that spawn in the players hands. There is no Vehicle area. It can be either assigned to '''tan''' (IS) or '''black''' (Clan), and/or left to be captured by an '''CapturePoint''' entity

/TODO/image showing it all

=== Single forward factory ===
The next step in complexity. All above applies, but an actual factory entity is placed nearby too. The entity can be assigned a 3d art, or used without.

For the factory to be assigned to a team, the same applies as for the spawn point or group ('''tan'''/'''black''').

For the factory to be of certain weight the map maker can opt to manually select the individual classes of spawn entities in the table shown in the roll-up bar, or one can assign the factory an predefined class:

{| border="2" cellspacing="0" cellpadding="8" align="center"
! Value
! Assets provided
|-
| ''defMechHanger''
| All Surface Assets
|-
| ''defVtolPad''
| VTOL
|-
| ''defAeroHanger''
| VTOL + ASF
|-
| /TODO/ unknown yet
| Medium Surface Assets up to 65 tons
|}
This might be very handy not to worry about any future convention changes, as those would be followed up by the dev team and the map would remain up to date by ''automagic''.

For the 3d art to work properly, if designed in blender, an actual mesh is mandatory to be supplied alongside the helpers (an ''empty'' in blender), the helpers are usually named ''spawn01'' and onward. One helper has to bear the same name as the *.cgf file to be created. This ''empty'' is to be ''parent to all'' other objects of the file. The rest of the preparation is same as every other export from blender via the Collada plugin: have all objects in a group named as the *.cgf to be, assign the mesh(-es) an material and UV, no spaces allowed anywhere.
 
If without, it is to be linked to an entity /TODO Geom Entity only?/ that will both orient and place the spawned product in the map space. The "body" of the factory has to provide spawn helpers,otherwise separate entities have to be used. Place the helpers so that the spawned assets don't fall from too high as it breaks the immersion somewhat - ideally let them be 1m or less above ground. 
Two area shapes are to be defined - one for the factory buy zone - and the smaller for the actual vehicle spawn area. There is provision for another area shape in each slot, this shape is used to define an area that will enforce ''an damage blow'' to each asset within as soon as asset building is started.
Never link this (AreaID) to the same ID as the larger buy area - or it will ''instantly'' kill every player making a purchase in that area.

Factories where the vehicle spawn area is not defined, will allow for multiple assets to spawn one atop of each other. This will lead to destroyed legs and damage upon spawn. Mappers are most strongly advised to avoid this.

=== Quad forward factory ===
The same applies here as for the preceding factory, except that we have more slots available for building. For a slot to spawn an purchased asset, it has to have the helper defined. If the Vehicle area is defined in such a way, that the spawned asset is outside of it once spawned, the slot will be available for further production. For this to be avoided three things are to be taken care of:
# The spawn slot is to be encircled with an Area shape reaching at least somewhat below (one meter or less) the ground, so the spawned asset is completely shrouded by it
# That same area shape has to be linked to the factory it belongs to (one way link)
Numbering of the Area ID is relative only to the factory they are linked to, so numbering schemes can be repeated without fear that any two factories might inter-connect or interfere.
# That same shape area's ID has to match the ID of the slot it represents in the factory parameter called '''VehicleAreaID'''
For the game flow, it is of great importance that only vacant slots be filled by spawning assets. It preserves immersion, reduces odd events during game-play and is overall more aesthetically pleasing.
If the factory is set up correctly, an occupied slot will accept assets in the Queue but will not build until it is vacated. Once vacant, the build process will commence in the slot with the lowest number. 
It is highly recommended to mark the production bays with the slot numbers designated.
In lower quality settings the decals and roads are not rendered in the play engine, but are shown in the editor engine - mappers should bear this in mind.

=== Dropship forward factory ===
/TODO/ differences for dropships - more solids where and why

=== Main Hanger bases factory ===
/TODO/ Maximal factory potential - 8 slots, animated body *.cga with separately animated parts of it (*.anm). even more solids,and occlusion areas to improve performance.

== Repair zones ==
We don't actually have an HUD indicator (yet) for repair zones, as we have for buy zones. In repair zones a shut down vehicle trades it's damage for c-bills. Area shapes define the zone of repair on repair pads, while Area shapes' ID via the VehicleAreasID, in the factory properties spawn slots, define them on factories.

=== Simple repair pad ===
The simple repair pad consists of the entity and the area shape. The entity can be assigned an 3d "body". The body can be linked to a capture point, so it can belong to a competing team, or not linked so it's serves any player in need.

=== Factories repair ability ===
The factory repair zone is defined by the Vehicle Area shape.
/TODO/ image

=== Mobile repair zone (Repair truck) ===
Merely a placeholder in case we get one ever :) .

== Buy zones ==
The buy zones of MWLL mod can be finely tuned for particular asset type or class, or, alternatively, a predefined factory type:
defMechHanger
defVtolPad
defAeroHanger
If the predefined factory type is used, the fine tuning of the available assets does not apply.

=== Air strip ===
The airstrip has to be a buy zone for the ASF assets to be able to replenish ammunition. They will be able to repair there as well.

=== Mobile buy zone (APC) ===
In the buy zone of the APC one can by infantry (BA) weapons and ammunition only.

=== Factory buy zones ===
The factory buy zone is one that can be tuned the most. For the clean tech game mode,one does not need to alternate IS and CL tech, it is done elsewhere, it suffices to define the classes regardless of faction.

{{Navbox Mapping}}

[[Category:Mapping]]

Factory Entities

2025-05-09T06:43:31Z

Fire-hound: Factories, initially added images

{{ Stub }}
Our game mod's strongly depends on building assets ranging from weapons to assault class war machines that fly or crawl across the battlefields of 31st century. To facilitate this we use factories across the map.

== Factories ==

For any factory to even exist or function in the level it has to have the '''Factory Entity''' to begin with.[[File:Factory_Void_of_mesh_team_tan_Use_Entity_true_Helper_spawn_VAI61_.jpg|400px|right|factory]] 
This entity can optionally have an mesh assigned to it (the "model" property). 
For said '''Entity''' to be usable at all it has to have at the very least the '''BuyArea''' defined ''and assigned'' to it. 
[[File:Buy_Zone.jpg|400px|center|capture point]] [[File:Buy_Zone_Area_Shape_Link_Target.jpg|400px|right|capture link]] 
Once said factory has ''a team'' assigned to it (by default '''property''' or by a designated '''Capture Point''') a player ''that is a member of that team'' can exchange c-bills for assets designated as available in that Factory.[[File:Capture_Point_Link_members.jpg|400px|right|capture point]] 
For said assets, once paid for and built, to appear at all on the map/level, the factory has to have a helper, typically called "spawn" or "spawn<number>" designated and assigned to a '''Factory Slot'''. 
Aforementioned Slot could potentially become crowded and further assets appearing in it could lead to damage, collisions or other unforeseen consequences - this is avoided by designating a '''Build Volume Trigger Area Shape''' that prevents further spawning of assets until vacated of any other similar entity. It lies upon the mapper to accordingly size and place the areas to help and facilitate those functions.
[[File:Vehicle_Trigger.jpg|400px|center|trigger]]
Historically there was one more Area Shape/Volume to be designated: the Kill Volume. It's role was to vacate the build area of players so that it appears the build process is both deadly to watch and never seen. This function is regarded obsolete in the mapper community of this mod since long time now. 

Aforementioned '''Spawn Helpers''' can be set up in the geometry of the factory mesh - in blender for instance, by making an Empty, that is a child of the main Empty that carries the same name of the Mesh/cgf file, so both the mesh and the empty are children to the parent-most empty. Those one or more Spawn_Helper_empty_entities are to be named "empty<number>" and same names are to be assigned to the corresponding slots in the Sandbox2 Editor.

The other option is to use '''Basic Entity''' or '''Geom Entity''' for the spawn helper. The corresponding tick box is to be set and the ''Link Name'' is to be set accordingly to the Factory Slot - the name of the entity is irrelevant in this case.

[[File:Entity_Helper_Link_name_is_spawn.jpg|400px|left|BasicEntity]] [[File:Basic_Entity_Void_of_mesh.jpg|400px|center|BasicEntity]]
There seems to be indication that this later case can lead to unforeseen consequences - like the said entity to undergo state change upon nearby strong enough explosion during the game play - rendering the factory disabled until reload. This phenomena while well documented to occur seems to be ill understood and hard to avoid when using factories in this fashion. However it seems to be totally absent when the spawn helpers are embedded in the Factory mesh. There seems to be evidence that the mesh alone can be void of any other geometry aside the spawn helpers (examine the quad forward factory prefab).

One of the future proofing consideration for the mapper is to decide if to extract any prefab or to keep it "sealed":
Any Prefab that is not extracted will get due updates as the game changes down the road. 
Any extracted prefab is no longer a prefab and as the game changes there might be manual labor due to make the map/level function again. This is only possible to do when the map source is available to the mapper.

GeomEntities are to be used very sparingly, and only if it can't be avoided by any other way.
It seems that Basic Entities work as well.

There is a range of prefabs in '''MWLL''' that can be used both as readily available factories with an assigned team or, once extracted, can be set up to change the team when a point nearby is captured/freed by the competing teams during a match.

=== Simple spawn point ===
The simple infantry bunker. One Spawn group, few spawn entities and a single buy area. Only weapons can be bought that spawn in the players hands. There is no Vehicle area. It can be either assigned to '''tan''' (IS) or '''black''' (Clan), and/or left to be captured by an '''CapturePoint''' entity

/TODO/image showing it all

=== Single forward factory ===
The next step in complexity. All above applies, but an actual factory entity is placed nearby too. The entity can be assigned a 3d art, or used without.

For the factory to be assigned to a team, the same applies as for the spawn point or group ('''tan'''/'''black''').

For the factory to be of certain weight the map maker can opt to manually select the individual classes of spawn entities in the table shown in the roll-up bar, or one can assign the factory an predefined class:

{| border="2" cellspacing="0" cellpadding="8" align="center"
! Value
! Assets provided
|-
| ''defMechHanger''
| All Surface Assets
|-
| ''defVtolPad''
| VTOL
|-
| ''defAeroHanger''
| VTOL + ASF
|-
| /TODO/ unknown yet
| Medium Surface Assets up to 65 tons
|}
This might be very handy not to worry about any future convention changes, as those would be followed up by the dev team and the map would remain up to date by ''automagic''.

For the 3d art to work properly, if designed in blender, an actual mesh is mandatory to be supplied alongside the helpers (an ''empty'' in blender), the helpers are usually named ''spawn01'' and onward. One helper has to bear the same name as the *.cgf file to be created. This ''empty'' is to be ''parent to all'' other objects of the file. The rest of the preparation is same as every other export from blender via the Collada plugin: have all objects in a group named as the *.cgf to be, assign the mesh(-es) an material and UV, no spaces allowed anywhere.
 
If without, it is to be linked to an entity /TODO Geom Entity only?/ that will both orient and place the spawned product in the map space. The "body" of the factory has to provide spawn helpers,otherwise separate entities have to be used. Place the helpers so that the spawned assets don't fall from too high as it breaks the immersion somewhat - ideally let them be 1m or less above ground. 
Two area shapes are to be defined - one for the factory buy zone - and the smaller for the actual vehicle spawn area. There is provision for another area shape in each slot, this shape is used to define an area that will enforce ''an damage blow'' to each asset within as soon as asset building is started.
Never link this (AreaID) to the same ID as the larger buy area - or it will ''instantly'' kill every player making a purchase in that area.

Factories where the vehicle spawn area is not defined, will allow for multiple assets to spawn one atop of each other. This will lead to destroyed legs and damage upon spawn. Mappers are most strongly advised to avoid this.

=== Quad forward factory ===
The same applies here as for the preceding factory, except that we have more slots available for building. For a slot to spawn an purchased asset, it has to have the helper defined. If the Vehicle area is defined in such a way, that the spawned asset is outside of it once spawned, the slot will be available for further production. For this to be avoided three things are to be taken care of:
# The spawn slot is to be encircled with an Area shape reaching at least somewhat below (one meter or less) the ground, so the spawned asset is completely shrouded by it
# That same area shape has to be linked to the factory it belongs to (one way link)
Numbering of the Area ID is relative only to the factory they are linked to, so numbering schemes can be repeated without fear that any two factories might inter-connect or interfere.
# That same shape area's ID has to match the ID of the slot it represents in the factory parameter called '''VehicleAreaID'''
For the game flow, it is of great importance that only vacant slots be filled by spawning assets. It preserves immersion, reduces odd events during game-play and is overall more aesthetically pleasing.
If the factory is set up correctly, an occupied slot will accept assets in the Queue but will not build until it is vacated. Once vacant, the build process will commence in the slot with the lowest number. 
It is highly recommended to mark the production bays with the slot numbers designated.
In lower quality settings the decals and roads are not rendered in the play engine, but are shown in the editor engine - mappers should bear this in mind.

=== Dropship forward factory ===
/TODO/ differences for dropships - more solids where and why

=== Main Hanger bases factory ===
/TODO/ Maximal factory potential - 8 slots, animated body *.cga with separately animated parts of it (*.anm). even more solids,and occlusion areas to improve performance.

== Repair zones ==
We don't actually have an HUD indicator (yet) for repair zones, as we have for buy zones. In repair zones a shut down vehicle trades it's damage for c-bills. Area shapes define the zone of repair on repair pads, while Area shapes' ID via the VehicleAreasID, in the factory properties spawn slots, define them on factories.

=== Simple repair pad ===
The simple repair pad consists of the entity and the area shape. The entity can be assigned an 3d "body". The body can be linked to a capture point, so it can belong to a competing team, or not linked so it's serves any player in need.

=== Factories repair ability ===
The factory repair zone is defined by the Vehicle Area shape.
/TODO/ image

=== Mobile repair zone (Repair truck) ===
Merely a placeholder in case we get one ever :) .

== Buy zones ==
The buy zones of MWLL mod can be finely tuned for particular asset type or class, or, alternatively, a predefined factory type:
defMechHanger
defVtolPad
defAeroHanger
If the predefined factory type is used, the fine tuning of the available assets does not apply.

=== Air strip ===
The airstrip has to be a buy zone for the ASF assets to be able to replenish ammunition. They will be able to repair there as well.

=== Mobile buy zone (APC) ===
In the buy zone of the APC one can by infantry (BA) weapons and ammunition only.

=== Factory buy zones ===
The factory buy zone is one that can be tuned the most. For the clean tech game mode,one does not need to alternate IS and CL tech, it is done elsewhere, it suffices to define the classes regardless of faction.

{{Navbox Mapping}}

[[Category:Mapping]]

File:Buy Zone Area Shape Link Target.jpg

2025-05-09T06:27:15Z

Fire-hound: Buy Zone Area Shape Target to link to

Buy Zone Area Shape Target to link to

File:Capture Zone Link member.jpg

2025-05-09T06:26:42Z

Fire-hound: Capture Zone Area Shape link member

Capture Zone Area Shape link member

File:Capture Point Link members.jpg

2025-05-09T06:25:55Z

Fire-hound: Link list members for the Capture Point entity

Link list members for the Capture Point entity

File:Entity Helper Link name is spawn.jpg

2025-05-09T06:25:06Z

Fire-hound: Entity Spawn Helper Link name details

Entity Spawn Helper Link name details

File:Factory Void of mesh team tan Use Entity true Helper spawn VAI61 .jpg

2025-05-09T06:24:26Z

Fire-hound: Factory Setup details in Sandbox2 Editor

Factory Setup details in Sandbox2 Editor

File:SpawnGroup Void of mesh.jpg

2025-05-09T06:23:23Z

Fire-hound: Spawn Group with no mesh assigned to it in Sandbox2 editor

Spawn Group with no mesh assigned to it in Sandbox2 editor

File:Basic Entity Void of mesh.jpg

2025-05-09T06:22:54Z

Fire-hound: Basic Entity with no mash assigned to it at all

Basic Entity with no mash assigned to it at all

File:Vehicle Trigger.jpg

2025-05-09T06:22:18Z

Fire-hound: Vehicle Trigger Area Shape For the Factory in Sandbox 2 Editor

Vehicle Trigger Area Shape For the Factory in Sandbox 2 Editor

File:Buy Zone.jpg

2025-05-09T06:21:25Z

Fire-hound: Buy Zone Area Shape Highlighted in Sandbox2 editor

Buy Zone Area Shape Highlighted in Sandbox2 editor

Factory Entities

2025-05-09T06:20:22Z

Fire-hound: /* Factories */ inital text edit

{{ Stub }}
Our game mod's strongly depends on building assets ranging from weapons to assault class war machines that fly or crawl across the battlefields of 31st century. To facilitate this we use factories across the map.

== Factories ==

For any factory to even exist or function in the level it has to have the '''Factory Entity''' to begin with. 
This entity can optionally have an mesh assigned to it (the "model" property). 
For said '''Entity''' to be usable at all it has to have at the very least the '''BuyArea''' defined ''and assigned'' to it. 
Once said factory has ''a team'' assigned to it (by default '''property''' or by a designated '''Capture Point''') a player ''that is a member of that team'' can exchange c-bills for assets designated as available in that Factory. 
For said assets, once paid for and built, to appear at all on the map/level, the factory has to have a helper, typically called "spawn" or "spawn<number>" designated and assigned to a '''Factory Slot'''. 
Aforementioned Slot could potentially become crowded and further assets appearing in it could lead to damage, collisions or other unforeseen consequences - this is avoided by designating a '''Build Volume Trigger Area Shape''' that prevents further spawning of assets until vacated of any other similar entity. It lies upon the mapper to accordingly size and place the areas to help and facilitate those functions.
Historically there was one more Area Shape/Volume to be designated: the Kill Volume. It's role was to vacate the build area of players so that it appears the build process is both deadly to watch and never seen. This function is regarded obsolete in the mapper community of this mod since long time now. 

Aforementioned '''Spawn Helpers''' can be set up in the geometry of the factory mesh - in blender for instance, by making an Empty, that is a child of the main Empty that carries the same name of the Mesh/cgf file, so both the mesh and the empty are children to the parent-most empty. Those one or more Spawn_Helper_empty_entities are to be named "empty<number>" and same names are to be assigned to the corresponding slots in the Sandbox2 Editor.

The other option is to use '''Basic Entity''' or '''Geom Entity''' for the spawn helper. The corresponding tick box is to be set and the ''Link Name'' is to be set accordingly to the Factory Slot - the name of the entity is irrelevant in this case.

There seems to be indication that this later case can lead to unforeseen consequences - like the said entity to undergo state change upon nearby strong enough explosion during the game play - rendering the factory disabled until reload. This phenomena while well documented to occur seems to be ill understood and hard to avoid when using factories in this fashion. However it seems to be totally absent when the spawn helpers are embedded in the Factory mesh. There seems to be evidence that the mesh alone can be void of any other geometry aside the spawn helpers (examine the quad forward factory prefab).

One of the future proofing consideration for the mapper is to decide if to extract any prefab or to keep it "sealed":
Any Prefab that is not extracted will get due updates as the game changes down the road. 
Any extracted prefab is no longer a prefab and as the game changes there might be manual labor due to make the map/level function again. This is only possible to do when the map source is available to the mapper.

GeomEntities are to be used very sparingly, and only if it can't be avoided by any other way.
It seems that Basic Entities work as well.

There is a range of prefabs in '''MWLL''' that can be used both as readily available factories with an assigned team or, once extracted, can be set up to change the team when a point nearby is captured/freed by the competing teams during a match.

=== Simple spawn point ===
The simple infantry bunker. One Spawn group, few spawn entities and a single buy area. Only weapons can be bought that spawn in the players hands. There is no Vehicle area. It can be either assigned to '''tan''' (IS) or '''black''' (Clan), and/or left to be captured by an '''CapturePoint''' entity

/TODO/image showing it all

=== Single forward factory ===
The next step in complexity. All above applies, but an actual factory entity is placed nearby too. The entity can be assigned a 3d art, or used without.

For the factory to be assigned to a team, the same applies as for the spawn point or group ('''tan'''/'''black''').

For the factory to be of certain weight the map maker can opt to manually select the individual classes of spawn entities in the table shown in the roll-up bar, or one can assign the factory an predefined class:

{| border="2" cellspacing="0" cellpadding="8" align="center"
! Value
! Assets provided
|-
| ''defMechHanger''
| All Surface Assets
|-
| ''defVtolPad''
| VTOL
|-
| ''defAeroHanger''
| VTOL + ASF
|-
| /TODO/ unknown yet
| Medium Surface Assets up to 65 tons
|}
This might be very handy not to worry about any future convention changes, as those would be followed up by the dev team and the map would remain up to date by ''automagic''.

For the 3d art to work properly, if designed in blender, an actual mesh is mandatory to be supplied alongside the helpers (an ''empty'' in blender), the helpers are usually named ''spawn01'' and onward. One helper has to bear the same name as the *.cgf file to be created. This ''empty'' is to be ''parent to all'' other objects of the file. The rest of the preparation is same as every other export from blender via the Collada plugin: have all objects in a group named as the *.cgf to be, assign the mesh(-es) an material and UV, no spaces allowed anywhere.
 
If without, it is to be linked to an entity /TODO Geom Entity only?/ that will both orient and place the spawned product in the map space. The "body" of the factory has to provide spawn helpers,otherwise separate entities have to be used. Place the helpers so that the spawned assets don't fall from too high as it breaks the immersion somewhat - ideally let them be 1m or less above ground. 
Two area shapes are to be defined - one for the factory buy zone - and the smaller for the actual vehicle spawn area. There is provision for another area shape in each slot, this shape is used to define an area that will enforce ''an damage blow'' to each asset within as soon as asset building is started.
Never link this (AreaID) to the same ID as the larger buy area - or it will ''instantly'' kill every player making a purchase in that area.

Factories where the vehicle spawn area is not defined, will allow for multiple assets to spawn one atop of each other. This will lead to destroyed legs and damage upon spawn. Mappers are most strongly advised to avoid this.

=== Quad forward factory ===
The same applies here as for the preceding factory, except that we have more slots available for building. For a slot to spawn an purchased asset, it has to have the helper defined. If the Vehicle area is defined in such a way, that the spawned asset is outside of it once spawned, the slot will be available for further production. For this to be avoided three things are to be taken care of:
# The spawn slot is to be encircled with an Area shape reaching at least somewhat below (one meter or less) the ground, so the spawned asset is completely shrouded by it
# That same area shape has to be linked to the factory it belongs to (one way link)
Numbering of the Area ID is relative only to the factory they are linked to, so numbering schemes can be repeated without fear that any two factories might inter-connect or interfere.
# That same shape area's ID has to match the ID of the slot it represents in the factory parameter called '''VehicleAreaID'''
For the game flow, it is of great importance that only vacant slots be filled by spawning assets. It preserves immersion, reduces odd events during game-play and is overall more aesthetically pleasing.
If the factory is set up correctly, an occupied slot will accept assets in the Queue but will not build until it is vacated. Once vacant, the build process will commence in the slot with the lowest number. 
It is highly recommended to mark the production bays with the slot numbers designated.
In lower quality settings the decals and roads are not rendered in the play engine, but are shown in the editor engine - mappers should bear this in mind.

=== Dropship forward factory ===
/TODO/ differences for dropships - more solids where and why

=== Main Hanger bases factory ===
/TODO/ Maximal factory potential - 8 slots, animated body *.cga with separately animated parts of it (*.anm). even more solids,and occlusion areas to improve performance.

== Repair zones ==
We don't actually have an HUD indicator (yet) for repair zones, as we have for buy zones. In repair zones a shut down vehicle trades it's damage for c-bills. Area shapes define the zone of repair on repair pads, while Area shapes' ID via the VehicleAreasID, in the factory properties spawn slots, define them on factories.

=== Simple repair pad ===
The simple repair pad consists of the entity and the area shape. The entity can be assigned an 3d "body". The body can be linked to a capture point, so it can belong to a competing team, or not linked so it's serves any player in need.

=== Factories repair ability ===
The factory repair zone is defined by the Vehicle Area shape.
/TODO/ image

=== Mobile repair zone (Repair truck) ===
Merely a placeholder in case we get one ever :) .

== Buy zones ==
The buy zones of MWLL mod can be finely tuned for particular asset type or class, or, alternatively, a predefined factory type:
defMechHanger
defVtolPad
defAeroHanger
If the predefined factory type is used, the fine tuning of the available assets does not apply.

=== Air strip ===
The airstrip has to be a buy zone for the ASF assets to be able to replenish ammunition. They will be able to repair there as well.

=== Mobile buy zone (APC) ===
In the buy zone of the APC one can by infantry (BA) weapons and ammunition only.

=== Factory buy zones ===
The factory buy zone is one that can be tuned the most. For the clean tech game mode,one does not need to alternate IS and CL tech, it is done elsewhere, it suffices to define the classes regardless of faction.

{{Navbox Mapping}}

[[Category:Mapping]]

MWLL Players Slang Guide

2024-11-20T21:08:35Z

Fire-hound: added 'inc'

As most online communities do, Mechwarrior: Living Legends players have their own ''slang'' terms. Here you'll find most common phrases and explanation of their meanings. Most of them are used in game, but also most commonly used forum or [[Discord]] phrases can be found here as well.

==Generic Slang==
* '''AA''' - Anti-air, typically a vehicle like the [[Partisan]] or [[Huit]].
* '''ASF''' / '''Aero''' - [[Aerospace]] Fighter.
* '''Ava''' - [[Avatar]] (or mistyped [[Avar]]).
* '''BA''' - [[Battle Armor]], usually used to identify Battle Armors jumping or "flying" around being a distraction. Some mechs are terrible at killing BA and need support (e.g. [[Hollander II#Variant A|Hollander II A]]).
* '''Back Capping''' - The act of capturing enemy bases far from the front line in [[Terrain Control]] matches.
* '''[[Gameplay_Tactics#Ballooning|Ballooning]]''' - The act of attacking ground targets from a high angle with [[aerospace]] and [[VTOL|VTOLs]] in order to avoid return fire.
* '''Boating/Boat''' - BattleTech slang for an asset that carries a large quantity of a specific variety of weapons. How specific that variety is depends on the asset; For example, you can have an Energy Boat like the [[Puma#Variant B|Puma B]] or [[Puma#Variant C|C]], or an LRM boat like the [[Vulture|Vulture C]], or a ballistics boat like the [[Huit#Variant F|Huit F]].
* '''[[Brawler]]''' - A type of weapon loadout for any asset that includes mostly close-range weapons such as [[LBX20]]s, [[AC20]]s, [[SRM]]s and [[SSRM]]s, [[MPL]]s, [[MBL]]s. Alternatively, the term can refer to a player who specializes in close-range combat.
* '''BT''' / '''BTU''' - BattleTech / BattleTech Universe - Universe and franchise on which all Mechwarrior games, including MWLL, are based.
* '''Capping''' - Shorthand for 'capturing', relevant to [[Terrain Control]] matches.
* '''CBT''' - Classic BattleTech - tabletop game set in the BattleTech universe.
* '''Cored''' - A Mech that has had its Center Torso armor reduced to 20% or less. Usually a reference to destruction of the Center Torso indirectly through the Side Torsos, or Back Torso.
* '''Credits''' - See [[Cbills]]
* '''Critical/Crit''' - Mech going critical - a downed mech that is going to destroy itself in a nuclear explosion. The mech's imminent detonation is indicated by [[:File:Critical.jpg|a bright glow]] and a subtle creaking sound coming from the mech's body seconds beforehand.
* '''CT, LT, RT, BT''' - Center Torso, Left Torso, Right Torso, Back torso, respectively. Refers to torso sections of a mech.
* '''ctc''' - Abbreviation for "contact." Used by players to indicate they have detected an enemy contact on their radar.
* '''Donut''' - Like being ''cored'', except with the rest of the mech almost completely untouched.
* '''DPS''' - [[DPS|Damage Per Second]].
* '''DPS Weapon''' - A weapon that must be fired very frequently in order to deal damage efficiently, such as [[Rotary AutoCannons|RACs]] and [[Machine Gun|Mguns]].
* '''Flanking''' / '''Flanker''' - A strategy and combat role wherein a player attempts to (often sneakily) attack the enemy team's forces from the side, or get behind it in order to snipe the Back Armor.
* '''Good NARC''' / '''NARC Good''' - A [[NARC]] beacon has landed on an enemy, you are free to fire missiles towards the enemy (even if you can't see the NARC beacon on your radar)
* '''inc''' - incoming it is often used in conjuction with '''ctc''' to emphasise that the enemies are approaching
* '''Jump Sniper''' - See '''poptarter'''
* '''k''' - Common multiplayer short for thousand, nearly always used for saying amount of money, eg: ''1k'' = 1000 Cbills, ''254k'' = 254 000 Cbills. Sometimes used as a shortcut for OK.
* '''K/D''' - Kills to Deaths ratio - the amount of kills compared to deaths. Often displayed as, for example, ''5/2'' or ''4/6'', sometimes also as ''2.5'' or ''0.66''.
* '''Legging''' - The act of shooting another mech's leg off. Almost always done to intentionally irritate or mock the target player.
* '''[[Asset_Roles#Missile_Boat|LRM Boat]]''' - See: 'Boat' above
* '''LRM camper''' - A player shooting missiles from great distances, who is mostly stationary, and acts as a missile turret. See: [[Gameplay Tactics#LRM Camping|LRM Camping]]
* '''LT''' - [[Long Tom Artillery Tank|Long Tom]] - Usually to identify that an enemy Long Tom is firing shells. A warning to encourage teammates to be unpredictable with their movement and try to keep radar in passive mode. Also as a request for someone to identify the location of the Long Tom for destruction. Also ''Left Torso''. Also the rank of ''Lieutenant''.
* '''[[Asset_Roles#Missile_Boat|Missile Boat]]''' - Usually refers to an asset equipped with a large number of [[LRM]]s or [[ArrowIV]]s, but can mean any asset with a large number of [[missiles]]. See: 'LRM Boat' above
* '''Newbie''' - A player who is in the early stages of learning; a beginner. Unlike ''noob'' this is a positive description.
* '''Nuke''' - A [[Engines#Fusion_Engine_Explosions|Fusion engine explosion]].
* '''Noob''' - Often a derogatory term used to describe someone as new to or poorly acquainted with the game or aspect(s) of it.
* '''Passive''' - Describing a player or asset as operating under [[Passive Radar]] mode, meaning they won't appear on your Radar outside of 250m. Eg. ''Passive Vulture''.
* '''Poke''' - To shoot an enemy, typically with a low-damage weapon, at range, in a way where the enemy doesn't usually have an opportunity to shoot back.
* '''Poptarter''' - A player jumping from behind cover to fire at an enemy. See: [[Gameplay Tactics#Poptarting|Poptarting]]
* '''Pubbing''' - Playing on public servers (those typically hosted by members of a [[:Category:Community Clans and Units|Clan or Unit]]) where there is usually no formally organized play.
* '''Ram'''ming - Kamikaze [[Gameplay Tactics#Ramming and Zero-Throttling|tactic]]; flying your ASF into an enemy, crashing into him.
* '''Redeploy''' - To [[suicide]] or disconnect and reconnect in order to quickly [[respawn]] at a different part of the map.
* '''Respawn''' - To reenter the game at a [[base]]. See: Spawn.
* '''Rifle''' - [[Rifleman]] or one of several weapons like the [[HAG]], [[Gauss]], or [[Battle_Armor#Battle_Armor_Weapons|BA Recoilless Rifle]].
* '''RTB''' - Returning to Base, usually for repairs or reloads.
* '''SA''' - [[Solaris Arena]] game mode.
* '''Salt''' - Refers to being upset or "salty" about something, usually an action by another player or a change in gameplay.
* '''Smurf''' - A player intentionally hiding his identity/nick in-game.
* '''Snip'''ing - Shooting at the enemy from long range with direct fire weapons, often with [[Gauss]] and/or ([[ERPPC|ER]])[[PPC]].
* '''Spares''' - Indicates that a player is asking for donations (e.g. "spare CBills?", "spares?").
* '''Spawn''' - To enter or reenter the game by clicking on a [[base]] on the [[in-game map]]. Or to [[buy]] an [[asset]].
* '''Stack''' / '''Team Stack''' / '''Vet Stack''' - The act of filling one team with players of same affiliation and/or game culture.
* '''Stomp''' - The result of a match wherein one team won over the other by a large margin, either by [[Ticket]] lead or killcount (or even both).
* '''[[Gameplay_Tactics#Supporting|Support Asset/Tank/Mech/etc]]''' - Any [[asset]] that comes with equipment that helps their allies like [[LAMS]], [[PDS]], [[AutoFlamer|Autoflamer]], [[AECM]], [[TAG]], [[NARC]], or [[C3]].
* '''TC''' - [[Terrain Control]] game mode.
* '''Ticket Bleed''' - When a team controls the majority of bases in [[Terrain Control]], the opposing team loses tickets every few seconds.
* '''TK''' / '''TKer''' / '''TKing''' - Teamkill / Teamkiller / Teamkilling - Heavily frowned upon and can be a bannable offense if intentionally repeated.
* '''ToS''' - [[Test of Strength]] game mode.
* '''Trading''' - When a player is in a situation where both the player and one or more enemies deal damage to each other. A trade can be "favorable" where the player deals more damage to the enemy than the player receives or "unfavorable" when enemies deal more damage to the player than the enemies receive. This is opposed to [[poking]] where only the enemy receives damage.
* '''TSA''' - [[Team Solaris Arena]] game mode.
* '''Unit''' - Usually refers to a player's player group like [[Clan Smoke Jaguar]] or the [[12th Vegan Rangers]], but occasionally refers to an [[asset]]
* '''Vet''' / '''Veteran''' - A skilled player, often one that has played for a long time.
* '''Zero-Throttle''' - A ramming [[Gameplay Tactics#Ramming and Zero-Throttling|tactic]] used to make an enemy an easier, slower target, or an accident when two allies collide.

==Asset Slang Names==
* '''Arrowpult'''- A reference to the Catapult C, which mounts two [[ArrowIV]]s as its primary weapons.
* '''Blanner''' or '''Lanner''' - [[Black Lanner]], most annoying AA and rush mech ever.
* '''Blasp''' - A shortened name for the [[Blood Asp]] Clan Assault mech.
* '''Bonar''' - A perversion of the Clan [[Donar]]'s name.
* '''Bushy''' - A contraction of the [[Bushwacker]]'s name.
* '''Chevy''' - Common nickname for the Inner Sphere scout tank, the [[Chevalier]]. Sometimes paired with a model name from the car company, Chevy, Ex. Chevy Silverado.
* '''Cockmoth''' - A perversion of the [[Hawkmoth]] Inner Sphere VTOL's name, often used to describe one that is being incredibly annoying.
* '''Demo''' - A shortened name for the [[Demolisher]] Inner Sphere main battle tank.
* '''Faffy''' - An affectionate nickname for the [[Fafnir]] Inner Sphere assault mech.
* '''Fastnir''' - Yet another nickname, directed at the Fafnir F, which has [[MASC]].
* '''Fatlas''' - A derogatory Atlas nickname.
* '''Fatnir''' - Another Fafnir nickname, most often directed at the old Light Gauss boat.
* '''Hawk''' - [[Hawkmoth]] or [[Sparrowhawk]].
* '''Hepatitis''' - Old, often derogatory nickname for the Hephaestus Clan hovercraft. Specifically in reference to old hitbox errors that caused the Hephaestus to be almost as hard to kill as a Madcat.
* '''Holly''' - Shortened name for the [[Hollander II]] Inner Sphere medium mech.
* '''Huit''' - Shortened name for the [[Huitzilopochtli]] Clan Assault tank.
* '''Hurasser''' - Affectionate derogatory nickname for the [[Harasser]] Inner Sphere light hovertank. Often a reference to a pilot driving a Harasser in a stupid or self-destructive manner.
* '''LT''' - Abbreviation for either the [[Mobile Long Tom]] artillery asset, or the [[Long Tom]] artillery weapon itself.
* '''Parti''' - A shortened name for the [[Partisan]] Inner Sphere support tank.
* '''Partyvan''' - Either an affectionate or accusatory name for the Partisan Inner Sphere support tank.
* '''Pony''' or '''Pwny''' - Nickname for the [[Epona]] Clan hovercraft
* '''RACnir''' - An old nickname for the former Fafnir G, which boated 4 RAC5s.
* '''Rifle''' - [[Rifleman]] or one of several weapons like the [[HAG]], [[Gauss]], or [[Battle_Armor#Battle_Armor_Weapons|BA Recoilless Rifle]].
* '''Rasser''' - A shortened name for the Harasser Inner Sphere hovertank.
* '''Roflman''' - Affectionate name for the [[Rifleman]] Inner Sphere heavy mech.
* '''Scat''' - Awesomest Clan medium in existence, the [[Shadowcat]]. Pronounced S-Cat.
* '''Solly''' or '''Soli''' - Shortened name for the [[Solitaire]] Clan light mech.
* '''Thanny''' - Nickname for the [[Thanatos]], an Inner Sphere heavy mech.
* '''Thumper''' - Often used to indicate the presence of the [[Rommel#Variant A|Rommel A]] heavy tank, which carries a singular [[Thumper]] artillery piece.
* '''Timby''' - A rare nickname, referring to the Clan designation, for the [[Mad Cat|Timber Wolf (Mad Cat)]] Clan heavy OmniMech.
* '''Ullie''' - Rare nickname for the [[Uller]] Clan light mech
* '''Urbie''' - UrbanMech, cutest Mech you've ever seen. Not an asset in [[MWLL]].
* '''Visi''' - Contraction of the [[Visigoth]] Clan heavy Aerospace Fighter.
* '''Whammy''' - Nickname for the [[Warhammer]] Inner Sphere heavy mech.

==Weapon Slang Names==
* '''LT''' - Abbreviation for the Long Tom artillery piece/cannon, usually used as a precursor to the word 'shell', to denote an incoming artillery shell
* '''Megagun(s)''' - Slang for [[Machine guns]]. Usually used as either high praise for machineguns, or sarcastically.
* '''Lurm''' - Common derogatory nickname for [[LRM]]s and [[ELRM]]s.
* '''Trollrm''' - Rare derogatory nickname for [[LRM]]s and [[ELRM]]s.
* '''Peeper''' or '''Peepee''' - Generally refers to a [[PPC]] or [[ERPPC]].

{{Navbox Guides}}

[[Category:Guides]]

Team Solaris Arena

2024-07-02T15:50:09Z

Fire-hound: fixed typos 'ammount' vs 'amount'

{{GameMode|
| Name =Team Solaris Arena
| Team Based = Yes
| Money = [[Rank]]
| Winning = [[Score]], [[Tickets]]
| RecPlayers = 6+
| Uses maps = [[TSA]], [[TC]]
}}

'''Team Solaris Arena''' or '''TSA''' is a game mode based on the struggle of two teams against each other, where players can earn [[CBills]] by damaging or destroying enemy units. Two opposing teams, the [[Inner Sphere]] and [[Clan|Clans]] fight as long as the map timer is set for. In score-based TSA, the team with the highest score wins the match. In ticket-based TSA, the team with more ticket wins. A game may also end early if one team runs out of tickets before the timer is up. This game mode resembles the Team Deathmatch game mode in most First Person Shooter multiplayer games.

In the TSA Mode players have to earn score to gain the next [[rank]], which gives more starting CBills on respawns, but he/she may also collect CBills during gameplay, by various activities, such as providing [[TAG]], [[NARC]] or [[C3]] support. If the amount of earned money is greater than amount of respawn CBills, than the player will keep his/her higher amount, otherwise they will be stocked up to the minimum of the players given rank.

Prior to version 0.4, this game mode was called 'Solaris Arena'. It was then renamed to 'Team Solaris Arena', and the game mode 'Free For All' which was later added in 0.5.0 was named [[Solaris Arena]].

==Canon==
The planet of Solaris VII is a world that is home to the most Battlemech Arenas anywhere in the [[Inner Sphere]]. The Mech fights there are the subject of many bets where fortunes are made and lost daily. Every arena has a different theme and layout, everything from a decrepit factory to a holographic stadium.

[http://www.sarna.net/wiki/Solaris Battletech Reference]

{{Navbox Gameplay Concepts}}

[[Category:Game Modes]]
[[Category:Gameplay Concepts]]

AlienArt

2023-12-11T09:15:57Z

Fire-hound: rephrased and tried to explain better the scope and intent of this article

{{ Stub }}
"Art" can be a rock, a building or even a working factory. 
This article documents each step of art import from recent 3.x blender into Cryengine 2. This will cover non animated objects and game assets only. 
By Alien (perhaps a misnomer) it's meant as totally new, possibly even strange "art" in respect of what's present in the present Asset Pool. 

The process:

== Preparing The geometry ==
=== now with blender 3.x ===
This is a procedure covering the ever growing technology gap between the free and ever livid blender and the aging cryengine2. 
Just get any blender past 3.x release.

=== Get it ready ===
[[File:Step01.png|200px|thumb|center|Prepare Collection]]

For a Mesh to be fit for cryengine it has to fulfill several criteria due to how some compromises were made. 
It is a ''convention'' and if one sticks to it good results will ensue. 
# No more than two triangles should share same edge.
# There should be nothing but triangles (or quads) as the final result - remove all and any nodes and or lines (''primitives'')...
# There should be no triangles of surfaces of size zero (degenerate faces).
# It is desirable for the mesh be airtight, but there are valid exceptions.

The Object is to be investigated for the quality and errors for UV mapping. 
Only a single UV map per mesh is supported in Cryengine 

The Object is to be assigned To a ''Collection'' (no more ''Groups'' in blender 3.x) that shares the same name 
The '''.blend''' file is to be saved with the same name, so that it shares (again) the same name as the object and collection. 

We should now be ready for the export to collada ('''.dae''' file) 

[[File:Step02.png|200px|thumb|center|Prepare Export]]

=== Export settings ===
[[File:Step03.png|200px|thumb|center|Collada export options]]

As seen on the image the favorable settings differ from defaults. It is therefore advisable to
create a operator preset (i aptly named "cryengine export") for further convenience.

{| class="wikitable" style="margin:auto"
|+ Parameter Meaning
|-
! Parameter name !! Explanation
|-
| Transform || Decomposed (this means rotation, translation and scale are decomposed)
|-
| Triangulate || leave no uncertain surfaces unresolved by blender.
|-
| Apply Transforms || Viewport (it is usually safe to assume this is true)
|-
| Selection Only || we rarely need everything from the file - watch for proper parent-children chains!
|-
| Include children || if parenting is properly laid out - this works miracles!
|-
| Use Object Instances || don't use this - i tried it once and it was ''ugly''
|-
| Use Blender Profile || this is best left off - always leave it off for Cryengine export.
|}

== Converting the format ==
=== Prepare your Linux ===
For this to work at all some prerequisites are to be met. You didn't think you'll get off
the hook as easy, didn't you? 
We need working '''ColladaCGF''' in '''wine''', for this we need working '''PyFFI''' in '''wine''', and for this we need working '''Python''' in '''wine''' in the first place.
For this all to work at all certain versions are to be downloaded and fed to '''wine''': 
* Python 2.6.6 (or earlier, but ideally ''exactly'' 2.6.6 (32bit release only)
* PyFFI 2.1.11 (the last one that works with 2.x python, newer ones require python 3.x)
* ColladaCGF 0.3.9 (the last one available)

For this to work you will need your '''Linux''' to be either "''multilib''" (more likely applies to you) or 32bit (less likely but possible)

Install In that exact order (Python, PyFFI, Collada). 
The very installation process:
# Locate the repositories
# Download the corresponding versions and to what place locally
# Point a file manager or ''explorer'' inside of wine to the downloaded files in order to install them
Is left as an exercise to the reader as the web locations are documented in another article on this wiki. 

To make certain they are in the right wine prefix check that both files: 
"C:\Python26\python.exe"
and
"C:\Python26\Scripts\colladacgf.py"
should be present.

Now if you are not using '''XFCE4''' as your GUI, ''too bad you're just out of luck''. Otherwise open the Custom Actions chooser via the Edit menu of '''Thunar''' and make a new custom action:

[[File:Step04.png|200px|thumb|center|Custom Actions setup with Thunar and XFCE4]]

I named the action [ ColladaCGF ] and gave it the default python icon. The description should be obvious: [ Convert a dae file into cgf ]. The command that worked for me was:

[ wineconsole "C:\Python26\python.exe" "C:\Python26\Scripts\colladacgf.py" %F --pause ]

where %F is a list of selected files with the full path.

The filters on the other tab are to be set accordingly: 
[ *.dae;*.DAE ]

mind the semicolon. And the affected files are the ''text files'' (since '''.dae''' files look like '''XML''' files) and ''other files'', just in case. Never mind this impossible screenshot - it is CGI - so you have it all on one place for '''''maximum convenience'''''.

Apply, close and restart '''Thunar'''. Now on You should have a context option for each '''.dae''' file:

[[File:Step05.png|200px|thumb|center|ColladaCGF usage in XFCE on Linux]]

=== Point the ColladaCGF to the .dae file ===
The '''.dae''' file is to be selected, '''rightclick > ColladaCGF''' and voila! by ''automagic'' a bunch of murr-murr and computer speak will fill a dark frame, once you notice the computer has stopped spewing insults and dark magic, there might be a blinking cursor waiting no you to press ['''enter'''] key and close the window. You might have just converted your first '''CGF''' file on Linux. Or you will be in due time. Conversions often fail due to not adhering to the ''convention'' mentioned earlier.

=== Find the cgf file ===
The newly generated '''.CGF''' file and it's belonging '''.MTL''' file should lay next to each other and next to the source '''.DAE''' file. There might be leftovers in the form of logs and dumps. This can be
safely ignored, they can safely be deleted too.

== Importing into engine on Linux ==
I assume Your Linux has ''multilib'' capability here on. I assume You understand what that means and know where to ask for details for Your distro of choice.

=== How to get the editor working (Glitch TKG's github) ===
I see not too many casualties to this point. Good; good, here onward it gets tough as nails, and by that i mean eating chains to fart back nails!.

https://github.com/Tk-Glitch (kudos to Tk-Glitch o/ )

https://github.com/Tk-Glitch/PKGBUILDS/wiki/wine-tkg-git#dependencies

You want to build a not only custom version of wine (as if that wasn't intimidating enough!).

No sir, you want a highly customized, overly patched VERY recent version wine-staging that has support for child-window our '''Sandbox2''' editor uses to render the game within it's app window.

No configuration files need to be modified in the [wine-tkg-git] directory, You merely cd to it and run [./non-makepkg-build.sh]

first time you will be dropped to a shell with info and stuff...

make the following file:

file: ['''~/.config/frogminer/wine-tkg.cfg''']:
<pre>

_LOCAL_PRESET="none"
_use_GE_patches="true"
_plain_version=""
_use_staging="true"
_staging_version="v7.22"
_use_fastsync="false"
_use_esync="true"
_use_fsync="true"
_fsync_futex_waitv="true"
_use_vkd3dlib="true"
_dxvk_dxgi="true"

_proton_battleye_support="false"
_proton_eac_support="false"
_warframelauncher_fix="false"
_mwo_fix="false"
_re4_fix="false"

_childwindow_fix="true"

_use_josh_flat_theme="true"

</pre>

And once saved, re-run the above command. Install the new '''wine''' and make MWLL run in it's prefix.

to run the editor you will need few more '''winetricks'''... 
Fended off yet? no? Good, because that isn't nearly the end of the desert :D. 
add (via winetricks) the following: 
#d3dcompiler_43
#d3dcompiler_47
#dotnet472 (needed for the launcher anyway (will pull in much down to dotnet40) )
#dxvk (i have dxvk1101 so far)
#vcrun2005 (MWLL needs it won't run w/o)
#(add the two redists from the MWLL package, 32bit ones)
Now on the editor should launch: 
(note there is no newline at the top of the file)

file: ['''~/.local/bin/MWLLeditor.sh''']:
<pre>
#! /bin/bash

v=0.10-beta
#executable=Crysis.exe
executable=Editor.exe
shaderspath=~/Documents/My\ Games/Crysis\ Wars/Shaders

i=${1:-3}

if [ "X"$i != "X" ] ; then
pass=$i
echo $i
fi

if (( $pass > 3 )) || (( $pass < 1 )); then
echo " uasge:"
echo $0 "{1|2|3}"
echo "1 = winecfg, 2 = winetricks, 3 = editor"
exit 2
fi

echo $pass

# switch comment whats appropriate
# export WINEARCH=win32
# winegamepath='/drive_c/Program Files (x86)/Electronic Arts/Crytek/Crysis Wars/Bin32'
# windowsgamepath='C:\Program Files (x86)\Electronic Arts\Crytek\Crysis Wars\Bin32\'

export WINEARCH=win64
winegamepath='/drive_c/Program Files (x86)/Electronic Arts/Crytek/Crysis Wars/Bin64'
windowsgamepath='C:\Program Files (x86)\Electronic Arts\Crytek\Crysis Wars\Bin64\'

#here we do "magic" to run DX9 (only supported so far)
#and tell Crysis we want the MWLL mod not the OEM game :^)
OPT="-dx9 -mod MWLL"
#OPT="-mod MWLL"
#OPT="-dx9"

# reducing what wine spews at us
#export WINEDEBUG=-fixme-all,-warn-all,-err-all,-all
export WINEDEBUG=-all

WINEFSYNC=1
WINEESYNC=1
DXVK_HUD=1
DXVK_FILTER_DEVICE_NAME="NVIDIA GeForce GTX 1060 3GB"

# we controll which directory we want be runned by the script
export WINEPREFIX=~/.wine

#this can really beak things if enabled but try it?
# export MESA_DEBUG=1

# we the humans check here what renders our stuff
# if not "Gallium" then it's software = too slow
REND=$(glxinfo | grep "OpenGL renderer" | awk -F: '{print $2}' | awk -F"(" '{print $1}')
echo "Renderer:"$REND
echo "if the above is llvm and not an actual card the game will not work"

#cleaning leftovers from late dinner ;)
killall $executable
killall -9 $executable

#cleaning shader cache for better performance each time
#rm -r "${shaderspath}/*"

#here I cleverly avoid calling the path with my user name :)
cd "${WINEPREFIX}${winegamepath}/${binpath}"
#here i cleverly ask to show the path so we see what WINEPREFIX was called
pwd

case $WINEARCH in
win64)
echo 64bit
case $pass in
1)
winecfg
;;
2)
winetricks
;;
3)
wine64 "${windowsgamepath}${executable}" $OPT # 2>/dev/null # &> MWLL_debug.log
#if uncommented, the last line's comment dumps a log file to the game folder - might prove usefull or a vaste of disk space
;;
esac
;;
win32)
echo 32bit
case $pass in
1)
winecfg
;;
2)
winetricks
;;
3)
#here (hopefully) no shit hits the fan, and we land in game menu
wine ${windowsgamepath}${executable} $OPT # &> MWLL_debug.log
#if uncommented, the last line's comment dumps a log file to the game folder - might prove usefull or a vaste of disk space
;;
esac
;;
esac
# to restore resolution put here what's appropriate or leave as is and just uncomment
xrandr -s 0 # last good resolution

</pre>

This should have you all set.

=== Run the editor ===
You can now start the file by typing ['''MWLLeditor.sh'''] in a command prompt and pressing enter.
Pick a map (['''TC_Reference'''] comes to mind) and try add an ''brush''. Here on is uncharted territory, keep me posted!

=== What breaks in the editor and how to work around it ===

''TODO''

Orion

2023-10-28T13:58:41Z

Fire-hound: /* Variant G - "Tacitus" */ shortened the fluff due to feedback in that favor

{{Mech|
| Image = File:Orion.png
| ImageGif =
| Class = Heavy
| Faction = Inner Sphere
| Tickets = 10
| Tier = 11
| Tonnage = 75
| Speed = 65
| Rotation = 250
| PitchStand = -28° to +31°
| PitchCrouch = -28° to +41°

| Price Prime = 83 900
| ArmorT Prime = 70 257
| Engine Prime = Light Fusion Vlar 300
| Weapons Prime = <ul>
<li>1x [[UAC10]]
<li>3x [[ERML]]
<li>1x [[LRM20]]
<li>1x [[NARC]]
<li>1x [[B-Pod]]
</ul>
| Equip Prime = <ul>
<li>5 [[DHS]]
<li>2 [[free tons]]
<li>14.5t [[Armor]]
</ul>

| Price A = 90 750
| ArmorT A = 70 257
| Engine A = Light Fusion Vlar 300
| Weapons A = <ul>
<li>3x [[Standard_AutoCannons|LAC5]]
<li>2x [[PPC]]
<li>3x [[TBolt5]]
<li>1x [[B-Pod]]
</ul>
| Equip A = <ul>
<li> [[EOptics]]
<li>3 [[DHS]]
<li>0 [[free ton]]
<li>14.5t [[Armor]]
</ul>

| Price B = 87 900
| ArmorT B = 70 257
| Engine B = Hermes 340 XL
| AltSpeed B = 76
| Weapons B = <ul>
<li>1x [[HPPC]]
<li>2x [[RAC5]]
<li>1x [[SRM2]]
<li>1x [[SRM4]]
</ul>
| Equip B = <ul>
<li> [[EOptics]]
<li>6 [[DHS]]
<li>4 [[free ton]]
<li>14.5t [[Armor]]
</ul>

| Price C = 92 000
| ArmorT C = 70 257
| Engine C = Hermes 340 XL
| AltSpeed C = 76
| Weapons C = <ul>
<li>1x [[Blazer]]
<li>1x [[HGauss]]
<li>2x [[MRM10]]
<li>2x [[Mgun]]
<li>1x [[B-Pod]]
</ul>
| Equip C = <ul>
<li>2 [[DHS]]
<li>2 [[free tons]]
<li>14.5t [[Armor]]
</ul>

| Price D = 85 750
| ArmorT D = 70 257
| Engine D = Hermes 340 XL
| AltSpeed D = 76
| Weapons D = <ul>
<li>1x [[HVAC2]]
<li>1x [[HVAC5]]
<li>2x [[LRM15]]
<li>1x [[TAG]]
</ul>
| Equip D = <ul>
<li> [[EOptics]]
<li> [[BAP]]
<li>3 [[DHS]]
<li>2 [[free tons]]
<li>14.5t [[Armor]]
</ul>

| Price E = 94 900
| ArmorT E = 70 257
| Engine E = Hermes 340 XL
| AltSpeed E = 76
| Weapons E = <ul>
<li>2x [[ERSL]]
<li>1x [[LBX20]]
<li>1x [[SSRM4]]
<li>2x [[SSRM6]]
</ul>
| Equip E = <ul>
<li> [[EOptics]]
<li> [[iJJ]]
<li> [[GECM]]
<li>3 [[DHS]]
<li>3 [[free tons]]
<li>14.5t [[Stealth Armor]]
</ul>

| Price F = 92 400
| ArmorT F = 70 257
| Engine F = Hermes 300 XL
| Weapons F = <ul>
<li>2x [[ERPPC]]
<li>1x [[Gauss]]
<li>4x [[Standard_AutoCannons|LAC2]]
<li>1x [[B-Pod]]
</ul>
| Equip F = <ul>
<li> [[EOptics]]
<li>2 [[DHS]]
<li>1 [[free tons]]
<li>14.5t [[Armor]]
</ul>

| Price G = 96 050
| ArmorT G = 70 257
| Engine G = Light Fusion Vlar 300
| Weapons G = <ul>
<li>1x [[Blazer]]
<li>1x [[SRM6]]
<li>2x [[UAC5]]
<li>2x [[Mgun]]
</ul>
| Equip G = <ul>
<li> [[EOptics]]
<li> [[GECM]]
<li> [[C3]]
<li> [[BAP]]
<li>2 [[DHS]]
<li>0 [[free tons]]
<li>14.5t [[Armor]]
</ul>

| Armor H = 2760
| Armor CT = 10387
| Armor LRT = 6752
| Armor B = 6232
| Armor LRA = 5973
| Armor LRL = 7946
| Armor INT = 4768

| Version153 = 0.16.1
}}

The '''Orion''' is [[Inner Sphere]] [[Heavy Mechs|Heavy Mech]]. Though in production for well over 500 years, the Orion remains a mainstay of the Free World’s heavy ’Mech forces, as its mix of firepower and resilience appeals to a wide range of MechWarriors. Over the centuries countless thousands have poured off the production line, but the last two decades have seen something of a renaissance for the Orion as the inclusion of recovered technologies has allowed the design to push its way to the forefront of the FWLM’s military exports. The Orion is a dependable workhorse design that can handle almost any combat role, thanks to its mix of long and short-range weaponry and its Valiant Lamellor armor. Unlike other Mechs that have diverse [[engine]] options, the Orion actually has different max speeds based on which engine each [[variant]] is equipped with. Orions with the more common XL engines travel at 76 km/h, the F Variant carries a smaller XL engine and travels at 65 km/h, while Orions with the less common light fusion engine also travel more slowly at 65 km/h, but benefit from greater survivability. Between the engine options and the Orion's 14.5 tons of armor (tied for the highest armor of any [[Inner Sphere]] heavy Mech) the Orion is a very durable Mech.

Note: Only the variants with a speed of 65 km/h (Prime, A, F, and G) can be bought at forward factories.

==Roles and Gameplay Hints==
===Prime===
The Orion Prime is a solid [[Gameplay_Tactics#Self-NARCing/TAGing|self-NARCing]] Mech with its [[LRM20]] and [[NARC]]. But unlike most other self-NARCing assets, the Prime has enough independent weaponry to contribute in medium- and short-[[range]] engagements. It can use its [[NARC]] to self-target enemies or to [[supporting|support]] allies. Between its 3 [[ML]]s and [[UAC10]] the Prime is equipped like an aggressive light Mech so long as it's in medium [[range]]. The Prime has 2 [[free tons]] of ammo and generally one ton of LRM ammo and one ton of UAC10 ammo is called for. Although it slows the Prime down to 65 km/h, it is also equipped a compact light [[engine]] making it one of the most durable Inner Sphere heavy Mechs.

===Variant A===
Unlike the similarly-equipped [[Argus#E_Variant|Argus E]] the Orion A struggles to accommodate its dual [[PPC]] energy weapons which should nearly always be [[chain fire]]ed. Even the A's trio of [[Tbolt5]]s should be chain fired when able, if enemy [[LAMS]] are active, [[group fire]] may be necessary. Group fire may also be necessary when [[damage spreading]] or [[brawling]]. Players will have to weigh the speed of the Argus vs the [[armor]] of the Orion, especially since the Argus E boasts superior [[range]]. While the Argus E dips into long-range, the Orion A is more solidly in medium-range. For anti-[[BA]] activity, the A should [[chain fire]] its trio of [[Standard_AutoCannons|LAC5]]s and be prepared to use its [[B-Pod]]. Although it slows the A down to 65 km/h, it is also equipped a compact light [[engine]] making it one of the most durable Inner Sphere heavy Mechs.

===Variant B===
The Orion B can serve multiple roles. Its [[SRM4]] and [[SRM2]] compliment both a [[poking]]- or [[staring]]-playstyle. Meanwhile, the B's [[HPPC]] lends itself to poking and its pair of [[RAC5]]s lend themselves to staring. Additionally, all the B's weapons can be conserved while its RAC5s are on [[cooldown]] allowing the B to [[damage spread]] in some situations. The B has 4 [[free tons]] of ammo and all four tons should be dedicated to the ammo-hungry RAC5s. The B differentiates itself from other double RAC5 heavies with a modest top speed of 76 km/h allowing it to get in and out of combat more easily.

===Variant C - ''"Imperator-6"''===
The Imperator-6 is a formidable short- to mid-[[range]] asset. While it does have 2 [[Mgun|Mguns]], the Imperator-6 doesn't benefit from [[staring]] at all, and is a full-blown [[damage spreading|twist-fighter]] or [[poke|poking]] Mech (if cover is available). Both of the Imperator-6's main weapons, the [[Binary Laser Cannon]] and [[HGauss]] have long [[weapons|recycle]] times, and while the recycle time of the Imperator-6's pair of [[MRM10]]s isn't as long, they are easily saved up for a single [[alpha strike]] before damage-spreading resumes. Both of the Imperator-6's [[free tons]] of ammo are best saved for HGauss ammo. While the Imperator-6 doesn't have the durability of the compact light engine [[variant]]s, its poke-and-hide playstyle, coming from its high [[burst damage]] weaponry and modest top speed of 76 km/h, can dramatically improve its staying power.

===Variant D===
More focused on long-[[range]] support than the Prime, the Orion D extremely focused. At 1500m, the HVAC2, and at 1400m the HVAC5 provide the D with significant long-range suppression. The hail of bullets these weapons lay down make many [[assets]] hide behind cover. Even though the D's primary damage is in the 1000m range pair of [[LRM15]]s, their effective range can easily be stretched out to 1300m with the use of [[TAG]] making the Orion D an excellent [[Gameplay_Tactics#Self-NARCing.2FTAGing|self-TAGing]] asset. Considering the TAG... The D's [[BAP]] seems almost unnecessary except for warning the pilot of incoming enemies a little bit sooner. This heads up can mean life or death for a Mech like the D when its weapons are so terrible at [[brawling]]. It needs every bit of warning and every single one of its 76 km/h to reposition before being charged and overwhelmed.

===Variant E - ''"Tiberius"''===
Although moderate in speed, at 76 km/h, the Tiberius is an agile, stealthy, hard-hitting, seek-and-destroy Mech. The Tiberius is the only [[stealth armor]] heavy Mech. Except for its [[Improved Jump Jets]], the Tiberius lacks the quick escape potential of faster heavies, depending on its stealth armor to make sure [[hit and run]] attacks don't turn into [[suicide run]]s. Unlike other heavies, though, the Tiberius is more than capable of getting in close to an enemy [[Long Tom]] or [[LRM Camper]] and eliminating them quickly before their allies can react. It's recommended to buy [[free ton|one ton]] of ammo for the [[LBX20]], and two tons for the [[SSRM|SSRMs]]. When it comes to extended [[brawler|brawling]], the Tiberius can struggle with its limited ammo and fast-firing SSRM6s. Pilots are advised to carefully aim their SRM shots.

===Variant F===
Similar loadouts on most other Mechs would be accompanied with [[JJ]]s. This is not so for the Orion F. The F sacrifices the ability to [[jump snipe]] for 4 [[Standard_AutoCannons|LAC2]]s that shoot out to 900m, perfectly matching its pair of [[ERPPC]]s and [[Gauss Rifle]]. In lengthy engagements at long-[[range]], few other heavy Mechs will give pilots as much [[direct fire]] firepower potential. The F, being a sniper, never needed the compact light engine that other Orion [[variant]]s nor the speed of other variants, and so the F has a smaller XL engine than the others and only travels at 65 km/h.

===Variant G - ''"Tacitus"''===
This Orion is right half way between the [[Thanatos]] scout and the [[Atlas]] scout. The [[C3]] coupled with [[GECM]] pretty much alleviates any concern for running the radar active the whole time. With the [[BAP]] the area will be illuminated somewhat further but it still won't help find [[APC|shut down adversaries units parked around]], if you know what i mean...

The weapons array compliments it's electronic package but it's nothing to lean excessively on. The [[Binary Laser Cannon]], while dreaded by the ground asset drivers, will tax the [[DHS]] pair pretty soon which could not only lead to a premature shutdown, but more importantly to a sensor spike across the whole satellite map. Furthermore caution is advised to avoid jamming the [[UAC5]] pair as [[SRM6]] and the [[MG]] array will have to serve as a backup for the while the mech cools down from the [[Binary Laser Cannon|BLaser]] and the [[UAC5]]s un-jam too. Noteworthy is to mention the [[Engines#Compact_Fusion_Engine|compact engine]] will reduce destroyed side torso damage spill over to the center torso.

==Trivia==
As the folklore has been told: 
Since his time of conception into the world of Mechwarrior, Invictus has felt the calling to battle with one of the most formidable mechs ever...
Thus the Orion was gifted to the project director to be included into MWLL.

According to CW/Γ Andrew co-director the reality is.
"let me change this up a little: thus in october of 2019 CW/Γ Andrew started Project Orion together with [SA] Bird_Thing™ and [CJF] Leeko. Previous active artists (Nighthawk, Chezzar, Pajama Boy and Nathan) consulted and created the mech secretly over a time frame of roughly 2 and a half years. When it was ready it was gifted to project director invictus."

An as they say the rest is History!

==Canon==
[[File:liberation_of_terra.jpg|212px|topM=20px|leftM=40px|right]]
Sometimes called “a poor man’s Atlas” since the introduction of that behemoth, the Orion is a venerable, general-duty heavy ’Mech—and a famous one. Everyone has seen the images of Aleksandr Kerensky storming Amaris’ last defenses on Terra, making the Orion one of the best known ’Mechs in history. Commissioned by the Terran Hegemony in response to improving ’Mech designs used by other Houses, the Orion is nearly half a millennium old. The roomy chassis has allowed it to be readily upgraded and maintained over the centuries. The Orion remains a mainstay of the Free World’s heavy ’Mech forces, as its mix of firepower and resilience appeals to a wide range of MechWarriors.
Like the Marauder, the Orion's armor is Valiant Lamellor, less massive and better able to distribute heat and kinetic energy than other armor types, though the secret of its manufacture has been lost to time.

Date Introduced 2453 during the Era known as "Era Age of War" (2005 - 2570) - Unit Role: Brawler

[https://www.sarna.net/wiki/Orion BattleTech Reference]

{{Template:Navbox_Assets_IS}}

Orion

2023-10-28T13:30:06Z

Fire-hound: /* Variant G - "Tacitus" */ removed out of date banner

{{Mech|
| Image = File:Orion.png
| ImageGif =
| Class = Heavy
| Faction = Inner Sphere
| Tickets = 10
| Tier = 11
| Tonnage = 75
| Speed = 65
| Rotation = 250
| PitchStand = -28° to +31°
| PitchCrouch = -28° to +41°

| Price Prime = 83 900
| ArmorT Prime = 70 257
| Engine Prime = Light Fusion Vlar 300
| Weapons Prime = <ul>
<li>1x [[UAC10]]
<li>3x [[ERML]]
<li>1x [[LRM20]]
<li>1x [[NARC]]
<li>1x [[B-Pod]]
</ul>
| Equip Prime = <ul>
<li>5 [[DHS]]
<li>2 [[free tons]]
<li>14.5t [[Armor]]
</ul>

| Price A = 90 750
| ArmorT A = 70 257
| Engine A = Light Fusion Vlar 300
| Weapons A = <ul>
<li>3x [[Standard_AutoCannons|LAC5]]
<li>2x [[PPC]]
<li>3x [[TBolt5]]
<li>1x [[B-Pod]]
</ul>
| Equip A = <ul>
<li> [[EOptics]]
<li>3 [[DHS]]
<li>0 [[free ton]]
<li>14.5t [[Armor]]
</ul>

| Price B = 87 900
| ArmorT B = 70 257
| Engine B = Hermes 340 XL
| AltSpeed B = 76
| Weapons B = <ul>
<li>1x [[HPPC]]
<li>2x [[RAC5]]
<li>1x [[SRM2]]
<li>1x [[SRM4]]
</ul>
| Equip B = <ul>
<li> [[EOptics]]
<li>6 [[DHS]]
<li>4 [[free ton]]
<li>14.5t [[Armor]]
</ul>

| Price C = 92 000
| ArmorT C = 70 257
| Engine C = Hermes 340 XL
| AltSpeed C = 76
| Weapons C = <ul>
<li>1x [[Blazer]]
<li>1x [[HGauss]]
<li>2x [[MRM10]]
<li>2x [[Mgun]]
<li>1x [[B-Pod]]
</ul>
| Equip C = <ul>
<li>2 [[DHS]]
<li>2 [[free tons]]
<li>14.5t [[Armor]]
</ul>

| Price D = 85 750
| ArmorT D = 70 257
| Engine D = Hermes 340 XL
| AltSpeed D = 76
| Weapons D = <ul>
<li>1x [[HVAC2]]
<li>1x [[HVAC5]]
<li>2x [[LRM15]]
<li>1x [[TAG]]
</ul>
| Equip D = <ul>
<li> [[EOptics]]
<li> [[BAP]]
<li>3 [[DHS]]
<li>2 [[free tons]]
<li>14.5t [[Armor]]
</ul>

| Price E = 94 900
| ArmorT E = 70 257
| Engine E = Hermes 340 XL
| AltSpeed E = 76
| Weapons E = <ul>
<li>2x [[ERSL]]
<li>1x [[LBX20]]
<li>1x [[SSRM4]]
<li>2x [[SSRM6]]
</ul>
| Equip E = <ul>
<li> [[EOptics]]
<li> [[iJJ]]
<li> [[GECM]]
<li>3 [[DHS]]
<li>3 [[free tons]]
<li>14.5t [[Stealth Armor]]
</ul>

| Price F = 92 400
| ArmorT F = 70 257
| Engine F = Hermes 300 XL
| Weapons F = <ul>
<li>2x [[ERPPC]]
<li>1x [[Gauss]]
<li>4x [[Standard_AutoCannons|LAC2]]
<li>1x [[B-Pod]]
</ul>
| Equip F = <ul>
<li> [[EOptics]]
<li>2 [[DHS]]
<li>1 [[free tons]]
<li>14.5t [[Armor]]
</ul>

| Price G = 96 050
| ArmorT G = 70 257
| Engine G = Light Fusion Vlar 300
| Weapons G = <ul>
<li>1x [[Blazer]]
<li>1x [[SRM6]]
<li>2x [[UAC5]]
<li>2x [[Mgun]]
</ul>
| Equip G = <ul>
<li> [[EOptics]]
<li> [[GECM]]
<li> [[C3]]
<li> [[BAP]]
<li>2 [[DHS]]
<li>0 [[free tons]]
<li>14.5t [[Armor]]
</ul>

| Armor H = 2760
| Armor CT = 10387
| Armor LRT = 6752
| Armor B = 6232
| Armor LRA = 5973
| Armor LRL = 7946
| Armor INT = 4768

| Version153 = 0.16.1
}}

The '''Orion''' is [[Inner Sphere]] [[Heavy Mechs|Heavy Mech]]. Though in production for well over 500 years, the Orion remains a mainstay of the Free World’s heavy ’Mech forces, as its mix of firepower and resilience appeals to a wide range of MechWarriors. Over the centuries countless thousands have poured off the production line, but the last two decades have seen something of a renaissance for the Orion as the inclusion of recovered technologies has allowed the design to push its way to the forefront of the FWLM’s military exports. The Orion is a dependable workhorse design that can handle almost any combat role, thanks to its mix of long and short-range weaponry and its Valiant Lamellor armor. Unlike other Mechs that have diverse [[engine]] options, the Orion actually has different max speeds based on which engine each [[variant]] is equipped with. Orions with the more common XL engines travel at 76 km/h, the F Variant carries a smaller XL engine and travels at 65 km/h, while Orions with the less common light fusion engine also travel more slowly at 65 km/h, but benefit from greater survivability. Between the engine options and the Orion's 14.5 tons of armor (tied for the highest armor of any [[Inner Sphere]] heavy Mech) the Orion is a very durable Mech.

Note: Only the variants with a speed of 65 km/h (Prime, A, F, and G) can be bought at forward factories.

==Roles and Gameplay Hints==
===Prime===
The Orion Prime is a solid [[Gameplay_Tactics#Self-NARCing/TAGing|self-NARCing]] Mech with its [[LRM20]] and [[NARC]]. But unlike most other self-NARCing assets, the Prime has enough independent weaponry to contribute in medium- and short-[[range]] engagements. It can use its [[NARC]] to self-target enemies or to [[supporting|support]] allies. Between its 3 [[ML]]s and [[UAC10]] the Prime is equipped like an aggressive light Mech so long as it's in medium [[range]]. The Prime has 2 [[free tons]] of ammo and generally one ton of LRM ammo and one ton of UAC10 ammo is called for. Although it slows the Prime down to 65 km/h, it is also equipped a compact light [[engine]] making it one of the most durable Inner Sphere heavy Mechs.

===Variant A===
Unlike the similarly-equipped [[Argus#E_Variant|Argus E]] the Orion A struggles to accommodate its dual [[PPC]] energy weapons which should nearly always be [[chain fire]]ed. Even the A's trio of [[Tbolt5]]s should be chain fired when able, if enemy [[LAMS]] are active, [[group fire]] may be necessary. Group fire may also be necessary when [[damage spreading]] or [[brawling]]. Players will have to weigh the speed of the Argus vs the [[armor]] of the Orion, especially since the Argus E boasts superior [[range]]. While the Argus E dips into long-range, the Orion A is more solidly in medium-range. For anti-[[BA]] activity, the A should [[chain fire]] its trio of [[Standard_AutoCannons|LAC5]]s and be prepared to use its [[B-Pod]]. Although it slows the A down to 65 km/h, it is also equipped a compact light [[engine]] making it one of the most durable Inner Sphere heavy Mechs.

===Variant B===
The Orion B can serve multiple roles. Its [[SRM4]] and [[SRM2]] compliment both a [[poking]]- or [[staring]]-playstyle. Meanwhile, the B's [[HPPC]] lends itself to poking and its pair of [[RAC5]]s lend themselves to staring. Additionally, all the B's weapons can be conserved while its RAC5s are on [[cooldown]] allowing the B to [[damage spread]] in some situations. The B has 4 [[free tons]] of ammo and all four tons should be dedicated to the ammo-hungry RAC5s. The B differentiates itself from other double RAC5 heavies with a modest top speed of 76 km/h allowing it to get in and out of combat more easily.

===Variant C - ''"Imperator-6"''===
The Imperator-6 is a formidable short- to mid-[[range]] asset. While it does have 2 [[Mgun|Mguns]], the Imperator-6 doesn't benefit from [[staring]] at all, and is a full-blown [[damage spreading|twist-fighter]] or [[poke|poking]] Mech (if cover is available). Both of the Imperator-6's main weapons, the [[Binary Laser Cannon]] and [[HGauss]] have long [[weapons|recycle]] times, and while the recycle time of the Imperator-6's pair of [[MRM10]]s isn't as long, they are easily saved up for a single [[alpha strike]] before damage-spreading resumes. Both of the Imperator-6's [[free tons]] of ammo are best saved for HGauss ammo. While the Imperator-6 doesn't have the durability of the compact light engine [[variant]]s, its poke-and-hide playstyle, coming from its high [[burst damage]] weaponry and modest top speed of 76 km/h, can dramatically improve its staying power.

===Variant D===
More focused on long-[[range]] support than the Prime, the Orion D extremely focused. At 1500m, the HVAC2, and at 1400m the HVAC5 provide the D with significant long-range suppression. The hail of bullets these weapons lay down make many [[assets]] hide behind cover. Even though the D's primary damage is in the 1000m range pair of [[LRM15]]s, their effective range can easily be stretched out to 1300m with the use of [[TAG]] making the Orion D an excellent [[Gameplay_Tactics#Self-NARCing.2FTAGing|self-TAGing]] asset. Considering the TAG... The D's [[BAP]] seems almost unnecessary except for warning the pilot of incoming enemies a little bit sooner. This heads up can mean life or death for a Mech like the D when its weapons are so terrible at [[brawling]]. It needs every bit of warning and every single one of its 76 km/h to reposition before being charged and overwhelmed.

===Variant E - ''"Tiberius"''===
Although moderate in speed, at 76 km/h, the Tiberius is an agile, stealthy, hard-hitting, seek-and-destroy Mech. The Tiberius is the only [[stealth armor]] heavy Mech. Except for its [[Improved Jump Jets]], the Tiberius lacks the quick escape potential of faster heavies, depending on its stealth armor to make sure [[hit and run]] attacks don't turn into [[suicide run]]s. Unlike other heavies, though, the Tiberius is more than capable of getting in close to an enemy [[Long Tom]] or [[LRM Camper]] and eliminating them quickly before their allies can react. It's recommended to buy [[free ton|one ton]] of ammo for the [[LBX20]], and two tons for the [[SSRM|SSRMs]]. When it comes to extended [[brawler|brawling]], the Tiberius can struggle with its limited ammo and fast-firing SSRM6s. Pilots are advised to carefully aim their SRM shots.

===Variant F===
Similar loadouts on most other Mechs would be accompanied with [[JJ]]s. This is not so for the Orion F. The F sacrifices the ability to [[jump snipe]] for 4 [[Standard_AutoCannons|LAC2]]s that shoot out to 900m, perfectly matching its pair of [[ERPPC]]s and [[Gauss Rifle]]. In lengthy engagements at long-[[range]], few other heavy Mechs will give pilots as much [[direct fire]] firepower potential. The F, being a sniper, never needed the compact light engine that other Orion [[variant]]s nor the speed of other variants, and so the F has a smaller XL engine than the others and only travels at 65 km/h.

===Variant G - ''"Tacitus"''===
This Orion is right half way between the [[Thanatos]] scout and the [[Atlas]] scout, where it somewhat upgrades the lesser, but still does not surpass the bigger with the electronic package it brings to the field. The [[C3]] coupled with [[GECM]] pretty much alleviates any concern for running the radar active the whole time. The only exception might be should an [[AECM]] asset be near by and the fighting is still in the opening/assuming-positions phase. With the [[BAP]] the area will be lit further but it still won't help find [[APC|shut down adversaries units parked around]], if you know what i mean...

The weapons array compliments it's electronic package but it's nothing to lean excessively on. The [[Binary Laser Cannon]], while dreaded by the ground asset drivers, will tax the [[DHS]] pair pretty soon wich could not only lead to a premature shutdown, but more importantly to a sensor spike across the whole satellite map. Furthermore caution is advised to avoid jamming the [[UAC5]] pair as it leads to prolonged delays and drops in the already moderate damage output. The [[SRM6]] and the [[MG]] array will hardly be a deterrence for a seasoned BA mainer, but surely will serve as a backup for the while the mech cools down from the [[Binary Laser Cannon|BLaser]] and the [[UAC5]]s un-jam. Noteworthy is to mention the [[Engines#Compact_Fusion_Engine|compact engine]] will effectively protect damaged side torsos along being boringly slow at 65KPH pace when running.

Should you use this asset to supplement an already substantial assault lance or wave it might thrive in sharing armor and adding to the damage pool 800 meter out and closer, but it is very ill advised to use it as a 1v1 opponent to an asset of the same class or higher. It has a punch but well in line if not below of the usual heavy class mech.

==Trivia==
As the folklore has been told: 
Since his time of conception into the world of Mechwarrior, Invictus has felt the calling to battle with one of the most formidable mechs ever...
Thus the Orion was gifted to the project director to be included into MWLL.

According to CW/Γ Andrew co-director the reality is.
"let me change this up a little: thus in october of 2019 CW/Γ Andrew started Project Orion together with [SA] Bird_Thing™ and [CJF] Leeko. Previous active artists (Nighthawk, Chezzar, Pajama Boy and Nathan) consulted and created the mech secretly over a time frame of roughly 2 and a half years. When it was ready it was gifted to project director invictus."

An as they say the rest is History!

==Canon==
[[File:liberation_of_terra.jpg|212px|topM=20px|leftM=40px|right]]
Sometimes called “a poor man’s Atlas” since the introduction of that behemoth, the Orion is a venerable, general-duty heavy ’Mech—and a famous one. Everyone has seen the images of Aleksandr Kerensky storming Amaris’ last defenses on Terra, making the Orion one of the best known ’Mechs in history. Commissioned by the Terran Hegemony in response to improving ’Mech designs used by other Houses, the Orion is nearly half a millennium old. The roomy chassis has allowed it to be readily upgraded and maintained over the centuries. The Orion remains a mainstay of the Free World’s heavy ’Mech forces, as its mix of firepower and resilience appeals to a wide range of MechWarriors.
Like the Marauder, the Orion's armor is Valiant Lamellor, less massive and better able to distribute heat and kinetic energy than other armor types, though the secret of its manufacture has been lost to time.

Date Introduced 2453 during the Era known as "Era Age of War" (2005 - 2570) - Unit Role: Brawler

[https://www.sarna.net/wiki/Orion BattleTech Reference]

{{Template:Navbox_Assets_IS}}

Orion

2023-10-28T13:29:44Z

Fire-hound: /* Variant G - "Tacitus" */ updated to 16.1

{{Mech|
| Image = File:Orion.png
| ImageGif =
| Class = Heavy
| Faction = Inner Sphere
| Tickets = 10
| Tier = 11
| Tonnage = 75
| Speed = 65
| Rotation = 250
| PitchStand = -28° to +31°
| PitchCrouch = -28° to +41°

| Price Prime = 83 900
| ArmorT Prime = 70 257
| Engine Prime = Light Fusion Vlar 300
| Weapons Prime = <ul>
<li>1x [[UAC10]]
<li>3x [[ERML]]
<li>1x [[LRM20]]
<li>1x [[NARC]]
<li>1x [[B-Pod]]
</ul>
| Equip Prime = <ul>
<li>5 [[DHS]]
<li>2 [[free tons]]
<li>14.5t [[Armor]]
</ul>

| Price A = 90 750
| ArmorT A = 70 257
| Engine A = Light Fusion Vlar 300
| Weapons A = <ul>
<li>3x [[Standard_AutoCannons|LAC5]]
<li>2x [[PPC]]
<li>3x [[TBolt5]]
<li>1x [[B-Pod]]
</ul>
| Equip A = <ul>
<li> [[EOptics]]
<li>3 [[DHS]]
<li>0 [[free ton]]
<li>14.5t [[Armor]]
</ul>

| Price B = 87 900
| ArmorT B = 70 257
| Engine B = Hermes 340 XL
| AltSpeed B = 76
| Weapons B = <ul>
<li>1x [[HPPC]]
<li>2x [[RAC5]]
<li>1x [[SRM2]]
<li>1x [[SRM4]]
</ul>
| Equip B = <ul>
<li> [[EOptics]]
<li>6 [[DHS]]
<li>4 [[free ton]]
<li>14.5t [[Armor]]
</ul>

| Price C = 92 000
| ArmorT C = 70 257
| Engine C = Hermes 340 XL
| AltSpeed C = 76
| Weapons C = <ul>
<li>1x [[Blazer]]
<li>1x [[HGauss]]
<li>2x [[MRM10]]
<li>2x [[Mgun]]
<li>1x [[B-Pod]]
</ul>
| Equip C = <ul>
<li>2 [[DHS]]
<li>2 [[free tons]]
<li>14.5t [[Armor]]
</ul>

| Price D = 85 750
| ArmorT D = 70 257
| Engine D = Hermes 340 XL
| AltSpeed D = 76
| Weapons D = <ul>
<li>1x [[HVAC2]]
<li>1x [[HVAC5]]
<li>2x [[LRM15]]
<li>1x [[TAG]]
</ul>
| Equip D = <ul>
<li> [[EOptics]]
<li> [[BAP]]
<li>3 [[DHS]]
<li>2 [[free tons]]
<li>14.5t [[Armor]]
</ul>

| Price E = 94 900
| ArmorT E = 70 257
| Engine E = Hermes 340 XL
| AltSpeed E = 76
| Weapons E = <ul>
<li>2x [[ERSL]]
<li>1x [[LBX20]]
<li>1x [[SSRM4]]
<li>2x [[SSRM6]]
</ul>
| Equip E = <ul>
<li> [[EOptics]]
<li> [[iJJ]]
<li> [[GECM]]
<li>3 [[DHS]]
<li>3 [[free tons]]
<li>14.5t [[Stealth Armor]]
</ul>

| Price F = 92 400
| ArmorT F = 70 257
| Engine F = Hermes 300 XL
| Weapons F = <ul>
<li>2x [[ERPPC]]
<li>1x [[Gauss]]
<li>4x [[Standard_AutoCannons|LAC2]]
<li>1x [[B-Pod]]
</ul>
| Equip F = <ul>
<li> [[EOptics]]
<li>2 [[DHS]]
<li>1 [[free tons]]
<li>14.5t [[Armor]]
</ul>

| Price G = 96 050
| ArmorT G = 70 257
| Engine G = Light Fusion Vlar 300
| Weapons G = <ul>
<li>1x [[Blazer]]
<li>1x [[SRM6]]
<li>2x [[UAC5]]
<li>2x [[Mgun]]
</ul>
| Equip G = <ul>
<li> [[EOptics]]
<li> [[GECM]]
<li> [[C3]]
<li> [[BAP]]
<li>2 [[DHS]]
<li>0 [[free tons]]
<li>14.5t [[Armor]]
</ul>

| Armor H = 2760
| Armor CT = 10387
| Armor LRT = 6752
| Armor B = 6232
| Armor LRA = 5973
| Armor LRL = 7946
| Armor INT = 4768

| Version153 = 0.16.1
}}

The '''Orion''' is [[Inner Sphere]] [[Heavy Mechs|Heavy Mech]]. Though in production for well over 500 years, the Orion remains a mainstay of the Free World’s heavy ’Mech forces, as its mix of firepower and resilience appeals to a wide range of MechWarriors. Over the centuries countless thousands have poured off the production line, but the last two decades have seen something of a renaissance for the Orion as the inclusion of recovered technologies has allowed the design to push its way to the forefront of the FWLM’s military exports. The Orion is a dependable workhorse design that can handle almost any combat role, thanks to its mix of long and short-range weaponry and its Valiant Lamellor armor. Unlike other Mechs that have diverse [[engine]] options, the Orion actually has different max speeds based on which engine each [[variant]] is equipped with. Orions with the more common XL engines travel at 76 km/h, the F Variant carries a smaller XL engine and travels at 65 km/h, while Orions with the less common light fusion engine also travel more slowly at 65 km/h, but benefit from greater survivability. Between the engine options and the Orion's 14.5 tons of armor (tied for the highest armor of any [[Inner Sphere]] heavy Mech) the Orion is a very durable Mech.

Note: Only the variants with a speed of 65 km/h (Prime, A, F, and G) can be bought at forward factories.

==Roles and Gameplay Hints==
===Prime===
The Orion Prime is a solid [[Gameplay_Tactics#Self-NARCing/TAGing|self-NARCing]] Mech with its [[LRM20]] and [[NARC]]. But unlike most other self-NARCing assets, the Prime has enough independent weaponry to contribute in medium- and short-[[range]] engagements. It can use its [[NARC]] to self-target enemies or to [[supporting|support]] allies. Between its 3 [[ML]]s and [[UAC10]] the Prime is equipped like an aggressive light Mech so long as it's in medium [[range]]. The Prime has 2 [[free tons]] of ammo and generally one ton of LRM ammo and one ton of UAC10 ammo is called for. Although it slows the Prime down to 65 km/h, it is also equipped a compact light [[engine]] making it one of the most durable Inner Sphere heavy Mechs.

===Variant A===
Unlike the similarly-equipped [[Argus#E_Variant|Argus E]] the Orion A struggles to accommodate its dual [[PPC]] energy weapons which should nearly always be [[chain fire]]ed. Even the A's trio of [[Tbolt5]]s should be chain fired when able, if enemy [[LAMS]] are active, [[group fire]] may be necessary. Group fire may also be necessary when [[damage spreading]] or [[brawling]]. Players will have to weigh the speed of the Argus vs the [[armor]] of the Orion, especially since the Argus E boasts superior [[range]]. While the Argus E dips into long-range, the Orion A is more solidly in medium-range. For anti-[[BA]] activity, the A should [[chain fire]] its trio of [[Standard_AutoCannons|LAC5]]s and be prepared to use its [[B-Pod]]. Although it slows the A down to 65 km/h, it is also equipped a compact light [[engine]] making it one of the most durable Inner Sphere heavy Mechs.

===Variant B===
The Orion B can serve multiple roles. Its [[SRM4]] and [[SRM2]] compliment both a [[poking]]- or [[staring]]-playstyle. Meanwhile, the B's [[HPPC]] lends itself to poking and its pair of [[RAC5]]s lend themselves to staring. Additionally, all the B's weapons can be conserved while its RAC5s are on [[cooldown]] allowing the B to [[damage spread]] in some situations. The B has 4 [[free tons]] of ammo and all four tons should be dedicated to the ammo-hungry RAC5s. The B differentiates itself from other double RAC5 heavies with a modest top speed of 76 km/h allowing it to get in and out of combat more easily.

===Variant C - ''"Imperator-6"''===
The Imperator-6 is a formidable short- to mid-[[range]] asset. While it does have 2 [[Mgun|Mguns]], the Imperator-6 doesn't benefit from [[staring]] at all, and is a full-blown [[damage spreading|twist-fighter]] or [[poke|poking]] Mech (if cover is available). Both of the Imperator-6's main weapons, the [[Binary Laser Cannon]] and [[HGauss]] have long [[weapons|recycle]] times, and while the recycle time of the Imperator-6's pair of [[MRM10]]s isn't as long, they are easily saved up for a single [[alpha strike]] before damage-spreading resumes. Both of the Imperator-6's [[free tons]] of ammo are best saved for HGauss ammo. While the Imperator-6 doesn't have the durability of the compact light engine [[variant]]s, its poke-and-hide playstyle, coming from its high [[burst damage]] weaponry and modest top speed of 76 km/h, can dramatically improve its staying power.

===Variant D===
More focused on long-[[range]] support than the Prime, the Orion D extremely focused. At 1500m, the HVAC2, and at 1400m the HVAC5 provide the D with significant long-range suppression. The hail of bullets these weapons lay down make many [[assets]] hide behind cover. Even though the D's primary damage is in the 1000m range pair of [[LRM15]]s, their effective range can easily be stretched out to 1300m with the use of [[TAG]] making the Orion D an excellent [[Gameplay_Tactics#Self-NARCing.2FTAGing|self-TAGing]] asset. Considering the TAG... The D's [[BAP]] seems almost unnecessary except for warning the pilot of incoming enemies a little bit sooner. This heads up can mean life or death for a Mech like the D when its weapons are so terrible at [[brawling]]. It needs every bit of warning and every single one of its 76 km/h to reposition before being charged and overwhelmed.

===Variant E - ''"Tiberius"''===
Although moderate in speed, at 76 km/h, the Tiberius is an agile, stealthy, hard-hitting, seek-and-destroy Mech. The Tiberius is the only [[stealth armor]] heavy Mech. Except for its [[Improved Jump Jets]], the Tiberius lacks the quick escape potential of faster heavies, depending on its stealth armor to make sure [[hit and run]] attacks don't turn into [[suicide run]]s. Unlike other heavies, though, the Tiberius is more than capable of getting in close to an enemy [[Long Tom]] or [[LRM Camper]] and eliminating them quickly before their allies can react. It's recommended to buy [[free ton|one ton]] of ammo for the [[LBX20]], and two tons for the [[SSRM|SSRMs]]. When it comes to extended [[brawler|brawling]], the Tiberius can struggle with its limited ammo and fast-firing SSRM6s. Pilots are advised to carefully aim their SRM shots.

===Variant F===
Similar loadouts on most other Mechs would be accompanied with [[JJ]]s. This is not so for the Orion F. The F sacrifices the ability to [[jump snipe]] for 4 [[Standard_AutoCannons|LAC2]]s that shoot out to 900m, perfectly matching its pair of [[ERPPC]]s and [[Gauss Rifle]]. In lengthy engagements at long-[[range]], few other heavy Mechs will give pilots as much [[direct fire]] firepower potential. The F, being a sniper, never needed the compact light engine that other Orion [[variant]]s nor the speed of other variants, and so the F has a smaller XL engine than the others and only travels at 65 km/h.

===Variant G - ''"Tacitus"''===
{{Section out of date|0.16.1}}
This Orion is right half way between the [[Thanatos]] scout and the [[Atlas]] scout, where it somewhat upgrades the lesser, but still does not surpass the bigger with the electronic package it brings to the field. The [[C3]] coupled with [[GECM]] pretty much alleviates any concern for running the radar active the whole time. The only exception might be should an [[AECM]] asset be near by and the fighting is still in the opening/assuming-positions phase. With the [[BAP]] the area will be lit further but it still won't help find [[APC|shut down adversaries units parked around]], if you know what i mean...

The weapons array compliments it's electronic package but it's nothing to lean excessively on. The [[Binary Laser Cannon]], while dreaded by the ground asset drivers, will tax the [[DHS]] pair pretty soon wich could not only lead to a premature shutdown, but more importantly to a sensor spike across the whole satellite map. Furthermore caution is advised to avoid jamming the [[UAC5]] pair as it leads to prolonged delays and drops in the already moderate damage output. The [[SRM6]] and the [[MG]] array will hardly be a deterrence for a seasoned BA mainer, but surely will serve as a backup for the while the mech cools down from the [[Binary Laser Cannon|BLaser]] and the [[UAC5]]s un-jam. Noteworthy is to mention the [[Engines#Compact_Fusion_Engine|compact engine]] will effectively protect damaged side torsos along being boringly slow at 65KPH pace when running.

Should you use this asset to supplement an already substantial assault lance or wave it might thrive in sharing armor and adding to the damage pool 800 meter out and closer, but it is very ill advised to use it as a 1v1 opponent to an asset of the same class or higher. It has a punch but well in line if not below of the usual heavy class mech.

==Trivia==
As the folklore has been told: 
Since his time of conception into the world of Mechwarrior, Invictus has felt the calling to battle with one of the most formidable mechs ever...
Thus the Orion was gifted to the project director to be included into MWLL.

According to CW/Γ Andrew co-director the reality is.
"let me change this up a little: thus in october of 2019 CW/Γ Andrew started Project Orion together with [SA] Bird_Thing™ and [CJF] Leeko. Previous active artists (Nighthawk, Chezzar, Pajama Boy and Nathan) consulted and created the mech secretly over a time frame of roughly 2 and a half years. When it was ready it was gifted to project director invictus."

An as they say the rest is History!

==Canon==
[[File:liberation_of_terra.jpg|212px|topM=20px|leftM=40px|right]]
Sometimes called “a poor man’s Atlas” since the introduction of that behemoth, the Orion is a venerable, general-duty heavy ’Mech—and a famous one. Everyone has seen the images of Aleksandr Kerensky storming Amaris’ last defenses on Terra, making the Orion one of the best known ’Mechs in history. Commissioned by the Terran Hegemony in response to improving ’Mech designs used by other Houses, the Orion is nearly half a millennium old. The roomy chassis has allowed it to be readily upgraded and maintained over the centuries. The Orion remains a mainstay of the Free World’s heavy ’Mech forces, as its mix of firepower and resilience appeals to a wide range of MechWarriors.
Like the Marauder, the Orion's armor is Valiant Lamellor, less massive and better able to distribute heat and kinetic energy than other armor types, though the secret of its manufacture has been lost to time.

Date Introduced 2453 during the Era known as "Era Age of War" (2005 - 2570) - Unit Role: Brawler

[https://www.sarna.net/wiki/Orion BattleTech Reference]

{{Template:Navbox_Assets_IS}}

Avatar

2023-09-24T12:07:45Z

Fire-hound: /* Variant E */

{{Mech|
| Image = File:Avatar.png
| ImageGif = File:Avatar_spin.gif
| Class = Heavy
| Faction = Inner Sphere
| Tickets = 10
| Tier = 11
| Tonnage = 70
| Speed = 76
| SpeedWithMasc = 106
| Rotation = 360
| PitchStand = -34° to +45°
| PitchCrouch = -34° to +55°

| Price Prime = 83 500
| ArmorT Prime = 60 258
| Engine Prime = 280 XL
| Weapons Prime = <ul>
<li>4x [[MXPL]]
<li>2x [[TBolt10]]
<li>1x [[LBX10]]
<li>1x [[B-Pod]]
</ul>
| Equip Prime = <ul>
<li>[[EOptics]]
<li>5 [[DHS]]
<li>0 [[free tons]]
<li>12.5t [[Armor]]
</ul>

| Price A = 86 100
| ArmorT A = 60 258
| Engine A = 280 XL
| Weapons A = <ul>
<li>2x [[ERML]]
<li>1x [[Gauss]]
<li>2x [[ERPPC]]
</ul>
| Equip A = <ul>
<li>[[EOptics]]
<li>[[JJ]]
<li>2 [[DHS]]
<li>1 [[free ton]]
<li>12.5t [[Armor]]
</ul>

| Price B = 84 000
| ArmorT B = 60 258
| Engine B = 280 XL
| Weapons B = <ul>
<li>5x [[ERML]]
<li>3x [[ERLL]]
</ul>
| Equip B = <ul>
<li>[[EOptics]]
<li>[[iJJ]]
<li>9 [[DHS]]
<li>0 [[free tons]]
<li>12.5t [[Armor]]
</ul>

| Price C = 87 800
| ArmorT C = 60 258
| Engine C = 280 XL
| Weapons C = <ul>
<li>3x [[MPL]]
<li>2x [[SRM6]]
<li>1x [[HGauss]]
</ul>
| Equip C = <ul>
<li>[[EOptics]]
<li>2 [[DHS]]
<li>4 [[free ton]]
<li>12.5t [[Armor]]
</ul>

| Price D = 79 700
| ArmorT D = 60 258
| Engine D = 280 XL
| Weapons D = <ul>
<li>3x [[ML]]
<li>2x [[SSRM6]]
<li>1x [[AC20]]
</ul>
| Equip D = <ul>
<li> [[iJJ]]
<li>2 [[DHS]]
<li>3 [[free tons]]
<li>12.5t [[Armor]]
</ul>

| Price E = 94 100
| ArmorT E = 60 258
| Engine E = 280 XL
| Weapons E = <ul>
<li>2x [[RAC5]]
<li>2x [[MPL]]
<li>2x [[SRM2]]
</ul>
| Equip E = <ul>
<li>[[EOptics]]
<li>[[MASC]]
<li>[[iJJ]]
<li>7 [[DHS]]
<li>2 [[free tons]]
<li>12.5t [[Armor]]
</ul>

| Price F = 87 900
| ArmorT F = 65 049
| Engine F = 280 XL
| Weapons F = <ul>
<li>1x [[UAC10]]
<li>3x [[ERML]]
<li>2x [[LRM5]]
<li>1x [[HPPC]]
<li>1x [[B-Pod]]
</ul>
| Equip F = <ul>
<li>[[EOptics]]
<li>5 [[DHS]]
<li>1 [[free ton]]
<li>13.5t [[Armor]]
</ul>

| Price G = 82 600
| ArmorT G = 60 258
| Engine G = 280 XL
| Weapons G = <ul>
<li>2x [[PPC]]
<li>2x [[ERML]]
<li>2x [[LRM15]]
</ul>
| Equip G = <ul>
<li>[[AECM]]
<li>4 [[DHS]]
<li>2 [[free ton]]
<li>12.5t [[Armor]]
</ul>

| Armor H = 2760
| Armor CT = 9502
| Armor LRT = 6108
| Armor B = 5430
| Armor LRA = 4751
| Armor LRL = 6515
| Armor INT = 3909

| Version153 = 0.16.1
}}

The '''Avatar''' is a [[Heavy_Mechs|heavy Omnimech]] built by the [[Inner Sphere]]. Comparable to the [[Clan]] [[Thor]], it is an agile multipurpose asset, trading the Thor's top speed for a full 360 degree torso [[yaw|twist]]. The Avatar gains in enough open tonnage and pod space to outgun the Vulture, while simultaneously boasting superior armor protection as well.

==Roles and Gameplay Hints==
===Prime===
The Avatar Prime is defined by its mix of medium to long range weapons supported by [[Eoptics|enhanced optics]]. Its duo of [[TBolt10|Thunderbolt10]] launchers allow it to provide long range fire support and a [[LBX10|Lubalin Ballistics-X AutoCannon 10]] is capable of peppering enemies from 700m out, despite needing them to close in further in order to focus its damage. Four [[MXPL|Medium X-Pulse Lasers]] significantly enhance its ability to protect itself from enemies that break into close combat range. The mech's main issue is sustaining long range fire, as it has no free tons to reload its ammo-dependent weapons. Its 5 [[DHS]] can somewhat manage to dissipate the heat of its arsenal, but fire discipline is required.
[[B-Pod]], should enemy [[Battle Armor]] get too close.

===Variant A===
A variant focusing on long range firepower, the Avatar A's main armaments are its [[gauss|Gauss Rifle]] and dual [[ERPPC]]. Sharing a range of 900m they allow the variant to provide long range direct fire support and in combination with its [[Eoptics|enhanced optics]] and [[JJ|jumpjets]] make the Avatar A capable of [[Gameplay Tactics|Poptarting]]. The pair of [[ERML|Medium Lasers]] standard to the Avatar, in their extended range form, give it a little extra punch against enemies that manage to close in. A single [[Free tons | free ton]] keeps its gauss rifle fed and 2 [[DHS]] somewhat manage the combined heat of its weapons and jumpjets, as long as minimal fire discipline is practiced.

===Variant B - ''"The Flying Red"''===
<div style="width:102px; background-color:#4c4c4c; border: 1px solid #6c6c6c; border-radius:2px; padding:1px 1px 2px 1px; float:left; margin-right:10px; margin-top:12px;">
[[File:Flyingred.jpg|100px|center|The Flying Red]]
</div>
Dubbed "'''''The Flying Red'''''," The Avatar B is the Inner Sphere's ultimate answer to [[Clan]] long range superiority among heavy 'Mechs. Featuring a blistering array of lasers, this variant mounts a trio of [[ERLL]] on its right arm, while carrying an additional set of five [[ERML]] spread across its left arm and torso. This multitude of lasers allows this variant to blast through enemy armor with a mighty [[Gameplay Tactics#Alpha Strike|alpha strike]], hitting with extreme precision from great range supported by [[Eoptics|enhanced optics]]. [[Jump Jets|Improved Jump Jets]] further allow [[Gameplay Tactics#Poptarting|poptart]] tactics and increased maneuverability, while 9 [[Double Heat Sinks|double heat sinks]] keep heat under control thanks to the cooler nature of Inner Sphere lasers. All in all, the Avatar B is a terrifying addition to the Inner Sphere's heavy 'Mech arsenal, one capable of inspiring fear even amongst pilots of the most premier Clan assets.
<div style="clear: left"></div> 

===Variant C===
A brawler at heart, the Avatar C is capable of dealing modest damage out to 700m, but it needs to break into medium and even close range to bring its full firepower to bear. A [[gauss|Heavy Gauss Rifle]] with the help of [[Eoptics|enhanced optics]] lets it fire potshots at its enemies from medium-long range, but it's best used at ranges less than 450m for it to do maximum damage. Complimented by three [[MPL|Medium Pulse Lasers]] and a pair of [[SRM|SRM6]] launchers, the Avatar C's close combat power is not to be ignored. Its relative slowness and lack of jump jets means that its users must have a good grasp of combat flow and map awareness, but its 360 degree torso [[yaw|twist]] allows it to maneuver while keeping its arsenal trained on the target and its heavy armor gives it some confidence in prolonged engagements. Its lack of lock-on weapons and powerful optics allow it to comfortably maintain [[Radar|passive radar]] most of the time. 2 [[DHS]] are passable for its relatively low heat arsenal and its 4 [[Free tons]] allow an extended combat period.

===Variant D - ''"Fallschirmjaeger"''===
The Avatar D, known as the "'''''Fallschirmjaeger'''''", is one of the more dangerous Inner Sphere heavy 'Mech brawlers and sports a well-balanced blend of weaponry. An arm-mounted [[AC20]] easily blows holes in opposing 'Mechs which its two [[SSRM6]] packs can then exploit. Three [[ML|Medium Lasers]] provide good, sustaining fire and are well-suited to precisely dishing out the final few points of damage needed to destroy a component or score a kill, while also being a danger to unwary [[Battle Armor]]. On top of all this, three [[Free tons]] for reloads allows the Avatar D to carry more than enough ammo for extended combat. [[Jump Jets|Improved Jump Jets]] provide a lot of utility; this Avatar can quickly lunge at a target to perform a takedown, or leap back into cover to escape a bad engagement. Despite its incredible jump mobility, the D only has a maximum range of only 500m, ideal range of 350m, and as a result is woefully unsuited to fighting in open terrain. Pilots considering this variant should think carefully about their overall strategy before deploying this 'Mech on such maps.

===Variant E===
This variant leans heavily on it's twin [[RAC5]] array rather than on anything else and then rightly so. There aren't many mechs sporting more of- or are able to tank more of- for any reasonable amount of time. That being said (and done), the two [[MPL|Medium Pulse]] Lasers will happily jump in for the time the two main weapons have to reload or heavens forbid un-jam. An ocassional bitch-slap with the two [[SRM2]] will add more than just insult to injury. Long story short; [[MASC]] to the ambush position, cool down, [[iJJ]] in front (or, even better yet - behind it's back!) of the unsuspecting target (the smaller the better), perform your act and jump out of the fray for the while the armor still serves. All weapons perform at their full capacity with the radar turned off on this unit, something to take note of.

===Variant F - ''"Scorpio"''===
Dubbed "Scorpio" The Avatar F has a much clearer focus towards medium range combat. A pounding [[UAC10]], 3 [[ERML]] to drill further into the armor and [[HPPC|Heavy PPC]] to reap your foes soul. Unleash the Hell Fire of the Scorpio, watch your attackers abandon the fight. Use it's duo [[LRM5]] supported by [[EOptics|Enhanced Optics]] provides a significant long range boost to soften incoming combatants thus luring them into their doom. Its 1 [[Free ton|free ton]] is usually dedicated to its ultra autocannon. 5 DHS do a decent job of managing the variant's heat, as long as everything isn't fired at once. Extra 1.5t of armor and [[B-Pod]] to maim irritant [[BA]], help with staying alive.

===Variant G===
The Avatar G is a fire support mech designed with teamwork in mind. Its rarest piece of equipment is an [[AECM]], allowing it to hide the radar signals of its teammates and offer protection from [[NARC]]s. Spending most of its time running active as the most visible signature is bound to attract enemy fire, but makes the use of its pair of [[LRM15]] launchers more straightforward when used as direct fire support. Additionally, the Avatar's 360 degree torso [[yaw|twist]] makes the G a great mech for [[Combat_Guide#Movement|kiting]] making it easy to keep enemies outside of the LRMs [[minimum range]]. Enemies that close into middle range will have to contend with a pair of [[PPC]]s, synergising with its missiles as a source of screenshake and splash damage, but potentially disabling friendly NARC beacons. Its two [[ERML]] offer some extra damage against enemies that begin to close in uncomfortably, as well as acting as a BA deterrent. 4 [[DHS]] keep the asset's heat manageable.

==Canon==
The first of the Inner Sphere OmniMechs to be conceptualized and one of the last to reach production by the Draconis Combine as part of its "first generation", the Avatar's design is based on captured Vulture OmniMechs. The Avatar is used primarily by the DCMS, but has also been sold to the Lyran Alliance and ComStar. The Avatar weighs in at seventy tons and is powered by a Hermes 280 XL Engine that gives it a top speed of 64.8 km/h. It is protected by twelve tons of StarSlab/4 armor that comes with CASE to protect the 'Mech against complete destruction from an internal ammunition explosion. The Avatar is a powerful OmniMech in its various configurations, with an impressive thirty-four tons of pod space allowing it to carry a wide range of weapons.

Date Introduced 3056 during the Era known as "Clan Invasion" (3050 - 3061) - Unit Role: Brawler

[http://www.sarna.net/wiki/Avatar_(BattleMech) BattleTech Reference]
{{Template:Navbox_Assets_IS}}

AlienArt

2023-03-08T12:12:39Z

Fire-hound: Added stub

{{ Stub }}
By Alien it's meant as totally new, possibly even strange art in respect of what's present in the Asset Pool. 
In effect successfully following this procedure will hopefully lead to gradual expansion and enrichment of the aforementioned Asset pool. 

The process:

== Preparing The geometry ==
=== now with blender 3.x ===
This is a procedure covering the ever growing technology gap between the free and ever livid blender and the aging cryengine2. 
Just get any blender past 3.x release.

=== Get it ready ===
[[File:Step01.png|200px|thumb|center|Prepare Collection]]

For a Mesh to be fit for cryengine it has to fulfill several criteria due to how some compromises were made. 
It is a ''convention'' and if one sticks to it good results will ensue. 
# No more than two triangles should share same edge.
# There should be nothing but triangles (or quads) as the final result - remove all and any nodes and or lines (''primitives'')...
# There should be no triangles of surfaces of size zero (degenerate faces).
# It is desirable for the mesh be airtight, but there are valid exceptions.

The Object is to be investigated for the quality and errors for UV mapping. 
Only a single UV map per mesh is supported in Cryengine 

The Object is to be assigned To a ''Collection'' (no more ''Groups'' in blender 3.x) that shares the same name 
The '''.blend''' file is to be saved with the same name, so that it shares (again) the same name as the object and collection. 

We should now be ready for the export to collada ('''.dae''' file) 

[[File:Step02.png|200px|thumb|center|Prepare Export]]

=== Export settings ===
[[File:Step03.png|200px|thumb|center|Collada export options]]

As seen on the image the favorable settings differ from defaults. It is therefore advisable to
create a operator preset (i aptly named "cryengine export") for further convenience.

{| class="wikitable" style="margin:auto"
|+ Parameter Meaning
|-
! Parameter name !! Explanation
|-
| Transform || Decomposed (this means rotation, translation and scale are decomposed)
|-
| Triangulate || leave no uncertain surfaces unresolved by blender.
|-
| Apply Transforms || Viewport (it is usually safe to assume this is true)
|-
| Selection Only || we rarely need everything from the file - watch for proper parent-children chains!
|-
| Include children || if parenting is properly laid out - this works miracles!
|-
| Use Object Instances || don't use this - i tried it once and it was ''ugly''
|-
| Use Blender Profile || this is best left off - always leave it off for Cryengine export.
|}

== Converting the format ==
=== Prepare your Linux ===
For this to work at all some prerequisites are to be met. You didn't think you'll get off
the hook as easy, didn't you? 
We need working '''ColladaCGF''' in '''wine''', for this we need working '''PyFFI''' in '''wine''', and for this we need working '''Python''' in '''wine''' in the first place.
For this all to work at all certain versions are to be downloaded and fed to '''wine''': 
* Python 2.6.6 (or earlier, but ideally ''exactly'' 2.6.6 (32bit release only)
* PyFFI 2.1.11 (the last one that works with 2.x python, newer ones require python 3.x)
* ColladaCGF 0.3.9 (the last one available)

For this to work you will need your '''Linux''' to be either "''multilib''" (more likely applies to you) or 32bit (less likely but possible)

Install In that exact order (Python, PyFFI, Collada). 
The very installation process:
# Locate the repositories
# Download the corresponding versions and to what place locally
# Point a file manager or ''explorer'' inside of wine to the downloaded files in order to install them
Is left as an exercise to the reader as the web locations are documented in another article on this wiki. 

To make certain they are in the right wine prefix check that both files: 
"C:\Python26\python.exe"
and
"C:\Python26\Scripts\colladacgf.py"
should be present.

Now if you are not using '''XFCE4''' as your GUI, ''too bad you're just out of luck''. Otherwise open the Custom Actions chooser via the Edit menu of '''Thunar''' and make a new custom action:

[[File:Step04.png|200px|thumb|center|Custom Actions setup with Thunar and XFCE4]]

I named the action [ ColladaCGF ] and gave it the default python icon. The description should be obvious: [ Convert a dae file into cgf ]. The command that worked for me was:

[ wineconsole "C:\Python26\python.exe" "C:\Python26\Scripts\colladacgf.py" %F --pause ]

where %F is a list of selected files with the full path.

The filters on the other tab are to be set accordingly: 
[ *.dae;*.DAE ]

mind the semicolon. And the affected files are the ''text files'' (since '''.dae''' files look like '''XML''' files) and ''other files'', just in case. Never mind this impossible screenshot - it is CGI - so you have it all on one place for '''''maximum convenience'''''.

Apply, close and restart '''Thunar'''. Now on You should have a context option for each '''.dae''' file:

[[File:Step05.png|200px|thumb|center|ColladaCGF usage in XFCE on Linux]]

=== Point the ColladaCGF to the .dae file ===
The '''.dae''' file is to be selected, '''rightclick > ColladaCGF''' and voila! by ''automagic'' a bunch of murr-murr and computer speak will fill a dark frame, once you notice the computer has stopped spewing insults and dark magic, there might be a blinking cursor waiting no you to press ['''enter'''] key and close the window. You might have just converted your first '''CGF''' file on Linux. Or you will be in due time. Conversions often fail due to not adhering to the ''convention'' mentioned earlier.

=== Find the cgf file ===
The newly generated '''.CGF''' file and it's belonging '''.MTL''' file should lay next to each other and next to the source '''.DAE''' file. There might be leftovers in the form of logs and dumps. This can be
safely ignored, they can safely be deleted too.

== Importing into engine on Linux ==
I assume Your Linux has ''multilib'' capability here on. I assume You understand what that means and know where to ask for details for Your distro of choice.

=== How to get the editor working (Glitch TKG's github) ===
I see not too many casualties to this point. Good; good, here onward it gets tough as nails, and by that i mean eating chains to fart back nails!.

https://github.com/Tk-Glitch (kudos to Tk-Glitch o/ )

https://github.com/Tk-Glitch/PKGBUILDS/wiki/wine-tkg-git#dependencies

You want to build a not only custom version of wine (as if that wasn't intimidating enough!).

No sir, you want a highly customized, overly patched VERY recent version wine-staging that has support for child-window our '''Sandbox2''' editor uses to render the game within it's app window.

No configuration files need to be modified in the [wine-tkg-git] directory, You merely cd to it and run [./non-makepkg-build.sh]

first time you will be dropped to a shell with info and stuff...

make the following file:

file: ['''~/.config/frogminer/wine-tkg.cfg''']:
<pre>

_LOCAL_PRESET="none"
_use_GE_patches="true"
_plain_version=""
_use_staging="true"
_staging_version="v7.22"
_use_fastsync="false"
_use_esync="true"
_use_fsync="true"
_fsync_futex_waitv="true"
_use_vkd3dlib="true"
_dxvk_dxgi="true"

_proton_battleye_support="false"
_proton_eac_support="false"
_warframelauncher_fix="false"
_mwo_fix="false"
_re4_fix="false"

_childwindow_fix="true"

_use_josh_flat_theme="true"

</pre>

And once saved, re-run the above command. Install the new '''wine''' and make MWLL run in it's prefix.

to run the editor you will need few more '''winetricks'''... 
Fended off yet? no? Good, because that isn't nearly the end of the desert :D. 
add (via winetricks) the following: 
#d3dcompiler_43
#d3dcompiler_47
#dotnet472 (needed for the launcher anyway (will pull in much down to dotnet40) )
#dxvk (i have dxvk1101 so far)
#vcrun2005 (MWLL needs it won't run w/o)
#(add the two redists from the MWLL package, 32bit ones)
Now on the editor should launch: 
(note there is no newline at the top of the file)

file: ['''~/.local/bin/MWLLeditor.sh''']:
<pre>
#! /bin/bash

v=0.10-beta
#executable=Crysis.exe
executable=Editor.exe
shaderspath=~/Documents/My\ Games/Crysis\ Wars/Shaders

i=${1:-3}

if [ "X"$i != "X" ] ; then
pass=$i
echo $i
fi

if (( $pass > 3 )) || (( $pass < 1 )); then
echo " uasge:"
echo $0 "{1|2|3}"
echo "1 = winecfg, 2 = winetricks, 3 = editor"
exit 2
fi

echo $pass

# switch comment whats appropriate
# export WINEARCH=win32
# winegamepath='/drive_c/Program Files (x86)/Electronic Arts/Crytek/Crysis Wars/Bin32'
# windowsgamepath='C:\Program Files (x86)\Electronic Arts\Crytek\Crysis Wars\Bin32\'

export WINEARCH=win64
winegamepath='/drive_c/Program Files (x86)/Electronic Arts/Crytek/Crysis Wars/Bin64'
windowsgamepath='C:\Program Files (x86)\Electronic Arts\Crytek\Crysis Wars\Bin64\'

#here we do "magic" to run DX9 (only supported so far)
#and tell Crysis we want the MWLL mod not the OEM game :^)
OPT="-dx9 -mod MWLL"
#OPT="-mod MWLL"
#OPT="-dx9"

# reducing what wine spews at us
#export WINEDEBUG=-fixme-all,-warn-all,-err-all,-all
export WINEDEBUG=-all

WINEFSYNC=1
WINEESYNC=1
DXVK_HUD=1
DXVK_FILTER_DEVICE_NAME="NVIDIA GeForce GTX 1060 3GB"

# we controll which directory we want be runned by the script
export WINEPREFIX=~/.wine

#this can really beak things if enabled but try it?
# export MESA_DEBUG=1

# we the humans check here what renders our stuff
# if not "Gallium" then it's software = too slow
REND=$(glxinfo | grep "OpenGL renderer" | awk -F: '{print $2}' | awk -F"(" '{print $1}')
echo "Renderer:"$REND
echo "if the above is llvm and not an actual card the game will not work"

#cleaning leftovers from late dinner ;)
killall $executable
killall -9 $executable

#cleaning shader cache for better performance each time
#rm -r "${shaderspath}/*"

#here I cleverly avoid calling the path with my user name :)
cd "${WINEPREFIX}${winegamepath}/${binpath}"
#here i cleverly ask to show the path so we see what WINEPREFIX was called
pwd

case $WINEARCH in
win64)
echo 64bit
case $pass in
1)
winecfg
;;
2)
winetricks
;;
3)
wine64 "${windowsgamepath}${executable}" $OPT # 2>/dev/null # &> MWLL_debug.log
#if uncommented, the last line's comment dumps a log file to the game folder - might prove usefull or a vaste of disk space
;;
esac
;;
win32)
echo 32bit
case $pass in
1)
winecfg
;;
2)
winetricks
;;
3)
#here (hopefully) no shit hits the fan, and we land in game menu
wine ${windowsgamepath}${executable} $OPT # &> MWLL_debug.log
#if uncommented, the last line's comment dumps a log file to the game folder - might prove usefull or a vaste of disk space
;;
esac
;;
esac
# to restore resolution put here what's appropriate or leave as is and just uncomment
xrandr -s 0 # last good resolution

</pre>

This should have you all set.

=== Run the editor ===
You can now start the file by typing ['''MWLLeditor.sh'''] in a command prompt and pressing enter.
Pick a map (['''TC_Reference'''] comes to mind) and try add an ''brush''. Here on is uncharted territory, keep me posted!

=== What breaks in the editor and how to work around it ===

''TODO''

AlienArt

2023-03-05T14:49:50Z

Fire-hound: /* Importing into engine on Linux */

By Alien it's meant as totally new, possibly even strange art in respect of what's present in the Asset Pool. 
In effect successfully following this procedure will hopefully lead to gradual expansion and enrichment of the aforementioned Asset pool. 

The process:

== Preparing The geometry ==
=== now with blender 3.x ===
This is a procedure covering the ever growing technology gap between the free and ever livid blender and the aging cryengine2. 
Just get any blender past 3.x release.

=== Get it ready ===
[[File:Step01.png|200px|thumb|center|Prepare Collection]]

For a Mesh to be fit for cryengine it has to fulfill several criteria due to how some compromises were made. 
It is a ''convention'' and if one sticks to it good results will ensue. 
# No more than two triangles should share same edge.
# There should be nothing but triangles (or quads) as the final result - remove all and any nodes and or lines (''primitives'')...
# There should be no triangles of surfaces of size zero (degenerate faces).
# It is desirable for the mesh be airtight, but there are valid exceptions.

The Object is to be investigated for the quality and errors for UV mapping. 
Only a single UV map per mesh is supported in Cryengine 

The Object is to be assigned To a ''Collection'' (no more ''Groups'' in blender 3.x) that shares the same name 
The '''.blend''' file is to be saved with the same name, so that it shares (again) the same name as the object and collection. 

We should now be ready for the export to collada ('''.dae''' file) 

[[File:Step02.png|200px|thumb|center|Prepare Export]]

=== Export settings ===
[[File:Step03.png|200px|thumb|center|Collada export options]]

As seen on the image the favorable settings differ from defaults. It is therefore advisable to
create a operator preset (i aptly named "cryengine export") for further convenience.

{| class="wikitable" style="margin:auto"
|+ Parameter Meaning
|-
! Parameter name !! Explanation
|-
| Transform || Decomposed (this means rotation, translation and scale are decomposed)
|-
| Triangulate || leave no uncertain surfaces unresolved by blender.
|-
| Apply Transforms || Viewport (it is usually safe to assume this is true)
|-
| Selection Only || we rarely need everything from the file - watch for proper parent-children chains!
|-
| Include children || if parenting is properly laid out - this works miracles!
|-
| Use Object Instances || don't use this - i tried it once and it was ''ugly''
|-
| Use Blender Profile || this is best left off - always leave it off for Cryengine export.
|}

== Converting the format ==
=== Prepare your Linux ===
For this to work at all some prerequisites are to be met. You didn't think you'll get off
the hook as easy, didn't you? 
We need working '''ColladaCGF''' in '''wine''', for this we need working '''PyFFI''' in '''wine''', and for this we need working '''Python''' in '''wine''' in the first place.
For this all to work at all certain versions are to be downloaded and fed to '''wine''': 
* Python 2.6.6 (or earlier, but ideally ''exactly'' 2.6.6 (32bit release only)
* PyFFI 2.1.11 (the last one that works with 2.x python, newer ones require python 3.x)
* ColladaCGF 0.3.9 (the last one available)

For this to work you will need your '''Linux''' to be either "''multilib''" (more likely applies to you) or 32bit (less likely but possible)

Install In that exact order (Python, PyFFI, Collada). 
The very installation process:
# Locate the repositories
# Download the corresponding versions and to what place locally
# Point a file manager or ''explorer'' inside of wine to the downloaded files in order to install them
Is left as an exercise to the reader as the web locations are documented in another article on this wiki. 

To make certain they are in the right wine prefix check that both files: 
"C:\Python26\python.exe"
and
"C:\Python26\Scripts\colladacgf.py"
should be present.

Now if you are not using '''XFCE4''' as your GUI, ''too bad you're just out of luck''. Otherwise open the Custom Actions chooser via the Edit menu of '''Thunar''' and make a new custom action:

[[File:Step04.png|200px|thumb|center|Custom Actions setup with Thunar and XFCE4]]

I named the action [ ColladaCGF ] and gave it the default python icon. The description should be obvious: [ Convert a dae file into cgf ]. The command that worked for me was:

[ wineconsole "C:\Python26\python.exe" "C:\Python26\Scripts\colladacgf.py" %F --pause ]

where %F is a list of selected files with the full path.

The filters on the other tab are to be set accordingly: 
[ *.dae;*.DAE ]

mind the semicolon. And the affected files are the ''text files'' (since '''.dae''' files look like '''XML''' files) and ''other files'', just in case. Never mind this impossible screenshot - it is CGI - so you have it all on one place for '''''maximum convenience'''''.

Apply, close and restart '''Thunar'''. Now on You should have a context option for each '''.dae''' file:

[[File:Step05.png|200px|thumb|center|ColladaCGF usage in XFCE on Linux]]

=== Point the ColladaCGF to the .dae file ===
The '''.dae''' file is to be selected, '''rightclick > ColladaCGF''' and voila! by ''automagic'' a bunch of murr-murr and computer speak will fill a dark frame, once you notice the computer has stopped spewing insults and dark magic, there might be a blinking cursor waiting no you to press ['''enter'''] key and close the window. You might have just converted your first '''CGF''' file on Linux. Or you will be in due time. Conversions often fail due to not adhering to the ''convention'' mentioned earlier.

=== Find the cgf file ===
The newly generated '''.CGF''' file and it's belonging '''.MTL''' file should lay next to each other and next to the source '''.DAE''' file. There might be leftovers in the form of logs and dumps. This can be
safely ignored, they can safely be deleted too.

== Importing into engine on Linux ==
I assume Your Linux has ''multilib'' capability here on. I assume You understand what that means and know where to ask for details for Your distro of choice.

=== How to get the editor working (Glitch TKG's github) ===
I see not too many casualties to this point. Good; good, here onward it gets tough as nails, and by that i mean eating chains to fart back nails!.

https://github.com/Tk-Glitch (kudos to Tk-Glitch o/ )

https://github.com/Tk-Glitch/PKGBUILDS/wiki/wine-tkg-git#dependencies

You want to build a not only custom version of wine (as if that wasn't intimidating enough!).

No sir, you want a highly customized, overly patched VERY recent version wine-staging that has support for child-window our '''Sandbox2''' editor uses to render the game within it's app window.

No configuration files need to be modified in the [wine-tkg-git] directory, You merely cd to it and run [./non-makepkg-build.sh]

first time you will be dropped to a shell with info and stuff...

make the following file:

file: ['''~/.config/frogminer/wine-tkg.cfg''']:
<pre>

_LOCAL_PRESET="none"
_use_GE_patches="true"
_plain_version=""
_use_staging="true"
_staging_version="v7.22"
_use_fastsync="false"
_use_esync="true"
_use_fsync="true"
_fsync_futex_waitv="true"
_use_vkd3dlib="true"
_dxvk_dxgi="true"

_proton_battleye_support="false"
_proton_eac_support="false"
_warframelauncher_fix="false"
_mwo_fix="false"
_re4_fix="false"

_childwindow_fix="true"

_use_josh_flat_theme="true"

</pre>

And once saved, re-run the above command. Install the new '''wine''' and make MWLL run in it's prefix.

to run the editor you will need few more '''winetricks'''... 
Fended off yet? no? Good, because that isn't nearly the end of the desert :D. 
add (via winetricks) the following: 
#d3dcompiler_43
#d3dcompiler_47
#dotnet472 (needed for the launcher anyway (will pull in much down to dotnet40) )
#dxvk (i have dxvk1101 so far)
#vcrun2005 (MWLL needs it won't run w/o)
#(add the two redists from the MWLL package, 32bit ones)
Now on the editor should launch: 
(note there is no newline at the top of the file)

file: ['''~/.local/bin/MWLLeditor.sh''']:
<pre>
#! /bin/bash

v=0.10-beta
#executable=Crysis.exe
executable=Editor.exe
shaderspath=~/Documents/My\ Games/Crysis\ Wars/Shaders

i=${1:-3}

if [ "X"$i != "X" ] ; then
pass=$i
echo $i
fi

if (( $pass > 3 )) || (( $pass < 1 )); then
echo " uasge:"
echo $0 "{1|2|3}"
echo "1 = winecfg, 2 = winetricks, 3 = editor"
exit 2
fi

echo $pass

# switch comment whats appropriate
# export WINEARCH=win32
# winegamepath='/drive_c/Program Files (x86)/Electronic Arts/Crytek/Crysis Wars/Bin32'
# windowsgamepath='C:\Program Files (x86)\Electronic Arts\Crytek\Crysis Wars\Bin32\'

export WINEARCH=win64
winegamepath='/drive_c/Program Files (x86)/Electronic Arts/Crytek/Crysis Wars/Bin64'
windowsgamepath='C:\Program Files (x86)\Electronic Arts\Crytek\Crysis Wars\Bin64\'

#here we do "magic" to run DX9 (only supported so far)
#and tell Crysis we want the MWLL mod not the OEM game :^)
OPT="-dx9 -mod MWLL"
#OPT="-mod MWLL"
#OPT="-dx9"

# reducing what wine spews at us
#export WINEDEBUG=-fixme-all,-warn-all,-err-all,-all
export WINEDEBUG=-all

WINEFSYNC=1
WINEESYNC=1
DXVK_HUD=1
DXVK_FILTER_DEVICE_NAME="NVIDIA GeForce GTX 1060 3GB"

# we controll which directory we want be runned by the script
export WINEPREFIX=~/.wine

#this can really beak things if enabled but try it?
# export MESA_DEBUG=1

# we the humans check here what renders our stuff
# if not "Gallium" then it's software = too slow
REND=$(glxinfo | grep "OpenGL renderer" | awk -F: '{print $2}' | awk -F"(" '{print $1}')
echo "Renderer:"$REND
echo "if the above is llvm and not an actual card the game will not work"

#cleaning leftovers from late dinner ;)
killall $executable
killall -9 $executable

#cleaning shader cache for better performance each time
#rm -r "${shaderspath}/*"

#here I cleverly avoid calling the path with my user name :)
cd "${WINEPREFIX}${winegamepath}/${binpath}"
#here i cleverly ask to show the path so we see what WINEPREFIX was called
pwd

case $WINEARCH in
win64)
echo 64bit
case $pass in
1)
winecfg
;;
2)
winetricks
;;
3)
wine64 "${windowsgamepath}${executable}" $OPT # 2>/dev/null # &> MWLL_debug.log
#if uncommented, the last line's comment dumps a log file to the game folder - might prove usefull or a vaste of disk space
;;
esac
;;
win32)
echo 32bit
case $pass in
1)
winecfg
;;
2)
winetricks
;;
3)
#here (hopefully) no shit hits the fan, and we land in game menu
wine ${windowsgamepath}${executable} $OPT # &> MWLL_debug.log
#if uncommented, the last line's comment dumps a log file to the game folder - might prove usefull or a vaste of disk space
;;
esac
;;
esac
# to restore resolution put here what's appropriate or leave as is and just uncomment
xrandr -s 0 # last good resolution

</pre>

This should have you all set.

=== Run the editor ===
You can now start the file by typing ['''MWLLeditor.sh'''] in a command prompt and pressing enter.
Pick a map (['''TC_Reference'''] comes to mind) and try add an ''brush''. Here on is uncharted territory, keep me posted!

=== What breaks in the editor and how to work around it ===

''TODO''

AlienArt

2023-03-05T14:43:55Z

Fire-hound: /* Point the ColladaCGF to the .dae file */

By Alien it's meant as totally new, possibly even strange art in respect of what's present in the Asset Pool. 
In effect successfully following this procedure will hopefully lead to gradual expansion and enrichment of the aforementioned Asset pool. 

The process:

== Preparing The geometry ==
=== now with blender 3.x ===
This is a procedure covering the ever growing technology gap between the free and ever livid blender and the aging cryengine2. 
Just get any blender past 3.x release.

=== Get it ready ===
[[File:Step01.png|200px|thumb|center|Prepare Collection]]

For a Mesh to be fit for cryengine it has to fulfill several criteria due to how some compromises were made. 
It is a ''convention'' and if one sticks to it good results will ensue. 
# No more than two triangles should share same edge.
# There should be nothing but triangles (or quads) as the final result - remove all and any nodes and or lines (''primitives'')...
# There should be no triangles of surfaces of size zero (degenerate faces).
# It is desirable for the mesh be airtight, but there are valid exceptions.

The Object is to be investigated for the quality and errors for UV mapping. 
Only a single UV map per mesh is supported in Cryengine 

The Object is to be assigned To a ''Collection'' (no more ''Groups'' in blender 3.x) that shares the same name 
The '''.blend''' file is to be saved with the same name, so that it shares (again) the same name as the object and collection. 

We should now be ready for the export to collada ('''.dae''' file) 

[[File:Step02.png|200px|thumb|center|Prepare Export]]

=== Export settings ===
[[File:Step03.png|200px|thumb|center|Collada export options]]

As seen on the image the favorable settings differ from defaults. It is therefore advisable to
create a operator preset (i aptly named "cryengine export") for further convenience.

{| class="wikitable" style="margin:auto"
|+ Parameter Meaning
|-
! Parameter name !! Explanation
|-
| Transform || Decomposed (this means rotation, translation and scale are decomposed)
|-
| Triangulate || leave no uncertain surfaces unresolved by blender.
|-
| Apply Transforms || Viewport (it is usually safe to assume this is true)
|-
| Selection Only || we rarely need everything from the file - watch for proper parent-children chains!
|-
| Include children || if parenting is properly laid out - this works miracles!
|-
| Use Object Instances || don't use this - i tried it once and it was ''ugly''
|-
| Use Blender Profile || this is best left off - always leave it off for Cryengine export.
|}

== Converting the format ==
=== Prepare your Linux ===
For this to work at all some prerequisites are to be met. You didn't think you'll get off
the hook as easy, didn't you? 
We need working '''ColladaCGF''' in '''wine''', for this we need working '''PyFFI''' in '''wine''', and for this we need working '''Python''' in '''wine''' in the first place.
For this all to work at all certain versions are to be downloaded and fed to '''wine''': 
* Python 2.6.6 (or earlier, but ideally ''exactly'' 2.6.6 (32bit release only)
* PyFFI 2.1.11 (the last one that works with 2.x python, newer ones require python 3.x)
* ColladaCGF 0.3.9 (the last one available)

For this to work you will need your '''Linux''' to be either "''multilib''" (more likely applies to you) or 32bit (less likely but possible)

Install In that exact order (Python, PyFFI, Collada). 
The very installation process:
# Locate the repositories
# Download the corresponding versions and to what place locally
# Point a file manager or ''explorer'' inside of wine to the downloaded files in order to install them
Is left as an exercise to the reader as the web locations are documented in another article on this wiki. 

To make certain they are in the right wine prefix check that both files: 
"C:\Python26\python.exe"
and
"C:\Python26\Scripts\colladacgf.py"
should be present.

Now if you are not using '''XFCE4''' as your GUI, ''too bad you're just out of luck''. Otherwise open the Custom Actions chooser via the Edit menu of '''Thunar''' and make a new custom action:

[[File:Step04.png|200px|thumb|center|Custom Actions setup with Thunar and XFCE4]]

I named the action [ ColladaCGF ] and gave it the default python icon. The description should be obvious: [ Convert a dae file into cgf ]. The command that worked for me was:

[ wineconsole "C:\Python26\python.exe" "C:\Python26\Scripts\colladacgf.py" %F --pause ]

where %F is a list of selected files with the full path.

The filters on the other tab are to be set accordingly: 
[ *.dae;*.DAE ]

mind the semicolon. And the affected files are the ''text files'' (since '''.dae''' files look like '''XML''' files) and ''other files'', just in case. Never mind this impossible screenshot - it is CGI - so you have it all on one place for '''''maximum convenience'''''.

Apply, close and restart '''Thunar'''. Now on You should have a context option for each '''.dae''' file:

[[File:Step05.png|200px|thumb|center|ColladaCGF usage in XFCE on Linux]]

=== Point the ColladaCGF to the .dae file ===
The '''.dae''' file is to be selected, '''rightclick > ColladaCGF''' and voila! by ''automagic'' a bunch of murr-murr and computer speak will fill a dark frame, once you notice the computer has stopped spewing insults and dark magic, there might be a blinking cursor waiting no you to press ['''enter'''] key and close the window. You might have just converted your first '''CGF''' file on Linux. Or you will be in due time. Conversions often fail due to not adhering to the ''convention'' mentioned earlier.

=== Find the cgf file ===
The newly generated '''.CGF''' file and it's belonging '''.MTL''' file should lay next to each other and next to the source '''.DAE''' file. There might be leftovers in the form of logs and dumps. This can be
safely ignored, they can safely be deleted too.

== Importing into engine on Linux ==
I assume Your Linux has ''multilib'' capability here on. I assume You understand what that means and know where to ask for details for Your distro of choice.

=== How to get the editor working (Glitch TKG's github) ===
I see not too many casualties to this point. Good; good, here onward it gets tough as nails, and by that i mean eating chains to fart back nails!.

https://github.com/Tk-Glitch (kudos to Tk-Glitch o/ )

https://github.com/Tk-Glitch/PKGBUILDS/wiki/wine-tkg-git#dependencies

You want to build a not only custom version of wine (as if that wasn't intimidating enough!).

No sir, you want a higly customized, overly patched VERY recent version wine-staging that has support for child-window our Sandbox2 editor uses to render the game withing it's app window.

No configuration files need to be modified in the [wine-tkg-git] directory, You merely cd to it and run [./non-makepkg-build.sh]

first time you will be dropped to a shell with info and stuff...

make the following file:

file: ['''~/.config/frogminer/wine-tkg.cfg''']:
<pre>

_LOCAL_PRESET="none"
_use_GE_patches="true"
_plain_version=""
_use_staging="true"
_staging_version="v7.22"
_use_fastsync="false"
_use_esync="true"
_use_fsync="true"
_fsync_futex_waitv="true"
_use_vkd3dlib="true"
_dxvk_dxgi="true"

_proton_battleye_support="false"
_proton_eac_support="false"
_warframelauncher_fix="false"
_mwo_fix="false"
_re4_fix="false"

_childwindow_fix="true"

_use_josh_flat_theme="true"

</pre>

And once saved, rerun the above command. Install the new wine and make MWLL run in it's prefix.

to run the editor you will need few more winetricks...
Fended off yet? no? Good, because that isn't nearly the end of the desert :D.
add (via winetricks) the following:
#d3dcompiler_43
#d3dcompiler_47
#dotnet472 (needed for the launcher anyway (will pull in much down to dotnet40) )
#dxvk (i have dxvk1101 so far)
#vcrun2005 (MWLL needs it won't run w/o)
#(add the two redists from the MWLL package, 32bit ones)
Now on the editor should launch:
(note there is no newline at the top of the file)

file: ['''~/.local/bin/MWLLeditor.sh''']:
<pre>
#! /bin/bash

v=0.10-beta
#executable=Crysis.exe
executable=Editor.exe
shaderspath=~/Documents/My\ Games/Crysis\ Wars/Shaders

i=${1:-3}

if [ "X"$i != "X" ] ; then
pass=$i
echo $i
fi

if (( $pass > 3 )) || (( $pass < 1 )); then
echo " uasge:"
echo $0 "{1|2|3}"
echo "1 = winecfg, 2 = winetricks, 3 = editor"
exit 2
fi

echo $pass

# switch comment whats appropriate
# export WINEARCH=win32
# winegamepath='/drive_c/Program Files (x86)/Electronic Arts/Crytek/Crysis Wars/Bin32'
# windowsgamepath='C:\Program Files (x86)\Electronic Arts\Crytek\Crysis Wars\Bin32\'

export WINEARCH=win64
winegamepath='/drive_c/Program Files (x86)/Electronic Arts/Crytek/Crysis Wars/Bin64'
windowsgamepath='C:\Program Files (x86)\Electronic Arts\Crytek\Crysis Wars\Bin64\'

#here we do "magic" to run DX9 (only supported so far)
#and tell Crysis we want the MWLL mod not the OEM game :^)
OPT="-dx9 -mod MWLL"
#OPT="-mod MWLL"
#OPT="-dx9"

# reducing what wine spews at us
#export WINEDEBUG=-fixme-all,-warn-all,-err-all,-all
export WINEDEBUG=-all

WINEFSYNC=1
WINEESYNC=1
DXVK_HUD=1
DXVK_FILTER_DEVICE_NAME="NVIDIA GeForce GTX 1060 3GB"

# we controll which directory we want be runned by the script
export WINEPREFIX=~/.wine

#this can really beak things if enabled but try it?
# export MESA_DEBUG=1

# we the humans check here what renders our stuff
# if not "Gallium" then it's software = too slow
REND=$(glxinfo | grep "OpenGL renderer" | awk -F: '{print $2}' | awk -F"(" '{print $1}')
echo "Renderer:"$REND
echo "if the above is llvm and not an actual card the game will not work"

#cleaning leftovers from late dinner ;)
killall $executable
killall -9 $executable

#cleaning shader cache for better performance each time
#rm -r "${shaderspath}/*"

#here I cleverly avoid calling the path with my user name :)
cd "${WINEPREFIX}${winegamepath}/${binpath}"
#here i cleverly ask to show the path so we see what WINEPREFIX was called
pwd

case $WINEARCH in
win64)
echo 64bit
case $pass in
1)
winecfg
;;
2)
winetricks
;;
3)
wine64 "${windowsgamepath}${executable}" $OPT # 2>/dev/null # &> MWLL_debug.log
#if uncommented, the last line's comment dumps a log file to the game folder - might prove usefull or a vaste of disk space
;;
esac
;;
win32)
echo 32bit
case $pass in
1)
winecfg
;;
2)
winetricks
;;
3)
#here (hopefully) no shit hits the fan, and we land in game menu
wine ${windowsgamepath}${executable} $OPT # &> MWLL_debug.log
#if uncommented, the last line's comment dumps a log file to the game folder - might prove usefull or a vaste of disk space
;;
esac
;;
esac
# to restore resolution put here what's appropriate or leave as is and just uncomment
xrandr -s 0 # last good resolution

</pre>

This should have you all set.

=== Run the editor ===
You can now start the file by typing ['''MWLLeditor.sh'''] in a command prompt and pressing enter.
Pick a map (['''TC_Reference'''] comes to mind) and try add an ''brush''. Here on is uncharted territory, keep me posted!

=== What breaks in the editor and how to work around it ===

''TODO''

AlienArt

2023-03-05T14:42:29Z

Fire-hound: /* Prepare your Linux */

By Alien it's meant as totally new, possibly even strange art in respect of what's present in the Asset Pool. 
In effect successfully following this procedure will hopefully lead to gradual expansion and enrichment of the aforementioned Asset pool. 

The process:

== Preparing The geometry ==
=== now with blender 3.x ===
This is a procedure covering the ever growing technology gap between the free and ever livid blender and the aging cryengine2. 
Just get any blender past 3.x release.

=== Get it ready ===
[[File:Step01.png|200px|thumb|center|Prepare Collection]]

For a Mesh to be fit for cryengine it has to fulfill several criteria due to how some compromises were made. 
It is a ''convention'' and if one sticks to it good results will ensue. 
# No more than two triangles should share same edge.
# There should be nothing but triangles (or quads) as the final result - remove all and any nodes and or lines (''primitives'')...
# There should be no triangles of surfaces of size zero (degenerate faces).
# It is desirable for the mesh be airtight, but there are valid exceptions.

The Object is to be investigated for the quality and errors for UV mapping. 
Only a single UV map per mesh is supported in Cryengine 

The Object is to be assigned To a ''Collection'' (no more ''Groups'' in blender 3.x) that shares the same name 
The '''.blend''' file is to be saved with the same name, so that it shares (again) the same name as the object and collection. 

We should now be ready for the export to collada ('''.dae''' file) 

[[File:Step02.png|200px|thumb|center|Prepare Export]]

=== Export settings ===
[[File:Step03.png|200px|thumb|center|Collada export options]]

As seen on the image the favorable settings differ from defaults. It is therefore advisable to
create a operator preset (i aptly named "cryengine export") for further convenience.

{| class="wikitable" style="margin:auto"
|+ Parameter Meaning
|-
! Parameter name !! Explanation
|-
| Transform || Decomposed (this means rotation, translation and scale are decomposed)
|-
| Triangulate || leave no uncertain surfaces unresolved by blender.
|-
| Apply Transforms || Viewport (it is usually safe to assume this is true)
|-
| Selection Only || we rarely need everything from the file - watch for proper parent-children chains!
|-
| Include children || if parenting is properly laid out - this works miracles!
|-
| Use Object Instances || don't use this - i tried it once and it was ''ugly''
|-
| Use Blender Profile || this is best left off - always leave it off for Cryengine export.
|}

== Converting the format ==
=== Prepare your Linux ===
For this to work at all some prerequisites are to be met. You didn't think you'll get off
the hook as easy, didn't you? 
We need working '''ColladaCGF''' in '''wine''', for this we need working '''PyFFI''' in '''wine''', and for this we need working '''Python''' in '''wine''' in the first place.
For this all to work at all certain versions are to be downloaded and fed to '''wine''': 
* Python 2.6.6 (or earlier, but ideally ''exactly'' 2.6.6 (32bit release only)
* PyFFI 2.1.11 (the last one that works with 2.x python, newer ones require python 3.x)
* ColladaCGF 0.3.9 (the last one available)

For this to work you will need your '''Linux''' to be either "''multilib''" (more likely applies to you) or 32bit (less likely but possible)

Install In that exact order (Python, PyFFI, Collada). 
The very installation process:
# Locate the repositories
# Download the corresponding versions and to what place locally
# Point a file manager or ''explorer'' inside of wine to the downloaded files in order to install them
Is left as an exercise to the reader as the web locations are documented in another article on this wiki. 

To make certain they are in the right wine prefix check that both files: 
"C:\Python26\python.exe"
and
"C:\Python26\Scripts\colladacgf.py"
should be present.

Now if you are not using '''XFCE4''' as your GUI, ''too bad you're just out of luck''. Otherwise open the Custom Actions chooser via the Edit menu of '''Thunar''' and make a new custom action:

[[File:Step04.png|200px|thumb|center|Custom Actions setup with Thunar and XFCE4]]

I named the action [ ColladaCGF ] and gave it the default python icon. The description should be obvious: [ Convert a dae file into cgf ]. The command that worked for me was:

[ wineconsole "C:\Python26\python.exe" "C:\Python26\Scripts\colladacgf.py" %F --pause ]

where %F is a list of selected files with the full path.

The filters on the other tab are to be set accordingly: 
[ *.dae;*.DAE ]

mind the semicolon. And the affected files are the ''text files'' (since '''.dae''' files look like '''XML''' files) and ''other files'', just in case. Never mind this impossible screenshot - it is CGI - so you have it all on one place for '''''maximum convenience'''''.

Apply, close and restart '''Thunar'''. Now on You should have a context option for each '''.dae''' file:

[[File:Step05.png|200px|thumb|center|ColladaCGF usage in XFCE on Linux]]

=== Point the ColladaCGF to the .dae file ===
The '''dae''' file is to be selected, '''rightclick > ColladaCGF''' and voila! by ''automagic'' a bunch of murr-murr and computer speak will fill a dark frame, once you notice the computer has stopped spewing insults and dark magic, there might be a blinking cursor waiting no you to press [enter] key and close the window. You might have just converted your first '''CGF''' file on Linux. Or you will be in due time. Conversions often fail due to not adhering to the convention mentioned above.

=== Find the cgf file ===
The newly generated '''.CGF''' file and it's belonging '''.MTL''' file should lay next to each other and next to the source '''.DAE''' file. There might be leftovers in the form of logs and dumps. This can be
safely ignored, they can safely be deleted too.

== Importing into engine on Linux ==
I assume Your Linux has ''multilib'' capability here on. I assume You understand what that means and know where to ask for details for Your distro of choice.

=== How to get the editor working (Glitch TKG's github) ===
I see not too many casualties to this point. Good; good, here onward it gets tough as nails, and by that i mean eating chains to fart back nails!.

https://github.com/Tk-Glitch (kudos to Tk-Glitch o/ )

https://github.com/Tk-Glitch/PKGBUILDS/wiki/wine-tkg-git#dependencies

You want to build a not only custom version of wine (as if that wasn't intimidating enough!).

No sir, you want a higly customized, overly patched VERY recent version wine-staging that has support for child-window our Sandbox2 editor uses to render the game withing it's app window.

No configuration files need to be modified in the [wine-tkg-git] directory, You merely cd to it and run [./non-makepkg-build.sh]

first time you will be dropped to a shell with info and stuff...

make the following file:

file: ['''~/.config/frogminer/wine-tkg.cfg''']:
<pre>

_LOCAL_PRESET="none"
_use_GE_patches="true"
_plain_version=""
_use_staging="true"
_staging_version="v7.22"
_use_fastsync="false"
_use_esync="true"
_use_fsync="true"
_fsync_futex_waitv="true"
_use_vkd3dlib="true"
_dxvk_dxgi="true"

_proton_battleye_support="false"
_proton_eac_support="false"
_warframelauncher_fix="false"
_mwo_fix="false"
_re4_fix="false"

_childwindow_fix="true"

_use_josh_flat_theme="true"

</pre>

And once saved, rerun the above command. Install the new wine and make MWLL run in it's prefix.

to run the editor you will need few more winetricks...
Fended off yet? no? Good, because that isn't nearly the end of the desert :D.
add (via winetricks) the following:
#d3dcompiler_43
#d3dcompiler_47
#dotnet472 (needed for the launcher anyway (will pull in much down to dotnet40) )
#dxvk (i have dxvk1101 so far)
#vcrun2005 (MWLL needs it won't run w/o)
#(add the two redists from the MWLL package, 32bit ones)
Now on the editor should launch:
(note there is no newline at the top of the file)

file: ['''~/.local/bin/MWLLeditor.sh''']:
<pre>
#! /bin/bash

v=0.10-beta
#executable=Crysis.exe
executable=Editor.exe
shaderspath=~/Documents/My\ Games/Crysis\ Wars/Shaders

i=${1:-3}

if [ "X"$i != "X" ] ; then
pass=$i
echo $i
fi

if (( $pass > 3 )) || (( $pass < 1 )); then
echo " uasge:"
echo $0 "{1|2|3}"
echo "1 = winecfg, 2 = winetricks, 3 = editor"
exit 2
fi

echo $pass

# switch comment whats appropriate
# export WINEARCH=win32
# winegamepath='/drive_c/Program Files (x86)/Electronic Arts/Crytek/Crysis Wars/Bin32'
# windowsgamepath='C:\Program Files (x86)\Electronic Arts\Crytek\Crysis Wars\Bin32\'

export WINEARCH=win64
winegamepath='/drive_c/Program Files (x86)/Electronic Arts/Crytek/Crysis Wars/Bin64'
windowsgamepath='C:\Program Files (x86)\Electronic Arts\Crytek\Crysis Wars\Bin64\'

#here we do "magic" to run DX9 (only supported so far)
#and tell Crysis we want the MWLL mod not the OEM game :^)
OPT="-dx9 -mod MWLL"
#OPT="-mod MWLL"
#OPT="-dx9"

# reducing what wine spews at us
#export WINEDEBUG=-fixme-all,-warn-all,-err-all,-all
export WINEDEBUG=-all

WINEFSYNC=1
WINEESYNC=1
DXVK_HUD=1
DXVK_FILTER_DEVICE_NAME="NVIDIA GeForce GTX 1060 3GB"

# we controll which directory we want be runned by the script
export WINEPREFIX=~/.wine

#this can really beak things if enabled but try it?
# export MESA_DEBUG=1

# we the humans check here what renders our stuff
# if not "Gallium" then it's software = too slow
REND=$(glxinfo | grep "OpenGL renderer" | awk -F: '{print $2}' | awk -F"(" '{print $1}')
echo "Renderer:"$REND
echo "if the above is llvm and not an actual card the game will not work"

#cleaning leftovers from late dinner ;)
killall $executable
killall -9 $executable

#cleaning shader cache for better performance each time
#rm -r "${shaderspath}/*"

#here I cleverly avoid calling the path with my user name :)
cd "${WINEPREFIX}${winegamepath}/${binpath}"
#here i cleverly ask to show the path so we see what WINEPREFIX was called
pwd

case $WINEARCH in
win64)
echo 64bit
case $pass in
1)
winecfg
;;
2)
winetricks
;;
3)
wine64 "${windowsgamepath}${executable}" $OPT # 2>/dev/null # &> MWLL_debug.log
#if uncommented, the last line's comment dumps a log file to the game folder - might prove usefull or a vaste of disk space
;;
esac
;;
win32)
echo 32bit
case $pass in
1)
winecfg
;;
2)
winetricks
;;
3)
#here (hopefully) no shit hits the fan, and we land in game menu
wine ${windowsgamepath}${executable} $OPT # &> MWLL_debug.log
#if uncommented, the last line's comment dumps a log file to the game folder - might prove usefull or a vaste of disk space
;;
esac
;;
esac
# to restore resolution put here what's appropriate or leave as is and just uncomment
xrandr -s 0 # last good resolution

</pre>

This should have you all set.

=== Run the editor ===
You can now start the file by typing ['''MWLLeditor.sh'''] in a command prompt and pressing enter.
Pick a map (['''TC_Reference'''] comes to mind) and try add an ''brush''. Here on is uncharted territory, keep me posted!

=== What breaks in the editor and how to work around it ===

''TODO''

AlienArt

2023-03-05T14:26:06Z

Fire-hound: /* Export settings */ clarifications and typos

By Alien it's meant as totally new, possibly even strange art in respect of what's present in the Asset Pool. 
In effect successfully following this procedure will hopefully lead to gradual expansion and enrichment of the aforementioned Asset pool. 

The process:

== Preparing The geometry ==
=== now with blender 3.x ===
This is a procedure covering the ever growing technology gap between the free and ever livid blender and the aging cryengine2. 
Just get any blender past 3.x release.

=== Get it ready ===
[[File:Step01.png|200px|thumb|center|Prepare Collection]]

For a Mesh to be fit for cryengine it has to fulfill several criteria due to how some compromises were made. 
It is a ''convention'' and if one sticks to it good results will ensue. 
# No more than two triangles should share same edge.
# There should be nothing but triangles (or quads) as the final result - remove all and any nodes and or lines (''primitives'')...
# There should be no triangles of surfaces of size zero (degenerate faces).
# It is desirable for the mesh be airtight, but there are valid exceptions.

The Object is to be investigated for the quality and errors for UV mapping. 
Only a single UV map per mesh is supported in Cryengine 

The Object is to be assigned To a ''Collection'' (no more ''Groups'' in blender 3.x) that shares the same name 
The '''.blend''' file is to be saved with the same name, so that it shares (again) the same name as the object and collection. 

We should now be ready for the export to collada ('''.dae''' file) 

[[File:Step02.png|200px|thumb|center|Prepare Export]]

=== Export settings ===
[[File:Step03.png|200px|thumb|center|Collada export options]]

As seen on the image the favorable settings differ from defaults. It is therefore advisable to
create a operator preset (i aptly named "cryengine export") for further convenience.

{| class="wikitable" style="margin:auto"
|+ Parameter Meaning
|-
! Parameter name !! Explanation
|-
| Transform || Decomposed (this means rotation, translation and scale are decomposed)
|-
| Triangulate || leave no uncertain surfaces unresolved by blender.
|-
| Apply Transforms || Viewport (it is usually safe to assume this is true)
|-
| Selection Only || we rarely need everything from the file - watch for proper parent-children chains!
|-
| Include children || if parenting is properly laid out - this works miracles!
|-
| Use Object Instances || don't use this - i tried it once and it was ''ugly''
|-
| Use Blender Profile || this is best left off - always leave it off for Cryengine export.
|}

== Converting the format ==
=== Prepare your Linux ===
For this to work at all some prerequisites are to be met. You didn't think you'll get off
the hook as easy, didn't you? 
# We need working ColladaCGF in wine, for this we need working PyFFI in wine, and for this we need working Python in wine in the first place. For this all to work at all certain versions are to be downloaded and fed to wine: 
* Python 2.6.6 (or ealrier, but idealy exactly 2.6.6 (32bit release only)
* PyFFI 2.1.11 (the last one that works with 2.x python, newer require python 3.x)
* ColladaCGF 0.3.9 (the last one available)

For this to work you will need your linux to be either "multilib" (more likely applies to you) or 32bit (less likely but possible)

Install In that order (Python, PyFFI, Collada) and see it is in the right wine prefix:

both files: 
"C:\Python26\python.exe"

and

"C:\Python26\Scripts\colladacgf.py"

should be present.

Now if you are not using XFCE4 as your GUI too bad you're just out of luck. Otherwise open the Custom Actions chooser via the Edit menu of Thunar and make a new custom action:

[[File:Step04.png|200px|thumb|center|Custom Actions setup with Thunar and XFCE4]]

I named the action [ ColladaCGF ] and gave it the usual python icon. The description should be obvious: [ Convert a dae file into cgf ]. The command that worked for me was:

[ wineconsole "C:\Python26\python.exe" "C:\Python26\Scripts\colladacgf.py" %F --pause ]

where %F is a list of selected files with the full path.

The filters on the other tab are to be set accordingly: 
[ *.dae;*.DAE ]

mind the semicolon. And the affected files are the text files (.dae files look like XML files) and other files, just in case. Never mind this crazy screenshot - it is CGI - so you have it all on one place.

Apply close and restart Thunar. Now on You should have a context option for each dae file:

[[File:Step05.png|200px|thumb|center|ColladaCGF usage in XFCE on Linux]]

=== Point the ColladaCGF to the .dae file ===
The '''dae''' file is to be selected, '''rightclick > ColladaCGF''' and voila! by ''automagic'' a bunch of murr-murr and computer speak will fill a dark frame, once you notice the computer has stopped spewing insults and dark magic, there might be a blinking cursor waiting no you to press [enter] key and close the window. You might have just converted your first '''CGF''' file on Linux. Or you will be in due time. Conversions often fail due to not adhering to the convention mentioned above.

=== Find the cgf file ===
The newly generated '''.CGF''' file and it's belonging '''.MTL''' file should lay next to each other and next to the source '''.DAE''' file. There might be leftovers in the form of logs and dumps. This can be
safely ignored, they can safely be deleted too.

== Importing into engine on Linux ==
I assume Your Linux has ''multilib'' capability here on. I assume You understand what that means and know where to ask for details for Your distro of choice.

=== How to get the editor working (Glitch TKG's github) ===
I see not too many casualties to this point. Good; good, here onward it gets tough as nails, and by that i mean eating chains to fart back nails!.

https://github.com/Tk-Glitch (kudos to Tk-Glitch o/ )

https://github.com/Tk-Glitch/PKGBUILDS/wiki/wine-tkg-git#dependencies

You want to build a not only custom version of wine (as if that wasn't intimidating enough!).

No sir, you want a higly customized, overly patched VERY recent version wine-staging that has support for child-window our Sandbox2 editor uses to render the game withing it's app window.

No configuration files need to be modified in the [wine-tkg-git] directory, You merely cd to it and run [./non-makepkg-build.sh]

first time you will be dropped to a shell with info and stuff...

make the following file:

file: ['''~/.config/frogminer/wine-tkg.cfg''']:
<pre>

_LOCAL_PRESET="none"
_use_GE_patches="true"
_plain_version=""
_use_staging="true"
_staging_version="v7.22"
_use_fastsync="false"
_use_esync="true"
_use_fsync="true"
_fsync_futex_waitv="true"
_use_vkd3dlib="true"
_dxvk_dxgi="true"

_proton_battleye_support="false"
_proton_eac_support="false"
_warframelauncher_fix="false"
_mwo_fix="false"
_re4_fix="false"

_childwindow_fix="true"

_use_josh_flat_theme="true"

</pre>

And once saved, rerun the above command. Install the new wine and make MWLL run in it's prefix.

to run the editor you will need few more winetricks...
Fended off yet? no? Good, because that isn't nearly the end of the desert :D.
add (via winetricks) the following:
#d3dcompiler_43
#d3dcompiler_47
#dotnet472 (needed for the launcher anyway (will pull in much down to dotnet40) )
#dxvk (i have dxvk1101 so far)
#vcrun2005 (MWLL needs it won't run w/o)
#(add the two redists from the MWLL package, 32bit ones)
Now on the editor should launch:
(note there is no newline at the top of the file)

file: ['''~/.local/bin/MWLLeditor.sh''']:
<pre>
#! /bin/bash

v=0.10-beta
#executable=Crysis.exe
executable=Editor.exe
shaderspath=~/Documents/My\ Games/Crysis\ Wars/Shaders

i=${1:-3}

if [ "X"$i != "X" ] ; then
pass=$i
echo $i
fi

if (( $pass > 3 )) || (( $pass < 1 )); then
echo " uasge:"
echo $0 "{1|2|3}"
echo "1 = winecfg, 2 = winetricks, 3 = editor"
exit 2
fi

echo $pass

# switch comment whats appropriate
# export WINEARCH=win32
# winegamepath='/drive_c/Program Files (x86)/Electronic Arts/Crytek/Crysis Wars/Bin32'
# windowsgamepath='C:\Program Files (x86)\Electronic Arts\Crytek\Crysis Wars\Bin32\'

export WINEARCH=win64
winegamepath='/drive_c/Program Files (x86)/Electronic Arts/Crytek/Crysis Wars/Bin64'
windowsgamepath='C:\Program Files (x86)\Electronic Arts\Crytek\Crysis Wars\Bin64\'

#here we do "magic" to run DX9 (only supported so far)
#and tell Crysis we want the MWLL mod not the OEM game :^)
OPT="-dx9 -mod MWLL"
#OPT="-mod MWLL"
#OPT="-dx9"

# reducing what wine spews at us
#export WINEDEBUG=-fixme-all,-warn-all,-err-all,-all
export WINEDEBUG=-all

WINEFSYNC=1
WINEESYNC=1
DXVK_HUD=1
DXVK_FILTER_DEVICE_NAME="NVIDIA GeForce GTX 1060 3GB"

# we controll which directory we want be runned by the script
export WINEPREFIX=~/.wine

#this can really beak things if enabled but try it?
# export MESA_DEBUG=1

# we the humans check here what renders our stuff
# if not "Gallium" then it's software = too slow
REND=$(glxinfo | grep "OpenGL renderer" | awk -F: '{print $2}' | awk -F"(" '{print $1}')
echo "Renderer:"$REND
echo "if the above is llvm and not an actual card the game will not work"

#cleaning leftovers from late dinner ;)
killall $executable
killall -9 $executable

#cleaning shader cache for better performance each time
#rm -r "${shaderspath}/*"

#here I cleverly avoid calling the path with my user name :)
cd "${WINEPREFIX}${winegamepath}/${binpath}"
#here i cleverly ask to show the path so we see what WINEPREFIX was called
pwd

case $WINEARCH in
win64)
echo 64bit
case $pass in
1)
winecfg
;;
2)
winetricks
;;
3)
wine64 "${windowsgamepath}${executable}" $OPT # 2>/dev/null # &> MWLL_debug.log
#if uncommented, the last line's comment dumps a log file to the game folder - might prove usefull or a vaste of disk space
;;
esac
;;
win32)
echo 32bit
case $pass in
1)
winecfg
;;
2)
winetricks
;;
3)
#here (hopefully) no shit hits the fan, and we land in game menu
wine ${windowsgamepath}${executable} $OPT # &> MWLL_debug.log
#if uncommented, the last line's comment dumps a log file to the game folder - might prove usefull or a vaste of disk space
;;
esac
;;
esac
# to restore resolution put here what's appropriate or leave as is and just uncomment
xrandr -s 0 # last good resolution

</pre>

This should have you all set.

=== Run the editor ===
You can now start the file by typing ['''MWLLeditor.sh'''] in a command prompt and pressing enter.
Pick a map (['''TC_Reference'''] comes to mind) and try add an ''brush''. Here on is uncharted territory, keep me posted!

=== What breaks in the editor and how to work around it ===

''TODO''

AlienArt

2023-03-05T14:22:59Z

Fire-hound: /* Get it ready */ emphasis and clarification

By Alien it's meant as totally new, possibly even strange art in respect of what's present in the Asset Pool. 
In effect successfully following this procedure will hopefully lead to gradual expansion and enrichment of the aforementioned Asset pool. 

The process:

== Preparing The geometry ==
=== now with blender 3.x ===
This is a procedure covering the ever growing technology gap between the free and ever livid blender and the aging cryengine2. 
Just get any blender past 3.x release.

=== Get it ready ===
[[File:Step01.png|200px|thumb|center|Prepare Collection]]

For a Mesh to be fit for cryengine it has to fulfill several criteria due to how some compromises were made. 
It is a ''convention'' and if one sticks to it good results will ensue. 
# No more than two triangles should share same edge.
# There should be nothing but triangles (or quads) as the final result - remove all and any nodes and or lines (''primitives'')...
# There should be no triangles of surfaces of size zero (degenerate faces).
# It is desirable for the mesh be airtight, but there are valid exceptions.

The Object is to be investigated for the quality and errors for UV mapping. 
Only a single UV map per mesh is supported in Cryengine 

The Object is to be assigned To a ''Collection'' (no more ''Groups'' in blender 3.x) that shares the same name 
The '''.blend''' file is to be saved with the same name, so that it shares (again) the same name as the object and collection. 

We should now be ready for the export to collada ('''.dae''' file) 

[[File:Step02.png|200px|thumb|center|Prepare Export]]

=== Export settings ===
[[File:Step03.png|200px|thumb|center|Collada export options]]

As seen on the image the favorable settings differ from defaults. It is therefore advisable to
create a operator preset (i aptly named "cryengine export") for further convenience.

{| class="wikitable" style="margin:auto"
|+ Parameter Meaning
|-
! Parameter name !! Explanation
|-
| Transform || Decomposed (this means rotation, translation and scale are decomposed)
|-
| Triangulate || leave no uncertain surfaces unresolved by blender.
|-
| Apply Transforms || Viewport (it is usually save to assume this is true)
|-
| Selection Only || we rarely need everything from the file - watch for proper parenting!
|-
| Include children || if parenting is properly laid out - this works miracles!
|-
| Use Object Instances || don't use this - i tried it once and it was ugly
|-
| Use Blender Profile || this is best left off - always leave it off for cryengine export.
|}

== Converting the format ==
=== Prepare your Linux ===
For this to work at all some prerequisites are to be met. You didn't think you'll get off
the hook as easy, didn't you? 
# We need working ColladaCGF in wine, for this we need working PyFFI in wine, and for this we need working Python in wine in the first place. For this all to work at all certain versions are to be downloaded and fed to wine: 
* Python 2.6.6 (or ealrier, but idealy exactly 2.6.6 (32bit release only)
* PyFFI 2.1.11 (the last one that works with 2.x python, newer require python 3.x)
* ColladaCGF 0.3.9 (the last one available)

For this to work you will need your linux to be either "multilib" (more likely applies to you) or 32bit (less likely but possible)

Install In that order (Python, PyFFI, Collada) and see it is in the right wine prefix:

both files: 
"C:\Python26\python.exe"

and

"C:\Python26\Scripts\colladacgf.py"

should be present.

Now if you are not using XFCE4 as your GUI too bad you're just out of luck. Otherwise open the Custom Actions chooser via the Edit menu of Thunar and make a new custom action:

[[File:Step04.png|200px|thumb|center|Custom Actions setup with Thunar and XFCE4]]

I named the action [ ColladaCGF ] and gave it the usual python icon. The description should be obvious: [ Convert a dae file into cgf ]. The command that worked for me was:

[ wineconsole "C:\Python26\python.exe" "C:\Python26\Scripts\colladacgf.py" %F --pause ]

where %F is a list of selected files with the full path.

The filters on the other tab are to be set accordingly: 
[ *.dae;*.DAE ]

mind the semicolon. And the affected files are the text files (.dae files look like XML files) and other files, just in case. Never mind this crazy screenshot - it is CGI - so you have it all on one place.

Apply close and restart Thunar. Now on You should have a context option for each dae file:

[[File:Step05.png|200px|thumb|center|ColladaCGF usage in XFCE on Linux]]

=== Point the ColladaCGF to the .dae file ===
The '''dae''' file is to be selected, '''rightclick > ColladaCGF''' and voila! by ''automagic'' a bunch of murr-murr and computer speak will fill a dark frame, once you notice the computer has stopped spewing insults and dark magic, there might be a blinking cursor waiting no you to press [enter] key and close the window. You might have just converted your first '''CGF''' file on Linux. Or you will be in due time. Conversions often fail due to not adhering to the convention mentioned above.

=== Find the cgf file ===
The newly generated '''.CGF''' file and it's belonging '''.MTL''' file should lay next to each other and next to the source '''.DAE''' file. There might be leftovers in the form of logs and dumps. This can be
safely ignored, they can safely be deleted too.

== Importing into engine on Linux ==
I assume Your Linux has ''multilib'' capability here on. I assume You understand what that means and know where to ask for details for Your distro of choice.

=== How to get the editor working (Glitch TKG's github) ===
I see not too many casualties to this point. Good; good, here onward it gets tough as nails, and by that i mean eating chains to fart back nails!.

https://github.com/Tk-Glitch (kudos to Tk-Glitch o/ )

https://github.com/Tk-Glitch/PKGBUILDS/wiki/wine-tkg-git#dependencies

You want to build a not only custom version of wine (as if that wasn't intimidating enough!).

No sir, you want a higly customized, overly patched VERY recent version wine-staging that has support for child-window our Sandbox2 editor uses to render the game withing it's app window.

No configuration files need to be modified in the [wine-tkg-git] directory, You merely cd to it and run [./non-makepkg-build.sh]

first time you will be dropped to a shell with info and stuff...

make the following file:

file: ['''~/.config/frogminer/wine-tkg.cfg''']:
<pre>

_LOCAL_PRESET="none"
_use_GE_patches="true"
_plain_version=""
_use_staging="true"
_staging_version="v7.22"
_use_fastsync="false"
_use_esync="true"
_use_fsync="true"
_fsync_futex_waitv="true"
_use_vkd3dlib="true"
_dxvk_dxgi="true"

_proton_battleye_support="false"
_proton_eac_support="false"
_warframelauncher_fix="false"
_mwo_fix="false"
_re4_fix="false"

_childwindow_fix="true"

_use_josh_flat_theme="true"

</pre>

And once saved, rerun the above command. Install the new wine and make MWLL run in it's prefix.

to run the editor you will need few more winetricks...
Fended off yet? no? Good, because that isn't nearly the end of the desert :D.
add (via winetricks) the following:
#d3dcompiler_43
#d3dcompiler_47
#dotnet472 (needed for the launcher anyway (will pull in much down to dotnet40) )
#dxvk (i have dxvk1101 so far)
#vcrun2005 (MWLL needs it won't run w/o)
#(add the two redists from the MWLL package, 32bit ones)
Now on the editor should launch:
(note there is no newline at the top of the file)

file: ['''~/.local/bin/MWLLeditor.sh''']:
<pre>
#! /bin/bash

v=0.10-beta
#executable=Crysis.exe
executable=Editor.exe
shaderspath=~/Documents/My\ Games/Crysis\ Wars/Shaders

i=${1:-3}

if [ "X"$i != "X" ] ; then
pass=$i
echo $i
fi

if (( $pass > 3 )) || (( $pass < 1 )); then
echo " uasge:"
echo $0 "{1|2|3}"
echo "1 = winecfg, 2 = winetricks, 3 = editor"
exit 2
fi

echo $pass

# switch comment whats appropriate
# export WINEARCH=win32
# winegamepath='/drive_c/Program Files (x86)/Electronic Arts/Crytek/Crysis Wars/Bin32'
# windowsgamepath='C:\Program Files (x86)\Electronic Arts\Crytek\Crysis Wars\Bin32\'

export WINEARCH=win64
winegamepath='/drive_c/Program Files (x86)/Electronic Arts/Crytek/Crysis Wars/Bin64'
windowsgamepath='C:\Program Files (x86)\Electronic Arts\Crytek\Crysis Wars\Bin64\'

#here we do "magic" to run DX9 (only supported so far)
#and tell Crysis we want the MWLL mod not the OEM game :^)
OPT="-dx9 -mod MWLL"
#OPT="-mod MWLL"
#OPT="-dx9"

# reducing what wine spews at us
#export WINEDEBUG=-fixme-all,-warn-all,-err-all,-all
export WINEDEBUG=-all

WINEFSYNC=1
WINEESYNC=1
DXVK_HUD=1
DXVK_FILTER_DEVICE_NAME="NVIDIA GeForce GTX 1060 3GB"

# we controll which directory we want be runned by the script
export WINEPREFIX=~/.wine

#this can really beak things if enabled but try it?
# export MESA_DEBUG=1

# we the humans check here what renders our stuff
# if not "Gallium" then it's software = too slow
REND=$(glxinfo | grep "OpenGL renderer" | awk -F: '{print $2}' | awk -F"(" '{print $1}')
echo "Renderer:"$REND
echo "if the above is llvm and not an actual card the game will not work"

#cleaning leftovers from late dinner ;)
killall $executable
killall -9 $executable

#cleaning shader cache for better performance each time
#rm -r "${shaderspath}/*"

#here I cleverly avoid calling the path with my user name :)
cd "${WINEPREFIX}${winegamepath}/${binpath}"
#here i cleverly ask to show the path so we see what WINEPREFIX was called
pwd

case $WINEARCH in
win64)
echo 64bit
case $pass in
1)
winecfg
;;
2)
winetricks
;;
3)
wine64 "${windowsgamepath}${executable}" $OPT # 2>/dev/null # &> MWLL_debug.log
#if uncommented, the last line's comment dumps a log file to the game folder - might prove usefull or a vaste of disk space
;;
esac
;;
win32)
echo 32bit
case $pass in
1)
winecfg
;;
2)
winetricks
;;
3)
#here (hopefully) no shit hits the fan, and we land in game menu
wine ${windowsgamepath}${executable} $OPT # &> MWLL_debug.log
#if uncommented, the last line's comment dumps a log file to the game folder - might prove usefull or a vaste of disk space
;;
esac
;;
esac
# to restore resolution put here what's appropriate or leave as is and just uncomment
xrandr -s 0 # last good resolution

</pre>

This should have you all set.

=== Run the editor ===
You can now start the file by typing ['''MWLLeditor.sh'''] in a command prompt and pressing enter.
Pick a map (['''TC_Reference'''] comes to mind) and try add an ''brush''. Here on is uncharted territory, keep me posted!

=== What breaks in the editor and how to work around it ===

''TODO''

AlienArt

2023-03-05T14:18:15Z

Fire-hound: /* now with blender 3.x */

By Alien it's meant as totally new, possibly even strange art in respect of what's present in the Asset Pool. 
In effect successfully following this procedure will hopefully lead to gradual expansion and enrichment of the aforementioned Asset pool. 

The process:

== Preparing The geometry ==
=== now with blender 3.x ===
This is a procedure covering the ever growing technology gap between the free and ever livid blender and the aging cryengine2. 
Just get any blender past 3.x release.

=== Get it ready ===
[[File:Step01.png|200px|thumb|center|Prepare Collection]]

For a Mesh to be fit for cryengine it has to fulfill several criteria due to how compromises were made. 
It is a convention and if one sticks to it good results won't fail to materialize. 
# No more than two triangles should share same edge.
# There should be nothing but triangles (or quads) as the final result - remove all and any nodes and or lines (primitives)...
# There shoudl be no triangles of surface size zero (degenerate faces).
# It is desirable for the mesh be airtight, but there are valid exceptions.

The Object is to be investigated for the quality and errors for UV mapping. 
Only a single UV map per mesh is supported in Cryengine 

The Object is to be assigned To a Collection (no more Groups in blender 3.x) that has the same name 
The .blend file is to be saved with the same name as the object and collection. 

We should now be ready for the export to collada (.dae file) 

[[File:Step02.png|200px|thumb|center|Prepare Export]]

=== Export settings ===
[[File:Step03.png|200px|thumb|center|Collada export options]]

As seen on the image the favorable settings differ from defaults. It is therefore advisable to
create a operator preset (i aptly named "cryengine export") for further convenience.

{| class="wikitable" style="margin:auto"
|+ Parameter Meaning
|-
! Parameter name !! Explanation
|-
| Transform || Decomposed (this means rotation, translation and scale are decomposed)
|-
| Triangulate || leave no uncertain surfaces unresolved by blender.
|-
| Apply Transforms || Viewport (it is usually save to assume this is true)
|-
| Selection Only || we rarely need everything from the file - watch for proper parenting!
|-
| Include children || if parenting is properly laid out - this works miracles!
|-
| Use Object Instances || don't use this - i tried it once and it was ugly
|-
| Use Blender Profile || this is best left off - always leave it off for cryengine export.
|}

== Converting the format ==
=== Prepare your Linux ===
For this to work at all some prerequisites are to be met. You didn't think you'll get off
the hook as easy, didn't you? 
# We need working ColladaCGF in wine, for this we need working PyFFI in wine, and for this we need working Python in wine in the first place. For this all to work at all certain versions are to be downloaded and fed to wine: 
* Python 2.6.6 (or ealrier, but idealy exactly 2.6.6 (32bit release only)
* PyFFI 2.1.11 (the last one that works with 2.x python, newer require python 3.x)
* ColladaCGF 0.3.9 (the last one available)

For this to work you will need your linux to be either "multilib" (more likely applies to you) or 32bit (less likely but possible)

Install In that order (Python, PyFFI, Collada) and see it is in the right wine prefix:

both files: 
"C:\Python26\python.exe"

and

"C:\Python26\Scripts\colladacgf.py"

should be present.

Now if you are not using XFCE4 as your GUI too bad you're just out of luck. Otherwise open the Custom Actions chooser via the Edit menu of Thunar and make a new custom action:

[[File:Step04.png|200px|thumb|center|Custom Actions setup with Thunar and XFCE4]]

I named the action [ ColladaCGF ] and gave it the usual python icon. The description should be obvious: [ Convert a dae file into cgf ]. The command that worked for me was:

[ wineconsole "C:\Python26\python.exe" "C:\Python26\Scripts\colladacgf.py" %F --pause ]

where %F is a list of selected files with the full path.

The filters on the other tab are to be set accordingly: 
[ *.dae;*.DAE ]

mind the semicolon. And the affected files are the text files (.dae files look like XML files) and other files, just in case. Never mind this crazy screenshot - it is CGI - so you have it all on one place.

Apply close and restart Thunar. Now on You should have a context option for each dae file:

[[File:Step05.png|200px|thumb|center|ColladaCGF usage in XFCE on Linux]]

=== Point the ColladaCGF to the .dae file ===
The '''dae''' file is to be selected, '''rightclick > ColladaCGF''' and voila! by ''automagic'' a bunch of murr-murr and computer speak will fill a dark frame, once you notice the computer has stopped spewing insults and dark magic, there might be a blinking cursor waiting no you to press [enter] key and close the window. You might have just converted your first '''CGF''' file on Linux. Or you will be in due time. Conversions often fail due to not adhering to the convention mentioned above.

=== Find the cgf file ===
The newly generated '''.CGF''' file and it's belonging '''.MTL''' file should lay next to each other and next to the source '''.DAE''' file. There might be leftovers in the form of logs and dumps. This can be
safely ignored, they can safely be deleted too.

== Importing into engine on Linux ==
I assume Your Linux has ''multilib'' capability here on. I assume You understand what that means and know where to ask for details for Your distro of choice.

=== How to get the editor working (Glitch TKG's github) ===
I see not too many casualties to this point. Good; good, here onward it gets tough as nails, and by that i mean eating chains to fart back nails!.

https://github.com/Tk-Glitch (kudos to Tk-Glitch o/ )

https://github.com/Tk-Glitch/PKGBUILDS/wiki/wine-tkg-git#dependencies

You want to build a not only custom version of wine (as if that wasn't intimidating enough!).

No sir, you want a higly customized, overly patched VERY recent version wine-staging that has support for child-window our Sandbox2 editor uses to render the game withing it's app window.

No configuration files need to be modified in the [wine-tkg-git] directory, You merely cd to it and run [./non-makepkg-build.sh]

first time you will be dropped to a shell with info and stuff...

make the following file:

file: ['''~/.config/frogminer/wine-tkg.cfg''']:
<pre>

_LOCAL_PRESET="none"
_use_GE_patches="true"
_plain_version=""
_use_staging="true"
_staging_version="v7.22"
_use_fastsync="false"
_use_esync="true"
_use_fsync="true"
_fsync_futex_waitv="true"
_use_vkd3dlib="true"
_dxvk_dxgi="true"

_proton_battleye_support="false"
_proton_eac_support="false"
_warframelauncher_fix="false"
_mwo_fix="false"
_re4_fix="false"

_childwindow_fix="true"

_use_josh_flat_theme="true"

</pre>

And once saved, rerun the above command. Install the new wine and make MWLL run in it's prefix.

to run the editor you will need few more winetricks...
Fended off yet? no? Good, because that isn't nearly the end of the desert :D.
add (via winetricks) the following:
#d3dcompiler_43
#d3dcompiler_47
#dotnet472 (needed for the launcher anyway (will pull in much down to dotnet40) )
#dxvk (i have dxvk1101 so far)
#vcrun2005 (MWLL needs it won't run w/o)
#(add the two redists from the MWLL package, 32bit ones)
Now on the editor should launch:
(note there is no newline at the top of the file)

file: ['''~/.local/bin/MWLLeditor.sh''']:
<pre>
#! /bin/bash

v=0.10-beta
#executable=Crysis.exe
executable=Editor.exe
shaderspath=~/Documents/My\ Games/Crysis\ Wars/Shaders

i=${1:-3}

if [ "X"$i != "X" ] ; then
pass=$i
echo $i
fi

if (( $pass > 3 )) || (( $pass < 1 )); then
echo " uasge:"
echo $0 "{1|2|3}"
echo "1 = winecfg, 2 = winetricks, 3 = editor"
exit 2
fi

echo $pass

# switch comment whats appropriate
# export WINEARCH=win32
# winegamepath='/drive_c/Program Files (x86)/Electronic Arts/Crytek/Crysis Wars/Bin32'
# windowsgamepath='C:\Program Files (x86)\Electronic Arts\Crytek\Crysis Wars\Bin32\'

export WINEARCH=win64
winegamepath='/drive_c/Program Files (x86)/Electronic Arts/Crytek/Crysis Wars/Bin64'
windowsgamepath='C:\Program Files (x86)\Electronic Arts\Crytek\Crysis Wars\Bin64\'

#here we do "magic" to run DX9 (only supported so far)
#and tell Crysis we want the MWLL mod not the OEM game :^)
OPT="-dx9 -mod MWLL"
#OPT="-mod MWLL"
#OPT="-dx9"

# reducing what wine spews at us
#export WINEDEBUG=-fixme-all,-warn-all,-err-all,-all
export WINEDEBUG=-all

WINEFSYNC=1
WINEESYNC=1
DXVK_HUD=1
DXVK_FILTER_DEVICE_NAME="NVIDIA GeForce GTX 1060 3GB"

# we controll which directory we want be runned by the script
export WINEPREFIX=~/.wine

#this can really beak things if enabled but try it?
# export MESA_DEBUG=1

# we the humans check here what renders our stuff
# if not "Gallium" then it's software = too slow
REND=$(glxinfo | grep "OpenGL renderer" | awk -F: '{print $2}' | awk -F"(" '{print $1}')
echo "Renderer:"$REND
echo "if the above is llvm and not an actual card the game will not work"

#cleaning leftovers from late dinner ;)
killall $executable
killall -9 $executable

#cleaning shader cache for better performance each time
#rm -r "${shaderspath}/*"

#here I cleverly avoid calling the path with my user name :)
cd "${WINEPREFIX}${winegamepath}/${binpath}"
#here i cleverly ask to show the path so we see what WINEPREFIX was called
pwd

case $WINEARCH in
win64)
echo 64bit
case $pass in
1)
winecfg
;;
2)
winetricks
;;
3)
wine64 "${windowsgamepath}${executable}" $OPT # 2>/dev/null # &> MWLL_debug.log
#if uncommented, the last line's comment dumps a log file to the game folder - might prove usefull or a vaste of disk space
;;
esac
;;
win32)
echo 32bit
case $pass in
1)
winecfg
;;
2)
winetricks
;;
3)
#here (hopefully) no shit hits the fan, and we land in game menu
wine ${windowsgamepath}${executable} $OPT # &> MWLL_debug.log
#if uncommented, the last line's comment dumps a log file to the game folder - might prove usefull or a vaste of disk space
;;
esac
;;
esac
# to restore resolution put here what's appropriate or leave as is and just uncomment
xrandr -s 0 # last good resolution

</pre>

This should have you all set.

=== Run the editor ===
You can now start the file by typing ['''MWLLeditor.sh'''] in a command prompt and pressing enter.
Pick a map (['''TC_Reference'''] comes to mind) and try add an ''brush''. Here on is uncharted territory, keep me posted!

=== What breaks in the editor and how to work around it ===

''TODO''

AlienArt

2023-03-05T14:17:24Z

Fire-hound: /* Get it ready */

By Alien it's meant as totally new, possibly even strange art in respect of what's present in the Asset Pool. 
In effect successfully following this procedure will hopefully lead to gradual expansion and enrichment of the aforementioned Asset pool. 

The process:

== Preparing The geometry ==
=== now with blender 3.x ===
This is a procedure covering the ever growing technology gap between the free and ever livid
blender and the aging cryengine2. Just get any blender past 3.x release.

=== Get it ready ===
[[File:Step01.png|200px|thumb|center|Prepare Collection]]

For a Mesh to be fit for cryengine it has to fulfill several criteria due to how compromises were made. 
It is a convention and if one sticks to it good results won't fail to materialize. 
# No more than two triangles should share same edge.
# There should be nothing but triangles (or quads) as the final result - remove all and any nodes and or lines (primitives)...
# There shoudl be no triangles of surface size zero (degenerate faces).
# It is desirable for the mesh be airtight, but there are valid exceptions.

The Object is to be investigated for the quality and errors for UV mapping. 
Only a single UV map per mesh is supported in Cryengine 

The Object is to be assigned To a Collection (no more Groups in blender 3.x) that has the same name 
The .blend file is to be saved with the same name as the object and collection. 

We should now be ready for the export to collada (.dae file) 

[[File:Step02.png|200px|thumb|center|Prepare Export]]

=== Export settings ===
[[File:Step03.png|200px|thumb|center|Collada export options]]

As seen on the image the favorable settings differ from defaults. It is therefore advisable to
create a operator preset (i aptly named "cryengine export") for further convenience.

{| class="wikitable" style="margin:auto"
|+ Parameter Meaning
|-
! Parameter name !! Explanation
|-
| Transform || Decomposed (this means rotation, translation and scale are decomposed)
|-
| Triangulate || leave no uncertain surfaces unresolved by blender.
|-
| Apply Transforms || Viewport (it is usually save to assume this is true)
|-
| Selection Only || we rarely need everything from the file - watch for proper parenting!
|-
| Include children || if parenting is properly laid out - this works miracles!
|-
| Use Object Instances || don't use this - i tried it once and it was ugly
|-
| Use Blender Profile || this is best left off - always leave it off for cryengine export.
|}

== Converting the format ==
=== Prepare your Linux ===
For this to work at all some prerequisites are to be met. You didn't think you'll get off
the hook as easy, didn't you? 
# We need working ColladaCGF in wine, for this we need working PyFFI in wine, and for this we need working Python in wine in the first place. For this all to work at all certain versions are to be downloaded and fed to wine: 
* Python 2.6.6 (or ealrier, but idealy exactly 2.6.6 (32bit release only)
* PyFFI 2.1.11 (the last one that works with 2.x python, newer require python 3.x)
* ColladaCGF 0.3.9 (the last one available)

For this to work you will need your linux to be either "multilib" (more likely applies to you) or 32bit (less likely but possible)

Install In that order (Python, PyFFI, Collada) and see it is in the right wine prefix:

both files: 
"C:\Python26\python.exe"

and

"C:\Python26\Scripts\colladacgf.py"

should be present.

Now if you are not using XFCE4 as your GUI too bad you're just out of luck. Otherwise open the Custom Actions chooser via the Edit menu of Thunar and make a new custom action:

[[File:Step04.png|200px|thumb|center|Custom Actions setup with Thunar and XFCE4]]

I named the action [ ColladaCGF ] and gave it the usual python icon. The description should be obvious: [ Convert a dae file into cgf ]. The command that worked for me was:

[ wineconsole "C:\Python26\python.exe" "C:\Python26\Scripts\colladacgf.py" %F --pause ]

where %F is a list of selected files with the full path.

The filters on the other tab are to be set accordingly: 
[ *.dae;*.DAE ]

mind the semicolon. And the affected files are the text files (.dae files look like XML files) and other files, just in case. Never mind this crazy screenshot - it is CGI - so you have it all on one place.

Apply close and restart Thunar. Now on You should have a context option for each dae file:

[[File:Step05.png|200px|thumb|center|ColladaCGF usage in XFCE on Linux]]

=== Point the ColladaCGF to the .dae file ===
The '''dae''' file is to be selected, '''rightclick > ColladaCGF''' and voila! by ''automagic'' a bunch of murr-murr and computer speak will fill a dark frame, once you notice the computer has stopped spewing insults and dark magic, there might be a blinking cursor waiting no you to press [enter] key and close the window. You might have just converted your first '''CGF''' file on Linux. Or you will be in due time. Conversions often fail due to not adhering to the convention mentioned above.

=== Find the cgf file ===
The newly generated '''.CGF''' file and it's belonging '''.MTL''' file should lay next to each other and next to the source '''.DAE''' file. There might be leftovers in the form of logs and dumps. This can be
safely ignored, they can safely be deleted too.

== Importing into engine on Linux ==
I assume Your Linux has ''multilib'' capability here on. I assume You understand what that means and know where to ask for details for Your distro of choice.

=== How to get the editor working (Glitch TKG's github) ===
I see not too many casualties to this point. Good; good, here onward it gets tough as nails, and by that i mean eating chains to fart back nails!.

https://github.com/Tk-Glitch (kudos to Tk-Glitch o/ )

https://github.com/Tk-Glitch/PKGBUILDS/wiki/wine-tkg-git#dependencies

You want to build a not only custom version of wine (as if that wasn't intimidating enough!).

No sir, you want a higly customized, overly patched VERY recent version wine-staging that has support for child-window our Sandbox2 editor uses to render the game withing it's app window.

No configuration files need to be modified in the [wine-tkg-git] directory, You merely cd to it and run [./non-makepkg-build.sh]

first time you will be dropped to a shell with info and stuff...

make the following file:

file: ['''~/.config/frogminer/wine-tkg.cfg''']:
<pre>

_LOCAL_PRESET="none"
_use_GE_patches="true"
_plain_version=""
_use_staging="true"
_staging_version="v7.22"
_use_fastsync="false"
_use_esync="true"
_use_fsync="true"
_fsync_futex_waitv="true"
_use_vkd3dlib="true"
_dxvk_dxgi="true"

_proton_battleye_support="false"
_proton_eac_support="false"
_warframelauncher_fix="false"
_mwo_fix="false"
_re4_fix="false"

_childwindow_fix="true"

_use_josh_flat_theme="true"

</pre>

And once saved, rerun the above command. Install the new wine and make MWLL run in it's prefix.

to run the editor you will need few more winetricks...
Fended off yet? no? Good, because that isn't nearly the end of the desert :D.
add (via winetricks) the following:
#d3dcompiler_43
#d3dcompiler_47
#dotnet472 (needed for the launcher anyway (will pull in much down to dotnet40) )
#dxvk (i have dxvk1101 so far)
#vcrun2005 (MWLL needs it won't run w/o)
#(add the two redists from the MWLL package, 32bit ones)
Now on the editor should launch:
(note there is no newline at the top of the file)

file: ['''~/.local/bin/MWLLeditor.sh''']:
<pre>
#! /bin/bash

v=0.10-beta
#executable=Crysis.exe
executable=Editor.exe
shaderspath=~/Documents/My\ Games/Crysis\ Wars/Shaders

i=${1:-3}

if [ "X"$i != "X" ] ; then
pass=$i
echo $i
fi

if (( $pass > 3 )) || (( $pass < 1 )); then
echo " uasge:"
echo $0 "{1|2|3}"
echo "1 = winecfg, 2 = winetricks, 3 = editor"
exit 2
fi

echo $pass

# switch comment whats appropriate
# export WINEARCH=win32
# winegamepath='/drive_c/Program Files (x86)/Electronic Arts/Crytek/Crysis Wars/Bin32'
# windowsgamepath='C:\Program Files (x86)\Electronic Arts\Crytek\Crysis Wars\Bin32\'

export WINEARCH=win64
winegamepath='/drive_c/Program Files (x86)/Electronic Arts/Crytek/Crysis Wars/Bin64'
windowsgamepath='C:\Program Files (x86)\Electronic Arts\Crytek\Crysis Wars\Bin64\'

#here we do "magic" to run DX9 (only supported so far)
#and tell Crysis we want the MWLL mod not the OEM game :^)
OPT="-dx9 -mod MWLL"
#OPT="-mod MWLL"
#OPT="-dx9"

# reducing what wine spews at us
#export WINEDEBUG=-fixme-all,-warn-all,-err-all,-all
export WINEDEBUG=-all

WINEFSYNC=1
WINEESYNC=1
DXVK_HUD=1
DXVK_FILTER_DEVICE_NAME="NVIDIA GeForce GTX 1060 3GB"

# we controll which directory we want be runned by the script
export WINEPREFIX=~/.wine

#this can really beak things if enabled but try it?
# export MESA_DEBUG=1

# we the humans check here what renders our stuff
# if not "Gallium" then it's software = too slow
REND=$(glxinfo | grep "OpenGL renderer" | awk -F: '{print $2}' | awk -F"(" '{print $1}')
echo "Renderer:"$REND
echo "if the above is llvm and not an actual card the game will not work"

#cleaning leftovers from late dinner ;)
killall $executable
killall -9 $executable

#cleaning shader cache for better performance each time
#rm -r "${shaderspath}/*"

#here I cleverly avoid calling the path with my user name :)
cd "${WINEPREFIX}${winegamepath}/${binpath}"
#here i cleverly ask to show the path so we see what WINEPREFIX was called
pwd

case $WINEARCH in
win64)
echo 64bit
case $pass in
1)
winecfg
;;
2)
winetricks
;;
3)
wine64 "${windowsgamepath}${executable}" $OPT # 2>/dev/null # &> MWLL_debug.log
#if uncommented, the last line's comment dumps a log file to the game folder - might prove usefull or a vaste of disk space
;;
esac
;;
win32)
echo 32bit
case $pass in
1)
winecfg
;;
2)
winetricks
;;
3)
#here (hopefully) no shit hits the fan, and we land in game menu
wine ${windowsgamepath}${executable} $OPT # &> MWLL_debug.log
#if uncommented, the last line's comment dumps a log file to the game folder - might prove usefull or a vaste of disk space
;;
esac
;;
esac
# to restore resolution put here what's appropriate or leave as is and just uncomment
xrandr -s 0 # last good resolution

</pre>

This should have you all set.

=== Run the editor ===
You can now start the file by typing ['''MWLLeditor.sh'''] in a command prompt and pressing enter.
Pick a map (['''TC_Reference'''] comes to mind) and try add an ''brush''. Here on is uncharted territory, keep me posted!

=== What breaks in the editor and how to work around it ===

''TODO''

AlienArt

2023-02-14T21:42:19Z

Fire-hound: /* Run the editor */

By Alien it's meant as totally new, possibly even strange art in respect of what's present in the Asset Pool. 
In effect successfully following this procedure will hopefully lead to gradual expansion and enrichment of the aforementioned Asset pool. 

The process:

== Preparing The geometry ==
=== now with blender 3.x ===
This is a procedure covering the ever growing technology gap between the free and ever livid
blender and the aging cryengine2. Just get any blender past 3.x release.

=== Get it ready ===
[[File:Step01.png|200px|thumb|center|Prepare Collection]]

For a Mesh to be fit for cryengine it has to fulfill several criteria due to how compromises were made.
It is a convention and if one sticks to it good results won't fail to materialize.
1. No more than two triangles should share same edge.
2. There should be nothing but triangles (or quads) as the final result - remove all and any nodes and or lines (primitives)...
3. There shoudl be no triangles of surface size zero (degenerate faces).
4. It is desirable for the mesh be airtight, but there are valid exceptions.

The Object is to be investigated for the quality and errors for UV mapping.
Only a single UV map per mesh is supported in Cryengine

The Object is to be assigned To a Collection (no more Groups in blender 3.x) that has the same name
The .blend file is to be saved with the same name as the object and collection.

We should now be ready for the export to collada (.dae file)

[[File:Step02.png|200px|thumb|center|Prepare Export]]

=== Export settings ===
[[File:Step03.png|200px|thumb|center|Collada export options]]

As seen on the image the favorable settings differ from defaults. It is therefore advisable to
create a operator preset (i aptly named "cryengine export") for further convenience.

{| class="wikitable" style="margin:auto"
|+ Parameter Meaning
|-
! Parameter name !! Explanation
|-
| Transform || Decomposed (this means rotation, translation and scale are decomposed)
|-
| Triangulate || leave no uncertain surfaces unresolved by blender.
|-
| Apply Transforms || Viewport (it is usually save to assume this is true)
|-
| Selection Only || we rarely need everything from the file - watch for proper parenting!
|-
| Include children || if parenting is properly laid out - this works miracles!
|-
| Use Object Instances || don't use this - i tried it once and it was ugly
|-
| Use Blender Profile || this is best left off - always leave it off for cryengine export.
|}

== Converting the format ==
=== Prepare your Linux ===
For this to work at all some prerequisites are to be met. You didn't think you'll get off
the hook as easy, didn't you? 
# We need working ColladaCGF in wine, for this we need working PyFFI in wine, and for this we need working Python in wine in the first place. For this all to work at all certain versions are to be downloaded and fed to wine: 
* Python 2.6.6 (or ealrier, but idealy exactly 2.6.6 (32bit release only)
* PyFFI 2.1.11 (the last one that works with 2.x python, newer require python 3.x)
* ColladaCGF 0.3.9 (the last one available)

For this to work you will need your linux to be either "multilib" (more likely applies to you) or 32bit (less likely but possible)

Install In that order (Python, PyFFI, Collada) and see it is in the right wine prefix:

both files: 
"C:\Python26\python.exe"

and

"C:\Python26\Scripts\colladacgf.py"

should be present.

Now if you are not using XFCE4 as your GUI too bad you're just out of luck. Otherwise open the Custom Actions chooser via the Edit menu of Thunar and make a new custom action:

[[File:Step04.png|200px|thumb|center|Custom Actions setup with Thunar and XFCE4]]

I named the action [ ColladaCGF ] and gave it the usual python icon. The description should be obvious: [ Convert a dae file into cgf ]. The command that worked for me was:

[ wineconsole "C:\Python26\python.exe" "C:\Python26\Scripts\colladacgf.py" %F --pause ]

where %F is a list of selected files with the full path.

The filters on the other tab are to be set accordingly: 
[ *.dae;*.DAE ]

mind the semicolon. And the affected files are the text files (.dae files look like XML files) and other files, just in case. Never mind this crazy screenshot - it is CGI - so you have it all on one place.

Apply close and restart Thunar. Now on You should have a context option for each dae file:

[[File:Step05.png|200px|thumb|center|ColladaCGF usage in XFCE on Linux]]

=== Point the ColladaCGF to the .dae file ===
The '''dae''' file is to be selected, '''rightclick > ColladaCGF''' and voila! by ''automagic'' a bunch of murr-murr and computer speak will fill a dark frame, once you notice the computer has stopped spewing insults and dark magic, there might be a blinking cursor waiting no you to press [enter] key and close the window. You might have just converted your first '''CGF''' file on Linux. Or you will be in due time. Conversions often fail due to not adhering to the convention mentioned above.

=== Find the cgf file ===
The newly generated '''.CGF''' file and it's belonging '''.MTL''' file should lay next to each other and next to the source '''.DAE''' file. There might be leftovers in the form of logs and dumps. This can be
safely ignored, they can safely be deleted too.

== Importing into engine on Linux ==
I assume Your Linux has ''multilib'' capability here on. I assume You understand what that means and know where to ask for details for Your distro of choice.

=== How to get the editor working (Glitch TKG's github) ===
I see not too many casualties to this point. Good; good, here onward it gets tough as nails, and by that i mean eating chains to fart back nails!.

https://github.com/Tk-Glitch (kudos to Tk-Glitch o/ )

https://github.com/Tk-Glitch/PKGBUILDS/wiki/wine-tkg-git#dependencies

You want to build a not only custom version of wine (as if that wasn't intimidating enough!).

No sir, you want a higly customized, overly patched VERY recent version wine-staging that has support for child-window our Sandbox2 editor uses to render the game withing it's app window.

No configuration files need to be modified in the [wine-tkg-git] directory, You merely cd to it and run [./non-makepkg-build.sh]

first time you will be dropped to a shell with info and stuff...

make the following file:

file: ['''~/.config/frogminer/wine-tkg.cfg''']:
<pre>

_LOCAL_PRESET="none"
_use_GE_patches="true"
_plain_version=""
_use_staging="true"
_staging_version="v7.22"
_use_fastsync="false"
_use_esync="true"
_use_fsync="true"
_fsync_futex_waitv="true"
_use_vkd3dlib="true"
_dxvk_dxgi="true"

_proton_battleye_support="false"
_proton_eac_support="false"
_warframelauncher_fix="false"
_mwo_fix="false"
_re4_fix="false"

_childwindow_fix="true"

_use_josh_flat_theme="true"

</pre>

And once saved, rerun the above command. Install the new wine and make MWLL run in it's prefix.

to run the editor you will need few more winetricks...
Fended off yet? no? Good, because that isn't nearly the end of the desert :D.
add (via winetricks) the following:
#d3dcompiler_43
#d3dcompiler_47
#dotnet472 (needed for the launcher anyway (will pull in much down to dotnet40) )
#dxvk (i have dxvk1101 so far)
#vcrun2005 (MWLL needs it won't run w/o)
#(add the two redists from the MWLL package, 32bit ones)
Now on the editor should launch:
(note there is no newline at the top of the file)

file: ['''~/.local/bin/MWLLeditor.sh''']:
<pre>
#! /bin/bash

v=0.10-beta
#executable=Crysis.exe
executable=Editor.exe
shaderspath=~/Documents/My\ Games/Crysis\ Wars/Shaders

i=${1:-3}

if [ "X"$i != "X" ] ; then
pass=$i
echo $i
fi

if (( $pass > 3 )) || (( $pass < 1 )); then
echo " uasge:"
echo $0 "{1|2|3}"
echo "1 = winecfg, 2 = winetricks, 3 = editor"
exit 2
fi

echo $pass

# switch comment whats appropriate
# export WINEARCH=win32
# winegamepath='/drive_c/Program Files (x86)/Electronic Arts/Crytek/Crysis Wars/Bin32'
# windowsgamepath='C:\Program Files (x86)\Electronic Arts\Crytek\Crysis Wars\Bin32\'

export WINEARCH=win64
winegamepath='/drive_c/Program Files (x86)/Electronic Arts/Crytek/Crysis Wars/Bin64'
windowsgamepath='C:\Program Files (x86)\Electronic Arts\Crytek\Crysis Wars\Bin64\'

#here we do "magic" to run DX9 (only supported so far)
#and tell Crysis we want the MWLL mod not the OEM game :^)
OPT="-dx9 -mod MWLL"
#OPT="-mod MWLL"
#OPT="-dx9"

# reducing what wine spews at us
#export WINEDEBUG=-fixme-all,-warn-all,-err-all,-all
export WINEDEBUG=-all

WINEFSYNC=1
WINEESYNC=1
DXVK_HUD=1
DXVK_FILTER_DEVICE_NAME="NVIDIA GeForce GTX 1060 3GB"

# we controll which directory we want be runned by the script
export WINEPREFIX=~/.wine

#this can really beak things if enabled but try it?
# export MESA_DEBUG=1

# we the humans check here what renders our stuff
# if not "Gallium" then it's software = too slow
REND=$(glxinfo | grep "OpenGL renderer" | awk -F: '{print $2}' | awk -F"(" '{print $1}')
echo "Renderer:"$REND
echo "if the above is llvm and not an actual card the game will not work"

#cleaning leftovers from late dinner ;)
killall $executable
killall -9 $executable

#cleaning shader cache for better performance each time
#rm -r "${shaderspath}/*"

#here I cleverly avoid calling the path with my user name :)
cd "${WINEPREFIX}${winegamepath}/${binpath}"
#here i cleverly ask to show the path so we see what WINEPREFIX was called
pwd

case $WINEARCH in
win64)
echo 64bit
case $pass in
1)
winecfg
;;
2)
winetricks
;;
3)
wine64 "${windowsgamepath}${executable}" $OPT # 2>/dev/null # &> MWLL_debug.log
#if uncommented, the last line's comment dumps a log file to the game folder - might prove usefull or a vaste of disk space
;;
esac
;;
win32)
echo 32bit
case $pass in
1)
winecfg
;;
2)
winetricks
;;
3)
#here (hopefully) no shit hits the fan, and we land in game menu
wine ${windowsgamepath}${executable} $OPT # &> MWLL_debug.log
#if uncommented, the last line's comment dumps a log file to the game folder - might prove usefull or a vaste of disk space
;;
esac
;;
esac
# to restore resolution put here what's appropriate or leave as is and just uncomment
xrandr -s 0 # last good resolution

</pre>

This should have you all set.

=== Run the editor ===
You can now start the file by typing ['''MWLLeditor.sh'''] in a command prompt and pressing enter.
Pick a map (['''TC_Reference'''] comes to mind) and try add an ''brush''. Here on is uncharted territory, keep me posted!

=== What breaks in the editor and how to work around it ===

''TODO''

AlienArt

2023-02-14T21:38:05Z

Fire-hound: /* How to get the editor working (Glitch TKG's github) */

By Alien it's meant as totally new, possibly even strange art in respect of what's present in the Asset Pool. 
In effect successfully following this procedure will hopefully lead to gradual expansion and enrichment of the aforementioned Asset pool. 

The process:

== Preparing The geometry ==
=== now with blender 3.x ===
This is a procedure covering the ever growing technology gap between the free and ever livid
blender and the aging cryengine2. Just get any blender past 3.x release.

=== Get it ready ===
[[File:Step01.png|200px|thumb|center|Prepare Collection]]

For a Mesh to be fit for cryengine it has to fulfill several criteria due to how compromises were made.
It is a convention and if one sticks to it good results won't fail to materialize.
1. No more than two triangles should share same edge.
2. There should be nothing but triangles (or quads) as the final result - remove all and any nodes and or lines (primitives)...
3. There shoudl be no triangles of surface size zero (degenerate faces).
4. It is desirable for the mesh be airtight, but there are valid exceptions.

The Object is to be investigated for the quality and errors for UV mapping.
Only a single UV map per mesh is supported in Cryengine

The Object is to be assigned To a Collection (no more Groups in blender 3.x) that has the same name
The .blend file is to be saved with the same name as the object and collection.

We should now be ready for the export to collada (.dae file)

[[File:Step02.png|200px|thumb|center|Prepare Export]]

=== Export settings ===
[[File:Step03.png|200px|thumb|center|Collada export options]]

As seen on the image the favorable settings differ from defaults. It is therefore advisable to
create a operator preset (i aptly named "cryengine export") for further convenience.

{| class="wikitable" style="margin:auto"
|+ Parameter Meaning
|-
! Parameter name !! Explanation
|-
| Transform || Decomposed (this means rotation, translation and scale are decomposed)
|-
| Triangulate || leave no uncertain surfaces unresolved by blender.
|-
| Apply Transforms || Viewport (it is usually save to assume this is true)
|-
| Selection Only || we rarely need everything from the file - watch for proper parenting!
|-
| Include children || if parenting is properly laid out - this works miracles!
|-
| Use Object Instances || don't use this - i tried it once and it was ugly
|-
| Use Blender Profile || this is best left off - always leave it off for cryengine export.
|}

== Converting the format ==
=== Prepare your Linux ===
For this to work at all some prerequisites are to be met. You didn't think you'll get off
the hook as easy, didn't you? 
# We need working ColladaCGF in wine, for this we need working PyFFI in wine, and for this we need working Python in wine in the first place. For this all to work at all certain versions are to be downloaded and fed to wine: 
* Python 2.6.6 (or ealrier, but idealy exactly 2.6.6 (32bit release only)
* PyFFI 2.1.11 (the last one that works with 2.x python, newer require python 3.x)
* ColladaCGF 0.3.9 (the last one available)

For this to work you will need your linux to be either "multilib" (more likely applies to you) or 32bit (less likely but possible)

Install In that order (Python, PyFFI, Collada) and see it is in the right wine prefix:

both files: 
"C:\Python26\python.exe"

and

"C:\Python26\Scripts\colladacgf.py"

should be present.

Now if you are not using XFCE4 as your GUI too bad you're just out of luck. Otherwise open the Custom Actions chooser via the Edit menu of Thunar and make a new custom action:

[[File:Step04.png|200px|thumb|center|Custom Actions setup with Thunar and XFCE4]]

I named the action [ ColladaCGF ] and gave it the usual python icon. The description should be obvious: [ Convert a dae file into cgf ]. The command that worked for me was:

[ wineconsole "C:\Python26\python.exe" "C:\Python26\Scripts\colladacgf.py" %F --pause ]

where %F is a list of selected files with the full path.

The filters on the other tab are to be set accordingly: 
[ *.dae;*.DAE ]

mind the semicolon. And the affected files are the text files (.dae files look like XML files) and other files, just in case. Never mind this crazy screenshot - it is CGI - so you have it all on one place.

Apply close and restart Thunar. Now on You should have a context option for each dae file:

[[File:Step05.png|200px|thumb|center|ColladaCGF usage in XFCE on Linux]]

=== Point the ColladaCGF to the .dae file ===
The '''dae''' file is to be selected, '''rightclick > ColladaCGF''' and voila! by ''automagic'' a bunch of murr-murr and computer speak will fill a dark frame, once you notice the computer has stopped spewing insults and dark magic, there might be a blinking cursor waiting no you to press [enter] key and close the window. You might have just converted your first '''CGF''' file on Linux. Or you will be in due time. Conversions often fail due to not adhering to the convention mentioned above.

=== Find the cgf file ===
The newly generated '''.CGF''' file and it's belonging '''.MTL''' file should lay next to each other and next to the source '''.DAE''' file. There might be leftovers in the form of logs and dumps. This can be
safely ignored, they can safely be deleted too.

== Importing into engine on Linux ==
I assume Your Linux has ''multilib'' capability here on. I assume You understand what that means and know where to ask for details for Your distro of choice.

=== How to get the editor working (Glitch TKG's github) ===
I see not too many casualties to this point. Good; good, here onward it gets tough as nails, and by that i mean eating chains to fart back nails!.

https://github.com/Tk-Glitch (kudos to Tk-Glitch o/ )

https://github.com/Tk-Glitch/PKGBUILDS/wiki/wine-tkg-git#dependencies

You want to build a not only custom version of wine (as if that wasn't intimidating enough!).

No sir, you want a higly customized, overly patched VERY recent version wine-staging that has support for child-window our Sandbox2 editor uses to render the game withing it's app window.

No configuration files need to be modified in the [wine-tkg-git] directory, You merely cd to it and run [./non-makepkg-build.sh]

first time you will be dropped to a shell with info and stuff...

make the following file:

file: ['''~/.config/frogminer/wine-tkg.cfg''']:
<pre>

_LOCAL_PRESET="none"
_use_GE_patches="true"
_plain_version=""
_use_staging="true"
_staging_version="v7.22"
_use_fastsync="false"
_use_esync="true"
_use_fsync="true"
_fsync_futex_waitv="true"
_use_vkd3dlib="true"
_dxvk_dxgi="true"

_proton_battleye_support="false"
_proton_eac_support="false"
_warframelauncher_fix="false"
_mwo_fix="false"
_re4_fix="false"

_childwindow_fix="true"

_use_josh_flat_theme="true"

</pre>

And once saved, rerun the above command. Install the new wine and make MWLL run in it's prefix.

to run the editor you will need few more winetricks...
Fended off yet? no? Good, because that isn't nearly the end of the desert :D.
add (via winetricks) the following:
#d3dcompiler_43
#d3dcompiler_47
#dotnet472 (needed for the launcher anyway (will pull in much down to dotnet40) )
#dxvk (i have dxvk1101 so far)
#vcrun2005 (MWLL needs it won't run w/o)
#(add the two redists from the MWLL package, 32bit ones)
Now on the editor should launch:
(note there is no newline at the top of the file)

file: ['''~/.local/bin/MWLLeditor.sh''']:
<pre>
#! /bin/bash

v=0.10-beta
#executable=Crysis.exe
executable=Editor.exe
shaderspath=~/Documents/My\ Games/Crysis\ Wars/Shaders

i=${1:-3}

if [ "X"$i != "X" ] ; then
pass=$i
echo $i
fi

if (( $pass > 3 )) || (( $pass < 1 )); then
echo " uasge:"
echo $0 "{1|2|3}"
echo "1 = winecfg, 2 = winetricks, 3 = editor"
exit 2
fi

echo $pass

# switch comment whats appropriate
# export WINEARCH=win32
# winegamepath='/drive_c/Program Files (x86)/Electronic Arts/Crytek/Crysis Wars/Bin32'
# windowsgamepath='C:\Program Files (x86)\Electronic Arts\Crytek\Crysis Wars\Bin32\'

export WINEARCH=win64
winegamepath='/drive_c/Program Files (x86)/Electronic Arts/Crytek/Crysis Wars/Bin64'
windowsgamepath='C:\Program Files (x86)\Electronic Arts\Crytek\Crysis Wars\Bin64\'

#here we do "magic" to run DX9 (only supported so far)
#and tell Crysis we want the MWLL mod not the OEM game :^)
OPT="-dx9 -mod MWLL"
#OPT="-mod MWLL"
#OPT="-dx9"

# reducing what wine spews at us
#export WINEDEBUG=-fixme-all,-warn-all,-err-all,-all
export WINEDEBUG=-all

WINEFSYNC=1
WINEESYNC=1
DXVK_HUD=1
DXVK_FILTER_DEVICE_NAME="NVIDIA GeForce GTX 1060 3GB"

# we controll which directory we want be runned by the script
export WINEPREFIX=~/.wine

#this can really beak things if enabled but try it?
# export MESA_DEBUG=1

# we the humans check here what renders our stuff
# if not "Gallium" then it's software = too slow
REND=$(glxinfo | grep "OpenGL renderer" | awk -F: '{print $2}' | awk -F"(" '{print $1}')
echo "Renderer:"$REND
echo "if the above is llvm and not an actual card the game will not work"

#cleaning leftovers from late dinner ;)
killall $executable
killall -9 $executable

#cleaning shader cache for better performance each time
#rm -r "${shaderspath}/*"

#here I cleverly avoid calling the path with my user name :)
cd "${WINEPREFIX}${winegamepath}/${binpath}"
#here i cleverly ask to show the path so we see what WINEPREFIX was called
pwd

case $WINEARCH in
win64)
echo 64bit
case $pass in
1)
winecfg
;;
2)
winetricks
;;
3)
wine64 "${windowsgamepath}${executable}" $OPT # 2>/dev/null # &> MWLL_debug.log
#if uncommented, the last line's comment dumps a log file to the game folder - might prove usefull or a vaste of disk space
;;
esac
;;
win32)
echo 32bit
case $pass in
1)
winecfg
;;
2)
winetricks
;;
3)
#here (hopefully) no shit hits the fan, and we land in game menu
wine ${windowsgamepath}${executable} $OPT # &> MWLL_debug.log
#if uncommented, the last line's comment dumps a log file to the game folder - might prove usefull or a vaste of disk space
;;
esac
;;
esac
# to restore resolution put here what's appropriate or leave as is and just uncomment
xrandr -s 0 # last good resolution

</pre>

This should have you all set.

=== Run the editor ===
You can now start the file by typing ['''MWLLeditor.sh'''] in a command prompt and pressing enter.
Pick a map ([TC_Reference] comes to mind) and try add an brush. Here on is uncharted territory, keep me posted!

=== What breaks in the editor and how to work around it ===

''TODO''

AlienArt

2023-02-14T21:37:03Z

Fire-hound: /* Importing into engine on Linux */

By Alien it's meant as totally new, possibly even strange art in respect of what's present in the Asset Pool. 
In effect successfully following this procedure will hopefully lead to gradual expansion and enrichment of the aforementioned Asset pool. 

The process:

== Preparing The geometry ==
=== now with blender 3.x ===
This is a procedure covering the ever growing technology gap between the free and ever livid
blender and the aging cryengine2. Just get any blender past 3.x release.

=== Get it ready ===
[[File:Step01.png|200px|thumb|center|Prepare Collection]]

For a Mesh to be fit for cryengine it has to fulfill several criteria due to how compromises were made.
It is a convention and if one sticks to it good results won't fail to materialize.
1. No more than two triangles should share same edge.
2. There should be nothing but triangles (or quads) as the final result - remove all and any nodes and or lines (primitives)...
3. There shoudl be no triangles of surface size zero (degenerate faces).
4. It is desirable for the mesh be airtight, but there are valid exceptions.

The Object is to be investigated for the quality and errors for UV mapping.
Only a single UV map per mesh is supported in Cryengine

The Object is to be assigned To a Collection (no more Groups in blender 3.x) that has the same name
The .blend file is to be saved with the same name as the object and collection.

We should now be ready for the export to collada (.dae file)

[[File:Step02.png|200px|thumb|center|Prepare Export]]

=== Export settings ===
[[File:Step03.png|200px|thumb|center|Collada export options]]

As seen on the image the favorable settings differ from defaults. It is therefore advisable to
create a operator preset (i aptly named "cryengine export") for further convenience.

{| class="wikitable" style="margin:auto"
|+ Parameter Meaning
|-
! Parameter name !! Explanation
|-
| Transform || Decomposed (this means rotation, translation and scale are decomposed)
|-
| Triangulate || leave no uncertain surfaces unresolved by blender.
|-
| Apply Transforms || Viewport (it is usually save to assume this is true)
|-
| Selection Only || we rarely need everything from the file - watch for proper parenting!
|-
| Include children || if parenting is properly laid out - this works miracles!
|-
| Use Object Instances || don't use this - i tried it once and it was ugly
|-
| Use Blender Profile || this is best left off - always leave it off for cryengine export.
|}

== Converting the format ==
=== Prepare your Linux ===
For this to work at all some prerequisites are to be met. You didn't think you'll get off
the hook as easy, didn't you? 
# We need working ColladaCGF in wine, for this we need working PyFFI in wine, and for this we need working Python in wine in the first place. For this all to work at all certain versions are to be downloaded and fed to wine: 
* Python 2.6.6 (or ealrier, but idealy exactly 2.6.6 (32bit release only)
* PyFFI 2.1.11 (the last one that works with 2.x python, newer require python 3.x)
* ColladaCGF 0.3.9 (the last one available)

For this to work you will need your linux to be either "multilib" (more likely applies to you) or 32bit (less likely but possible)

Install In that order (Python, PyFFI, Collada) and see it is in the right wine prefix:

both files: 
"C:\Python26\python.exe"

and

"C:\Python26\Scripts\colladacgf.py"

should be present.

Now if you are not using XFCE4 as your GUI too bad you're just out of luck. Otherwise open the Custom Actions chooser via the Edit menu of Thunar and make a new custom action:

[[File:Step04.png|200px|thumb|center|Custom Actions setup with Thunar and XFCE4]]

I named the action [ ColladaCGF ] and gave it the usual python icon. The description should be obvious: [ Convert a dae file into cgf ]. The command that worked for me was:

[ wineconsole "C:\Python26\python.exe" "C:\Python26\Scripts\colladacgf.py" %F --pause ]

where %F is a list of selected files with the full path.

The filters on the other tab are to be set accordingly: 
[ *.dae;*.DAE ]

mind the semicolon. And the affected files are the text files (.dae files look like XML files) and other files, just in case. Never mind this crazy screenshot - it is CGI - so you have it all on one place.

Apply close and restart Thunar. Now on You should have a context option for each dae file:

[[File:Step05.png|200px|thumb|center|ColladaCGF usage in XFCE on Linux]]

=== Point the ColladaCGF to the .dae file ===
The '''dae''' file is to be selected, '''rightclick > ColladaCGF''' and voila! by ''automagic'' a bunch of murr-murr and computer speak will fill a dark frame, once you notice the computer has stopped spewing insults and dark magic, there might be a blinking cursor waiting no you to press [enter] key and close the window. You might have just converted your first '''CGF''' file on Linux. Or you will be in due time. Conversions often fail due to not adhering to the convention mentioned above.

=== Find the cgf file ===
The newly generated '''.CGF''' file and it's belonging '''.MTL''' file should lay next to each other and next to the source '''.DAE''' file. There might be leftovers in the form of logs and dumps. This can be
safely ignored, they can safely be deleted too.

== Importing into engine on Linux ==
I assume Your Linux has ''multilib'' capability here on. I assume You understand what that means and know where to ask for details for Your distro of choice.

=== How to get the editor working (Glitch TKG's github) ===
I see not too many casualties to this point. Good; good, here onward it gets tough as nails, and by that i mean eating chains to fart back nails!.
https://github.com/Tk-Glitch (kudos to Tk-Glitch o/ )
https://github.com/Tk-Glitch/PKGBUILDS/wiki/wine-tkg-git#dependencies
You want to build a not only custom version of wine (as if that wasn't intimidating enough!).
No sir, you want a higly customized, overly patched VERY recent version wine-staging that has support for child-window our Sandbox2 editor uses to render the game withing it's app window.
No configurationfiles need to be modified in the [wine-tkg-git] directory, You merely cd to
it and run [./non-makepkg-build.sh]

first time you will be dropped to a shell with info and stuff...

make the following file:

file: ['''~/.config/frogminer/wine-tkg.cfg''']:
<pre>

_LOCAL_PRESET="none"
_use_GE_patches="true"
_plain_version=""
_use_staging="true"
_staging_version="v7.22"
_use_fastsync="false"
_use_esync="true"
_use_fsync="true"
_fsync_futex_waitv="true"
_use_vkd3dlib="true"
_dxvk_dxgi="true"

_proton_battleye_support="false"
_proton_eac_support="false"
_warframelauncher_fix="false"
_mwo_fix="false"
_re4_fix="false"

_childwindow_fix="true"

_use_josh_flat_theme="true"

</pre>

And once saved, rerun the above command. Install the new wine and make MWLL run in it's prefix.

to run the editor you will need few more winetricks...
Fended off yet? no? Good, because that isn't nearly the end of the desert :D.
add (via winetricks) the following:
#d3dcompiler_43
#d3dcompiler_47
#dotnet472 (needed for the launcher anyway (will pull in much down to dotnet40) )
#dxvk (i have dxvk1101 so far)
#vcrun2005 (MWLL needs it won't run w/o)
#(add the two redists from the MWLL package, 32bit ones)
Now on the editor should launch:
(note there is no newline at the top of the file)

file: ['''~/.local/bin/MWLLeditor.sh''']:
<pre>
#! /bin/bash

v=0.10-beta
#executable=Crysis.exe
executable=Editor.exe
shaderspath=~/Documents/My\ Games/Crysis\ Wars/Shaders

i=${1:-3}

if [ "X"$i != "X" ] ; then
pass=$i
echo $i
fi

if (( $pass > 3 )) || (( $pass < 1 )); then
echo " uasge:"
echo $0 "{1|2|3}"
echo "1 = winecfg, 2 = winetricks, 3 = editor"
exit 2
fi

echo $pass

# switch comment whats appropriate
# export WINEARCH=win32
# winegamepath='/drive_c/Program Files (x86)/Electronic Arts/Crytek/Crysis Wars/Bin32'
# windowsgamepath='C:\Program Files (x86)\Electronic Arts\Crytek\Crysis Wars\Bin32\'

export WINEARCH=win64
winegamepath='/drive_c/Program Files (x86)/Electronic Arts/Crytek/Crysis Wars/Bin64'
windowsgamepath='C:\Program Files (x86)\Electronic Arts\Crytek\Crysis Wars\Bin64\'

#here we do "magic" to run DX9 (only supported so far)
#and tell Crysis we want the MWLL mod not the OEM game :^)
OPT="-dx9 -mod MWLL"
#OPT="-mod MWLL"
#OPT="-dx9"

# reducing what wine spews at us
#export WINEDEBUG=-fixme-all,-warn-all,-err-all,-all
export WINEDEBUG=-all

WINEFSYNC=1
WINEESYNC=1
DXVK_HUD=1
DXVK_FILTER_DEVICE_NAME="NVIDIA GeForce GTX 1060 3GB"

# we controll which directory we want be runned by the script
export WINEPREFIX=~/.wine

#this can really beak things if enabled but try it?
# export MESA_DEBUG=1

# we the humans check here what renders our stuff
# if not "Gallium" then it's software = too slow
REND=$(glxinfo | grep "OpenGL renderer" | awk -F: '{print $2}' | awk -F"(" '{print $1}')
echo "Renderer:"$REND
echo "if the above is llvm and not an actual card the game will not work"

#cleaning leftovers from late dinner ;)
killall $executable
killall -9 $executable

#cleaning shader cache for better performance each time
#rm -r "${shaderspath}/*"

#here I cleverly avoid calling the path with my user name :)
cd "${WINEPREFIX}${winegamepath}/${binpath}"
#here i cleverly ask to show the path so we see what WINEPREFIX was called
pwd

case $WINEARCH in
win64)
echo 64bit
case $pass in
1)
winecfg
;;
2)
winetricks
;;
3)
wine64 "${windowsgamepath}${executable}" $OPT # 2>/dev/null # &> MWLL_debug.log
#if uncommented, the last line's comment dumps a log file to the game folder - might prove usefull or a vaste of disk space
;;
esac
;;
win32)
echo 32bit
case $pass in
1)
winecfg
;;
2)
winetricks
;;
3)
#here (hopefully) no shit hits the fan, and we land in game menu
wine ${windowsgamepath}${executable} $OPT # &> MWLL_debug.log
#if uncommented, the last line's comment dumps a log file to the game folder - might prove usefull or a vaste of disk space
;;
esac
;;
esac
# to restore resolution put here what's appropriate or leave as is and just uncomment
xrandr -s 0 # last good resolution

</pre>

This should have you all set.

=== Run the editor ===
You can now start the file by typing ['''MWLLeditor.sh'''] in a command prompt and pressing enter.
Pick a map ([TC_Reference] comes to mind) and try add an brush. Here on is uncharted territory, keep me posted!

=== What breaks in the editor and how to work around it ===

''TODO''

AlienArt

2023-02-14T21:35:26Z

Fire-hound: /* How to get the editor working (Glitch TKG's github) */

By Alien it's meant as totally new, possibly even strange art in respect of what's present in the Asset Pool. 
In effect successfully following this procedure will hopefully lead to gradual expansion and enrichment of the aforementioned Asset pool. 

The process:

== Preparing The geometry ==
=== now with blender 3.x ===
This is a procedure covering the ever growing technology gap between the free and ever livid
blender and the aging cryengine2. Just get any blender past 3.x release.

=== Get it ready ===
[[File:Step01.png|200px|thumb|center|Prepare Collection]]

For a Mesh to be fit for cryengine it has to fulfill several criteria due to how compromises were made.
It is a convention and if one sticks to it good results won't fail to materialize.
1. No more than two triangles should share same edge.
2. There should be nothing but triangles (or quads) as the final result - remove all and any nodes and or lines (primitives)...
3. There shoudl be no triangles of surface size zero (degenerate faces).
4. It is desirable for the mesh be airtight, but there are valid exceptions.

The Object is to be investigated for the quality and errors for UV mapping.
Only a single UV map per mesh is supported in Cryengine

The Object is to be assigned To a Collection (no more Groups in blender 3.x) that has the same name
The .blend file is to be saved with the same name as the object and collection.

We should now be ready for the export to collada (.dae file)

[[File:Step02.png|200px|thumb|center|Prepare Export]]

=== Export settings ===
[[File:Step03.png|200px|thumb|center|Collada export options]]

As seen on the image the favorable settings differ from defaults. It is therefore advisable to
create a operator preset (i aptly named "cryengine export") for further convenience.

{| class="wikitable" style="margin:auto"
|+ Parameter Meaning
|-
! Parameter name !! Explanation
|-
| Transform || Decomposed (this means rotation, translation and scale are decomposed)
|-
| Triangulate || leave no uncertain surfaces unresolved by blender.
|-
| Apply Transforms || Viewport (it is usually save to assume this is true)
|-
| Selection Only || we rarely need everything from the file - watch for proper parenting!
|-
| Include children || if parenting is properly laid out - this works miracles!
|-
| Use Object Instances || don't use this - i tried it once and it was ugly
|-
| Use Blender Profile || this is best left off - always leave it off for cryengine export.
|}

== Converting the format ==
=== Prepare your Linux ===
For this to work at all some prerequisites are to be met. You didn't think you'll get off
the hook as easy, didn't you? 
# We need working ColladaCGF in wine, for this we need working PyFFI in wine, and for this we need working Python in wine in the first place. For this all to work at all certain versions are to be downloaded and fed to wine: 
* Python 2.6.6 (or ealrier, but idealy exactly 2.6.6 (32bit release only)
* PyFFI 2.1.11 (the last one that works with 2.x python, newer require python 3.x)
* ColladaCGF 0.3.9 (the last one available)

For this to work you will need your linux to be either "multilib" (more likely applies to you) or 32bit (less likely but possible)

Install In that order (Python, PyFFI, Collada) and see it is in the right wine prefix:

both files: 
"C:\Python26\python.exe"

and

"C:\Python26\Scripts\colladacgf.py"

should be present.

Now if you are not using XFCE4 as your GUI too bad you're just out of luck. Otherwise open the Custom Actions chooser via the Edit menu of Thunar and make a new custom action:

[[File:Step04.png|200px|thumb|center|Custom Actions setup with Thunar and XFCE4]]

I named the action [ ColladaCGF ] and gave it the usual python icon. The description should be obvious: [ Convert a dae file into cgf ]. The command that worked for me was:

[ wineconsole "C:\Python26\python.exe" "C:\Python26\Scripts\colladacgf.py" %F --pause ]

where %F is a list of selected files with the full path.

The filters on the other tab are to be set accordingly: 
[ *.dae;*.DAE ]

mind the semicolon. And the affected files are the text files (.dae files look like XML files) and other files, just in case. Never mind this crazy screenshot - it is CGI - so you have it all on one place.

Apply close and restart Thunar. Now on You should have a context option for each dae file:

[[File:Step05.png|200px|thumb|center|ColladaCGF usage in XFCE on Linux]]

=== Point the ColladaCGF to the .dae file ===
The '''dae''' file is to be selected, '''rightclick > ColladaCGF''' and voila! by ''automagic'' a bunch of murr-murr and computer speak will fill a dark frame, once you notice the computer has stopped spewing insults and dark magic, there might be a blinking cursor waiting no you to press [enter] key and close the window. You might have just converted your first '''CGF''' file on Linux. Or you will be in due time. Conversions often fail due to not adhering to the convention mentioned above.

=== Find the cgf file ===
The newly generated '''.CGF''' file and it's belonging '''.MTL''' file should lay next to each other and next to the source '''.DAE''' file. There might be leftovers in the form of logs and dumps. This can be
safely ignored, they can safely be deleted too.

== Importing into engine on Linux ==

=== How to get the editor working (Glitch TKG's github) ===
I see not too many casualties to this point. Good; good, here onward it gets tough as nails, and by that i mean eating chains to fart back nails!.
https://github.com/Tk-Glitch (kudos to Tk-Glitch o/ )
https://github.com/Tk-Glitch/PKGBUILDS/wiki/wine-tkg-git#dependencies
You want to build a not only custom version of wine (as if that wasn't intimidating enough!).
No sir, you want a higly customized, overly patched VERY recent version wine-staging that has support for child-window our Sandbox2 editor uses to render the game withing it's app window.
No configurationfiles need to be modified in the [wine-tkg-git] directory, You merely cd to
it and run [./non-makepkg-build.sh]

first time you will be dropped to a shell with info and stuff...

make the following file:

file: ['''~/.config/frogminer/wine-tkg.cfg''']:
<pre>

_LOCAL_PRESET="none"
_use_GE_patches="true"
_plain_version=""
_use_staging="true"
_staging_version="v7.22"
_use_fastsync="false"
_use_esync="true"
_use_fsync="true"
_fsync_futex_waitv="true"
_use_vkd3dlib="true"
_dxvk_dxgi="true"

_proton_battleye_support="false"
_proton_eac_support="false"
_warframelauncher_fix="false"
_mwo_fix="false"
_re4_fix="false"

_childwindow_fix="true"

_use_josh_flat_theme="true"

</pre>

And once saved, rerun the above command. Install the new wine and make MWLL run in it's prefix.

to run the editor you will need few more winetricks...
Fended off yet? no? Good, because that isn't nearly the end of the desert :D.
add (via winetricks) the following:
#d3dcompiler_43
#d3dcompiler_47
#dotnet472 (needed for the launcher anyway (will pull in much down to dotnet40) )
#dxvk (i have dxvk1101 so far)
#vcrun2005 (MWLL needs it won't run w/o)
#(add the two redists from the MWLL package, 32bit ones)
Now on the editor should launch:
(note there is no newline at the top of the file)

file: ['''~/.local/bin/MWLLeditor.sh''']:
<pre>
#! /bin/bash

v=0.10-beta
#executable=Crysis.exe
executable=Editor.exe
shaderspath=~/Documents/My\ Games/Crysis\ Wars/Shaders

i=${1:-3}

if [ "X"$i != "X" ] ; then
pass=$i
echo $i
fi

if (( $pass > 3 )) || (( $pass < 1 )); then
echo " uasge:"
echo $0 "{1|2|3}"
echo "1 = winecfg, 2 = winetricks, 3 = editor"
exit 2
fi

echo $pass

# switch comment whats appropriate
# export WINEARCH=win32
# winegamepath='/drive_c/Program Files (x86)/Electronic Arts/Crytek/Crysis Wars/Bin32'
# windowsgamepath='C:\Program Files (x86)\Electronic Arts\Crytek\Crysis Wars\Bin32\'

export WINEARCH=win64
winegamepath='/drive_c/Program Files (x86)/Electronic Arts/Crytek/Crysis Wars/Bin64'
windowsgamepath='C:\Program Files (x86)\Electronic Arts\Crytek\Crysis Wars\Bin64\'

#here we do "magic" to run DX9 (only supported so far)
#and tell Crysis we want the MWLL mod not the OEM game :^)
OPT="-dx9 -mod MWLL"
#OPT="-mod MWLL"
#OPT="-dx9"

# reducing what wine spews at us
#export WINEDEBUG=-fixme-all,-warn-all,-err-all,-all
export WINEDEBUG=-all

WINEFSYNC=1
WINEESYNC=1
DXVK_HUD=1
DXVK_FILTER_DEVICE_NAME="NVIDIA GeForce GTX 1060 3GB"

# we controll which directory we want be runned by the script
export WINEPREFIX=~/.wine

#this can really beak things if enabled but try it?
# export MESA_DEBUG=1

# we the humans check here what renders our stuff
# if not "Gallium" then it's software = too slow
REND=$(glxinfo | grep "OpenGL renderer" | awk -F: '{print $2}' | awk -F"(" '{print $1}')
echo "Renderer:"$REND
echo "if the above is llvm and not an actual card the game will not work"

#cleaning leftovers from late dinner ;)
killall $executable
killall -9 $executable

#cleaning shader cache for better performance each time
#rm -r "${shaderspath}/*"

#here I cleverly avoid calling the path with my user name :)
cd "${WINEPREFIX}${winegamepath}/${binpath}"
#here i cleverly ask to show the path so we see what WINEPREFIX was called
pwd

case $WINEARCH in
win64)
echo 64bit
case $pass in
1)
winecfg
;;
2)
winetricks
;;
3)
wine64 "${windowsgamepath}${executable}" $OPT # 2>/dev/null # &> MWLL_debug.log
#if uncommented, the last line's comment dumps a log file to the game folder - might prove usefull or a vaste of disk space
;;
esac
;;
win32)
echo 32bit
case $pass in
1)
winecfg
;;
2)
winetricks
;;
3)
#here (hopefully) no shit hits the fan, and we land in game menu
wine ${windowsgamepath}${executable} $OPT # &> MWLL_debug.log
#if uncommented, the last line's comment dumps a log file to the game folder - might prove usefull or a vaste of disk space
;;
esac
;;
esac
# to restore resolution put here what's appropriate or leave as is and just uncomment
xrandr -s 0 # last good resolution

</pre>

This should have you all set.

=== Run the editor ===
You can now start the file by typing ['''MWLLeditor.sh'''] in a command prompt and pressing enter.
Pick a map ([TC_Reference] comes to mind) and try add an brush. Here on is uncharted territory, keep me posted!

=== What breaks in the editor and how to work around it ===

''TODO''

AlienArt

2023-02-14T21:33:56Z

Fire-hound: /* How to get the editor working (Glitch TKG's github) */ typos

By Alien it's meant as totally new, possibly even strange art in respect of what's present in the Asset Pool. 
In effect successfully following this procedure will hopefully lead to gradual expansion and enrichment of the aforementioned Asset pool. 

The process:

== Preparing The geometry ==
=== now with blender 3.x ===
This is a procedure covering the ever growing technology gap between the free and ever livid
blender and the aging cryengine2. Just get any blender past 3.x release.

=== Get it ready ===
[[File:Step01.png|200px|thumb|center|Prepare Collection]]

For a Mesh to be fit for cryengine it has to fulfill several criteria due to how compromises were made.
It is a convention and if one sticks to it good results won't fail to materialize.
1. No more than two triangles should share same edge.
2. There should be nothing but triangles (or quads) as the final result - remove all and any nodes and or lines (primitives)...
3. There shoudl be no triangles of surface size zero (degenerate faces).
4. It is desirable for the mesh be airtight, but there are valid exceptions.

The Object is to be investigated for the quality and errors for UV mapping.
Only a single UV map per mesh is supported in Cryengine

The Object is to be assigned To a Collection (no more Groups in blender 3.x) that has the same name
The .blend file is to be saved with the same name as the object and collection.

We should now be ready for the export to collada (.dae file)

[[File:Step02.png|200px|thumb|center|Prepare Export]]

=== Export settings ===
[[File:Step03.png|200px|thumb|center|Collada export options]]

As seen on the image the favorable settings differ from defaults. It is therefore advisable to
create a operator preset (i aptly named "cryengine export") for further convenience.

{| class="wikitable" style="margin:auto"
|+ Parameter Meaning
|-
! Parameter name !! Explanation
|-
| Transform || Decomposed (this means rotation, translation and scale are decomposed)
|-
| Triangulate || leave no uncertain surfaces unresolved by blender.
|-
| Apply Transforms || Viewport (it is usually save to assume this is true)
|-
| Selection Only || we rarely need everything from the file - watch for proper parenting!
|-
| Include children || if parenting is properly laid out - this works miracles!
|-
| Use Object Instances || don't use this - i tried it once and it was ugly
|-
| Use Blender Profile || this is best left off - always leave it off for cryengine export.
|}

== Converting the format ==
=== Prepare your Linux ===
For this to work at all some prerequisites are to be met. You didn't think you'll get off
the hook as easy, didn't you? 
# We need working ColladaCGF in wine, for this we need working PyFFI in wine, and for this we need working Python in wine in the first place. For this all to work at all certain versions are to be downloaded and fed to wine: 
* Python 2.6.6 (or ealrier, but idealy exactly 2.6.6 (32bit release only)
* PyFFI 2.1.11 (the last one that works with 2.x python, newer require python 3.x)
* ColladaCGF 0.3.9 (the last one available)

For this to work you will need your linux to be either "multilib" (more likely applies to you) or 32bit (less likely but possible)

Install In that order (Python, PyFFI, Collada) and see it is in the right wine prefix:

both files: 
"C:\Python26\python.exe"

and

"C:\Python26\Scripts\colladacgf.py"

should be present.

Now if you are not using XFCE4 as your GUI too bad you're just out of luck. Otherwise open the Custom Actions chooser via the Edit menu of Thunar and make a new custom action:

[[File:Step04.png|200px|thumb|center|Custom Actions setup with Thunar and XFCE4]]

I named the action [ ColladaCGF ] and gave it the usual python icon. The description should be obvious: [ Convert a dae file into cgf ]. The command that worked for me was:

[ wineconsole "C:\Python26\python.exe" "C:\Python26\Scripts\colladacgf.py" %F --pause ]

where %F is a list of selected files with the full path.

The filters on the other tab are to be set accordingly: 
[ *.dae;*.DAE ]

mind the semicolon. And the affected files are the text files (.dae files look like XML files) and other files, just in case. Never mind this crazy screenshot - it is CGI - so you have it all on one place.

Apply close and restart Thunar. Now on You should have a context option for each dae file:

[[File:Step05.png|200px|thumb|center|ColladaCGF usage in XFCE on Linux]]

=== Point the ColladaCGF to the .dae file ===
The '''dae''' file is to be selected, '''rightclick > ColladaCGF''' and voila! by ''automagic'' a bunch of murr-murr and computer speak will fill a dark frame, once you notice the computer has stopped spewing insults and dark magic, there might be a blinking cursor waiting no you to press [enter] key and close the window. You might have just converted your first '''CGF''' file on Linux. Or you will be in due time. Conversions often fail due to not adhering to the convention mentioned above.

=== Find the cgf file ===
The newly generated '''.CGF''' file and it's belonging '''.MTL''' file should lay next to each other and next to the source '''.DAE''' file. There might be leftovers in the form of logs and dumps. This can be
safely ignored, they can safely be deleted too.

== Importing into engine on Linux ==

=== How to get the editor working (Glitch TKG's github) ===
I see not too many casualties to this point. Good; good, here onward it gets tough as nails, and by that i mean eating chains to fart back nails!.
https://github.com/Tk-Glitch (kudos to Tk-Glitch o/ )
https://github.com/Tk-Glitch/PKGBUILDS/wiki/wine-tkg-git#dependencies
You want to build a not only custom version of wine (as if that wasn't intimidating enough!).
No sir, you want a higly customized, overly patched VERY recent version wine-staging that has support for child-window our Sandbox2 editor uses to render the game withing it's app window.
No configurationfiles need to be modified in the [wine-tkg-git] directory, You merely cd to
it and run [./non-makepkg-build.sh]

first time you will be dropped to a shell with info and stuff...

make the following file:

file: ['''~/.config/frogminer/wine-tkg.cfg''']:
<pre>

_LOCAL_PRESET="none"
_use_GE_patches="true"
_plain_version=""
_use_staging="true"
_staging_version="v7.22"
_use_fastsync="false"
_use_esync="true"
_use_fsync="true"
_fsync_futex_waitv="true"
_use_vkd3dlib="true"
_dxvk_dxgi="true"

_proton_battleye_support="false"
_proton_eac_support="false"
_warframelauncher_fix="false"
_mwo_fix="false"
_re4_fix="false"

_childwindow_fix="true"

_use_josh_flat_theme="true"

</pre>

And once saved, rerun the above command. Install the new wine and make MWLL run in it's prefix.

to run the editor you will need few more winetricks...
Fended of yet? no? Good, because that isn't nearly the end of the desert :D.
add (via winetricks) the follwing:
d3dcompiler_43
d3dcompiler_47
dotnet472 (needed for the launcher anyway (will pull in much down to dotnet40) )
dxvk (i have dxvk1101 so far)
vcrun2005 (MWLL needs it won't run w/o)
(add the two redists from the MWLL package, 32bit ones)
Now on the editor should launch:
(note there is no newline at the top of the file)

file: ['''~/.local/bin/MWLLeditor.sh''']:
<pre>
#! /bin/bash

v=0.10-beta
#executable=Crysis.exe
executable=Editor.exe
shaderspath=~/Documents/My\ Games/Crysis\ Wars/Shaders

i=${1:-3}

if [ "X"$i != "X" ] ; then
pass=$i
echo $i
fi

if (( $pass > 3 )) || (( $pass < 1 )); then
echo " uasge:"
echo $0 "{1|2|3}"
echo "1 = winecfg, 2 = winetricks, 3 = editor"
exit 2
fi

echo $pass

# switch comment whats appropriate
# export WINEARCH=win32
# winegamepath='/drive_c/Program Files (x86)/Electronic Arts/Crytek/Crysis Wars/Bin32'
# windowsgamepath='C:\Program Files (x86)\Electronic Arts\Crytek\Crysis Wars\Bin32\'

export WINEARCH=win64
winegamepath='/drive_c/Program Files (x86)/Electronic Arts/Crytek/Crysis Wars/Bin64'
windowsgamepath='C:\Program Files (x86)\Electronic Arts\Crytek\Crysis Wars\Bin64\'

#here we do "magic" to run DX9 (only supported so far)
#and tell Crysis we want the MWLL mod not the OEM game :^)
OPT="-dx9 -mod MWLL"
#OPT="-mod MWLL"
#OPT="-dx9"

# reducing what wine spews at us
#export WINEDEBUG=-fixme-all,-warn-all,-err-all,-all
export WINEDEBUG=-all

WINEFSYNC=1
WINEESYNC=1
DXVK_HUD=1
DXVK_FILTER_DEVICE_NAME="NVIDIA GeForce GTX 1060 3GB"

# we controll which directory we want be runned by the script
export WINEPREFIX=~/.wine

#this can really beak things if enabled but try it?
# export MESA_DEBUG=1

# we the humans check here what renders our stuff
# if not "Gallium" then it's software = too slow
REND=$(glxinfo | grep "OpenGL renderer" | awk -F: '{print $2}' | awk -F"(" '{print $1}')
echo "Renderer:"$REND
echo "if the above is llvm and not an actual card the game will not work"

#cleaning leftovers from late dinner ;)
killall $executable
killall -9 $executable

#cleaning shader cache for better performance each time
#rm -r "${shaderspath}/*"

#here I cleverly avoid calling the path with my user name :)
cd "${WINEPREFIX}${winegamepath}/${binpath}"
#here i cleverly ask to show the path so we see what WINEPREFIX was called
pwd

case $WINEARCH in
win64)
echo 64bit
case $pass in
1)
winecfg
;;
2)
winetricks
;;
3)
wine64 "${windowsgamepath}${executable}" $OPT # 2>/dev/null # &> MWLL_debug.log
#if uncommented, the last line's comment dumps a log file to the game folder - might prove usefull or a vaste of disk space
;;
esac
;;
win32)
echo 32bit
case $pass in
1)
winecfg
;;
2)
winetricks
;;
3)
#here (hopefully) no shit hits the fan, and we land in game menu
wine ${windowsgamepath}${executable} $OPT # &> MWLL_debug.log
#if uncommented, the last line's comment dumps a log file to the game folder - might prove usefull or a vaste of disk space
;;
esac
;;
esac
# to restore resolution put here what's appropriate or leave as is and just uncomment
xrandr -s 0 # last good resolution

</pre>

This should have you all set.

=== Run the editor ===
You can now start the file by typing ['''MWLLeditor.sh'''] in a command prompt and pressing enter.
Pick a map ([TC_Reference] comes to mind) and try add an brush. Here on is uncharted territory, keep me posted!

=== What breaks in the editor and how to work around it ===

''TODO''

AlienArt

2023-02-14T21:31:37Z

Fire-hound: /* Importing into engine */

By Alien it's meant as totally new, possibly even strange art in respect of what's present in the Asset Pool. 
In effect successfully following this procedure will hopefully lead to gradual expansion and enrichment of the aforementioned Asset pool. 

The process:

== Preparing The geometry ==
=== now with blender 3.x ===
This is a procedure covering the ever growing technology gap between the free and ever livid
blender and the aging cryengine2. Just get any blender past 3.x release.

=== Get it ready ===
[[File:Step01.png|200px|thumb|center|Prepare Collection]]

For a Mesh to be fit for cryengine it has to fulfill several criteria due to how compromises were made.
It is a convention and if one sticks to it good results won't fail to materialize.
1. No more than two triangles should share same edge.
2. There should be nothing but triangles (or quads) as the final result - remove all and any nodes and or lines (primitives)...
3. There shoudl be no triangles of surface size zero (degenerate faces).
4. It is desirable for the mesh be airtight, but there are valid exceptions.

The Object is to be investigated for the quality and errors for UV mapping.
Only a single UV map per mesh is supported in Cryengine

The Object is to be assigned To a Collection (no more Groups in blender 3.x) that has the same name
The .blend file is to be saved with the same name as the object and collection.

We should now be ready for the export to collada (.dae file)

[[File:Step02.png|200px|thumb|center|Prepare Export]]

=== Export settings ===
[[File:Step03.png|200px|thumb|center|Collada export options]]

As seen on the image the favorable settings differ from defaults. It is therefore advisable to
create a operator preset (i aptly named "cryengine export") for further convenience.

{| class="wikitable" style="margin:auto"
|+ Parameter Meaning
|-
! Parameter name !! Explanation
|-
| Transform || Decomposed (this means rotation, translation and scale are decomposed)
|-
| Triangulate || leave no uncertain surfaces unresolved by blender.
|-
| Apply Transforms || Viewport (it is usually save to assume this is true)
|-
| Selection Only || we rarely need everything from the file - watch for proper parenting!
|-
| Include children || if parenting is properly laid out - this works miracles!
|-
| Use Object Instances || don't use this - i tried it once and it was ugly
|-
| Use Blender Profile || this is best left off - always leave it off for cryengine export.
|}

== Converting the format ==
=== Prepare your Linux ===
For this to work at all some prerequisites are to be met. You didn't think you'll get off
the hook as easy, didn't you? 
# We need working ColladaCGF in wine, for this we need working PyFFI in wine, and for this we need working Python in wine in the first place. For this all to work at all certain versions are to be downloaded and fed to wine: 
* Python 2.6.6 (or ealrier, but idealy exactly 2.6.6 (32bit release only)
* PyFFI 2.1.11 (the last one that works with 2.x python, newer require python 3.x)
* ColladaCGF 0.3.9 (the last one available)

For this to work you will need your linux to be either "multilib" (more likely applies to you) or 32bit (less likely but possible)

Install In that order (Python, PyFFI, Collada) and see it is in the right wine prefix:

both files: 
"C:\Python26\python.exe"

and

"C:\Python26\Scripts\colladacgf.py"

should be present.

Now if you are not using XFCE4 as your GUI too bad you're just out of luck. Otherwise open the Custom Actions chooser via the Edit menu of Thunar and make a new custom action:

[[File:Step04.png|200px|thumb|center|Custom Actions setup with Thunar and XFCE4]]

I named the action [ ColladaCGF ] and gave it the usual python icon. The description should be obvious: [ Convert a dae file into cgf ]. The command that worked for me was:

[ wineconsole "C:\Python26\python.exe" "C:\Python26\Scripts\colladacgf.py" %F --pause ]

where %F is a list of selected files with the full path.

The filters on the other tab are to be set accordingly: 
[ *.dae;*.DAE ]

mind the semicolon. And the affected files are the text files (.dae files look like XML files) and other files, just in case. Never mind this crazy screenshot - it is CGI - so you have it all on one place.

Apply close and restart Thunar. Now on You should have a context option for each dae file:

[[File:Step05.png|200px|thumb|center|ColladaCGF usage in XFCE on Linux]]

=== Point the ColladaCGF to the .dae file ===
The '''dae''' file is to be selected, '''rightclick > ColladaCGF''' and voila! by ''automagic'' a bunch of murr-murr and computer speak will fill a dark frame, once you notice the computer has stopped spewing insults and dark magic, there might be a blinking cursor waiting no you to press [enter] key and close the window. You might have just converted your first '''CGF''' file on Linux. Or you will be in due time. Conversions often fail due to not adhering to the convention mentioned above.

=== Find the cgf file ===
The newly generated '''.CGF''' file and it's belonging '''.MTL''' file should lay next to each other and next to the source '''.DAE''' file. There might be leftovers in the form of logs and dumps. This can be
safely ignored, they can safely be deleted too.

== Importing into engine on Linux ==

=== How to get the editor working (Glitch TKG's github) ===
I see not too many casualties to this point. Good; good, here onward it gets tough as nails, and by that i mean eating chains to fart back nails!.
https://github.com/Tk-Glitch (kudos to Tk-Glitch o/ )
https://github.com/Tk-Glitch/PKGBUILDS/wiki/wine-tkg-git#dependencies
You want to build a not only custom version of wine (as if that wasn't intimidating enough!).
No sir, you want a higly customized, overly patched VERY recent version wine-staging that has support for child-window our Sandbox2 editor uses to render the game withing it's app window.
No configurationfiles need to be modified in the [wine-tkg-git] directory, You merely cd to
it and run [./non-makepkg-build.sh]

first time you will be dropped to a shel with inof and stuff...

make the following file:

file: ['''~/.config/frogminer/wine-tkg.cfg''']:
<pre>

_LOCAL_PRESET="none"
_use_GE_patches="true"
_plain_version=""
_use_staging="true"
_staging_version="v7.22"
_use_fastsync="false"
_use_esync="true"
_use_fsync="true"
_fsync_futex_waitv="true"
_use_vkd3dlib="true"
_dxvk_dxgi="true"

_proton_battleye_support="false"
_proton_eac_support="false"
_warframelauncher_fix="false"
_mwo_fix="false"
_re4_fix="false"

_childwindow_fix="true"

_use_josh_flat_theme="true"

</pre>

And once saved, rerun the above command. Install the new wine and make MWLL run in it's prefix.

to run the editor you will need few more winetricks...
Fended of yet? no? Good, because that isn't nearly the end of the desert :D.
add (via winetricks) the follwing:
d3dcompiler_43
d3dcompiler_47
dotnet472 (needed for the launcher anyway (will pull in much down to dotnet40) )
dxvk (i have dxvk1101 so far)
vcrun2005 (MWLL needs it won't run w/o)
(add the two redists from the MWLL package, 32bit ones)
Now on the editor should launch:
(note there is no newline at the top of the file)

file: ['''~/.local/bin/MWLLeditor.sh''']:
<pre>
#! /bin/bash

v=0.10-beta
#executable=Crysis.exe
executable=Editor.exe
shaderspath=~/Documents/My\ Games/Crysis\ Wars/Shaders

i=${1:-3}

if [ "X"$i != "X" ] ; then
pass=$i
echo $i
fi

if (( $pass > 3 )) || (( $pass < 1 )); then
echo " uasge:"
echo $0 "{1|2|3}"
echo "1 = winecfg, 2 = winetricks, 3 = editor"
exit 2
fi

echo $pass

# switch comment whats appropriate
# export WINEARCH=win32
# winegamepath='/drive_c/Program Files (x86)/Electronic Arts/Crytek/Crysis Wars/Bin32'
# windowsgamepath='C:\Program Files (x86)\Electronic Arts\Crytek\Crysis Wars\Bin32\'

export WINEARCH=win64
winegamepath='/drive_c/Program Files (x86)/Electronic Arts/Crytek/Crysis Wars/Bin64'
windowsgamepath='C:\Program Files (x86)\Electronic Arts\Crytek\Crysis Wars\Bin64\'

#here we do "magic" to run DX9 (only supported so far)
#and tell Crysis we want the MWLL mod not the OEM game :^)
OPT="-dx9 -mod MWLL"
#OPT="-mod MWLL"
#OPT="-dx9"

# reducing what wine spews at us
#export WINEDEBUG=-fixme-all,-warn-all,-err-all,-all
export WINEDEBUG=-all

WINEFSYNC=1
WINEESYNC=1
DXVK_HUD=1
DXVK_FILTER_DEVICE_NAME="NVIDIA GeForce GTX 1060 3GB"

# we controll which directory we want be runned by the script
export WINEPREFIX=~/.wine

#this can really beak things if enabled but try it?
# export MESA_DEBUG=1

# we the humans check here what renders our stuff
# if not "Gallium" then it's software = too slow
REND=$(glxinfo | grep "OpenGL renderer" | awk -F: '{print $2}' | awk -F"(" '{print $1}')
echo "Renderer:"$REND
echo "if the above is llvm and not an actual card the game will not work"

#cleaning leftovers from late dinner ;)
killall $executable
killall -9 $executable

#cleaning shader cache for better performance each time
#rm -r "${shaderspath}/*"

#here I cleverly avoid calling the path with my user name :)
cd "${WINEPREFIX}${winegamepath}/${binpath}"
#here i cleverly ask to show the path so we see what WINEPREFIX was called
pwd

case $WINEARCH in
win64)
echo 64bit
case $pass in
1)
winecfg
;;
2)
winetricks
;;
3)
wine64 "${windowsgamepath}${executable}" $OPT # 2>/dev/null # &> MWLL_debug.log
#if uncommented, the last line's comment dumps a log file to the game folder - might prove usefull or a vaste of disk space
;;
esac
;;
win32)
echo 32bit
case $pass in
1)
winecfg
;;
2)
winetricks
;;
3)
#here (hopefully) no shit hits the fan, and we land in game menu
wine ${windowsgamepath}${executable} $OPT # &> MWLL_debug.log
#if uncommented, the last line's comment dumps a log file to the game folder - might prove usefull or a vaste of disk space
;;
esac
;;
esac
# to restore resolution put here what's appropriate or leave as is and just uncomment
xrandr -s 0 # last good resolution

</pre>

This should have you all set.

=== Run the editor ===
You can now start the file by typing ['''MWLLeditor.sh'''] in a command prompt and pressing enter.
Pick a map ([TC_Reference] comes to mind) and try add an brush. Here on is uncharted territory, keep me posted!

=== What breaks in the editor and how to work around it ===

''TODO''

AlienArt

2023-02-14T20:28:16Z

Fire-hound: /* Run the editor */

By Alien it's meant as totally new, possibly even strange art in respect of what's present in the Asset Pool. 
In effect successfully following this procedure will hopefully lead to gradual expansion and enrichment of the aforementioned Asset pool. 

The process:

== Preparing The geometry ==
=== now with blender 3.x ===
This is a procedure covering the ever growing technology gap between the free and ever livid
blender and the aging cryengine2. Just get any blender past 3.x release.

=== Get it ready ===
[[File:Step01.png|200px|thumb|center|Prepare Collection]]

For a Mesh to be fit for cryengine it has to fulfill several criteria due to how compromises were made.
It is a convention and if one sticks to it good results won't fail to materialize.
1. No more than two triangles should share same edge.
2. There should be nothing but triangles (or quads) as the final result - remove all and any nodes and or lines (primitives)...
3. There shoudl be no triangles of surface size zero (degenerate faces).
4. It is desirable for the mesh be airtight, but there are valid exceptions.

The Object is to be investigated for the quality and errors for UV mapping.
Only a single UV map per mesh is supported in Cryengine

The Object is to be assigned To a Collection (no more Groups in blender 3.x) that has the same name
The .blend file is to be saved with the same name as the object and collection.

We should now be ready for the export to collada (.dae file)

[[File:Step02.png|200px|thumb|center|Prepare Export]]

=== Export settings ===
[[File:Step03.png|200px|thumb|center|Collada export options]]

As seen on the image the favorable settings differ from defaults. It is therefore advisable to
create a operator preset (i aptly named "cryengine export") for further convenience.

{| class="wikitable" style="margin:auto"
|+ Parameter Meaning
|-
! Parameter name !! Explanation
|-
| Transform || Decomposed (this means rotation, translation and scale are decomposed)
|-
| Triangulate || leave no uncertain surfaces unresolved by blender.
|-
| Apply Transforms || Viewport (it is usually save to assume this is true)
|-
| Selection Only || we rarely need everything from the file - watch for proper parenting!
|-
| Include children || if parenting is properly laid out - this works miracles!
|-
| Use Object Instances || don't use this - i tried it once and it was ugly
|-
| Use Blender Profile || this is best left off - always leave it off for cryengine export.
|}

== Converting the format ==
=== Prepare your Linux ===
For this to work at all some prerequisites are to be met. You didn't think you'll get off
the hook as easy, didn't you? 
# We need working ColladaCGF in wine, for this we need working PyFFI in wine, and for this we need working Python in wine in the first place. For this all to work at all certain versions are to be downloaded and fed to wine: 
* Python 2.6.6 (or ealrier, but idealy exactly 2.6.6 (32bit release only)
* PyFFI 2.1.11 (the last one that works with 2.x python, newer require python 3.x)
* ColladaCGF 0.3.9 (the last one available)

For this to work you will need your linux to be either "multilib" (more likely applies to you) or 32bit (less likely but possible)

Install In that order (Python, PyFFI, Collada) and see it is in the right wine prefix:

both files: 
"C:\Python26\python.exe"

and

"C:\Python26\Scripts\colladacgf.py"

should be present.

Now if you are not using XFCE4 as your GUI too bad you're just out of luck. Otherwise open the Custom Actions chooser via the Edit menu of Thunar and make a new custom action:

[[File:Step04.png|200px|thumb|center|Custom Actions setup with Thunar and XFCE4]]

I named the action [ ColladaCGF ] and gave it the usual python icon. The description should be obvious: [ Convert a dae file into cgf ]. The command that worked for me was:

[ wineconsole "C:\Python26\python.exe" "C:\Python26\Scripts\colladacgf.py" %F --pause ]

where %F is a list of selected files with the full path.

The filters on the other tab are to be set accordingly: 
[ *.dae;*.DAE ]

mind the semicolon. And the affected files are the text files (.dae files look like XML files) and other files, just in case. Never mind this crazy screenshot - it is CGI - so you have it all on one place.

Apply close and restart Thunar. Now on You should have a context option for each dae file:

[[File:Step05.png|200px|thumb|center|ColladaCGF usage in XFCE on Linux]]

=== Point the ColladaCGF to the .dae file ===
The '''dae''' file is to be selected, '''rightclick > ColladaCGF''' and voila! by ''automagic'' a bunch of murr-murr and computer speak will fill a dark frame, once you notice the computer has stopped spewing insults and dark magic, there might be a blinking cursor waiting no you to press [enter] key and close the window. You might have just converted your first '''CGF''' file on Linux. Or you will be in due time. Conversions often fail due to not adhering to the convention mentioned above.

=== Find the cgf file ===
The newly generated '''.CGF''' file and it's belonging '''.MTL''' file should lay next to each other and next to the source '''.DAE''' file. There might be leftovers in the form of logs and dumps. This can be
safely ignored, they can safely be deleted too.

== Importing into engine ==

=== How to get the editor working (Glitch TKG's github) ===
I see not too many casualties to this point. Good; good, here onward it gets tough as nails, and by that i mean eating chains to fart back nails!.
https://github.com/Tk-Glitch (kudos to Tk-Glitch o/ )
https://github.com/Tk-Glitch/PKGBUILDS/wiki/wine-tkg-git#dependencies
You want to build a not only custom version of wine (as if that wasn't intimidating enough!).
No sir, you want a higly customized, overly patched VERY recent version wine-staging that has support for child-window our Sandbox2 editor uses to render the game withing it's app window.
No configurationfiles need to be modified in the [wine-tkg-git] directory, You merely cd to
it and run [./non-makepkg-build.sh]

first time you will be dropped to a shel with inof and stuff...

make the following file:

file: ['''~/.config/frogminer/wine-tkg.cfg''']:
<pre>

_LOCAL_PRESET="none"
_use_GE_patches="true"
_plain_version=""
_use_staging="true"
_staging_version="v7.22"
_use_fastsync="false"
_use_esync="true"
_use_fsync="true"
_fsync_futex_waitv="true"
_use_vkd3dlib="true"
_dxvk_dxgi="true"

_proton_battleye_support="false"
_proton_eac_support="false"
_warframelauncher_fix="false"
_mwo_fix="false"
_re4_fix="false"

_childwindow_fix="true"

_use_josh_flat_theme="true"

</pre>

And once saved, rerun the above command. Install the new wine and make MWLL run in it's prefix.

to run the editor you will need few more winetricks...
Fended of yet? no? Good, because that isn't nearly the end of the desert :D.
add (via winetricks) the follwing:
d3dcompiler_43
d3dcompiler_47
dotnet472 (needed for the launcher anyway (will pull in much down to dotnet40) )
dxvk (i have dxvk1101 so far)
vcrun2005 (MWLL needs it won't run w/o)
(add the two redists from the MWLL package, 32bit ones)
Now on the editor should launch:
(note there is no newline at the top of the file)

file: ['''~/.local/bin/MWLLeditor.sh''']:
<pre>
#! /bin/bash

v=0.10-beta
#executable=Crysis.exe
executable=Editor.exe
shaderspath=~/Documents/My\ Games/Crysis\ Wars/Shaders

i=${1:-3}

if [ "X"$i != "X" ] ; then
pass=$i
echo $i
fi

if (( $pass > 3 )) || (( $pass < 1 )); then
echo " uasge:"
echo $0 "{1|2|3}"
echo "1 = winecfg, 2 = winetricks, 3 = editor"
exit 2
fi

echo $pass

# switch comment whats appropriate
# export WINEARCH=win32
# winegamepath='/drive_c/Program Files (x86)/Electronic Arts/Crytek/Crysis Wars/Bin32'
# windowsgamepath='C:\Program Files (x86)\Electronic Arts\Crytek\Crysis Wars\Bin32\'

export WINEARCH=win64
winegamepath='/drive_c/Program Files (x86)/Electronic Arts/Crytek/Crysis Wars/Bin64'
windowsgamepath='C:\Program Files (x86)\Electronic Arts\Crytek\Crysis Wars\Bin64\'

#here we do "magic" to run DX9 (only supported so far)
#and tell Crysis we want the MWLL mod not the OEM game :^)
OPT="-dx9 -mod MWLL"
#OPT="-mod MWLL"
#OPT="-dx9"

# reducing what wine spews at us
#export WINEDEBUG=-fixme-all,-warn-all,-err-all,-all
export WINEDEBUG=-all

WINEFSYNC=1
WINEESYNC=1
DXVK_HUD=1
DXVK_FILTER_DEVICE_NAME="NVIDIA GeForce GTX 1060 3GB"

# we controll which directory we want be runned by the script
export WINEPREFIX=~/.wine

#this can really beak things if enabled but try it?
# export MESA_DEBUG=1

# we the humans check here what renders our stuff
# if not "Gallium" then it's software = too slow
REND=$(glxinfo | grep "OpenGL renderer" | awk -F: '{print $2}' | awk -F"(" '{print $1}')
echo "Renderer:"$REND
echo "if the above is llvm and not an actual card the game will not work"

#cleaning leftovers from late dinner ;)
killall $executable
killall -9 $executable

#cleaning shader cache for better performance each time
#rm -r "${shaderspath}/*"

#here I cleverly avoid calling the path with my user name :)
cd "${WINEPREFIX}${winegamepath}/${binpath}"
#here i cleverly ask to show the path so we see what WINEPREFIX was called
pwd

case $WINEARCH in
win64)
echo 64bit
case $pass in
1)
winecfg
;;
2)
winetricks
;;
3)
wine64 "${windowsgamepath}${executable}" $OPT # 2>/dev/null # &> MWLL_debug.log
#if uncommented, the last line's comment dumps a log file to the game folder - might prove usefull or a vaste of disk space
;;
esac
;;
win32)
echo 32bit
case $pass in
1)
winecfg
;;
2)
winetricks
;;
3)
#here (hopefully) no shit hits the fan, and we land in game menu
wine ${windowsgamepath}${executable} $OPT # &> MWLL_debug.log
#if uncommented, the last line's comment dumps a log file to the game folder - might prove usefull or a vaste of disk space
;;
esac
;;
esac
# to restore resolution put here what's appropriate or leave as is and just uncomment
xrandr -s 0 # last good resolution

</pre>

This should have you all set.

=== Run the editor ===
You can now start the file by typing ['''MWLLeditor.sh'''] in a command prompt and pressing enter.
Pick a map ([TC_Reference] comes to mind) and try add an brush. Here on is uncharted territory, keep me posted!

=== What breaks in the editor and how to work around it ===

''TODO''

AlienArt

2023-02-14T20:27:35Z

Fire-hound: /* Prepare your Linux */

By Alien it's meant as totally new, possibly even strange art in respect of what's present in the Asset Pool. 
In effect successfully following this procedure will hopefully lead to gradual expansion and enrichment of the aforementioned Asset pool. 

The process:

== Preparing The geometry ==
=== now with blender 3.x ===
This is a procedure covering the ever growing technology gap between the free and ever livid
blender and the aging cryengine2. Just get any blender past 3.x release.

=== Get it ready ===
[[File:Step01.png|200px|thumb|center|Prepare Collection]]

For a Mesh to be fit for cryengine it has to fulfill several criteria due to how compromises were made.
It is a convention and if one sticks to it good results won't fail to materialize.
1. No more than two triangles should share same edge.
2. There should be nothing but triangles (or quads) as the final result - remove all and any nodes and or lines (primitives)...
3. There shoudl be no triangles of surface size zero (degenerate faces).
4. It is desirable for the mesh be airtight, but there are valid exceptions.

The Object is to be investigated for the quality and errors for UV mapping.
Only a single UV map per mesh is supported in Cryengine

The Object is to be assigned To a Collection (no more Groups in blender 3.x) that has the same name
The .blend file is to be saved with the same name as the object and collection.

We should now be ready for the export to collada (.dae file)

[[File:Step02.png|200px|thumb|center|Prepare Export]]

=== Export settings ===
[[File:Step03.png|200px|thumb|center|Collada export options]]

As seen on the image the favorable settings differ from defaults. It is therefore advisable to
create a operator preset (i aptly named "cryengine export") for further convenience.

{| class="wikitable" style="margin:auto"
|+ Parameter Meaning
|-
! Parameter name !! Explanation
|-
| Transform || Decomposed (this means rotation, translation and scale are decomposed)
|-
| Triangulate || leave no uncertain surfaces unresolved by blender.
|-
| Apply Transforms || Viewport (it is usually save to assume this is true)
|-
| Selection Only || we rarely need everything from the file - watch for proper parenting!
|-
| Include children || if parenting is properly laid out - this works miracles!
|-
| Use Object Instances || don't use this - i tried it once and it was ugly
|-
| Use Blender Profile || this is best left off - always leave it off for cryengine export.
|}

== Converting the format ==
=== Prepare your Linux ===
For this to work at all some prerequisites are to be met. You didn't think you'll get off
the hook as easy, didn't you? 
# We need working ColladaCGF in wine, for this we need working PyFFI in wine, and for this we need working Python in wine in the first place. For this all to work at all certain versions are to be downloaded and fed to wine: 
* Python 2.6.6 (or ealrier, but idealy exactly 2.6.6 (32bit release only)
* PyFFI 2.1.11 (the last one that works with 2.x python, newer require python 3.x)
* ColladaCGF 0.3.9 (the last one available)

For this to work you will need your linux to be either "multilib" (more likely applies to you) or 32bit (less likely but possible)

Install In that order (Python, PyFFI, Collada) and see it is in the right wine prefix:

both files: 
"C:\Python26\python.exe"

and

"C:\Python26\Scripts\colladacgf.py"

should be present.

Now if you are not using XFCE4 as your GUI too bad you're just out of luck. Otherwise open the Custom Actions chooser via the Edit menu of Thunar and make a new custom action:

[[File:Step04.png|200px|thumb|center|Custom Actions setup with Thunar and XFCE4]]

I named the action [ ColladaCGF ] and gave it the usual python icon. The description should be obvious: [ Convert a dae file into cgf ]. The command that worked for me was:

[ wineconsole "C:\Python26\python.exe" "C:\Python26\Scripts\colladacgf.py" %F --pause ]

where %F is a list of selected files with the full path.

The filters on the other tab are to be set accordingly: 
[ *.dae;*.DAE ]

mind the semicolon. And the affected files are the text files (.dae files look like XML files) and other files, just in case. Never mind this crazy screenshot - it is CGI - so you have it all on one place.

Apply close and restart Thunar. Now on You should have a context option for each dae file:

[[File:Step05.png|200px|thumb|center|ColladaCGF usage in XFCE on Linux]]

=== Point the ColladaCGF to the .dae file ===
The '''dae''' file is to be selected, '''rightclick > ColladaCGF''' and voila! by ''automagic'' a bunch of murr-murr and computer speak will fill a dark frame, once you notice the computer has stopped spewing insults and dark magic, there might be a blinking cursor waiting no you to press [enter] key and close the window. You might have just converted your first '''CGF''' file on Linux. Or you will be in due time. Conversions often fail due to not adhering to the convention mentioned above.

=== Find the cgf file ===
The newly generated '''.CGF''' file and it's belonging '''.MTL''' file should lay next to each other and next to the source '''.DAE''' file. There might be leftovers in the form of logs and dumps. This can be
safely ignored, they can safely be deleted too.

== Importing into engine ==

=== How to get the editor working (Glitch TKG's github) ===
I see not too many casualties to this point. Good; good, here onward it gets tough as nails, and by that i mean eating chains to fart back nails!.
https://github.com/Tk-Glitch (kudos to Tk-Glitch o/ )
https://github.com/Tk-Glitch/PKGBUILDS/wiki/wine-tkg-git#dependencies
You want to build a not only custom version of wine (as if that wasn't intimidating enough!).
No sir, you want a higly customized, overly patched VERY recent version wine-staging that has support for child-window our Sandbox2 editor uses to render the game withing it's app window.
No configurationfiles need to be modified in the [wine-tkg-git] directory, You merely cd to
it and run [./non-makepkg-build.sh]

first time you will be dropped to a shel with inof and stuff...

make the following file:

file: ['''~/.config/frogminer/wine-tkg.cfg''']:
<pre>

_LOCAL_PRESET="none"
_use_GE_patches="true"
_plain_version=""
_use_staging="true"
_staging_version="v7.22"
_use_fastsync="false"
_use_esync="true"
_use_fsync="true"
_fsync_futex_waitv="true"
_use_vkd3dlib="true"
_dxvk_dxgi="true"

_proton_battleye_support="false"
_proton_eac_support="false"
_warframelauncher_fix="false"
_mwo_fix="false"
_re4_fix="false"

_childwindow_fix="true"

_use_josh_flat_theme="true"

</pre>

And once saved, rerun the above command. Install the new wine and make MWLL run in it's prefix.

to run the editor you will need few more winetricks...
Fended of yet? no? Good, because that isn't nearly the end of the desert :D.
add (via winetricks) the follwing:
d3dcompiler_43
d3dcompiler_47
dotnet472 (needed for the launcher anyway (will pull in much down to dotnet40) )
dxvk (i have dxvk1101 so far)
vcrun2005 (MWLL needs it won't run w/o)
(add the two redists from the MWLL package, 32bit ones)
Now on the editor should launch:
(note there is no newline at the top of the file)

file: ['''~/.local/bin/MWLLeditor.sh''']:
<pre>
#! /bin/bash

v=0.10-beta
#executable=Crysis.exe
executable=Editor.exe
shaderspath=~/Documents/My\ Games/Crysis\ Wars/Shaders

i=${1:-3}

if [ "X"$i != "X" ] ; then
pass=$i
echo $i
fi

if (( $pass > 3 )) || (( $pass < 1 )); then
echo " uasge:"
echo $0 "{1|2|3}"
echo "1 = winecfg, 2 = winetricks, 3 = editor"
exit 2
fi

echo $pass

# switch comment whats appropriate
# export WINEARCH=win32
# winegamepath='/drive_c/Program Files (x86)/Electronic Arts/Crytek/Crysis Wars/Bin32'
# windowsgamepath='C:\Program Files (x86)\Electronic Arts\Crytek\Crysis Wars\Bin32\'

export WINEARCH=win64
winegamepath='/drive_c/Program Files (x86)/Electronic Arts/Crytek/Crysis Wars/Bin64'
windowsgamepath='C:\Program Files (x86)\Electronic Arts\Crytek\Crysis Wars\Bin64\'

#here we do "magic" to run DX9 (only supported so far)
#and tell Crysis we want the MWLL mod not the OEM game :^)
OPT="-dx9 -mod MWLL"
#OPT="-mod MWLL"
#OPT="-dx9"

# reducing what wine spews at us
#export WINEDEBUG=-fixme-all,-warn-all,-err-all,-all
export WINEDEBUG=-all

WINEFSYNC=1
WINEESYNC=1
DXVK_HUD=1
DXVK_FILTER_DEVICE_NAME="NVIDIA GeForce GTX 1060 3GB"

# we controll which directory we want be runned by the script
export WINEPREFIX=~/.wine

#this can really beak things if enabled but try it?
# export MESA_DEBUG=1

# we the humans check here what renders our stuff
# if not "Gallium" then it's software = too slow
REND=$(glxinfo | grep "OpenGL renderer" | awk -F: '{print $2}' | awk -F"(" '{print $1}')
echo "Renderer:"$REND
echo "if the above is llvm and not an actual card the game will not work"

#cleaning leftovers from late dinner ;)
killall $executable
killall -9 $executable

#cleaning shader cache for better performance each time
#rm -r "${shaderspath}/*"

#here I cleverly avoid calling the path with my user name :)
cd "${WINEPREFIX}${winegamepath}/${binpath}"
#here i cleverly ask to show the path so we see what WINEPREFIX was called
pwd

case $WINEARCH in
win64)
echo 64bit
case $pass in
1)
winecfg
;;
2)
winetricks
;;
3)
wine64 "${windowsgamepath}${executable}" $OPT # 2>/dev/null # &> MWLL_debug.log
#if uncommented, the last line's comment dumps a log file to the game folder - might prove usefull or a vaste of disk space
;;
esac
;;
win32)
echo 32bit
case $pass in
1)
winecfg
;;
2)
winetricks
;;
3)
#here (hopefully) no shit hits the fan, and we land in game menu
wine ${windowsgamepath}${executable} $OPT # &> MWLL_debug.log
#if uncommented, the last line's comment dumps a log file to the game folder - might prove usefull or a vaste of disk space
;;
esac
;;
esac
# to restore resolution put here what's appropriate or leave as is and just uncomment
xrandr -s 0 # last good resolution

</pre>

This should have you all set.

=== Run the editor ===
You can now start the file by typing [MWLLeditor] in a command prompt and pressing enter.
Pick a map ([TC_Reference] comes to mind) and try add an brush. Here on is uncharted territory, keep me posted!

=== What breaks in the editor and how to work around it ===

''TODO''

AlienArt

2023-02-14T20:26:32Z

Fire-hound: /* Export settings */

By Alien it's meant as totally new, possibly even strange art in respect of what's present in the Asset Pool. 
In effect successfully following this procedure will hopefully lead to gradual expansion and enrichment of the aforementioned Asset pool. 

The process:

== Preparing The geometry ==
=== now with blender 3.x ===
This is a procedure covering the ever growing technology gap between the free and ever livid
blender and the aging cryengine2. Just get any blender past 3.x release.

=== Get it ready ===
[[File:Step01.png|200px|thumb|center|Prepare Collection]]

For a Mesh to be fit for cryengine it has to fulfill several criteria due to how compromises were made.
It is a convention and if one sticks to it good results won't fail to materialize.
1. No more than two triangles should share same edge.
2. There should be nothing but triangles (or quads) as the final result - remove all and any nodes and or lines (primitives)...
3. There shoudl be no triangles of surface size zero (degenerate faces).
4. It is desirable for the mesh be airtight, but there are valid exceptions.

The Object is to be investigated for the quality and errors for UV mapping.
Only a single UV map per mesh is supported in Cryengine

The Object is to be assigned To a Collection (no more Groups in blender 3.x) that has the same name
The .blend file is to be saved with the same name as the object and collection.

We should now be ready for the export to collada (.dae file)

[[File:Step02.png|200px|thumb|center|Prepare Export]]

=== Export settings ===
[[File:Step03.png|200px|thumb|center|Collada export options]]

As seen on the image the favorable settings differ from defaults. It is therefore advisable to
create a operator preset (i aptly named "cryengine export") for further convenience.

{| class="wikitable" style="margin:auto"
|+ Parameter Meaning
|-
! Parameter name !! Explanation
|-
| Transform || Decomposed (this means rotation, translation and scale are decomposed)
|-
| Triangulate || leave no uncertain surfaces unresolved by blender.
|-
| Apply Transforms || Viewport (it is usually save to assume this is true)
|-
| Selection Only || we rarely need everything from the file - watch for proper parenting!
|-
| Include children || if parenting is properly laid out - this works miracles!
|-
| Use Object Instances || don't use this - i tried it once and it was ugly
|-
| Use Blender Profile || this is best left off - always leave it off for cryengine export.
|}

== Converting the format ==
=== Prepare your Linux ===
For this to work at all some prerequisites are to be met. You didn't think you'll get off
the hook as easy, didn't you? 
# We need working ColladaCGF in wine, for this we need working PyFFI in wine, and for this we need working Python in wine in the first place. For this all to work at all certain versions are to be downloaded and fed to wine: 
* Python 2.6.6 (or ealrier, but idealy exactly 2.6.6 (32bit release only)
* PyFFI 2.1.11 (the last one that works with 2.x python, newer require python 3.x)
* ColladaCGF 0.3.9 (the last one available)

For this to work you will need your linux to be either "multilib" (more likely applies to you) or 32bit (less likely but possible)

Install In that order (Python, PyFFI, Collada) and see it is in the right wine prefix:

both files: 
"C:\Python26\python.exe"

and

"C:\Python26\Scripts\colladacgf.py"

should be present.

Now if you are not using XFCE4 as your GUI too bad you're just out of luck. Otherwise open the Custom Actions chooser via the Edit menu of Thunar and make a new custom action:

[[File:Step04.png|200px|thumb|center|alt text]]

I named the action [ ColladaCGF ] and gave it the usual python icon. The description should be obvious: [ Convert a dae file into cgf ]. The command that worked for me was:

[ wineconsole "C:\Python26\python.exe" "C:\Python26\Scripts\colladacgf.py" %F --pause ]

where %F is a list of selected files with the full path.

The filters on the other tab are to be set accordingly: 
[ *.dae;*.DAE ]

mind the semicolon. And the affected files are the text files (.dae files look like XML files) and other files, just in case. Never mind this crazy screenshot - it is CGI - so you have it all on one place.

Apply close and restart Thunar. Now on You should have a context option for each dae file:

[[File:Step05.png|200px|thumb|center|alt text]]

=== Point the ColladaCGF to the .dae file ===
The '''dae''' file is to be selected, '''rightclick > ColladaCGF''' and voila! by ''automagic'' a bunch of murr-murr and computer speak will fill a dark frame, once you notice the computer has stopped spewing insults and dark magic, there might be a blinking cursor waiting no you to press [enter] key and close the window. You might have just converted your first '''CGF''' file on Linux. Or you will be in due time. Conversions often fail due to not adhering to the convention mentioned above.

=== Find the cgf file ===
The newly generated '''.CGF''' file and it's belonging '''.MTL''' file should lay next to each other and next to the source '''.DAE''' file. There might be leftovers in the form of logs and dumps. This can be
safely ignored, they can safely be deleted too.

== Importing into engine ==

=== How to get the editor working (Glitch TKG's github) ===
I see not too many casualties to this point. Good; good, here onward it gets tough as nails, and by that i mean eating chains to fart back nails!.
https://github.com/Tk-Glitch (kudos to Tk-Glitch o/ )
https://github.com/Tk-Glitch/PKGBUILDS/wiki/wine-tkg-git#dependencies
You want to build a not only custom version of wine (as if that wasn't intimidating enough!).
No sir, you want a higly customized, overly patched VERY recent version wine-staging that has support for child-window our Sandbox2 editor uses to render the game withing it's app window.
No configurationfiles need to be modified in the [wine-tkg-git] directory, You merely cd to
it and run [./non-makepkg-build.sh]

first time you will be dropped to a shel with inof and stuff...

make the following file:

file: ['''~/.config/frogminer/wine-tkg.cfg''']:
<pre>

_LOCAL_PRESET="none"
_use_GE_patches="true"
_plain_version=""
_use_staging="true"
_staging_version="v7.22"
_use_fastsync="false"
_use_esync="true"
_use_fsync="true"
_fsync_futex_waitv="true"
_use_vkd3dlib="true"
_dxvk_dxgi="true"

_proton_battleye_support="false"
_proton_eac_support="false"
_warframelauncher_fix="false"
_mwo_fix="false"
_re4_fix="false"

_childwindow_fix="true"

_use_josh_flat_theme="true"

</pre>

And once saved, rerun the above command. Install the new wine and make MWLL run in it's prefix.

to run the editor you will need few more winetricks...
Fended of yet? no? Good, because that isn't nearly the end of the desert :D.
add (via winetricks) the follwing:
d3dcompiler_43
d3dcompiler_47
dotnet472 (needed for the launcher anyway (will pull in much down to dotnet40) )
dxvk (i have dxvk1101 so far)
vcrun2005 (MWLL needs it won't run w/o)
(add the two redists from the MWLL package, 32bit ones)
Now on the editor should launch:
(note there is no newline at the top of the file)

file: ['''~/.local/bin/MWLLeditor.sh''']:
<pre>
#! /bin/bash

v=0.10-beta
#executable=Crysis.exe
executable=Editor.exe
shaderspath=~/Documents/My\ Games/Crysis\ Wars/Shaders

i=${1:-3}

if [ "X"$i != "X" ] ; then
pass=$i
echo $i
fi

if (( $pass > 3 )) || (( $pass < 1 )); then
echo " uasge:"
echo $0 "{1|2|3}"
echo "1 = winecfg, 2 = winetricks, 3 = editor"
exit 2
fi

echo $pass

# switch comment whats appropriate
# export WINEARCH=win32
# winegamepath='/drive_c/Program Files (x86)/Electronic Arts/Crytek/Crysis Wars/Bin32'
# windowsgamepath='C:\Program Files (x86)\Electronic Arts\Crytek\Crysis Wars\Bin32\'

export WINEARCH=win64
winegamepath='/drive_c/Program Files (x86)/Electronic Arts/Crytek/Crysis Wars/Bin64'
windowsgamepath='C:\Program Files (x86)\Electronic Arts\Crytek\Crysis Wars\Bin64\'

#here we do "magic" to run DX9 (only supported so far)
#and tell Crysis we want the MWLL mod not the OEM game :^)
OPT="-dx9 -mod MWLL"
#OPT="-mod MWLL"
#OPT="-dx9"

# reducing what wine spews at us
#export WINEDEBUG=-fixme-all,-warn-all,-err-all,-all
export WINEDEBUG=-all

WINEFSYNC=1
WINEESYNC=1
DXVK_HUD=1
DXVK_FILTER_DEVICE_NAME="NVIDIA GeForce GTX 1060 3GB"

# we controll which directory we want be runned by the script
export WINEPREFIX=~/.wine

#this can really beak things if enabled but try it?
# export MESA_DEBUG=1

# we the humans check here what renders our stuff
# if not "Gallium" then it's software = too slow
REND=$(glxinfo | grep "OpenGL renderer" | awk -F: '{print $2}' | awk -F"(" '{print $1}')
echo "Renderer:"$REND
echo "if the above is llvm and not an actual card the game will not work"

#cleaning leftovers from late dinner ;)
killall $executable
killall -9 $executable

#cleaning shader cache for better performance each time
#rm -r "${shaderspath}/*"

#here I cleverly avoid calling the path with my user name :)
cd "${WINEPREFIX}${winegamepath}/${binpath}"
#here i cleverly ask to show the path so we see what WINEPREFIX was called
pwd

case $WINEARCH in
win64)
echo 64bit
case $pass in
1)
winecfg
;;
2)
winetricks
;;
3)
wine64 "${windowsgamepath}${executable}" $OPT # 2>/dev/null # &> MWLL_debug.log
#if uncommented, the last line's comment dumps a log file to the game folder - might prove usefull or a vaste of disk space
;;
esac
;;
win32)
echo 32bit
case $pass in
1)
winecfg
;;
2)
winetricks
;;
3)
#here (hopefully) no shit hits the fan, and we land in game menu
wine ${windowsgamepath}${executable} $OPT # &> MWLL_debug.log
#if uncommented, the last line's comment dumps a log file to the game folder - might prove usefull or a vaste of disk space
;;
esac
;;
esac
# to restore resolution put here what's appropriate or leave as is and just uncomment
xrandr -s 0 # last good resolution

</pre>

This should have you all set.

=== Run the editor ===
You can now start the file by typing [MWLLeditor] in a command prompt and pressing enter.
Pick a map ([TC_Reference] comes to mind) and try add an brush. Here on is uncharted territory, keep me posted!

=== What breaks in the editor and how to work around it ===

''TODO''

File:Step05.png

2023-02-14T20:25:02Z

Fire-hound: Usage example of ColladaCGF with XFCE4, on Linux.

Usage example of ColladaCGF with XFCE4, on Linux.

File:Step04.png

2023-02-14T20:23:58Z

Fire-hound: Thunar Special Actions set up for ColladaCGF

Thunar Special Actions set up for ColladaCGF

File:Step03.png

2023-02-14T20:22:02Z

Fire-hound: Collada export options in 3.x blender

Collada export options in 3.x blender

AlienArt

2023-02-14T20:21:16Z

Fire-hound: /* Prepare your Linux */

By Alien it's meant as totally new, possibly even strange art in respect of what's present in the Asset Pool. 
In effect successfully following this procedure will hopefully lead to gradual expansion and enrichment of the aforementioned Asset pool. 

The process:

== Preparing The geometry ==
=== now with blender 3.x ===
This is a procedure covering the ever growing technology gap between the free and ever livid
blender and the aging cryengine2. Just get any blender past 3.x release.

=== Get it ready ===
[[File:Step01.png|200px|thumb|center|Prepare Collection]]

For a Mesh to be fit for cryengine it has to fulfill several criteria due to how compromises were made.
It is a convention and if one sticks to it good results won't fail to materialize.
1. No more than two triangles should share same edge.
2. There should be nothing but triangles (or quads) as the final result - remove all and any nodes and or lines (primitives)...
3. There shoudl be no triangles of surface size zero (degenerate faces).
4. It is desirable for the mesh be airtight, but there are valid exceptions.

The Object is to be investigated for the quality and errors for UV mapping.
Only a single UV map per mesh is supported in Cryengine

The Object is to be assigned To a Collection (no more Groups in blender 3.x) that has the same name
The .blend file is to be saved with the same name as the object and collection.

We should now be ready for the export to collada (.dae file)

[[File:Step02.png|200px|thumb|center|Prepare Export]]

=== Export settings ===
[[File:Step03.png|200px|thumb|center|alt text]]

As seen on the image the favorable settings differ from defaults. It is therefore advisable to
create a operator preset (i aptly named "cryengine export") for further convenience.

{| class="wikitable" style="margin:auto"
|+ Parameter Meaning
|-
! Parameter name !! Explanation
|-
| Transform || Decomposed (this means rotation, translation and scale are decomposed)
|-
| Triangulate || leave no uncertain surfaces unresolved by blender.
|-
| Apply Transforms || Viewport (it is usually save to assume this is true)
|-
| Selection Only || we rarely need everything from the file - watch for proper parenting!
|-
| Include children || if parenting is properly laid out - this works miracles!
|-
| Use Object Instances || don't use this - i tried it once and it was ugly
|-
| Use Blender Profile || this is best left off - always leave it off for cryengine export.
|}

== Converting the format ==
=== Prepare your Linux ===
For this to work at all some prerequisites are to be met. You didn't think you'll get off
the hook as easy, didn't you? 
# We need working ColladaCGF in wine, for this we need working PyFFI in wine, and for this we need working Python in wine in the first place. For this all to work at all certain versions are to be downloaded and fed to wine: 
* Python 2.6.6 (or ealrier, but idealy exactly 2.6.6 (32bit release only)
* PyFFI 2.1.11 (the last one that works with 2.x python, newer require python 3.x)
* ColladaCGF 0.3.9 (the last one available)

For this to work you will need your linux to be either "multilib" (more likely applies to you) or 32bit (less likely but possible)

Install In that order (Python, PyFFI, Collada) and see it is in the right wine prefix:

both files: 
"C:\Python26\python.exe"

and

"C:\Python26\Scripts\colladacgf.py"

should be present.

Now if you are not using XFCE4 as your GUI too bad you're just out of luck. Otherwise open the Custom Actions chooser via the Edit menu of Thunar and make a new custom action:

[[File:Step04.png|200px|thumb|center|alt text]]

I named the action [ ColladaCGF ] and gave it the usual python icon. The description should be obvious: [ Convert a dae file into cgf ]. The command that worked for me was:

[ wineconsole "C:\Python26\python.exe" "C:\Python26\Scripts\colladacgf.py" %F --pause ]

where %F is a list of selected files with the full path.

The filters on the other tab are to be set accordingly: 
[ *.dae;*.DAE ]

mind the semicolon. And the affected files are the text files (.dae files look like XML files) and other files, just in case. Never mind this crazy screenshot - it is CGI - so you have it all on one place.

Apply close and restart Thunar. Now on You should have a context option for each dae file:

[[File:Step05.png|200px|thumb|center|alt text]]

=== Point the ColladaCGF to the .dae file ===
The '''dae''' file is to be selected, '''rightclick > ColladaCGF''' and voila! by ''automagic'' a bunch of murr-murr and computer speak will fill a dark frame, once you notice the computer has stopped spewing insults and dark magic, there might be a blinking cursor waiting no you to press [enter] key and close the window. You might have just converted your first '''CGF''' file on Linux. Or you will be in due time. Conversions often fail due to not adhering to the convention mentioned above.

=== Find the cgf file ===
The newly generated '''.CGF''' file and it's belonging '''.MTL''' file should lay next to each other and next to the source '''.DAE''' file. There might be leftovers in the form of logs and dumps. This can be
safely ignored, they can safely be deleted too.

== Importing into engine ==

=== How to get the editor working (Glitch TKG's github) ===
I see not too many casualties to this point. Good; good, here onward it gets tough as nails, and by that i mean eating chains to fart back nails!.
https://github.com/Tk-Glitch (kudos to Tk-Glitch o/ )
https://github.com/Tk-Glitch/PKGBUILDS/wiki/wine-tkg-git#dependencies
You want to build a not only custom version of wine (as if that wasn't intimidating enough!).
No sir, you want a higly customized, overly patched VERY recent version wine-staging that has support for child-window our Sandbox2 editor uses to render the game withing it's app window.
No configurationfiles need to be modified in the [wine-tkg-git] directory, You merely cd to
it and run [./non-makepkg-build.sh]

first time you will be dropped to a shel with inof and stuff...

make the following file:

file: ['''~/.config/frogminer/wine-tkg.cfg''']:
<pre>

_LOCAL_PRESET="none"
_use_GE_patches="true"
_plain_version=""
_use_staging="true"
_staging_version="v7.22"
_use_fastsync="false"
_use_esync="true"
_use_fsync="true"
_fsync_futex_waitv="true"
_use_vkd3dlib="true"
_dxvk_dxgi="true"

_proton_battleye_support="false"
_proton_eac_support="false"
_warframelauncher_fix="false"
_mwo_fix="false"
_re4_fix="false"

_childwindow_fix="true"

_use_josh_flat_theme="true"

</pre>

And once saved, rerun the above command. Install the new wine and make MWLL run in it's prefix.

to run the editor you will need few more winetricks...
Fended of yet? no? Good, because that isn't nearly the end of the desert :D.
add (via winetricks) the follwing:
d3dcompiler_43
d3dcompiler_47
dotnet472 (needed for the launcher anyway (will pull in much down to dotnet40) )
dxvk (i have dxvk1101 so far)
vcrun2005 (MWLL needs it won't run w/o)
(add the two redists from the MWLL package, 32bit ones)
Now on the editor should launch:
(note there is no newline at the top of the file)

file: ['''~/.local/bin/MWLLeditor.sh''']:
<pre>
#! /bin/bash

v=0.10-beta
#executable=Crysis.exe
executable=Editor.exe
shaderspath=~/Documents/My\ Games/Crysis\ Wars/Shaders

i=${1:-3}

if [ "X"$i != "X" ] ; then
pass=$i
echo $i
fi

if (( $pass > 3 )) || (( $pass < 1 )); then
echo " uasge:"
echo $0 "{1|2|3}"
echo "1 = winecfg, 2 = winetricks, 3 = editor"
exit 2
fi

echo $pass

# switch comment whats appropriate
# export WINEARCH=win32
# winegamepath='/drive_c/Program Files (x86)/Electronic Arts/Crytek/Crysis Wars/Bin32'
# windowsgamepath='C:\Program Files (x86)\Electronic Arts\Crytek\Crysis Wars\Bin32\'

export WINEARCH=win64
winegamepath='/drive_c/Program Files (x86)/Electronic Arts/Crytek/Crysis Wars/Bin64'
windowsgamepath='C:\Program Files (x86)\Electronic Arts\Crytek\Crysis Wars\Bin64\'

#here we do "magic" to run DX9 (only supported so far)
#and tell Crysis we want the MWLL mod not the OEM game :^)
OPT="-dx9 -mod MWLL"
#OPT="-mod MWLL"
#OPT="-dx9"

# reducing what wine spews at us
#export WINEDEBUG=-fixme-all,-warn-all,-err-all,-all
export WINEDEBUG=-all

WINEFSYNC=1
WINEESYNC=1
DXVK_HUD=1
DXVK_FILTER_DEVICE_NAME="NVIDIA GeForce GTX 1060 3GB"

# we controll which directory we want be runned by the script
export WINEPREFIX=~/.wine

#this can really beak things if enabled but try it?
# export MESA_DEBUG=1

# we the humans check here what renders our stuff
# if not "Gallium" then it's software = too slow
REND=$(glxinfo | grep "OpenGL renderer" | awk -F: '{print $2}' | awk -F"(" '{print $1}')
echo "Renderer:"$REND
echo "if the above is llvm and not an actual card the game will not work"

#cleaning leftovers from late dinner ;)
killall $executable
killall -9 $executable

#cleaning shader cache for better performance each time
#rm -r "${shaderspath}/*"

#here I cleverly avoid calling the path with my user name :)
cd "${WINEPREFIX}${winegamepath}/${binpath}"
#here i cleverly ask to show the path so we see what WINEPREFIX was called
pwd

case $WINEARCH in
win64)
echo 64bit
case $pass in
1)
winecfg
;;
2)
winetricks
;;
3)
wine64 "${windowsgamepath}${executable}" $OPT # 2>/dev/null # &> MWLL_debug.log
#if uncommented, the last line's comment dumps a log file to the game folder - might prove usefull or a vaste of disk space
;;
esac
;;
win32)
echo 32bit
case $pass in
1)
winecfg
;;
2)
winetricks
;;
3)
#here (hopefully) no shit hits the fan, and we land in game menu
wine ${windowsgamepath}${executable} $OPT # &> MWLL_debug.log
#if uncommented, the last line's comment dumps a log file to the game folder - might prove usefull or a vaste of disk space
;;
esac
;;
esac
# to restore resolution put here what's appropriate or leave as is and just uncomment
xrandr -s 0 # last good resolution

</pre>

This should have you all set.

=== Run the editor ===
You can now start the file by typing [MWLLeditor] in a command prompt and pressing enter.
Pick a map ([TC_Reference] comes to mind) and try add an brush. Here on is uncharted territory, keep me posted!

=== What breaks in the editor and how to work around it ===

''TODO''

AlienArt

2023-02-14T20:20:38Z

Fire-hound: /* Export settings */ graphics

By Alien it's meant as totally new, possibly even strange art in respect of what's present in the Asset Pool. 
In effect successfully following this procedure will hopefully lead to gradual expansion and enrichment of the aforementioned Asset pool. 

The process:

== Preparing The geometry ==
=== now with blender 3.x ===
This is a procedure covering the ever growing technology gap between the free and ever livid
blender and the aging cryengine2. Just get any blender past 3.x release.

=== Get it ready ===
[[File:Step01.png|200px|thumb|center|Prepare Collection]]

For a Mesh to be fit for cryengine it has to fulfill several criteria due to how compromises were made.
It is a convention and if one sticks to it good results won't fail to materialize.
1. No more than two triangles should share same edge.
2. There should be nothing but triangles (or quads) as the final result - remove all and any nodes and or lines (primitives)...
3. There shoudl be no triangles of surface size zero (degenerate faces).
4. It is desirable for the mesh be airtight, but there are valid exceptions.

The Object is to be investigated for the quality and errors for UV mapping.
Only a single UV map per mesh is supported in Cryengine

The Object is to be assigned To a Collection (no more Groups in blender 3.x) that has the same name
The .blend file is to be saved with the same name as the object and collection.

We should now be ready for the export to collada (.dae file)

[[File:Step02.png|200px|thumb|center|Prepare Export]]

=== Export settings ===
[[File:Step03.png|200px|thumb|center|alt text]]

As seen on the image the favorable settings differ from defaults. It is therefore advisable to
create a operator preset (i aptly named "cryengine export") for further convenience.

{| class="wikitable" style="margin:auto"
|+ Parameter Meaning
|-
! Parameter name !! Explanation
|-
| Transform || Decomposed (this means rotation, translation and scale are decomposed)
|-
| Triangulate || leave no uncertain surfaces unresolved by blender.
|-
| Apply Transforms || Viewport (it is usually save to assume this is true)
|-
| Selection Only || we rarely need everything from the file - watch for proper parenting!
|-
| Include children || if parenting is properly laid out - this works miracles!
|-
| Use Object Instances || don't use this - i tried it once and it was ugly
|-
| Use Blender Profile || this is best left off - always leave it off for cryengine export.
|}

== Converting the format ==
=== Prepare your Linux ===
For this to work at all some prerequisites are to be met. You didn't think you'll get off
the hook as easy, didn't you? 
# We need working ColladaCGF in wine, for this we need working PyFFI in wine, and for this we need working Python in wine in the first place. For this all to work at all certain versions are to be downloaded and fed to wine: 
* Python 2.6.6 (or ealrier, but idealy exactly 2.6.6 (32bit release only)
* PyFFI 2.1.11 (the last one that works with 2.x python, newer require python 3.x)
* ColladaCGF 0.3.9 (the last one available)

For this to work you will need your linux to be either "multilib" (more likely applies to you) or 32bit (less likely but possible)

Install In that order (Python, PyFFI, Collada) and see it is in the right wine prefix:

both files: 
"C:\Python26\python.exe"

and

"C:\Python26\Scripts\colladacgf.py"

should be present.

Now if you are not using XFCE4 as your GUI too bad you're just out of luck. Otherwise open the Custom Actions chooser via the Edit menu of Thunar and make a new custom action:

Step04.png

I named the action [ ColladaCGF ] and gave it the usual python icon. The description should be obvious: [ Convert a dae file into cgf ]. The command that worked for me was:

[ wineconsole "C:\Python26\python.exe" "C:\Python26\Scripts\colladacgf.py" %F --pause ]

where %F is a list of selected files with the full path.

The filters on the other tab are to be set accordingly: 
[ *.dae;*.DAE ]

mind the semicolon. And the affected files are the text files (.dae files look like XML files) and other files, just in case. Never mind this crazy screenshot - it is CGI - so you have it all on one place.

Apply close and restart Thunar. Now on You should have a context option for each dae file:

Step05.png

=== Point the ColladaCGF to the .dae file ===
The '''dae''' file is to be selected, '''rightclick > ColladaCGF''' and voila! by ''automagic'' a bunch of murr-murr and computer speak will fill a dark frame, once you notice the computer has stopped spewing insults and dark magic, there might be a blinking cursor waiting no you to press [enter] key and close the window. You might have just converted your first '''CGF''' file on Linux. Or you will be in due time. Conversions often fail due to not adhering to the convention mentioned above.

=== Find the cgf file ===
The newly generated '''.CGF''' file and it's belonging '''.MTL''' file should lay next to each other and next to the source '''.DAE''' file. There might be leftovers in the form of logs and dumps. This can be
safely ignored, they can safely be deleted too.

== Importing into engine ==

=== How to get the editor working (Glitch TKG's github) ===
I see not too many casualties to this point. Good; good, here onward it gets tough as nails, and by that i mean eating chains to fart back nails!.
https://github.com/Tk-Glitch (kudos to Tk-Glitch o/ )
https://github.com/Tk-Glitch/PKGBUILDS/wiki/wine-tkg-git#dependencies
You want to build a not only custom version of wine (as if that wasn't intimidating enough!).
No sir, you want a higly customized, overly patched VERY recent version wine-staging that has support for child-window our Sandbox2 editor uses to render the game withing it's app window.
No configurationfiles need to be modified in the [wine-tkg-git] directory, You merely cd to
it and run [./non-makepkg-build.sh]

first time you will be dropped to a shel with inof and stuff...

make the following file:

file: ['''~/.config/frogminer/wine-tkg.cfg''']:
<pre>

_LOCAL_PRESET="none"
_use_GE_patches="true"
_plain_version=""
_use_staging="true"
_staging_version="v7.22"
_use_fastsync="false"
_use_esync="true"
_use_fsync="true"
_fsync_futex_waitv="true"
_use_vkd3dlib="true"
_dxvk_dxgi="true"

_proton_battleye_support="false"
_proton_eac_support="false"
_warframelauncher_fix="false"
_mwo_fix="false"
_re4_fix="false"

_childwindow_fix="true"

_use_josh_flat_theme="true"

</pre>

And once saved, rerun the above command. Install the new wine and make MWLL run in it's prefix.

to run the editor you will need few more winetricks...
Fended of yet? no? Good, because that isn't nearly the end of the desert :D.
add (via winetricks) the follwing:
d3dcompiler_43
d3dcompiler_47
dotnet472 (needed for the launcher anyway (will pull in much down to dotnet40) )
dxvk (i have dxvk1101 so far)
vcrun2005 (MWLL needs it won't run w/o)
(add the two redists from the MWLL package, 32bit ones)
Now on the editor should launch:
(note there is no newline at the top of the file)

file: ['''~/.local/bin/MWLLeditor.sh''']:
<pre>
#! /bin/bash

v=0.10-beta
#executable=Crysis.exe
executable=Editor.exe
shaderspath=~/Documents/My\ Games/Crysis\ Wars/Shaders

i=${1:-3}

if [ "X"$i != "X" ] ; then
pass=$i
echo $i
fi

if (( $pass > 3 )) || (( $pass < 1 )); then
echo " uasge:"
echo $0 "{1|2|3}"
echo "1 = winecfg, 2 = winetricks, 3 = editor"
exit 2
fi

echo $pass

# switch comment whats appropriate
# export WINEARCH=win32
# winegamepath='/drive_c/Program Files (x86)/Electronic Arts/Crytek/Crysis Wars/Bin32'
# windowsgamepath='C:\Program Files (x86)\Electronic Arts\Crytek\Crysis Wars\Bin32\'

export WINEARCH=win64
winegamepath='/drive_c/Program Files (x86)/Electronic Arts/Crytek/Crysis Wars/Bin64'
windowsgamepath='C:\Program Files (x86)\Electronic Arts\Crytek\Crysis Wars\Bin64\'

#here we do "magic" to run DX9 (only supported so far)
#and tell Crysis we want the MWLL mod not the OEM game :^)
OPT="-dx9 -mod MWLL"
#OPT="-mod MWLL"
#OPT="-dx9"

# reducing what wine spews at us
#export WINEDEBUG=-fixme-all,-warn-all,-err-all,-all
export WINEDEBUG=-all

WINEFSYNC=1
WINEESYNC=1
DXVK_HUD=1
DXVK_FILTER_DEVICE_NAME="NVIDIA GeForce GTX 1060 3GB"

# we controll which directory we want be runned by the script
export WINEPREFIX=~/.wine

#this can really beak things if enabled but try it?
# export MESA_DEBUG=1

# we the humans check here what renders our stuff
# if not "Gallium" then it's software = too slow
REND=$(glxinfo | grep "OpenGL renderer" | awk -F: '{print $2}' | awk -F"(" '{print $1}')
echo "Renderer:"$REND
echo "if the above is llvm and not an actual card the game will not work"

#cleaning leftovers from late dinner ;)
killall $executable
killall -9 $executable

#cleaning shader cache for better performance each time
#rm -r "${shaderspath}/*"

#here I cleverly avoid calling the path with my user name :)
cd "${WINEPREFIX}${winegamepath}/${binpath}"
#here i cleverly ask to show the path so we see what WINEPREFIX was called
pwd

case $WINEARCH in
win64)
echo 64bit
case $pass in
1)
winecfg
;;
2)
winetricks
;;
3)
wine64 "${windowsgamepath}${executable}" $OPT # 2>/dev/null # &> MWLL_debug.log
#if uncommented, the last line's comment dumps a log file to the game folder - might prove usefull or a vaste of disk space
;;
esac
;;
win32)
echo 32bit
case $pass in
1)
winecfg
;;
2)
winetricks
;;
3)
#here (hopefully) no shit hits the fan, and we land in game menu
wine ${windowsgamepath}${executable} $OPT # &> MWLL_debug.log
#if uncommented, the last line's comment dumps a log file to the game folder - might prove usefull or a vaste of disk space
;;
esac
;;
esac
# to restore resolution put here what's appropriate or leave as is and just uncomment
xrandr -s 0 # last good resolution

</pre>

This should have you all set.

=== Run the editor ===
You can now start the file by typing [MWLLeditor] in a command prompt and pressing enter.
Pick a map ([TC_Reference] comes to mind) and try add an brush. Here on is uncharted territory, keep me posted!

=== What breaks in the editor and how to work around it ===

''TODO''

AlienArt

2023-02-14T20:19:37Z

Fire-hound: /* Get it ready */ edited how images display

By Alien it's meant as totally new, possibly even strange art in respect of what's present in the Asset Pool. 
In effect successfully following this procedure will hopefully lead to gradual expansion and enrichment of the aforementioned Asset pool. 

The process:

== Preparing The geometry ==
=== now with blender 3.x ===
This is a procedure covering the ever growing technology gap between the free and ever livid
blender and the aging cryengine2. Just get any blender past 3.x release.

=== Get it ready ===
[[File:Step01.png|200px|thumb|center|Prepare Collection]]

For a Mesh to be fit for cryengine it has to fulfill several criteria due to how compromises were made.
It is a convention and if one sticks to it good results won't fail to materialize.
1. No more than two triangles should share same edge.
2. There should be nothing but triangles (or quads) as the final result - remove all and any nodes and or lines (primitives)...
3. There shoudl be no triangles of surface size zero (degenerate faces).
4. It is desirable for the mesh be airtight, but there are valid exceptions.

The Object is to be investigated for the quality and errors for UV mapping.
Only a single UV map per mesh is supported in Cryengine

The Object is to be assigned To a Collection (no more Groups in blender 3.x) that has the same name
The .blend file is to be saved with the same name as the object and collection.

We should now be ready for the export to collada (.dae file)

[[File:Step02.png|200px|thumb|center|Prepare Export]]

=== Export settings ===
Step03.png
As seen on the image the favorable settings differ from defaults. It is therefore advisable to
create a operator preset (i aptly named "cryengine export") for further convenience.

{| class="wikitable" style="margin:auto"
|+ Parameter Meaning
|-
! Parameter name !! Explanation
|-
| Transform || Decomposed (this means rotation, translation and scale are decomposed)
|-
| Triangulate || leave no uncertain surfaces unresolved by blender.
|-
| Apply Transforms || Viewport (it is usually save to assume this is true)
|-
| Selection Only || we rarely need everything from the file - watch for proper parenting!
|-
| Include children || if parenting is properly laid out - this works miracles!
|-
| Use Object Instances || don't use this - i tried it once and it was ugly
|-
| Use Blender Profile || this is best left off - always leave it off for cryengine export.
|}

== Converting the format ==
=== Prepare your Linux ===
For this to work at all some prerequisites are to be met. You didn't think you'll get off
the hook as easy, didn't you? 
# We need working ColladaCGF in wine, for this we need working PyFFI in wine, and for this we need working Python in wine in the first place. For this all to work at all certain versions are to be downloaded and fed to wine: 
* Python 2.6.6 (or ealrier, but idealy exactly 2.6.6 (32bit release only)
* PyFFI 2.1.11 (the last one that works with 2.x python, newer require python 3.x)
* ColladaCGF 0.3.9 (the last one available)

For this to work you will need your linux to be either "multilib" (more likely applies to you) or 32bit (less likely but possible)

Install In that order (Python, PyFFI, Collada) and see it is in the right wine prefix:

both files: 
"C:\Python26\python.exe"

and

"C:\Python26\Scripts\colladacgf.py"

should be present.

Now if you are not using XFCE4 as your GUI too bad you're just out of luck. Otherwise open the Custom Actions chooser via the Edit menu of Thunar and make a new custom action:

Step04.png

I named the action [ ColladaCGF ] and gave it the usual python icon. The description should be obvious: [ Convert a dae file into cgf ]. The command that worked for me was:

[ wineconsole "C:\Python26\python.exe" "C:\Python26\Scripts\colladacgf.py" %F --pause ]

where %F is a list of selected files with the full path.

The filters on the other tab are to be set accordingly: 
[ *.dae;*.DAE ]

mind the semicolon. And the affected files are the text files (.dae files look like XML files) and other files, just in case. Never mind this crazy screenshot - it is CGI - so you have it all on one place.

Apply close and restart Thunar. Now on You should have a context option for each dae file:

Step05.png

=== Point the ColladaCGF to the .dae file ===
The '''dae''' file is to be selected, '''rightclick > ColladaCGF''' and voila! by ''automagic'' a bunch of murr-murr and computer speak will fill a dark frame, once you notice the computer has stopped spewing insults and dark magic, there might be a blinking cursor waiting no you to press [enter] key and close the window. You might have just converted your first '''CGF''' file on Linux. Or you will be in due time. Conversions often fail due to not adhering to the convention mentioned above.

=== Find the cgf file ===
The newly generated '''.CGF''' file and it's belonging '''.MTL''' file should lay next to each other and next to the source '''.DAE''' file. There might be leftovers in the form of logs and dumps. This can be
safely ignored, they can safely be deleted too.

== Importing into engine ==

=== How to get the editor working (Glitch TKG's github) ===
I see not too many casualties to this point. Good; good, here onward it gets tough as nails, and by that i mean eating chains to fart back nails!.
https://github.com/Tk-Glitch (kudos to Tk-Glitch o/ )
https://github.com/Tk-Glitch/PKGBUILDS/wiki/wine-tkg-git#dependencies
You want to build a not only custom version of wine (as if that wasn't intimidating enough!).
No sir, you want a higly customized, overly patched VERY recent version wine-staging that has support for child-window our Sandbox2 editor uses to render the game withing it's app window.
No configurationfiles need to be modified in the [wine-tkg-git] directory, You merely cd to
it and run [./non-makepkg-build.sh]

first time you will be dropped to a shel with inof and stuff...

make the following file:

file: ['''~/.config/frogminer/wine-tkg.cfg''']:
<pre>

_LOCAL_PRESET="none"
_use_GE_patches="true"
_plain_version=""
_use_staging="true"
_staging_version="v7.22"
_use_fastsync="false"
_use_esync="true"
_use_fsync="true"
_fsync_futex_waitv="true"
_use_vkd3dlib="true"
_dxvk_dxgi="true"

_proton_battleye_support="false"
_proton_eac_support="false"
_warframelauncher_fix="false"
_mwo_fix="false"
_re4_fix="false"

_childwindow_fix="true"

_use_josh_flat_theme="true"

</pre>

And once saved, rerun the above command. Install the new wine and make MWLL run in it's prefix.

to run the editor you will need few more winetricks...
Fended of yet? no? Good, because that isn't nearly the end of the desert :D.
add (via winetricks) the follwing:
d3dcompiler_43
d3dcompiler_47
dotnet472 (needed for the launcher anyway (will pull in much down to dotnet40) )
dxvk (i have dxvk1101 so far)
vcrun2005 (MWLL needs it won't run w/o)
(add the two redists from the MWLL package, 32bit ones)
Now on the editor should launch:
(note there is no newline at the top of the file)

file: ['''~/.local/bin/MWLLeditor.sh''']:
<pre>
#! /bin/bash

v=0.10-beta
#executable=Crysis.exe
executable=Editor.exe
shaderspath=~/Documents/My\ Games/Crysis\ Wars/Shaders

i=${1:-3}

if [ "X"$i != "X" ] ; then
pass=$i
echo $i
fi

if (( $pass > 3 )) || (( $pass < 1 )); then
echo " uasge:"
echo $0 "{1|2|3}"
echo "1 = winecfg, 2 = winetricks, 3 = editor"
exit 2
fi

echo $pass

# switch comment whats appropriate
# export WINEARCH=win32
# winegamepath='/drive_c/Program Files (x86)/Electronic Arts/Crytek/Crysis Wars/Bin32'
# windowsgamepath='C:\Program Files (x86)\Electronic Arts\Crytek\Crysis Wars\Bin32\'

export WINEARCH=win64
winegamepath='/drive_c/Program Files (x86)/Electronic Arts/Crytek/Crysis Wars/Bin64'
windowsgamepath='C:\Program Files (x86)\Electronic Arts\Crytek\Crysis Wars\Bin64\'

#here we do "magic" to run DX9 (only supported so far)
#and tell Crysis we want the MWLL mod not the OEM game :^)
OPT="-dx9 -mod MWLL"
#OPT="-mod MWLL"
#OPT="-dx9"

# reducing what wine spews at us
#export WINEDEBUG=-fixme-all,-warn-all,-err-all,-all
export WINEDEBUG=-all

WINEFSYNC=1
WINEESYNC=1
DXVK_HUD=1
DXVK_FILTER_DEVICE_NAME="NVIDIA GeForce GTX 1060 3GB"

# we controll which directory we want be runned by the script
export WINEPREFIX=~/.wine

#this can really beak things if enabled but try it?
# export MESA_DEBUG=1

# we the humans check here what renders our stuff
# if not "Gallium" then it's software = too slow
REND=$(glxinfo | grep "OpenGL renderer" | awk -F: '{print $2}' | awk -F"(" '{print $1}')
echo "Renderer:"$REND
echo "if the above is llvm and not an actual card the game will not work"

#cleaning leftovers from late dinner ;)
killall $executable
killall -9 $executable

#cleaning shader cache for better performance each time
#rm -r "${shaderspath}/*"

#here I cleverly avoid calling the path with my user name :)
cd "${WINEPREFIX}${winegamepath}/${binpath}"
#here i cleverly ask to show the path so we see what WINEPREFIX was called
pwd

case $WINEARCH in
win64)
echo 64bit
case $pass in
1)
winecfg
;;
2)
winetricks
;;
3)
wine64 "${windowsgamepath}${executable}" $OPT # 2>/dev/null # &> MWLL_debug.log
#if uncommented, the last line's comment dumps a log file to the game folder - might prove usefull or a vaste of disk space
;;
esac
;;
win32)
echo 32bit
case $pass in
1)
winecfg
;;
2)
winetricks
;;
3)
#here (hopefully) no shit hits the fan, and we land in game menu
wine ${windowsgamepath}${executable} $OPT # &> MWLL_debug.log
#if uncommented, the last line's comment dumps a log file to the game folder - might prove usefull or a vaste of disk space
;;
esac
;;
esac
# to restore resolution put here what's appropriate or leave as is and just uncomment
xrandr -s 0 # last good resolution

</pre>

This should have you all set.

=== Run the editor ===
You can now start the file by typing [MWLLeditor] in a command prompt and pressing enter.
Pick a map ([TC_Reference] comes to mind) and try add an brush. Here on is uncharted territory, keep me posted!

=== What breaks in the editor and how to work around it ===

''TODO''

File:Step02.png

2023-02-14T20:17:36Z

Fire-hound: Preparing Alien Art for export to Collada

Preparing Alien Art for export to Collada

AlienArt

2023-02-14T20:16:54Z

Fire-hound: /* Get it ready */ added links

By Alien it's meant as totally new, possibly even strange art in respect of what's present in the Asset Pool. 
In effect successfully following this procedure will hopefully lead to gradual expansion and enrichment of the aforementioned Asset pool. 

The process:

== Preparing The geometry ==
=== now with blender 3.x ===
This is a procedure covering the ever growing technology gap between the free and ever livid
blender and the aging cryengine2. Just get any blender past 3.x release.

=== Get it ready ===
[[File:Step01.png]]

For a Mesh to be fit for cryengine it has to fulfill several criteria due to how compromises were made.
It is a convention and if one sticks to it good results won't fail to materialize.
1. No more than two triangles should share same edge.
2. There should be nothing but triangles (or quads) as the final result - remove all and any nodes and or lines (primitives)...
3. There shoudl be no triangles of surface size zero (degenerate faces).
4. It is desirable for the mesh be airtight, but there are valid exceptions.

The Object is to be investigated for the quality and errors for UV mapping.
Only a single UV map per mesh is supported in Cryengine

The Object is to be assigned To a Collection (no more Groups in blender 3.x) that has the same name
The .blend file is to be saved with the same name as the object and collection.

We should now be ready for the export to collada (.dae file)

[[File:Step02.png]]

=== Export settings ===
Step03.png
As seen on the image the favorable settings differ from defaults. It is therefore advisable to
create a operator preset (i aptly named "cryengine export") for further convenience.

{| class="wikitable" style="margin:auto"
|+ Parameter Meaning
|-
! Parameter name !! Explanation
|-
| Transform || Decomposed (this means rotation, translation and scale are decomposed)
|-
| Triangulate || leave no uncertain surfaces unresolved by blender.
|-
| Apply Transforms || Viewport (it is usually save to assume this is true)
|-
| Selection Only || we rarely need everything from the file - watch for proper parenting!
|-
| Include children || if parenting is properly laid out - this works miracles!
|-
| Use Object Instances || don't use this - i tried it once and it was ugly
|-
| Use Blender Profile || this is best left off - always leave it off for cryengine export.
|}

== Converting the format ==
=== Prepare your Linux ===
For this to work at all some prerequisites are to be met. You didn't think you'll get off
the hook as easy, didn't you? 
# We need working ColladaCGF in wine, for this we need working PyFFI in wine, and for this we need working Python in wine in the first place. For this all to work at all certain versions are to be downloaded and fed to wine: 
* Python 2.6.6 (or ealrier, but idealy exactly 2.6.6 (32bit release only)
* PyFFI 2.1.11 (the last one that works with 2.x python, newer require python 3.x)
* ColladaCGF 0.3.9 (the last one available)

For this to work you will need your linux to be either "multilib" (more likely applies to you) or 32bit (less likely but possible)

Install In that order (Python, PyFFI, Collada) and see it is in the right wine prefix:

both files: 
"C:\Python26\python.exe"

and

"C:\Python26\Scripts\colladacgf.py"

should be present.

Now if you are not using XFCE4 as your GUI too bad you're just out of luck. Otherwise open the Custom Actions chooser via the Edit menu of Thunar and make a new custom action:

Step04.png

I named the action [ ColladaCGF ] and gave it the usual python icon. The description should be obvious: [ Convert a dae file into cgf ]. The command that worked for me was:

[ wineconsole "C:\Python26\python.exe" "C:\Python26\Scripts\colladacgf.py" %F --pause ]

where %F is a list of selected files with the full path.

The filters on the other tab are to be set accordingly: 
[ *.dae;*.DAE ]

mind the semicolon. And the affected files are the text files (.dae files look like XML files) and other files, just in case. Never mind this crazy screenshot - it is CGI - so you have it all on one place.

Apply close and restart Thunar. Now on You should have a context option for each dae file:

Step05.png

=== Point the ColladaCGF to the .dae file ===
The '''dae''' file is to be selected, '''rightclick > ColladaCGF''' and voila! by ''automagic'' a bunch of murr-murr and computer speak will fill a dark frame, once you notice the computer has stopped spewing insults and dark magic, there might be a blinking cursor waiting no you to press [enter] key and close the window. You might have just converted your first '''CGF''' file on Linux. Or you will be in due time. Conversions often fail due to not adhering to the convention mentioned above.

=== Find the cgf file ===
The newly generated '''.CGF''' file and it's belonging '''.MTL''' file should lay next to each other and next to the source '''.DAE''' file. There might be leftovers in the form of logs and dumps. This can be
safely ignored, they can safely be deleted too.

== Importing into engine ==

=== How to get the editor working (Glitch TKG's github) ===
I see not too many casualties to this point. Good; good, here onward it gets tough as nails, and by that i mean eating chains to fart back nails!.
https://github.com/Tk-Glitch (kudos to Tk-Glitch o/ )
https://github.com/Tk-Glitch/PKGBUILDS/wiki/wine-tkg-git#dependencies
You want to build a not only custom version of wine (as if that wasn't intimidating enough!).
No sir, you want a higly customized, overly patched VERY recent version wine-staging that has support for child-window our Sandbox2 editor uses to render the game withing it's app window.
No configurationfiles need to be modified in the [wine-tkg-git] directory, You merely cd to
it and run [./non-makepkg-build.sh]

first time you will be dropped to a shel with inof and stuff...

make the following file:

file: ['''~/.config/frogminer/wine-tkg.cfg''']:
<pre>

_LOCAL_PRESET="none"
_use_GE_patches="true"
_plain_version=""
_use_staging="true"
_staging_version="v7.22"
_use_fastsync="false"
_use_esync="true"
_use_fsync="true"
_fsync_futex_waitv="true"
_use_vkd3dlib="true"
_dxvk_dxgi="true"

_proton_battleye_support="false"
_proton_eac_support="false"
_warframelauncher_fix="false"
_mwo_fix="false"
_re4_fix="false"

_childwindow_fix="true"

_use_josh_flat_theme="true"

</pre>

And once saved, rerun the above command. Install the new wine and make MWLL run in it's prefix.

to run the editor you will need few more winetricks...
Fended of yet? no? Good, because that isn't nearly the end of the desert :D.
add (via winetricks) the follwing:
d3dcompiler_43
d3dcompiler_47
dotnet472 (needed for the launcher anyway (will pull in much down to dotnet40) )
dxvk (i have dxvk1101 so far)
vcrun2005 (MWLL needs it won't run w/o)
(add the two redists from the MWLL package, 32bit ones)
Now on the editor should launch:
(note there is no newline at the top of the file)

file: ['''~/.local/bin/MWLLeditor.sh''']:
<pre>
#! /bin/bash

v=0.10-beta
#executable=Crysis.exe
executable=Editor.exe
shaderspath=~/Documents/My\ Games/Crysis\ Wars/Shaders

i=${1:-3}

if [ "X"$i != "X" ] ; then
pass=$i
echo $i
fi

if (( $pass > 3 )) || (( $pass < 1 )); then
echo " uasge:"
echo $0 "{1|2|3}"
echo "1 = winecfg, 2 = winetricks, 3 = editor"
exit 2
fi

echo $pass

# switch comment whats appropriate
# export WINEARCH=win32
# winegamepath='/drive_c/Program Files (x86)/Electronic Arts/Crytek/Crysis Wars/Bin32'
# windowsgamepath='C:\Program Files (x86)\Electronic Arts\Crytek\Crysis Wars\Bin32\'

export WINEARCH=win64
winegamepath='/drive_c/Program Files (x86)/Electronic Arts/Crytek/Crysis Wars/Bin64'
windowsgamepath='C:\Program Files (x86)\Electronic Arts\Crytek\Crysis Wars\Bin64\'

#here we do "magic" to run DX9 (only supported so far)
#and tell Crysis we want the MWLL mod not the OEM game :^)
OPT="-dx9 -mod MWLL"
#OPT="-mod MWLL"
#OPT="-dx9"

# reducing what wine spews at us
#export WINEDEBUG=-fixme-all,-warn-all,-err-all,-all
export WINEDEBUG=-all

WINEFSYNC=1
WINEESYNC=1
DXVK_HUD=1
DXVK_FILTER_DEVICE_NAME="NVIDIA GeForce GTX 1060 3GB"

# we controll which directory we want be runned by the script
export WINEPREFIX=~/.wine

#this can really beak things if enabled but try it?
# export MESA_DEBUG=1

# we the humans check here what renders our stuff
# if not "Gallium" then it's software = too slow
REND=$(glxinfo | grep "OpenGL renderer" | awk -F: '{print $2}' | awk -F"(" '{print $1}')
echo "Renderer:"$REND
echo "if the above is llvm and not an actual card the game will not work"

#cleaning leftovers from late dinner ;)
killall $executable
killall -9 $executable

#cleaning shader cache for better performance each time
#rm -r "${shaderspath}/*"

#here I cleverly avoid calling the path with my user name :)
cd "${WINEPREFIX}${winegamepath}/${binpath}"
#here i cleverly ask to show the path so we see what WINEPREFIX was called
pwd

case $WINEARCH in
win64)
echo 64bit
case $pass in
1)
winecfg
;;
2)
winetricks
;;
3)
wine64 "${windowsgamepath}${executable}" $OPT # 2>/dev/null # &> MWLL_debug.log
#if uncommented, the last line's comment dumps a log file to the game folder - might prove usefull or a vaste of disk space
;;
esac
;;
win32)
echo 32bit
case $pass in
1)
winecfg
;;
2)
winetricks
;;
3)
#here (hopefully) no shit hits the fan, and we land in game menu
wine ${windowsgamepath}${executable} $OPT # &> MWLL_debug.log
#if uncommented, the last line's comment dumps a log file to the game folder - might prove usefull or a vaste of disk space
;;
esac
;;
esac
# to restore resolution put here what's appropriate or leave as is and just uncomment
xrandr -s 0 # last good resolution

</pre>

This should have you all set.

=== Run the editor ===
You can now start the file by typing [MWLLeditor] in a command prompt and pressing enter.
Pick a map ([TC_Reference] comes to mind) and try add an brush. Here on is uncharted territory, keep me posted!

=== What breaks in the editor and how to work around it ===

''TODO''

File:Step01.png

2023-02-14T20:14:41Z

Fire-hound: Alien Art Preparing in Blender

Alien Art Preparing in Blender

AlienArt

2023-02-14T16:01:43Z

Fire-hound: How to make assets from scratch in Blender and import them into Cryengine, initial commit, not linked anywhere yet

By Alien it's meant as totally new, possibly even strange art in respect of what's present in the Asset Pool. 
In effect successfully following this procedure will hopefully lead to gradual expansion and enrichment of the aforementioned Asset pool. 

The process:

== Preparing The geometry ==
=== now with blender 3.x ===
This is a procedure covering the ever growing technology gap between the free and ever livid
blender and the aging cryengine2. Just get any blender past 3.x release.

=== Get it ready ===
Step01.png

For a Mesh to be fit for cryengine it has to fulfill several criteria due to how compromises were made.
It is a convention and if one sticks to it good results won't fail to materialize.
1. No more than two triangles should share same edge.
2. There should be nothing but triangles (or quads) as the final result - remove all and any nodes and or lines (primitives)...
3. There shoudl be no triangles of surface size zero (degenerate faces).
4. It is desirable for the mesh be airtight, but there are valid exceptions.

The Object is to be investigated for the quality and errors for UV mapping.
Only a single UV map per mesh is supported in Cryengine

The Object is to be assigned To a Collection (no more Groups in blender 3.x) that has the same name
The .blend file is to be saved with the same name as the object and collection.

We should now be ready for the export to collada (.dae file)

Step02.png

=== Export settings ===
Step03.png
As seen on the image the favorable settings differ from defaults. It is therefore advisable to
create a operator preset (i aptly named "cryengine export") for further convenience.

{| class="wikitable" style="margin:auto"
|+ Parameter Meaning
|-
! Parameter name !! Explanation
|-
| Transform || Decomposed (this means rotation, translation and scale are decomposed)
|-
| Triangulate || leave no uncertain surfaces unresolved by blender.
|-
| Apply Transforms || Viewport (it is usually save to assume this is true)
|-
| Selection Only || we rarely need everything from the file - watch for proper parenting!
|-
| Include children || if parenting is properly laid out - this works miracles!
|-
| Use Object Instances || don't use this - i tried it once and it was ugly
|-
| Use Blender Profile || this is best left off - always leave it off for cryengine export.
|}

== Converting the format ==
=== Prepare your Linux ===
For this to work at all some prerequisites are to be met. You didn't think you'll get off
the hook as easy, didn't you? 
# We need working ColladaCGF in wine, for this we need working PyFFI in wine, and for this we need working Python in wine in the first place. For this all to work at all certain versions are to be downloaded and fed to wine: 
* Python 2.6.6 (or ealrier, but idealy exactly 2.6.6 (32bit release only)
* PyFFI 2.1.11 (the last one that works with 2.x python, newer require python 3.x)
* ColladaCGF 0.3.9 (the last one available)

For this to work you will need your linux to be either "multilib" (more likely applies to you) or 32bit (less likely but possible)

Install In that order (Python, PyFFI, Collada) and see it is in the right wine prefix:

both files: 
"C:\Python26\python.exe"

and

"C:\Python26\Scripts\colladacgf.py"

should be present.

Now if you are not using XFCE4 as your GUI too bad you're just out of luck. Otherwise open the Custom Actions chooser via the Edit menu of Thunar and make a new custom action:

Step04.png

I named the action [ ColladaCGF ] and gave it the usual python icon. The description should be obvious: [ Convert a dae file into cgf ]. The command that worked for me was:

[ wineconsole "C:\Python26\python.exe" "C:\Python26\Scripts\colladacgf.py" %F --pause ]

where %F is a list of selected files with the full path.

The filters on the other tab are to be set accordingly: 
[ *.dae;*.DAE ]

mind the semicolon. And the affected files are the text files (.dae files look like XML files) and other files, just in case. Never mind this crazy screenshot - it is CGI - so you have it all on one place.

Apply close and restart Thunar. Now on You should have a context option for each dae file:

Step05.png

=== Point the ColladaCGF to the .dae file ===
The '''dae''' file is to be selected, '''rightclick > ColladaCGF''' and voila! by ''automagic'' a bunch of murr-murr and computer speak will fill a dark frame, once you notice the computer has stopped spewing insults and dark magic, there might be a blinking cursor waiting no you to press [enter] key and close the window. You might have just converted your first '''CGF''' file on Linux. Or you will be in due time. Conversions often fail due to not adhering to the convention mentioned above.

=== Find the cgf file ===
The newly generated '''.CGF''' file and it's belonging '''.MTL''' file should lay next to each other and next to the source '''.DAE''' file. There might be leftovers in the form of logs and dumps. This can be
safely ignored, they can safely be deleted too.

== Importing into engine ==

=== How to get the editor working (Glitch TKG's github) ===
I see not too many casualties to this point. Good; good, here onward it gets tough as nails, and by that i mean eating chains to fart back nails!.
https://github.com/Tk-Glitch (kudos to Tk-Glitch o/ )
https://github.com/Tk-Glitch/PKGBUILDS/wiki/wine-tkg-git#dependencies
You want to build a not only custom version of wine (as if that wasn't intimidating enough!).
No sir, you want a higly customized, overly patched VERY recent version wine-staging that has support for child-window our Sandbox2 editor uses to render the game withing it's app window.
No configurationfiles need to be modified in the [wine-tkg-git] directory, You merely cd to
it and run [./non-makepkg-build.sh]

first time you will be dropped to a shel with inof and stuff...

make the following file:

file: ['''~/.config/frogminer/wine-tkg.cfg''']:
<pre>

_LOCAL_PRESET="none"
_use_GE_patches="true"
_plain_version=""
_use_staging="true"
_staging_version="v7.22"
_use_fastsync="false"
_use_esync="true"
_use_fsync="true"
_fsync_futex_waitv="true"
_use_vkd3dlib="true"
_dxvk_dxgi="true"

_proton_battleye_support="false"
_proton_eac_support="false"
_warframelauncher_fix="false"
_mwo_fix="false"
_re4_fix="false"

_childwindow_fix="true"

_use_josh_flat_theme="true"

</pre>

And once saved, rerun the above command. Install the new wine and make MWLL run in it's prefix.

to run the editor you will need few more winetricks...
Fended of yet? no? Good, because that isn't nearly the end of the desert :D.
add (via winetricks) the follwing:
d3dcompiler_43
d3dcompiler_47
dotnet472 (needed for the launcher anyway (will pull in much down to dotnet40) )
dxvk (i have dxvk1101 so far)
vcrun2005 (MWLL needs it won't run w/o)
(add the two redists from the MWLL package, 32bit ones)
Now on the editor should launch:
(note there is no newline at the top of the file)

file: ['''~/.local/bin/MWLLeditor.sh''']:
<pre>
#! /bin/bash

v=0.10-beta
#executable=Crysis.exe
executable=Editor.exe
shaderspath=~/Documents/My\ Games/Crysis\ Wars/Shaders

i=${1:-3}

if [ "X"$i != "X" ] ; then
pass=$i
echo $i
fi

if (( $pass > 3 )) || (( $pass < 1 )); then
echo " uasge:"
echo $0 "{1|2|3}"
echo "1 = winecfg, 2 = winetricks, 3 = editor"
exit 2
fi

echo $pass

# switch comment whats appropriate
# export WINEARCH=win32
# winegamepath='/drive_c/Program Files (x86)/Electronic Arts/Crytek/Crysis Wars/Bin32'
# windowsgamepath='C:\Program Files (x86)\Electronic Arts\Crytek\Crysis Wars\Bin32\'

export WINEARCH=win64
winegamepath='/drive_c/Program Files (x86)/Electronic Arts/Crytek/Crysis Wars/Bin64'
windowsgamepath='C:\Program Files (x86)\Electronic Arts\Crytek\Crysis Wars\Bin64\'

#here we do "magic" to run DX9 (only supported so far)
#and tell Crysis we want the MWLL mod not the OEM game :^)
OPT="-dx9 -mod MWLL"
#OPT="-mod MWLL"
#OPT="-dx9"

# reducing what wine spews at us
#export WINEDEBUG=-fixme-all,-warn-all,-err-all,-all
export WINEDEBUG=-all

WINEFSYNC=1
WINEESYNC=1
DXVK_HUD=1
DXVK_FILTER_DEVICE_NAME="NVIDIA GeForce GTX 1060 3GB"

# we controll which directory we want be runned by the script
export WINEPREFIX=~/.wine

#this can really beak things if enabled but try it?
# export MESA_DEBUG=1

# we the humans check here what renders our stuff
# if not "Gallium" then it's software = too slow
REND=$(glxinfo | grep "OpenGL renderer" | awk -F: '{print $2}' | awk -F"(" '{print $1}')
echo "Renderer:"$REND
echo "if the above is llvm and not an actual card the game will not work"

#cleaning leftovers from late dinner ;)
killall $executable
killall -9 $executable

#cleaning shader cache for better performance each time
#rm -r "${shaderspath}/*"

#here I cleverly avoid calling the path with my user name :)
cd "${WINEPREFIX}${winegamepath}/${binpath}"
#here i cleverly ask to show the path so we see what WINEPREFIX was called
pwd

case $WINEARCH in
win64)
echo 64bit
case $pass in
1)
winecfg
;;
2)
winetricks
;;
3)
wine64 "${windowsgamepath}${executable}" $OPT # 2>/dev/null # &> MWLL_debug.log
#if uncommented, the last line's comment dumps a log file to the game folder - might prove usefull or a vaste of disk space
;;
esac
;;
win32)
echo 32bit
case $pass in
1)
winecfg
;;
2)
winetricks
;;
3)
#here (hopefully) no shit hits the fan, and we land in game menu
wine ${windowsgamepath}${executable} $OPT # &> MWLL_debug.log
#if uncommented, the last line's comment dumps a log file to the game folder - might prove usefull or a vaste of disk space
;;
esac
;;
esac
# to restore resolution put here what's appropriate or leave as is and just uncomment
xrandr -s 0 # last good resolution

</pre>

This should have you all set.

=== Run the editor ===
You can now start the file by typing [MWLLeditor] in a command prompt and pressing enter.
Pick a map ([TC_Reference] comes to mind) and try add an brush. Here on is uncharted territory, keep me posted!

=== What breaks in the editor and how to work around it ===

''TODO''

Warhammer

2021-08-22T08:04:27Z

Fire-hound: /* Variant B */ clarified

{{Mech|
| Image = File:Warhammer.png
| ImageGif = File:Warhammer_spin.gif
| Class = Heavy
| Faction = Inner Sphere
| Tickets = 8
| Tier = 10
| Tonnage = 70
| Speed = 64
| SpeedWithMasc =
| Rotation = 260
| PitchStand = -33° to +41°
| PitchCrouch = -33° to +51°

| Price Prime = 67 900
| ArmorT Prime = 64 474
| Engine Prime = VOX 280 STD
| Weapons Prime = <ul>
<li>2x [[PPC]]
<li>2x [[ML]]
<li>2x [[SL]]
<li>1x [[SRM6]]
</ul>
| Equip Prime = <ul>
<li>4 [[DHS]]
<li>1 [[free tons]]
<li>13t [[Armor]]
</ul>

| Price A = 89 200
| ArmorT A = 61 312
| Engine A = VOX 280 XL
| Weapons A = <ul>
<li>3x [[LPL]]
<li>2x [[SSRM6]]
</ul>
| Equip A = <ul>
<li>[[GECM]]
<li>[[EOptics]]
<li>8 [[DHS]]
<li>0 [[free tons]]
<li>12.5t [[Armor]]
</ul>

| Price B = 77 500
| ArmorT B = 61 312
| Engine B = VOX 280 XL
| Weapons B = <ul>
<li>2x [[HVAC10]]
<li>2x [[ERSL]]
<li>1x [[SRM6]]
<li>2x [[HMG]]
<li>1x [[B-Pod]]
</ul>
| Equip B = <ul>
<li>[[EOptics]]
<li>0 [[DHS]]
<li>4 [[free tons]]
<li>12.5t [[Armor]]
</ul>

| Price C = 89 150
| ArmorT C = 64 474
| Engine C = VOX 280 XL
| Weapons C = <ul>
<li>2x [[SPL]]
<li>1x [[LBX20]]
<li>4x [[LPPC]]
</ul>
| Equip C = <ul>
<li>[[LAMS]]
<li>[[GECM]]
<li>[[BAP]]
<li>[[EOptics]]
<li>5 [[DHS]]
<li>1 [[free ton]]
<li>13t [[Armor]]
</ul>

| Price D = 80 500
| ArmorT D = 64 474
| Engine D = VOX 280 XL
| Weapons D = <ul>
<li>1x [[UAC20]]
<li>2x [[ERLL]]
<li>2x [[TBolt5]]
</ul>
| Equip D = <ul>
<li>[[EOptics]]
<li>4 [[DHS]]
<li>1 [[free tons]]
<li>13t [[Armor]]
</ul>

| Price E = 73 000
| ArmorT E = 64 474
| Engine E = VOX 280 XL
| Weapons E = <ul>
<li>1x [[AC10]]
<li>2x [[AC5]]
<li>1x [[LRM20]]
<li>1x [[MPL]]
<li>2x [[SL]]
</ul>
| Equip E = <ul>
<li>[[EOptics]]
<li>1 [[DHS]]
<li>2 [[free tons]]
<li>13t [[Armor]]
</ul>

| Price F = 79 250
| ArmorT F = 64 474
| Engine F = VOX 280 XL
| Weapons F = <ul>
<li>2x [[RAC5]]
<li>1x [[MRM30]]
<li>3x [[Flamer]]
</ul>
| Equip F = <ul>
<li>3 [[DHS]]
<li>3 [[free tons]]
<li>13t [[Armor]]
</ul>

| Price G = 77 500
| ArmorT G = 61 312
| Engine G = VOX 280 XL
| Weapons G = <ul>
<li>2x [[ERPPC]]
<li>1x [[ELRM15]]
<li>4x [[AC2]]
<li>1x [[B-Pod]]
</ul>
| Equip G = <ul>
<li>[[EOptics]]
<li>2 [[DHS]]
<li>1 [[free tons]]
<li>12.5t [[Armor]]
</ul>

| Pods = RE
| Armor H = 2760
| Armor CT = 9138
| Armor LRT = 5939
| Armor B = 5483
| Armor LRA = 5254
| Armor INT = 3947
| Armor LRL = 6579
| Armor RE = 3655

| Version142 = 0.14.2
}}

The '''Warhammer''' is a heavily armed and moderately [[Armor|armored]] [[Inner Sphere]] [[Heavy Mechs|Heavy Mech]], possessing modest speed and maneuverability. Able to dish it out and take it in, the Warhammer is a powerful force on the battlefield, capable of shredding [[Light Mechs]] and [[Vehicles]], as well as standing toe to toe against other Heavies.

Warhammer's large spotlight can be turned on with the ['''L'''] key. It functions differently than the standard Mech spotlights, as it has a much longer range. When fighting [[Battle Armor]] in the Warhammer, players can turn on the spotlight to discern the battlearmor from the surroundings. The Mech also has a narrow vertical field of view, which may make it hard to deal with [[Aerospace]] fighters and [[VTOL]]s.

==Roles and Gameplay Hints==
===Prime===
The Warhammer Prime is the signature mech of Natasha Kerensky. It is also a Knights of the Inner Sphere favorite. With its low price the Prime is a budget favorite and a well-armed mech, possessing a variety of weapons capable of inflicting significant damage at short range and modest damage at medium range. 2 [[PPC]]s provide the initial mid-range punch, disorienting enemy mechwarriors with cockpit shake and disabling [[night vision]]. The Prime's mid-range output is supplemented by 2 [[ML]]s, but it reaches its full damage potential as it closes within 250m. The Prime's 2 [[SL]]s and an [[SRM6]] allow it to step up its firepower as it closes on its foes. The [[SRM6]] provides the primary defense against [[Battle Armor]], allowing the Warhammer Prime to defend both itself and nearby allies from BA ambushes. Being primarily [[Energy Weapon]] based, the Prime sports 4 [[Double Heat Sinks]] allowing a disciplined mechwarrior to output fire continuously without fear of excess heat. The Prime has a major difference from all other variants. It is equipped with a [[Engines|standard engine]] which causes no bonus damage to be transferred to its vital center torso from a busted side torso. Spreading damage by torso twisting can allow a Prime to survive far longer than its already hard to kill brethren. The Prime can often escape damaging encounters that would have destroyed many other mechs. The Warhammer Prime is dangerous mech capable of handling a variety of threats at a variety of ranges.

===Variant A===
The Warhammer A operates a bit [[heat|hot]], but is a formidable asset with robust [[pinpoint]] accuracy and [[screen shake]] backup weapons - an excellent medium range mech that can turn into a [[brawler]] in a pinch. The A, however, has no [[spare ammo]] for its pair of [[SSRM6]]s. The A should focus on being sustainable medium range firepower when in long engagements and avoid close combat unless [[resupply]] is near. Players should utilize [[group fire]] for the A's impressive array of three [[LPL|Large Pulse Lasers]] and [[chain fire]] for its SSRM6s to maximize screen shake. If more than two mouse buttons are available, a third, chain fired group containing the three pulse lasers will help when trying to even out heat or shoot at pesky [[BA]].

===Variant B===
Many famous warriors where seduced by beauty, several by that of weapons yet only few came to know the [[HVAC10]]. If there ever where warriors guided by the beauty of the weapon, then the admirers of the HVAC10 certainly are some of those. 
This War Hammer puts its stakes on the fact that the two HVAC10 deliver more damage than two [[AC10|heavy Auto Cannons]] would all the while still reaching beyond even the nimbler [[AC5|standard Auto Cannon]], rivaling the Gauss and ERPPC. In contrast to all but ERPPC it also induces heavy screen shake to the target. 
This alone makes this asset capable of shaking the object of his attention almost out of the ability to retaliate all the way up to 900m out. 
Besides the 4 tons for spare reloads, most certainly reserved for the HVAC10s, the Mech also carries an somewhat disparate array of tertiary (in the sense of weapons grouping) backup weapons: 
Once we realize the bulk of that arrays damage reaches out up to between 350 and 200m, we can see the group is less unfortunate but rather a dissonant one. Just fire it all and at once - to your hearts content, or until the two "Beauties" come to wake again. 

This one is devoted for those who are able to step in the thick of the battle and are intimate to the intricacies of the equipment.

===Variant C===
Nothing reaches beyond 500 meters on this one - [[GECM]] suite ensures not even radar microwaves. With the least of an firing discipline the 4 [[LPPC]] can be fired indefinitely and in short succession - rendering any opponent blind at night, out to 450m. This sole property renders this variant an night hunter of supreme potential. The 2 [[SPL]], reaching out to 250m bring on the hurt at close range. While the main trump card of this variant, however, is the persuading potential of the [[LBX20]] cannon and it is backed up by the usual ton of spare ammunition. Utmost care is to be taken that each hit counts as the LBX20 cannon does the majority of the C variant's damage. The selling points of this top priced Warhammer is its night hunting potential backed up by the [[GECM]] suite's stealth and extended sensor range provided by [[BAP]], although note that the stealth can be too easily broken by any stray enemy missile on a fly-by, by the treacherous [[LAMS]]. This only applies if the radar is held in the active mode. 5 [[DHS]] and 13t [[Armor]] round out this Whammy that has all the toys. God help the fool that gets in your way!

===Variant D===
The Warhammer D is the wolf-in-sheep's-clothing of the Warhammer line. 2 [[ERLL]]s and 2 [[Tbolt5]]s will lure your targets in for an easy kill of an long ranged helpless low DPS sniper. Brawlers will weather the storm, closing on you with the intent of scoring a quick kill. Once they arrive, however, they'll be in for a nasty surprise as the D variant's main weapon, a single [[UAC20]], roars into life. This weapon is capable of immense burst damage, and will quickly tear into any dents the enemy took from their approach, coring smaller enemy mechs in a few seconds of fire. Furthermore, it is also placed high on the mech's shoulder, allowing the mechwarrior to fire double AC rounds at enemies while in partial cover. 4 [[DHS]] give the D variant acceptable heat management, and an extra ton of [[free tons|free space]] ensures that its autocannon has more ammo should the enemy prove tougher than expected. 
The selling point of this Variant is to have a foot in both of the worlds - snipers and brute brawlers.

===Variant E===
The E is a vicious and inexpensive, but somewhat unfocused, Warhammer. It is more than capable of serving as a back-of-the-line- or midrange-, fire support mech with its [[LRM20]] and two [[AC5]]s. Unlike most fire support mechs, the E can fend for itself in close combat. While its LRM20 becomes useless in close combat, all of its other weapons remain effective, including one [[AC10]], two [[Small laser]]s, and one [[Medium pulse laser]].

Players that constantly position the E for midrange combat will find themselves juggling many different weapon groups while simultaneously attempting to maintain missile lock. Although difficult, this tactic allows the player to put down withering fire on their opponents, especially with the [[screen shake]] from the AC10. Players will also find that the E particularly shines when allies are using [[TAG]] or [[NARC]] effectively, as this allows the E to focus on its other weapons and allows it to [[damage spreading|damage spread]] since it doesn't have to [[stare]] to maintain [[missile lock]].

Weapon groups should be customized depending on the number of available mouse buttons. For four or more mouse buttons, group the [[MPL]] and two [[SL]]s together. When only three mouse buttons are available, the [[AC10]] can be grouped with the [[AC5]]s at only a slight reduction in effectiveness. Regardless of how many mouse buttons are available, players should ensure that the AC10 is mapped to a button that can be held down continually.

===Variant F===
The Warhammer F excels at close combat and can provide modest mid-range support. 2 [[RAC5]]s, the F's primary weapon systems, are able to dish out serious damage allowing the F to engage other heavies as well as strip the armor from assaults at close range. A single [[MRM30]] supplements the already great damage provided by the rotary autocannons, and 3 [[flamers]] give the Warhammer F the ability to punish any energy-focused mechs that are foolish enough to get close. 3 [[DHS]] help dump the waste heat flamers will saddle you with, while 3 [[free tons]] give you some staying power before returning to rearm.

===Variant G===
When we speak about this War Hammer, we speak about minding busyness in our neighbor's back yard and in his neighbor's back yard too. We are speaking serious long range and serious punch. 
Speaking of serious, be sure you will be facing serious heat levels as well, for the while the two [[DHS|Double Heat Sinks]] struggle to cool off the waste heat from the two mighty [[ERPPC]]. The trusty [[ELRM15|Extended Long Range Missile launcher of class 15]] isn't too cold either, so the only slack that's cut to you is from the four extremely ranged [[AC2]]. 
If you come to haste, due to an stray Battle Armor trying to take it out on you, the very situational [[BPod]] might bring the tide of the battle in your favor, but only if you manage to capitalize on it otherwise - alone it won't matter too much. 
On the other hand, if you look on the ELRM15 launcher as a spare weapon, and use the two ERPPC as a primary group each, putting the four AC2 in the tertiary group, forgoing any [[DPS]] plan in favor of opportune lucky strikes by either single ERPPC jolt or "Alpha" shooting form a totally cold state, you might actually secure a kill steal from an unsuspected angle. This implies superb position seeking and that extrasensory feeling for the battle tide. 
A long range sniper with a backup ELRM15 launcher.

==Canon==
The Warhammer BattleMech was introduced by StarCorps Industries in 2515 to be "a mobile 'Mech with enough firepower to destroy or severely damage any 'Mech of the same weight class or lower." In the mission it was designed for, the Warhammer proved to be a very capable 'Mech, and for centuries practically defined the entire class of heavy 'Mechs. Boasting incredible firepower and respectable armoring, the Warhammer served prominently in the Star League Defense Force and was one of the premier 'Mechs in the Gunslinger Program. Indeed, many of the greatest MechWarriors in history were Warhammer pilots.
Being more lightly armored then other mechs of its class, the Warhammer preferred to stay at range where its weaponry was most effective. In addition to PPCs, SRMs, and Lasers, it had two machine guns for defense against infantry.
Date Introduced 2515 during the Era known as "Age of War" (2005 - 2570) - Unit Role: Brawler

Amongst BT fans, the Warhammer, along with other Mechs designed for the ''Macross'' Anime series, is referred as the ''Unseen''. Another ''Unseen'' Mech (which was originally planned to appear in MWLL) is the [[Marauder]].

[http://www.sarna.net/wiki/Warhammer BattleTech Reference]
{{Template:Navbox_Assets_IS}}

Atlas

2020-10-24T17:08:26Z

Fire-hound: /* Variant C "The Big Bully" */ reworked the replaced AC20 fluff

{{Mech|
| Image = File:Atlas.png
| ImageGif = File:Atlas_spin.gif
| Class = Assault
| Faction = Inner Sphere
| Tickets = 14
| Tier = 15
| Tonnage = 100
| Speed = 53
| SpeedWithMasc =
| Rotation = 180
| PitchStand = -35° to +45°
| PitchCrouch = -35° to +55°

| Price Prime = 106 100
| ArmorT Prime = 92 755
| Engine Prime = Vlar 300 STD
| Weapons Prime = <ul>
<li>2x [[ERPPC]]
<li>2x [[ERML]]
<li>2x [[LRM5]]
<li>1x [[Gauss]]
<li>1x [[B-Pod]]
</ul>
| Equip Prime = <ul>
<li>[[EOptics]]
<li>1 [[LAMS]]
<li>4 [[DHS]]
<li>1 [[free ton]]
<li>19t [[Armor]]
</ul>

| Price A = 114 900
| ArmorT A = 94 359
| Engine A = Vlar 300 STD
| Weapons A = <ul>
<li>3x [[RAC5]]
<li>2x [[DSRM4]]
</ul>
| Equip A = <ul>
<li>[[GECM]]
<li>2 [[DHS]]
<li>8 [[free tons]]
<li>19.5t [[Armor]]
</ul>

| Price B = 121 700
| ArmorT B = 94 359
| Engine B = Vlar 300 STD
| Weapons B = <ul>
<li>2x [[PPC]]
<li>2x [[SRM4]]
<li>1x [[iHGauss]]
<li>1x [[B-Pod]]
</ul>
| Equip B = <ul>
<li>[[AECM]]
<li>[[EOptics]]
<li>5 [[DHS]]
<li>2 [[free tons]]
<li>19.5t [[Armor]]
</ul>

| Price C = 102 400
| ArmorT C = 94 359
| Engine C = Vlar 300 STD
| Weapons C = <ul>
<li>2x [[AC10]]
<li>1x [[HPPC]]
<li>2x [[DSRM4]]
</ul>
| Equip C = <ul>
<li>4 [[DHS]]
<li>4 [[free tons]]
<li>19.5t [[Armor]]
</ul>

| Price D = 100 400
| ArmorT D = 94 359
| Engine D = Vlar 300 STD
| Weapons D = <ul>
<li>4x [[ML]]
<li>1x [[AC20]]
<li>1x [[LRM20]]
<li>1x [[SRM6]]
</ul>
| Equip D = <ul>
<li>[[LAMS]]
<li>6 [[DHS]]
<li>4 [[free tons]]
<li>19.5t [[Armor]]
</ul>

| Price E = 116 100
| ArmorT E = 91 146
| Engine E = Vlar 300 STD
| Weapons E = <ul>
<li>2x [[ERLL]]
<li>2x [[LRM15]]
<li>2x [[ERML]]
<li>1x [[iNARC]]
</ul>
| Equip E = <ul>
<li>[[C3|C3 Master]]
<li>[[BHP]]
<li>[[GECM]]
<li>[[EOptics]]
<li>2 [[LAMS]]
<li>4 [[DHS]]
<li>1 [[free ton]]
<li>18.5t [[Armor]]
</ul>

| Price F = 111 000
| ArmorT F = 94 359
| Engine F = Vlar 300 STD
| Weapons F = <ul>
<li>3x [[LPL]]
<li>2x [[TBolt10]]
<li>2x [[TBolt5]]
</ul>
| Equip F = <ul>
<li>[[EOptics]]
<li>9 [[DHS]]
<li>2 [[free tons]]
<li>19.5t [[Armor]]
</ul>

| Price G = 98 100
| ArmorT G = 94 359
| Engine G = Vlar 300 STD
| Weapons G = <ul>
<li>2x [[MRM30]]
<li>4x [[HMG]]
<li>1x [[UAC20]]
</ul>
| Equip G = <ul>
<li>[[EOptics]]
<li>2 [[DHS]]
<li>3 [[free tons]]
<li>19.5t [[Armor]]
</ul>

| Armor H = 2760
| Armor CT = 13849
| Armor RT = 11080
| Armor LT = 9002
| Armor B = 8310
| Armor LRA = 6925
| Armor LRL = 10595
| Armor INT = 6357

| Version130 = 0.13.0
}}



The '''Atlas''' is an iconic [[Inner Sphere]] [[Assault Mech]] well recognized by Battletech fans for generations. With it's awe-inspiring [[Weapons]], and extremely tough [[Armor]], the Atlas has built itself a reputation as one of the most fearsome Inner Sphere [[Mechs]] available. With a surprisingly low price tag for a 100 ton [[Mech]], the Atlas is relatively easy to field compared to its better-armed cousins, yet raw firepower is hardly lacking in any Atlas variant. Furthermore, the primary feature of the Atlas isn't the weaponry itself - it is the incredible longevity provided by extremely thick armor, coupled with the use of the [[Engines#Standard Engine|Standard Engine]], netting it an additional survivability bonus. This allows the Atlas to take inordinate amounts of punishment before succumbing to enemy fire, and makes the Atlas an ideal choice for defending positions from enemy attack. Furthermore, the Atlas is able to carry a wide array of electronics, allowing it to fill a support role while it takes punishment for the rest of its team.

==Roles and Gameplay Hints==
===Prime===
The Atlas Prime is built towards command and control of large areas of the [[Maps|Map]] with its heavy, long-range firepower. 2 [[ERPPC]]s on the arms and twin [[LRM5]]s give it firepower at long range, while a [[Gauss|Gauss Rifle]] provides a powerful punch at any range. If an enemy approaches too close to use the [[LRM]]s, the [[ERML]]s come into the fight to keep the pressure on. A single [[LAMS]] protects the Atlas Prime from enemy missile fire while it supports its allies from afar. Single [[B-Pod]] helps fending off enemy [[Battle Armor]], 4 [[DHS]] are somewhat enough to keep heat in check, so long as the pilot doesn't lean too heavily on the PPCs.

===Variant A - ''"Mr. Bubbles"''===
The ''Atlas A'', dubbed '''''"Mr. Bubbles"''''', is armed with 3 [[RAC5]], giving it incredible damage-per-second against enemy targets.
This style of combat is very suited for the Atlas, as its heavy armor allows it to endure the return fire such an exposed method of combat brings with it, a luxury many other DPS based Mechs and tanks do not have. The twin [[DSRM4]]s require a different lead then the [[RAC]]s, and thus are best used while your [[RAC|rotary cannons]] cool down or reload to screen yourself behind their exhaust and to shake the enemy, reducing the effectiveness of its counterstrike. They can also finish off heavily damaged targets in a pinch given their strong damage output. The biggest downside to this variant is its short effective range of only around 250 - 300m, especially since almost every other asset is faster then the Atlas. The [[RAC]]s can be used further out, but the spread and damage falloff prevents them from dealing significant damage behind 500m, and the [[DSRM]]s alone are not enough to threaten anything bigger then a light Mech. Furthermore, this variant lacks [[LAMS]] to dissuade enemy missile fire, leaving the pilot vulnerable to screen shake from retaliatory fire, meaning that pilots should carefully approach their targets under the cover of [[GECM]] rather than march across the open field to fight. 8 tons of extra ammo are enough to keep all its weapons firing for a while, but caution must still be applied, because the Atlas is too slow to retreat should its ammo run out during combat.

===Variant B===
The B Variant is one of only 3 mechs armed with a [[iHGauss|Improved Heavy Gauss]], giving it serious firepower at medium- to short-range. This terrifying weapon is supported by two [[PPC]]s, complimenting the iHGauss' 800m range bracket. For even more close-range firepower, this variant is equipped with two [[SRM4]] launchers. This leaves the Atlas B with excellent mid- and close-range firepower. Its 5 [[DHS]] are sufficient to handle almost continuous firing of the IS PPCs. A good tactic is to chain fire them to maximize enemy screen shake while the Improved Heavy Gauss reloads between shots. [[AECM]] makes this range bracket ideal for this Atlas, allowing it to provide an umbrella of radar protection to allies while they march toward the enemy. However, the lack of [[LAMS]] means that this Atlas is quite vulnerable to enemy missile fire while it moves in - such coverage would need to be provided by friendly units instead.

===Variant C ''"The Big Bully"''===
Informally called '''''"The Big Bully"''''', this variant is designed to be a return fire disruptor. It is mounting an array of aim disrupting weaponry consisting of 2 [[AC10|AutoCannon10]]s, twin [[DSSRM4|dual SSRM4s]] launchers, and the massive [[HPPC]], the Atlas C has the capacity to keep in check anything that gets within it's range for quite a while. 4 [[DHS]] easily allow the Mechwarrior to continuously fire all weapons in close succession. 
However, its greatest weakness lays right in its greatest strength - The AC10 array and the formidable HPPC while quite aim disrupting are ill suited for quick depleting an heavy armored asset by them selves. This designates this unit as an second line attacker, perhaps skirmisher where its extra armor can keep it in massive firefights for extended periods of time. As such, the Atlas C is the perfect supplement for an attack lance consisting of shorter ranged units in need of medium range fire disruption.

===Variant D - ''"Ol' Daddy"''===
An homage to the classic AS7-D Atlas, the Atlas D is an economy solution. Snubbing advanced weaponry and electronics for older, cheaper tech, the Atlas D provides players with the chance to field the heavily-armored Atlas chassis relatively early compared to other [[Assault Mech]]s. Its firepower is primarily brought to bear at close range, with an [[AC20]] being the main damage-dealer, while a [[SRM6]] exploits weakened sections. 4 [[ML|Medium Lasers]] provide some support fire at slightly further ranges, and a single [[LRM20]] allows this Atlas to reach out and hit enemies at long-range, at once allowing it to soften enemies up while moving into closer ranges and also giving it the ability to retaliate against long-range snipers that outrun it. 4 [[free tons]] of ammo allow the pilot to have two AC20 reloads and two LRM l reloads for extended time in combat. Lacking any electronics except for the [[LAMS]] to speak of leaves this Atlas inferior in the electronics warfare department, though this also helps keep costs down. While the Atlas D may lack the raw firepower compared to some Atlas variants and the extensive electronics packages of others, the Atlas D is still a powerful asset in the right hands, and the low price tag allows it to get into more hands.

===Variant E - ''"Master & Commander"''===
The Atlas Variant E is outfitted with the most sophisticated electronics available. [[BHP]] gives it enormous sensor range, an advantage it can share with its comrades due to the [[C3|C3 Master]], while [[GECM]] keeps it hidden from detection. Dual [[LAMS]] offer itself and nearby allies good protection from missile barrages, and the [[NARC|iNARC]] enables it to select targets for friendly missile artillery. The armament of 2 [[ERLL]]s and 2 [[LRM15]]s give it long range firepower similar to most long-range IS heavy Mechs and 2 [[ERML]] add a little extra firepower at medium ranges. Overall, it cannot expect to defeat [[Clan]] heavy and assault Mechs on its own. But, as the anchor that keeps the forces rallied, single combat is not amongst its abilities. It is supposed to be the leader of a pack, giving them cover, giving them information, giving them protection, and giving them their targets to slay. The Atlas E only has [[Free tons|1 ton for extra ammo]], meaning the player will have to choose: NARC ammo or LRM ammo? Even if the player chooses LRM ammo, they will find their damage output dramatically reduced as only one of the two LRM15s will be able to reload. It is the least [[Armor|Armored]] in the group and carries an additional 4 [[DHS]].

Note: This asset has both C3 and GECM, meaning there is no benefit to using [[Radar#Passive Radar|passive radar]].

===Variant F===
A unique variant, the Atlas F heavily relies on the mechwarrior's ability to use the four heavy hitting [[Thunderbolt]] missile launchers as effectively as possible. Their lock on range is 700m but will still do massive damage to targets up to 1000m away. They do have a rather slow turning radius, thus are quite ineffective against agile targets. Instead, mechwarriors should unleash the pinpoint accuracy of the long range three [[LPL|Large Pulse Lasers]] against said targets. Furthermore, mastering the ability to dumbfire the Thunderbolt missiles at brawling range is somewhat difficult but oh so rewarding when accomplished successfully. Careful maneuvering is required for the F to get into position, trying to get a down the throat or up the kilt shot that'll maximize the chance of the Tbolts hitting. This is far easier against slower targets while quick mechs can dodge out of the way relatively easily unless at close range. 2 [[free tons]] of ammo are insufficient for longer combat engagements. The Atlas F lacks any defensive electronics equipment, so mechwarriors should not be caught out in the open against enemy missile boats or dedicated long range snipers.

===Variant G===
The punishing power of the G is a bargin at only 98100 CBills for a brutal close in warrior. Any enemy mechs that are on the receiving end of its [[Gameplay_Tactics#Alpha_Strike|alpha strike]] consisting of a [[UAC20]] and twin [[MRM30]]s, plus four [[HMG]]s can attest to its awesome firepower that shreds opponents in mere seconds. Two [[DHS]] are sufficient for extended autocannon & heavy machine guns fire but may pose a problem when incorporating the MRM30's, so keep an eye on your temperature. 3 [[free tons]] of ammo are just enough for an average battle time period, know your reload locations. Though, its slow movement must be accounted for thus wise pilots should always be situationally aware of the ebb and flow of the battle to not get over-extended and swarmed by the enemy. Furthermore, a clever opponent can partially mitigate this Atlas's firepower by closing *inside* of the [[MRM30]]'s [[minimum range]], so be wary of fast brawlers and take them down quickly!
{{Clear}}

==History==
[[File:Atlas.jpg|thumb|175px|Original "Fishbowl" head Atlas from pre-0.3.0]]
Before version 0.3.0, the Atlas was referred to as a ''swimming pool'' or ''glass bulb''. The top part of the head was made entirely of glass, appearing for units or [[BA]] above it as an empty space, often leading to surprise when a direct hit on the pilot didn't result in a kill. In the 0.3.0 release, a metal helmet-like cover was added to the head, changing the appearance of the unit, though still not giving it the instantly recognizable skull-head/death's mask due to technical limitations. A head modeled entirely as a skull would make it nearly impossible to pilot the unit, due to obscured vision.

==Canon==
{{Quote|"A ’Mech as powerful as possible, as impenetrable as possible, and as ugly and foreboding as conceivable, so that fear itself will be our ally."|Aleksandr Kerensky}}
The Atlas, or "''Death's Head''" as it was nicknamed by MechWarriors, is a 100 ton Assault 'Mech built in the period leading up to the fall of the Star League. The first appearance of this 'Mech on the battlefield was during the [https://www.sarna.net/wiki/Amaris_Civil_War Amaris Civil War], as the forces of General Kerensky sought to retake Terra and end the rule of Stefan the Usurper. When Kerensky sounded the call that was to become the Exodus, most of the Atlas pilots in the SLDF refused to respond, and thus the 'Mech remained in the Inner Sphere where it would go on to many years of glory.

Originally the Atlas was one of the first units to mount the [[AC20]], supported by a uniquely configured [[LRM20]]. Utilizing a faster than usual reload mechanism, the launcher fired 20 missiles from five tubes in the time a traditional LRM20 launcher would shoot a single salvo and reload. Additional support weapons were 4 [[ML|Medium Lasers]] and a single [[SRM6]] launcher. A small dish antenna mounted on the Atlas' head allowed communication with orbital units or satellites, and it could be folded inside of head. Until the rediscovery of ferro-fibrous armor in the mid-3030s, the Atlas was the most heavily armored 'Mech to ever walk the battlefield.

Date Introduced 2755 during the Era known as "Star League" (2571 - 2780) - Unit Role: Juggernaut

[http://www.sarna.net/wiki/Atlas_(BattleMech) BattleTech Reference]

{{Template:Navbox_Assets_IS}}

Download MWLL

2020-05-26T06:37:53Z

Fire-hound:

{{Stub}}
{| style="width: 100%; text-align: center"
{{ContentCell|100%|[https://mechlivinglegends.net/ Official Servers]|
While certainly at all times the most up to date version; official download speeds can be slow during high-demand times. 
}}
{| style="width: 100%"
{{ContentCell|50%|[https://mechlivinglegends.net/download/MWLL-Installer.exe Downloader Client]|
 
'''[https://mechlivinglegends.net/download/MWLL-Installer.exe MWLL + Crysis Wars installer]''' 
(60MB) 
Usually you get this, let it run and it will download just about everything in one pass or two. While it might not be the fastest option, it will be the most recent one and the actual original source of every other download option. 
It will reliably continue interrupted downloads at the same file it failed to successfully complete.

}}
{{ContentCell|50%|[https://mechlivinglegends.net/download/Offline-Installer/ Offline Installer]|
'''[https://mechlivinglegends.net/download/Offline-Installer Offline-Installer]''' 
(7GB) 
Like former, but contains all game data (download all files) in one big chunk. 
Available as direct download or as a [https://mechlivinglegends.net/download/Offline-Installer/ torrent]. 
Those versions are generated only after the former version is put to service, usually the same day of release or sooner. 

}}
|}

{|
{| style="width: 100%; text-align: center"
{|[https://mechlivinglegends.net/download/Offline-Installer/ Torrent download]|
|}
{| style="width: 100%; text-align: center"
{{ContentCell|100%|Mod DB|
'''[https://www.moddb.com/mods/mechwarrior-living-legends/downloads Mod DB]''' 
Often has better download speeds than the official server.}}
|}
{| style="width: 100%; text-align: center"
{{ContentCell|100%|12th VR Network|
'''[https://mwll-tc.12vr.org/mechlivinglegends.net/install/MWLL-012-Offline-Installer/ 12th VR Network]''' 
Another fast backup mirror.
}}
|}
{| style="width: 100%; text-align: center"
{{ContentCell|100%|Torrent|
'''[https://mechlivinglegends.net/download/Offline-Installer/ Torrent download]''' 
Try the [https://mechlivinglegends.net/download/Offline-Installer/ torrent] as an alternative to direct download when official servers are busy or slow. 
Alternative location of the [https://mwll-tc.12vr.org/mechlivinglegends.net/MWLL012TorrentFile/ torrent] file. 
The torrent is the only source of download that has finer grained resume mechanism than the Launcher/Downloader.
}}
|}

{{ContentCell|100%|[https://mwll-tc.12vr.org/mechlivinglegends.net/install/MWLL-012-Offline-Installer/ Extras for Experts]|
''Only for those who absolutely know what they are doing'' 
'''[https://mechlivinglegends.net/download/CrysisWars-1.5.zip Crysis Wars 1.5 archive only]''' 
(3.5GB)
 
Zip archive - Trial version, without maps, with Editor.
 Patched to use our replacement GameSpy service. 
 
'''[https://mechlivinglegends.net/download/ Individual Patches and Other Files]''' 
 
'''[https://mechlivinglegends.net/download/old/ Old Versions]''' 
In the case you contract nostalgia or something.}}
|}

=== The History of Why Downloading MW:LL Can Be Hard ===

Historically this mod has been difficult to find and install. Around 0.7.1 [https://web.archive.org/web/20160312164449/http://forum.mechlivinglegends.net/index.php/topic,19022.0.html Gouty] made an installer to streamline the process of installation. Since then, and up to the revival of the project by the community, this very installer served through what is sometimes called the "dark age" of MW:LL. 

Around 2016 MW:LL development was revived, this time carried by the community led by '''xInViCtuSx''' and '''Star Wraith'''; as the original development team of [[Mechwarrior: Living Legends/Legacy Team| Wandering Samurai Studios]] dissolved already earlier around the unfortunate pseudo-C&D event. Year 2017 had already seen a vivid release cycle with a new launcher that was able to download, re-download, and repair corrupted files of the game. It was also able to perform additional tasks and roles like the [[actionmapper]], server setup, and more. 

The infrastructure bearing the game files that the downloader points to, now and then, have remained the same: A voluntary dedicated server with a personal ISP data plan. And as such it is easy to over burden the setup with even moderate download spikes that usually occur around release days. 

The community has been struggling every since to provide alternate download links and options - the most obvious being a torrent seeded by the beefier ISP subscribers who happen to get the ''Offline installer'' first, alas this was not always met with luck. We, the community, where lucky to have our good host and member '''Rick Hunter''' who not only hosts the excellent ''Neucasson'' game servers alongside the ever trusty [[Clan Jade Wolf| HAARP's]] ''Funbocks'', but Rick also has put in substantial effort and resources, to provide alternate fast download links for other community needs as well. 

=== Why resort first to the Launcher/Downloader ===

As one might infer, historically, majority of issues players had with MW:LL were related to having the downloaded content match current game version. Once the team moved to the automated procedure endorsed by the Launcher, the community tech support effort shifted to mainly pointing troubled users to the few launchers file-checking facilities and system optimizations related to our ancient engine system quirks (Windows changed a lot since XP era the underlying Crysis Wars were developed on). Thus players are encouraged to get familiar with the Launcher in the sense of file checking if they receive error messages from the game systems in that regard. 
Besides file checking, the handy Launcher is also the first thing to resort to when in need of a freshly generated player profile - in case the used one becomes corrupt. This might usually happen between game versions among other causes. You backed up your player profile on time, right?