adding landing pad lights on a skirmish map

[testtest1]

For 2.3 it is setLandingZone(x1,y1,x2,y2)

where do you got your commands from noq?
commands for 2.3??

[NoQ]

Very Interesting can have feed back if it works please?

It was the feedback already. It works. It also explains our experiement when we mixed USM with Volcanic Tilesets (it worked because Volcanic's vidmem.wrf was loaded last, and USM didn't need anything extra in vidmem.wrf at all).
I guess those textures get picked up automatically when the pie is mentioned in piestats.wrf.
So if we change eg. terrain textures we still need to put them into vidmem*.wrf.

following up on all of this is there a way of moving a unit from x,y to another x,y coordanate?

Teleport? No, i think not. Not in 3.1 for sure. For 3.2 (aka current master) we have removeDroid() for removing droids, we have addDroid (for 3.1 as well) for adding droid with given stats, but we can't really disassemble the droid to stats even in 3.2 (even though body and propulsion stats are already available, finally!), and we can't set health and armed status etc. via scripts. A dedicated teleport function is also not available yet, i think. There is some support for campaign-like "away" missions though.

[carbon dude oxide]

hmm ok so you cant jut set droid.x = 100?

jorzi said that i only had to put the texture and tcmask with nothing else and it works fine so yea its proven

[Per]

Very Interesting can have feed back if it works please?

This is supposed to work. I added lazy loading to the model texture code a while ago.

[NoQ]

hmm ok so you cant jut set droid.x = 100?

No.

The droid object that you receive here has multiple properties that can be accessed to learn more about it. These propertie are read-only, and cannot be changed. In fact, objects that you get are just a copies of game state, and do not give any access to changing the game state itself.

[carbon dude oxide]

Can the developers make it so you can change the position of the units ^.^

[carbon dude oxide]

Teleport? No, i think not. Not in 3.1 for sure. For 3.2 (aka current master) we have removeDroid() for removing droids, we have addDroid (for 3.1 as well) for adding droid with given stats, but we can't really disassemble the droid to stats even in 3.2 (even though body and propulsion stats are already available, finally!), and we can't set health and armed status etc. via scripts. A dedicated teleport function is also not available yet, i think. There is some support for campaign-like "away" missions though.

I thaught that adddroid does not work in skirmish or multyplayer

[carbon dude oxide]

hello ive run into a little problem again ^.^ i was hoping that i could get it to work without asking but it failed ^.^

i tried to get the structure that i have built into the research tree but i comes up with this error when i try to play a skirmish:



here is the mod along with the two reports ^.^

testmod (2).wz

Warzone2100.RPT

WZlog-0906_180150.txt

and there you go ^.^ if you could help me find the problem that would be brilliant

[carbon dude oxide]

dont worry about it ^.^i found out the problem idid not realise you add reearch stuff to naes.txt aswell so i added this:

R-Struc-LZArea _("Landing Zone")

and it works

[NoQ]

I thaught that adddroid does not work in skirmish or multyplayer

I think everything works everywhere, but of course there will be a desync if different players run different scripts.

[carbon dude oxide]

ok so if they all have the script there wont be a desync?

[NoQ]

The AI script runs only on host (other players don't need to have it), but it acts as a player (so other players will see a desync if the AI tries to cheat).

The rules.js script should be the same on all systems.

I'm not sure of anything written above, just a blind guess, never tried.

[carbon dude oxide]

so what is a desync and what does it do exsactly?

[NoQ]

so what is a desync and what does it do exsactly?

During the 3.1+ network game, two things are being sent between the machines:
1. Orders (droid orders, production orders, etc.)
2. Checksums (a way to check that the game state is the same on all machines)

The whole game state never gets transmitted.

If the checksum test fails, there is said to be a "desync". In this case the game proceeds, but the players see a "2+2=5" icon (similar to "Zzz" icon, just different) with a number pointing to the players whose checksum is different. But the game state on other machines is not altered or corrected in any way.

Thus, if a cheater manages to do something that violates the game rules, his machine will just go into a desync. Everybody sees the "2+2=5" icon with his number, but the cheat doesn't happen on any machines but his; so on all other machines the game proceeds as planned. That way, a cheater can do whatever he want on his machine, adjust the game code or scripts as much as he wants, but he can't make other people on the network actually see himself winning only by that; others will still see him loosing, and what he sees will just eventually have nothing in common with what others see,

which is about as effective as if the cheater glues a "You win!" sign to their own monitor.

A desync can also be a result of a game bug as well; it used to happen pretty often when we were testing early 3.1 releases, but now i didn't see much of them. A broken mod can actually lead to a desync, we've seen it in wzmini recently: there was a tank without a weapon connector, so machines couldn't decide which part of the tank was firing.

[carbon dude oxide]

how come thi function wont wrk on skirmish?

setReinforcementTime(600);