Feature Request: Fetch a parameter from a map.

Archangel of Death · Post by **Archangel of Death** » 17 Sep 2005, 22:42

I'd like to be able to set an arbitrary value on a map that a unit's script can fetch. Like how wind generators get windspeed. Consider this very low priority, as there are no wind generators as far as I know in Battletech. I am going to highjack the wind value to use as a maps ambient temperature for now. Of course it will have to be constant and will likely be weird on maps that aren't built for this mod with tailored windspeed.

GrOuNd_ZeRo · Post by **GrOuNd_ZeRo** » 18 Sep 2005, 00:33

How about units fetching what type of map it is like green, desert, snow, etc, so we can have different camo schemes? not necesarilly for Battletech/Mechwarrior.

Gnomre · Post by **Gnomre** » 18 Sep 2005, 00:45

Yeah, now if we just had someone to code it for us!

SinbadEV · Post by **SinbadEV** » 18 Sep 2005, 01:15

Or read type-maps... you know... the things that define hardness etc... they already have names... then you could have the areas around Lava be of a type that the mod recognizes as "really freaking hot" or visa-versa for Ice maps...

Warlord Zsinj · Post by **Warlord Zsinj** » 18 Sep 2005, 05:07

For those too lazy to click Gnome's link, Gnome suggestd and coded map-specific camo, but for some reason, even with the coding presented on a silver platter, the SY's haven't put it in yet. o_O

GrOuNd_ZeRo · Post by **GrOuNd_ZeRo** » 18 Sep 2005, 05:22

This could would be great.

I urge Gnome to add Desert Camo to it too, the default can be whatever, but it would be nice if units could have a model for every occasion!

Archangel of Death · Post by **Archangel of Death** » 18 Sep 2005, 06:19

Ok, I can't use windspeed like I wanted. It seems it will only tell the script the windspeed if it is a windgenerator (>0). I don't want them generating varied amounts of power now. I can't use small numbers like .01 because then randfloat * 2 * PI would make massive changes to it. Consider this request changed to priority 1!

Gnomre · Post by **Gnomre** » 18 Sep 2005, 06:26

GrOuNd_ZeRo wrote:This could would be great.

I urge Gnome to add Desert Camo to it too, the default can be whatever, but it would be nice if units could have a model for every occasion!

Well, in that topic I only had a couple different types just to test if it worked. Obviously the list would need expanded, but that's not a huge problem...

FizWizz · Post by **FizWizz** » 18 Sep 2005, 08:33

there are no wind generators as far as I know in Battletech.

Okay, it's not strictly "BattleTech," but there are Wind Generators that you have to destroy in a mission of MW2:Mercs...

zwzsg · Post by **zwzsg** » 18 Sep 2005, 18:15

Archangel of Death wrote:Ok, I can't use windspeed like I wanted. It seems it will only tell the script the windspeed if it is a windgenerator (>0). I don't want them generating varied amounts of power now. I can't use small numbers like .01 because then randfloat * 2 * PI would make massive changes to it. Consider this request changed to priority 1!

In TA, I think the value passed to SetSpeed is independant from the WindGenerator tag in the FBI. Cause I set it to 1 and still got value apparently similars to what I had with 30. In Spring I'll have to test, using that BriDoDon119windmill.ufo.

And why hasn't Gnome's code been included, or a least been given a reason for why not to include?

Post by SJ » 18 Sep 2005, 23:15

Letting scripts getting arbitary map def values would be hard since it would require the scripts to be able to handle strings which I dont think bos/cob is really capable off ? But we could easily add some sort of tag to get the wind value without being a windgenerator.

Out of curiosity though, im not very knowledgable about battletech but my impression is that it relies a lot on being able to do component damage with damage penetrating armor, how are you going to try to simulate this ?

The main reasons I didnt add in Gnome code was

1: It limits us to just a few world types
2: It requires different models instead of just different textures

But if thats how the modellers want it I can add it in.

SinbadEV · Post by **SinbadEV** » 18 Sep 2005, 23:46

I think the best option would be to let the units read the terrain type variable that are pulled from the typemap (ground hardness, movement speed) for it's current location... this would have a lot of uses other then just the wind generator/heat stuff... also having a unit just plain read the maps settings, water height aswell as all of the good stuff in the SMD file would be great... might be a mess, but it would be more dynamic than all the awkward extractsmetal-like propeties properties etc...

Archangel of Death · Post by **Archangel of Death** » 19 Sep 2005, 00:40

Ok, I've done some testing with the bridodon in spring and it appears that I read the code incorrectly. Of course it also did confirm that it passes a value between min-max windspeed times 3000. The reason I need to know what kind of values I'll be getting is because my script is going to be doing something like multiplying the heatsink's strength by a normal heat value/map heat value. Thus in "normal" tempurature environments it will get normal heat efficieny (normal/normal=1), in hot environments it will get less heat efficiency (normal/largerN=less than 1), and cold environments will get improved efficiency (normal/smallerN=greater than 1). No conflict with setting windgenerator to a small number (I tested 1) as I lead myself to believe, or really anything else as I had lead myself to believe.

Now armed with this information I can set windspeed guidlines for mapmakers to use when making maps for the battletech mod. 1-50 sounds good, with 25 as normal.

And yes, after looking through the involved code so much I can see how difficult it would be to get a units script to get values from a map. However it does look rather easy to add new tags that can be fed to the units script the same way it gets wind strength. I started working on adding in a tempurature tag that is passed to the units script through a cob function GetMapTemp, stopped at the point of testing as from what I've heard being able to compile the code is difficult to achieve. Gnome suggested using a new type map instead of a mapwide value. Now this would be far superior, but is pretty far beyond what I'm capable of so far, and I'm unsure how much processor power that would take.

And on the issue of component specific damage, I'm going to assume the vast majority of pilots in your service aren't especially skilled and will tend to spread the damage around. Actually I have considered adding in a damage script in which they would lose pieces and the weapons in them as they took damage and preferbly not get them back until they visited an mfb or dropship. I would need to be able to detect that a unit is being or has been loaded into a transport in the script to do this. Can I in Spring? It would be really nice to know as an ammo system could benefit from this as well.

Gnomre · Post by **Gnomre** » 19 Sep 2005, 01:12

SJ wrote:The main reasons I didnt add in Gnome code was

1: It limits us to just a few world types
2: It requires different models instead of just different textures

But if thats how the modellers want it I can add it in.

Put the "world definitions" in sidedata.tdf and then store the values in an array or something... that way a mod could easily specify what he wants World1, World2, etc to be, and then have the units load according to that. I don't know how you'd do a different texture job instead of a different model, my skills aren't quite that advanced... but hey, if you want to take a shot at it...

Maybe that'd be best saved for the new model format that will have the UV mapping and stuff? I mean, unless you guys are pulling miracles out of your ass for teamcoloring methods, you're going to have lots of different texture sheets for models anyway... may as well have the ability to have camo too at that point.

Warlord Zsinj · Post by **Warlord Zsinj** » 19 Sep 2005, 10:18

Even though I have nothing but the absolute basic knowledge in scripting, I feel I am qualified enough to open my big mouth (;)):

Perhaps it wouldn't be impossible to put in world-specific camouflage which does not require new texture sets for every unit for every world.

Could you make it so that for each world type created, a single texture is provided with it, which acts as a camouflage template. Then Spring would simply overlay each texture provided with the unit with this template, which would give the units the feel of this particular world. Obviously the Camo template would not be obvious or obnoxious, likely a basic blurred/despecled thing with a strong colour.

For example, on a snow world, there would be a white camo texture, which would be applied to the surface of all unit textures and give them a white camo tinge...

zwzsg · Post by **zwzsg** » 19 Sep 2005, 11:57

Archangel of Death wrote:I would need to be able to detect that a unit is being or has been loaded into a transport in the script to do this. Can I in Spring?

In TA, setSFXoccupy gets called with 0 for argument when a unit is loaded. setSFXoccupy gets called with another value when .... hey wait I already PMed you that!

AF · Post by AF » 19 Sep 2005, 12:19

As for limited nubmer of worlds I posted a solution in the thread whereby instead of differentiating between worlds using names you use numbers instead. I believe the theoretical max would then become somewhere around 32,000 worlds.

So gnome, how do you feel about remodelling all XTA units so we have a close up normal and far away model, then for each of those we have a desert grass and snow model, 9 new models per unit? 3 if warlords suggestion is coded?

And if the world texture overlay can be coded then so too can custom insignia.

GrOuNd_ZeRo · Post by **GrOuNd_ZeRo** » 19 Sep 2005, 21:07

In real life the most common are these:

-Olav Drab, was used mainly in WW2 till the late 60's in the US army, it's a form of green.
-Woodland: as the name implies, textures to blend in with grass and trees, combination of shades of green, brown and black.
-Desert: Usually Tan or tan, light brown and little pieces of white for pebbles.
Artic: Usually a combination of whites, greys and blues.

Other less conventional camo-schemes are Urban, Lowlight (Black or dark blue) or Euro which is a combination of brown IIRC.

Those would be enough currently, Crystal, Acid, Slate etc are not very common so those can just use the defaults.

I wouldn't mind having support for multiple models for different settings, in this way you could add more details to a Snow map like icicles and maybe mounds of snow, Desert could have other small details too.

Go ahead SJ, include it :) I wouldn't mind one bit :)

Archangel of Death · Post by **Archangel of Death** » 19 Sep 2005, 22:33

zwzsg wrote:In TA, setSFXoccupy gets called with 0 for argument when a unit is loaded. setSFXoccupy gets called with another value when .... hey wait I already PMed you that!

Yes you did. Then I pmed Fnordia asking whether it still worked in Spring. He has yet to respond. I was however about to test it today.

Doomweaver · Post by **Doomweaver** » 19 Sep 2005, 22:47

Camo seems like a bit of a waste of time. I mean it changes the look of units, so that they match the map. But this just makes the game look monotonous, doesn't it?

Spring RTS Engine

Feature Request: Fetch a parameter from a map.

Doesn't Battletech Spring sound so awsome!

Feature Request: Fetch a parameter from a map.