Jump to content
zigeris

Gundam Mod: Starting off small.

Recommended Posts

Gundam Mod: Starting off small.

Because, for whatever reasons this forum has been broken and there is a image verification over the title portion o f this posting guide.

Right, Of course this has been chatting about before, but no real "good" conversations about particulars regarding the how. I have very specific requests for help regarding this project. I have a MS-05B model created for the Alpha mod of what I am calling Federation Vs. Zeon: Earth Conflict. Or FVZEC for the 'mod' name. I want a SP story line and a MP for LAN and RP servers and whichever. My first concerns is getting the MS-05B up to spec.

This is exactly how I see it to work out. Many talk about using a tank as a base for 'mech' machines and I believe for the purpose of what I am trying to do it might fall short. I was thinking, originally, using a base of a human script and just scaling it to the MS-05B. The way the mech moves, handles weapons, and targets. Upon that, I wondered how I would get them to fly. One of my bigger questions is how I can create the Backpack slot to being the "flight pack" (attachable component with rocket motors that can repel the mech into the sky). The issue of weight comes to mind as I wanna keep this on the realistic side as well.

Project's Goals and Scheduled plans for the mod.

Release for testing FVZEC V0.0.0.1 Set for October (grant I get some help).

Phase One:

My first goal is to convert a human solider player into the framework and body of the MS-05B (which is 18 feet tall)

- Finish the Model/with textures and prime it for ARMA II

- Animations (re scaling preset animations if possible)

- Weapon Handling (picking up and dropping weapons)

- Controls

- Damage (I do want to change how the damage is received and how it effects the mech)

Phase Two:

-Flight packs (Standard model, and ParaDrop Edition which will have a parachute that opens when dropped from high attitudes)

-Recharging/discharging power supplies for flight and operation time (Two types, one is for flight the other is for everything else. Mobile Suits use reactors to power them.)

-Embarking and Disembarking (Human to machine)

-Targeting Systems for 120mm machinegun (Primary Test Weapon) (Auto locking System, the weapon's muzzle will be forced to follow the target based on which is activated Inferred or Laser)

-Zeroing For 120mm MachineGun

-Thruster Animations, dust animations, sounds, and other effects

- Able to fire weapons while running (using the laser or inferred targeting as guidance)

Phase Three:

- Maintenance and compartment upgrading

- Balancing

- Cockpit mode (3d Cockpit that uses a 3 monitor scheme (early designs)

- Hud GUI customized

- IFF for safe guards against friendly fire.

So my (first) question is, how successful would it be to re-scale a regular solider's data plus animations?

That is where I would like to begin, the rest of it should this work

Edited by Rellikki
Moved to Arma 2 board.

Share this post


Link to post
Share on other sites

For Arma II? This is the Arma: Cold War Assault section of the forum.

A little input, no matter which of those two games, though:

I wouldn't start off with a standard human model, and I'd forget the idea of using standard animations. Scaling up the 100+ animation files (there was a tool for that in CWA, but still...) is too much work, and each one would have to be re-edited anyway to fit the Gundam style. Better to start with the model from scratch, name the different sections for the movements and create own animations - a Gundam won't need as many as a soldier anyway. Blender and the Arma toolset would be a good way to get the animations done easier.

Making it human would cause several issues (most likely in both games) - in CWA specifically death; if the movement speed is too high, the friction kills the soldier. I have a lots of other confused thoughts on how to pull it off, but all of them have their own specific sets of problems...

Share this post


Link to post
Share on other sites

I doubt the standard animations would visually suit something that large.But scaling them up isn't difficult.Although what ever approach you take it means some work.There's no way of batch scaling them as far as I know.So it would mean doing them one by one.

For whatever reason,the various classes had restrictions placed on them.Hard coded restrictions.

This will factor into your limited choices.As you mentioned,the tank and man classes are the main

candidates.

Man class:

Man class units can use rtms.So this allows key framed animations which can be tailored to the model in question.If you're concerned with aesthetics then this is the best choice.But it comes with it's own limitations.As I mentioned,there's restrictions.Instead of an entity interacting with the game world,based solely on mass and volume,it's a combination of those and what ever limits BI decided to place on the class.This applies to CWA.I believe it's handled differently in A2.

In CWA this means a 20 foot tall,heavily armed robot can't push aside lighter vehicles.They will also be unable to trample trees,houses,or even infantry.In fact,a standard man unit will be able to push this giant machine around as if it was a beach ball.The only counter to this is scripting.

Optics are limited to the weapons the unit carries.

Trying to put a 3 dimensional cockpit into the "head" in the first person view,will result in some very odd movement.The default range of motion for the player view point would need to be tweaked.That's something you'd need to try out to understand.

Weapons are not an integral part of the man class.They can be dropped and picked up.

The unit bleeds when hit.

Lenyoga mentions a character dying if it moves too quickly.This is true.But for whatever reason(Stride length?)this hasn't affected two of my own units.One measuring 7 feet 6 inches tall.The other standing 15 meters in height.It seems to be related to the speed and total move,relative to size.As I didn't really change the speed value much, for the individual anims.They do both have very high armour levels.So I thought they might be taking damage,which was offset by that.I did try a looping script though to return the damage level every 2 seconds.Impact damage did register.But normal operation(Running,walking) didn't register any damage for the duration of the test.

Tank class:

Tanks,or other "vehicles",cannot use rtms. :(

Animations are config based.And quite limited in how they can be used.Only one selection per animation is accepted.This is why it's the least aesthetically appealing.In fact it can look pretty bad.Some people are fine with that,as the class addresses the other issues.

It's mass more accurately interacts with the game environment.In other words,with the

exception of some buildings,a tank class can knock down and push aside lighter models.

It can have a variety of integral weapons.

It can have various interior views.

It doesn't bleed when hit.

Obviously,not all of that applies to the post CWA titles.But a lot of it does.

:)

Edited by Maczer

Share this post


Link to post
Share on other sites
I doubt the standard animations would visually suit something that large.But scaling them up isn't difficult.Although what ever approach you take it means some work.There's no way of batch scaling them as far as I know.So it would mean doing them one by one.

For whatever reason,the various classes had restrictions placed on them.Hard coded restrictions.

This will factor into your limited choices.As you mentioned,the tank and man classes are the main

candidates.

Man class:

Man class units can use rtms.So this allows key framed animations which can be tailored to the model in question.If you're concerned with aesthetics then this is the best choice.But it comes with it's own limitations.As I mentioned,there's restrictions.Instead of an entity interacting with the game world,based solely on mass and volume,it's a combination of those and what ever limits BI decided to place on the class.This applies to CWA.I believe it's handled differently in A2.

In CWA this means a 20 foot tall,heavily armed robot can't push aside lighter vehicles.They will also be unable to trample trees,houses,or even infantry.In fact,a standard man unit will be able to push this giant machine around as if it was a beach ball.The only counter to this is scripting.

Optics are limited to the weapons the unit carries.

Trying to put a 3 dimensional cockpit into the "head" in the first person view,will result in some very odd movement.The default range of motion for the player view point would need to be tweaked.That's something you'd need to try out to understand.

Weapons are not an integral part of the man class.They can be dropped and picked up.

The unit bleeds when hit.

Lenyoga mentions a character dying if it moves too quickly.This is true.But for whatever reason(Stride length?)this hasn't affected two of my own units.One measuring 7 feet 6 inches tall.The other standing 15 meters in height.It seems to be related to the speed and total move,relative to size.As I didn't really change the speed value much, for the individual anims.They do both have very high armour levels.So I thought they might be taking damage,which was offset by that.I did try a looping script though to return the damage level every 2 seconds.Impact damage did register.But normal operation(Running,walking) didn't register any damage for the duration of the test.

Tank class:

Tanks,or other "vehicles",cannot use rtms. :(

Animations are config based.And quite limited in how they can be used.Only one selection per animation is accepted.This is why it's the least aesthetically appealing.In fact it can look pretty bad.Some people are fine with that,as the class addresses the other issues.

It's mass more accurately interacts with the game environment.In other words,with the

exception of some buildings,a tank class can knock down and push aside lighter models.

It can have a variety of integral weapons.

It can have various interior views.

It doesn't bleed when hit.

Obviously,not all of that applies to the post CWA titles.But a lot of it does.

:)

A lot to go through here.

I'll go in order for which my brain received.

- Bleeding, as I see it, can be altered to "Sparks and arching connections" as part of the effects. If I could change the color and particle shape, making a new one, then I don't see an issue for it.

- Weapon Optics: I am not too concern about being the weapon hosting the target system. I was looking to doing a 'missile' type locking. As long as I can turn auto aim systems on and off while zeroing/zooming then I am perfectly fine with it.

-Weigh. Now I was looking through tuts about mass and such. So based on my limited experience with this engine, if I were to change the center of mass and weigh the 18 foot tall mecha to be heavier than that of a 'small' car would that work as to the effect of who could push who? As for stepping on cars and all that I believe I could add a collision point that if an object is touched by this point it will act as a bullet hitting it?

- Camera's for internal view. The cockpit is in the chest and it's a completely closed cockpit. I was interested in seeing if I could have camera points positioned in three locations and have the image projected onto the screens within the model itself. Like when you're looking through the target camera's of the Apache. That's how I was looking to do it. That, and having the ability to open the hatch and you can look through it. In the TV series they open the hatch from time to time for what I believe is a sense of fresh air and what not.

- Damage while moving too fast? That is a very interesting cause and effect. When I read your statements. Wear and tear is something that is a routine burden for a crew and pilot. Insta-death though from running...yeah. So when it comes to that time to observe that, I would need more instruction. I did note from time to time that walking into trucks would cause injury, even tents.

Movement is important in my mind. And I agree that the mecha wouldn't need as many animations. Kneel, Walk, Run, Forward Flight, Backwards flight, L/R flight, defense (shield moved forward, and eventually some melee options. Blender.... urg I could never get that program to operation the way I want it to. I've used 3dmax before, but now I have neither.

I'm curious about the effects of center of mass, mass, center pins? I ask, because at some point I'll want to start working on the "flying ability" which is nothing more than a jump with thrusters and a control fall afterwards. Well, at least, with the MS-05B and other types.

Which would lead to the other issue of reducing the fall impact. I believe that a 10% blow fall should be worked to keep the mech from 'dyin' if I were to persist on using a man class. This means only 90% of the thrust power will go into the vertical lift, and unalterable 10% thrust at X height for X velocity.

The main thing I want to project is two things gameplay, and appearance of intensity.

A lot of mecha games I've played fell into two main pitfalls, clunky-slow limited mobility and or so impervious to physics it was just too easy. I want every fight, for every pilot (player), to feel like they are truly pushing their ability. And for some it becomes as a default to their nature, everyone has a craft they hone in. They put personality into their object. This is why I say movement is even greater importance than the rest of the project.

Edited by Zigeris
typo

Share this post


Link to post
Share on other sites

I still don't know whether you want to create the machine for Arma II or CWA, but if it's the latter, I think I can address some of the points.

- the bleeding can be edited in the main config, the thing is it would affect the bleeding particle drop of every single human unit in the game. Wouldn't be too much of an issue for a Sci Fi mod, I guess (as I'm handling it similar, with a very dark colored sprite, which goes for robots and soldiers/cyborgs alike.)

- locking system (based on weapon config) is entirely possible, also with custom lock-on symbols and all that. Auto aim won't be possible without some external things like FWatch.

- Weight and mass are strange. If man-based units weigh more than car-based ones, they can sometimes push them aside, but no matter how much they weigh, they can still be easily moved by lighter soldiers. There are script workarounds for that nasty flying back effect when being hit by something explosive, though.

- Movement damage: Counting in what Maczer said, there are several possible factors which might or might not affect this. Movement speed in config file, actual distance covered in the animation file, position of the 'landcontact' and other 3d model points could be factors. A workaround would be a very subtle regeneration script for the unit. I think I tried something like that for a flying unit once.

- and there we go for the movement too, you can set the crawling stance for the unit to be the flying move - simply increase the height in the animation and add some fitting pose, etc. In my example, the LOTR fellbeast, flying was the default (altitude couldn't change, though) and staying on the ground was the crawling stance. Flying won't be influenced by physics then, though. (other maddening-to-work-on workarounds would be creating an invisible helicopter class unit which handles that, like the swimming simulation for some special forces addon I've seen)

- Falling impact can easily be negated by running a script that checks your x distance to the ground when falling and decreasing the velocity.

- reminds me of something I did for the HL2 gunships - a hybrid between helicopter and soldier, I used a man-based unit which was only wings and did the wing flapping animation and the helicopter which was basically the fuselage of the whole thing which handled the guns and flying. Animations can still be triggered for pilots.

@Zulu1 Thanks for posting! As Ghost in the Shell, this is gold for me!

Share this post


Link to post
Share on other sites

Thanks for the quick replies, definitely gave me a lot of idea's so far! I am going to do a model from scratch, I will attempt a man class. As mentioned a heli hybrid was one of the other ways I was thinking. Ok, so for the Oxy2, I've imported my model and messing around I'll report in on my findings. I am wondering, and why I was trying to convert a premade sample, is the minimum requirements regarding the ability to put the model in game. Disbarring all the ambition for what I want to have done with it. SO that means like contact points, camera points, hit points, LODs, and whichever is left. What are the MUST have points? Also, I lost my texture for my model some time ago, would I be able to texture directly from Oxy2?

And this is for ARMA II, if I had monies...I'd get ARMA III and work on it from there...but that too would require my brother to have a computer that can handle it...as one of my major reasons for making this mod is for him.

Edited by Zigeris

Share this post


Link to post
Share on other sites

So, you need a few basic LODs - at least one resolution LOD, geometry (collisions), fire geometry (bullet impacts), view geometry (blocks camera and view, optional, if not present, it will use the geo LOD), memory (lots of important components for all kinds of things - better copy that from a soldier model and scale it up), hit points (to detect which body part has been hit) and LandContact (where the unit touches the ground).

To make animations possible, each body part has to be defined in a named selection (also in all the other LODs, not just the visible one)

You can texture in O2, but you'll probably need some tools for UV mapping, because sticking the pictures at the model from 2d perspectives is painful enough... I've done that for years and still didn't recover.

Share this post


Link to post
Share on other sites

Thanks again your help is spot on. I'll update the progress as it emerges from my desk. I will do bi weekly reports at the least.

---------- Post added at 23:53 ---------- Previous post was at 22:24 ----------

Another question...crap I forgot what I was going to ask... oh right!

What is the component that controls thrust? IE from like a fighter jet (vs. heli)?

Assuming I construct all the LODs correctly, a script would have to define each? Or could I do the same as with the sample unit and rename some of the configs?

Final question: The machine has several parts to it as listed:

Head > Camera > RadarAnt

UpperBody>L/R ARM>L/RLowerARM>L/R hands

BackPack> Engine>L/R Nozzels

LowerBody(hip)>L/R Upper Leg>L/R lower leg>L/R foot

If I have them in separate sections (groupings) I could animate each section rather than having the model morph/bending?

For animation I can make each

Share this post


Link to post
Share on other sites

Well.As you're working with A2,that should open up some new options.Or at least deal with

some of the inherent limitations of CWA.If you did use the tank class,you'd have multiple

turrets available to you.

I can't personally give you all the information you need regarding the man class and how it

interacts with the game world.I've only really experimented with vehicles.

But I've spent quite a bit of time animating for CWA.The animation workflow is the same

for any of the titles.As the file format hasn't changed.But the main difference is the

config files.A model will typically have two separate files.The config.cpp and the model.cfg.

The config.cpp and it's sub-sections,concerns attributes of an addon and how it functions in game.

What model to use.What sounds.How fast it is.Etc.

The model.cfg is used to a define hierarchical list of "bones".And other sections that can be animated

or hidden/revealed.

As for the model.You can unwrap a model in O2Pe.Many people do.But I'd recommend trying something else.

As you can see from my Sig,I use Blender.Because there are some great addons for it specific to the Arma

engines,which cover model and rtm export.But there's also Soul assassin's 3ds max toolbox.Which looks very

high quality.There may be others.But I can't think of any right now.You'll need to have a look around.

EDIT:

If I didn't answer your questions,it's because I was typing while you were. :)

A man class has no provision for things like thrust.Not within the Model itself.

Edited by Maczer

Share this post


Link to post
Share on other sites

Thank you! Big boost of knowledge.

Would it be theoretically possible to mimic thrust, using the same parameters as "w" forward. Example: "q" key = 0(+1) * 30^2 by the positive or negative z axis? Whichever is up for arma. Then have an movement checker: if false then it descends 1/30 terminal velocity per second?

Share this post


Link to post
Share on other sites

Been searching for the script that controls movement. I swear I saw a debug mode for in game play. It'd help finding what resources are being used at what time.

Share this post


Link to post
Share on other sites

So could I created a hybrid class? How does the game engine recognize differences in classes? And Unit speed is still something I am looking for, I was thinking about tying it to a custom class. Do classes define type, or just unit names? IE Man - Air - Vech vs. USMC medic, Civilian. ect ect

Share this post


Link to post
Share on other sites

Not that I'm aware of.

Although you can create custom classes,they will still have to inherit from the hard-coded variety.

CfgVehicles is where the "Vehicle" classes are defined.Human and machine are considered vehicles.

The Umbrella class being Class all.Then Class Logic,class AllVehicles,Class Land,Class Man.And I

believe Class CaManBase inherits from Class Man.The soldier types are then presumably derived from that.

Then the specific types of unit would be defined in their own PBOs.

A helicopter,jet or car would also have their own hard-coded base classes.So there's no

provision for hybridising.A human,is a human,and a tank is a tank.

:)

Share this post


Link to post
Share on other sites

Ok, fair enough, so custom man units share one line of code when it comes to stats like velocity? Where would I observe that line of code? I've looked through the pbo's of the samples BI supplied, and still having a troubled time finding where I want to start. I wanted to test some things before I went further into the project. Mainly I want to create a code that controls jumping (using boost) and ejects a warning (a text that will display for the player) when falling below X alt at X speed that will be replaced with the automatic controlled thrust from the engine to reduce impact. Basically would look like moon walking for the test unit I want to create.

Share this post


Link to post
Share on other sites

It sounds like you'll need to create a function/script to handle that.

Possibly by using what are known as user actions.Which are the options that

show up as text on the bottom right of your screen in game.They can be defined

within the "vehicle's" class.

It's not a very elegant way of approaching it.But I don't have the knowledge to give

you a better solution.

It may be possible to tie certain keys to script/function.But I've never explored that

side of things.

For classes,try the SIX config browser.This is the CfgVehicles page for A2 with OA v1.62.

If you scroll down to the man class you can expand the "subclasses" to get a look at what's derived from it.

Inheritance should allow you to create your own config without having to quote each class in it's

entirety.

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×