[request] set ARMORED to 0.36 (and an armored button)

[Optimus Prime]

Hi

i think a real value for set ARMORED would be cool, so we could have different damagemodifier values. In the unit fbi you have to set the damagemodifier for example to 0.1 and in the script you can multiplie this value for example with 10 or 0.35 or whatelse.
Also a button armored would be cool because the on/off button is already used by so many functions.

[KDR_11k]

I don't agree with the button for armored, that's too specific, what we need is script hook buttons in general, not specific buttons.

Values in the script must be integral so you can only set ARMORED to 1, 2 655, etc, fractions aren't possible. That's why float values are multiplied with a constant when you get/set them, e.g. radius and speed are multiplied with 65536 and veterancy with 100. But yes, a backwards compatible way to handle this would definitely be to allow setting ARMORED to multiples (more likely exponents so the effect of the damage multiplier is increased instead of always driven upwards).

[Caydr]

I can see JC coming now.

"NOOOOOOooooOOOO!!! WE NEED ABSTRACTION!!!!! ABBBSSSTRRAAACTIONNNN!!!!!!"

What we really need is a way to, in the script, set a condition based on something in the UI.

Something like

Code: Select all

[Button1]
{
states=3;
{
if button "HighTrajectory" = 0;
set label "HighTrajectory","Low Traj";
set state x;
if button "HighTrajectory" = 1;
set label "HighTrajectory","High Traj";
set state y;
if button "HighTrajectory" = 2;
set label "HighTrajectory","Auto Traj";
set state z;
}
}
[Button2]
{
states=2;
{
if button "armor" = 0;
set label "armor","Armor Deactivated";
set armored to 0;
if button "armor" = 1;
set label "armor","Armor Activated";
set armored to 1;
}
}

or whatever whatever whatever. You know what I mean, right?

Basically you can set via script anything to happen and have an unlimited number of buttons and they can say whatever you want for whatever they're set to.

[Optimus Prime]

that would be so cool. You really could give mods their own style and make a lot more things possible people dont even think at. Please one of the devs tell me that someone will work on this!

[KDR_11k]

Caydr, your proposal would require strings which aren't supported by the COB format.

[PK Maximoo]

People have been recommending a new scripting format for a long time.

As with 3do models and all other TA formats, they don't do anything more than TA wanted. And scripting in spring is still exactly the same as it ever was.

[Caydr]

Caydr, your proposal would require strings which aren't supported by the COB format.

I know, I'm suggesting a direction the new script format thing that's being worked on (....right? I thought I heard..., er..) might go.

[Dragon45]

You mean full LUA scripting support, set to follow a proper abstraction of the model and scripting code?? Its about as quickly coming as the new GUI

[AF]

[Button1]
{
states=3;
{
if button "HighTrajectory" = 0;
set label "HighTrajectory","Low Traj";
set state x;
if button "HighTrajectory" = 1;
set label "HighTrajectory","High Traj";
set state y;
if button "HighTrajectory" = 2;
set label "HighTrajectory","Auto Traj";
set state z;
}
}
[Button2]
{
states=2;
{
if button "armor" = 0;
set label "armor","Armor Deactivated";
set armored to 0;
if button "armor" = 1;
set label "armor","Armor Activated";
set armored to 1;
}
}

internally high trajectory is CMD_TRAJECTORY which has a numeric value of 120. It would be perfectly possible to tie something like this to the cob scripting along with move state, fire state, cloak, on/off, among other things, havign a direct imapct on the GUI and the untis actions.

of course this is all dependant on cobs ability to pass over 2 arguements/parameters to a keyword.

But adding buttons to the GUI and editing their labels through the script isnt possible. You'd need a groupAI to do that.

[SinbadEV]

But adding buttons to the GUI and editing their labels through the script isnt possible. You'd need a groupAI to do that.

Well, again, the solution to that is abstraction and a new gui and scripting language... groupAIs should only be user selectable dll's to attach to units... not default AIs for units (though with abstraction the same type of code in a group AI would be fine to attach to a unit's code... just don't want you calling it groupAI)... argue with me if you don't think I understand what you are saying.