Unit script have a menu button to switch between weapons

[FLOZi]

Excellent post knorke <3

[Jools]

SetSFXOccupy(terraintype): Supposedly called when the unit changes terrain type, although it didn't work last time I tried it? Maybe I was using it wrong. terraintype: 0 = transported, 1 = sea, 2 = deep sea (greater than 5 water depth and unit is upright), 4 = land.

About this function: the terrain type in this function means what terrain type the unit is over, not what it is in. For example, if a plane flies over water this function will return water and not air. Maybe it worked differently before, as many units scripts check for terraintype == 3, but that is never called in my opinion.

Instead: to check whether unit is in water you can use:

Code: Select all

if( Terraintype == 1 AND (get IN_WATER) )

[yuritch]

knorke: enough of those piece-variables are actually used in the script that I decided not to remove all the ones that aren't. Tables are used too (as arrays), and code duplication is less than it seems (any less would be more reflection than I like). But yes, it's a loooong script, unit has 32 independent turreted weapons...

[Forboding Angel]

Smoth and I sat down last night, and he walked me through it step by step, and we also implemented one of the key things I wanted (common functions that I can call from anywhere).

At this point I'm fairly confident that I could script just about anything that I wanted to in evo.

Here are the resultant files. I'll make a guide on my wiki page when I get some time. I approach it form an entirely different angle than any of you, and my angle will make it much easier for newbies to lus scripting who are already familiar with bos to pick it up without much difficulty.

As a result so last night, scripting tanks becomes more or less a total snoozefest.

Tank script:
https://code.google.com/p/evolutionrts/ ... k4_lus.lua

Common Includes:
https://code.google.com/p/evolutionrts/ ... es_lus.lua

[knorke]

one of the key things I wanted (common functions that I can call from anywhere).

I thought you wanted none of that "modular crap"?
And yes, sharing common used functions is basic idea of scripting (in any field), so that is why "show me a lus example of a unit with a weapon, that does not rely on any includes. " was bit silly question.
now your script has become the thing you previously hated

With regard to "setSFXOccupy does nothing? Orly." Yarly.
Read the long post. It explains why my linked script does not need it and the unit still follows terrain slopes just the same.

[smoth]

From what I gather, he doesn't want a setup as complex as mine or flozis.

Read the long post. It explains why my linked script does not need it and the unit still follows terrain slopes just the same.

what long post? what link?

[knorke]

the last post on previous page: http://springrts.com/phpbb/viewtopic.ph ... 20#p557486
The part numbered 2)

[smoth]

He now has the script altered. I don't know about the upright or not on water. It seems he was indicating the terrain beneath the water somehow effected his unit.

Forb, if you don't have this code running what happens with your unit on water that required you to setupright true when on water?

[Forboding Angel]

one of the key things I wanted (common functions that I can call from anywhere).

I thought you wanted none of that "modular crap"?

That is not "modular". At best it is cached functions that work for everything.

Modular is what smoth and flozi use and would make your head spin just to hear how it works.

[knorke]

[Forboding Angel]

Here is a fairly detailed video showing what happens, why it happens, and why the setSFXOccupy script is necessary.

http://www.twitch.tv/forbodingangel/b/525259372

That said, as you can see in the video, we find that upright = false no longer does anything for hovers at all. This was not always the case and it is not documented anywhere in the engine changelog (lolfigures). So somewhere between spring 75b1 and spring 96.0, upright is forced onto hovercraft, even if you set upright = false in the unitdef.

---

Knorke, just a point... You shouldn't use engine effects, ever. For anything. CEGs do it better (ship wakes are debatable, but they only appear on dynamic water anyway, so more or less useless). The ceg that you remove over water actually has a water only effect that happens as it is moving.

[knorke]

Knorke, just a point... You shouldn't use engine effects, ever. For anything. CEGs do it better. The ceg that you remove over water actually has a water only effect that happens as it is moving.

Not sure what you mean, but the CEGs in my script were just something I put as placeholders.

Here is a fairly detailed video showing what happens, why it happens, and why the setSFXOccupy script is necessary.

http://www.twitch.tv/forbodingangel/b/525259372

That said, as you can see in the video, we find that upright = false no longer does anything for hovers at all. This was not always the case and it is not documented anywhere in the engine changelog (lolfigures). So somewhere between spring 75b1 and spring 96.0, upright is forced onto hovercraft, even if you set upright = false in the unitdef.

In that recording you say "The last video actually failed to save" - ....
I just watched it. You had posted the link to it. But if you lost it, I can reupload it maybe?

The amusing part is that you record three videos in which you keep telling how important that script is...and then during recording "we find" that the oppossite of what videos were supposed to show was right.
If you look at my other post, it already has and explains solution, so can we please be done with this?

[Forboding Angel]

http://www.twitch.tv/forbodingangel/b/525259372

That's fairly detailed

but since spring 75.b1 they changed it at some point so that upright = true is forced upon hovercraft all the time, no matter what

used to, you could set upright = false on them.

But that was why you wrote that script for fang

because in ee

he wanted his hovercraft to act like tanks on land, and like hovers over water

cause he could have them act like tanks over land, but the moment they got on water, hilarity ensued.

Then, when I decided to use hovercraft extensively in evo, 5 years ago or so, you pointed me to that script, and I've been using it ever since.

In that recording you say "The last video actually failed to save" - ....
I just watched it. You had posted the link to it. But if you lost it, I can reupload it maybe?

In that video, I hit ctrl+s to save the script, but it didn't register in N++ rendering the entire vid invalid (you can tell by the way the tab stays red as I start spring). Which is why I had to record it a second time.

[knorke]

CEGs do it better (ship wakes are debatable, but they only appear on dynamic water anyway, so more or less useless).

Wrong. http://springrts.com/phpbb/viewtopic.ph ... es#p524636
How do you come up with these things?

http://www.twitch.tv/forbodingangel/b/525259372
but since spring 75.b1 they changed it at some point so that upright = true is forced upon hovercraft all the time, no matter what

Yes, such condition exists in engine code. But that was never up to debatte.

I said that the setOccuppyblawub is not needed now, while you were saying the opposite.
Had you bothered to test my script or read the posts, you would quickly have noticed that this was false.

I absolutely do not care that which point the script-blurb was still needed: Whether it was 3 or 8 years ago, or just last version, the script continued to get copied over and over, either out of habit or as a placebo...
Always interessting when such threads show how deeply the hoodoo-voodoo-cargocult approach to scripts is rooted in some spring peoplepersons.

Again: If you look at my other post, it already has and explains solution, so can we please be done with this?

[Google_Frog]

In the stumpy example where do the GGs go?
http://pastebin.com/yk2w3k0B

Code: Select all

function script.RockUnit(unitID, x, z) return GG.UnitScript.RockUnit(unitID, x, z, base)
--#include "hitweap.h"
function script.HitByWeapon(unitID, x, z) return GG.UnitScript.HitByWeapon(unitID, x, z, base)

[FLOZi]

For clarity:

Hovers always used to be forced to upright = true.

I added engine patch back in the old days for cob set UPRIGHT for S44 amphibians e.g. DUKW.

This is because units on the water surface with upright = false tracked the contours of the ground under the water, so you had to use SetSFXOccupy to be upright on water and not upright on land - unitdef tag alone was not enough.

If this has changed (as knorke suggests) that means engine now forces upright status for hovers when they are on water itself; not sure why that change would be implemented.

[FLOZi]

In the stumpy example where do the GGs go?
http://pastebin.com/yk2w3k0B

Code: Select all

function script.RockUnit(unitID, x, z) return GG.UnitScript.RockUnit(unitID, x, z, base)
--#include "hitweap.h"
function script.HitByWeapon(unitID, x, z) return GG.UnitScript.HitByWeapon(unitID, x, z, base)

Stumpy example i posted is a 'off the cuff' first attempt at writing LUS, I imagined that one could have a single script or gadget place such functions in GG (you can!) rather than bothering to write them.

[Forboding Angel]

CEGs do it better (ship wakes are debatable, but they only appear on dynamic water anyway, so more or less useless).

Wrong. http://springrts.com/phpbb/viewtopic.ph ... es#p524636
How do you come up with these things?

Didn't work in spring 94, don't give a shit in spring 96.

Regardless, engine effects < CEG.

Again: If you look at my other post, it already has and explains solution, so can we please be done with this?

You asked, I explained.

[knorke]

Didn't work in spring 94, don't give a shit in spring 96.

wrong.
spring 94, basic water, SFX.WAKE effect shows normal:



I never asked anything. I simply told that the setSFXOccupy script is not nessecary.
And posted a script that proves that.

Neither did you explain anything. You just repeat hat "the setSFXOccupy script is necessary."
Even after a script was posted that does not use it and still behaves same way.
Even after you have recorded videos that have actually shown the opposite but you just ignored what you saw.

[Forboding Angel]

You need to be trying wakes on all water. Afaik it has always worked on 0, but of course you know that, because you play/test on a toaster. It has always worked for dynamic as well. Not so much for reflective, reflective+refractive, and bump, and those 3 are the only ones I care about.

That said, wakes are on the meh side of cool. Cegs are just plain better although I doubt I could be arsed to make a nice ceg wake effect, so there's that.