OK, I'm not sure whats changed here, this all worked perfectly yesterday. For some reason, when ever I attack with this unit, it calls script.StartMoving() (I know it calls this as if I uncoment the 'Spring.Echo' that pings a message everytime I attack.) and it does so for as far as I can tell, no valid reason. The only changes I made were adding in the gadets and luas for normal maps, so I dont see how that could have screwed it up. SO, I'm guessing that at some point I deleted or added a line and didn't notice in the unit script.

code: http://pastebin.com/iWZNaJMb

Anyone see where I went wrong? Also... why do Signals have to be 1 2 4 etc...?

aGorm

knorke: made you a pastebin

It's not too unusual that StartMoving is called when you don't want it to, are you sure it wasn't being called before? Did you change the unitdef or weapondef at all?

As for signals, in cob they are bitmasks, though Tobi added something in LUS which means you can actually use any object. I imagine they still behave as bitmasks for integers though (which can be useful if you say, want one signal to kill two independent threads)

StartMoving / StopMoving get called all the time in strange situations. ie if a unit is driving and decreases speed just a tiny speed to make a turn, they get called too. (imo a bug but oh well)

To decide if threadnumber A is killed by signalnumber B some bitwise operation is used. (see Flozis link)
http://pastebin.com/raw.php?i=qEPRtcD9
X means thread gets killed.
Notice most numbers kill multiple threads at once.
Now look at row 1,2,8,16: Notice there is only one X
Some numbers only kill one thread, usually those are the ones you want to use. (ie do not want to stop the recoil animation if the unit stops walking)
1,2,8,16,32,128,256,...
x^2

(disclaimer: not sure if 100% correct)

OK, so i found the bug.



For some reason this sleep causes it to trigger? I don't know why though. I was using it to desynce the walk cycles so large groups would look odd, (by giving them a small random delay), but I suppose I shall have to come at it another way... anyone got any good ideas how to achive somthign similar? And anyone have an explanation for why that would have been the cause?

PS thanks knorke for the paste bin, I'll start to use that from now on.

aGorm

try like:
(set signal first, then sleep)

Yep... more questions for you coding gurus out there...

I have a function and I want it to call another function.

Example:


Now, I know at the moment the putting the aim code in there own functions is unessesery, as I could just put it stright in, but thats cause this is a realy simplfied version of what I want to do. What I'm wondering is, why would that not work?

aGorm

iirc WaitForX and Sleep can only be called in 'threads', i.e. functions called using StartThread. This of course results in other possible problems.

... hmmm, OK, is there some way I can include the code (IE, like in PHP you might do an include of say your page headers, so there all referencing one file? Although in this case I just want to reference a block of code elsewere in the script...)

aGorm

Dont know if i can give any good avice here - but my attempt to solve this would be to have three diffrent walk animations, and to hand to every unit a diffrent walkanimation seed.

Seeds would be generated and stored while manufacturing.
Unit with seed: 332211>>doALoop would walk diffrent (just by the looks of course) then unit with 313131.

Dont know if this is a good solution though. If every unit has such a value that is constantly called during movement, the price for moving large groups could get very high, very fast.. so i would make a safetyline that doesent use the seed when more then fifty units are selected.

TL, dr; Grab yourself Code Blocks and a Compiler, and start forking things up

are you getting a specific error? have you tried using a forward declaration?

Derp, I didn't even think of the obvious issue. I'm so off the ball lately.

OK, so I worked a way around my problem... (by not trying to do it that way, I realised I was being stupid and trying to do somthing I didn't even need)

I'm wondering though... is there a limit on the number of threads in a script? Currently I have 4, will going to 5 make it slow down loads if there are many units? How about 6 or 7? Has anyone tested this?

aGorm

I guess eventually too much of anything is bad. But in practice it does not seem to matter much/at all.

Any idea how you stop a thred from with itself? Apparenly signaling it from within itself doesn't work.

It's a function, you can just use a return statement to leave it

I broke it... for some reason it thinks the files not there even though it is. So I'm assumeing that I've prob missed something. I've re exported the s30 incase it was corrupt, check all the piece names are correct, set a height and hitbox... is there somthing else that could result in this error?

aGorm

Did you reset the textures when re-exporting / resaving the s3o?

I was an idiot.... had changed the textures to dds, and forgot to go back though my s3o's and re name....

Now I have a very odd problem. I have to units, both using pretty much the same script. Both have a walk cycle that is identical (sharing teh same legs as they do). But for some reason I can't quite figure out, the walk on one is messed up and on the other isn't. I've been pulling my hair out and final have narrowed it down to this:



For some reason "function script.StopMoving()" keeps being called on one unit. its walking just teh same as the other one, but were as one just pings "starting to walk!" at teh start and "stopped walking!" when it reaches its destination, the second unit keeps pinging both all the time its walking (hence the walk cycle is stoped and started from the start again all the time.)

Has anyone else had a smililar issue at all? I can't help think its not so much the script but maybe somthing in the unit defs? Can you have a max-speed less than 1? Thats the only difference I think?

aGorm

yes, i had similar issues. You actually can see it in the console, the unit is stoping all the time. While Turning. While coming to a hill.. encountering friends and so on.

Trick is to make the stop thread slightly timedelayed, so when the unit starts walking again, the signal kills the stopthread before it can signal the walkthread to be killed.

Speed is a float so that should be fine. Picasso is probably on the right track