wc3campaigns
WC3C Homepage - www.wc3c.netUser Control Panel (Requires Log-In)Engage in discussions with other users and join contests in the WC3C forums!Read one of our many tutorials, ranging in difficulty from beginner to advanced!Show off your artistic talents in the WC3C Gallery!Download quality models, textures, spells (vJASS/JASS), systems, and scripts!Download maps that have passed through our rigorous approval process!

Go Back   Wc3C.net > Warcraft III Modding > Developer's Corner > Triggers & Scripts
User Name
Password
Register Rules Get Hosted! Chat Pastebin FAQ and Rules Members List Calendar



Reply
 
Thread Tools Search this Thread
Old 05-15-2009, 02:57 PM   #1
Opossum
User
 
Opossum's Avatar
 
Join Date: Mar 2008
Posts: 205

Submissions (4)

Opossum will become famous soon enough (59)Opossum will become famous soon enough (59)

Default Player-specific weather

I'm having a weird problem with a recent script that's is supposed to let a player change his local weather.
The problem is though that whenever Player(0) changes his weather, Player(1)'s weather will be removed (or vice verca, probably occurs with multiple players too).
Expand JASS:

Now what I'm wondering about is: How can Player(1)'s weather effect (that is WeatherEffect[1]) be destroyed if Player(0) changes his weather (that is WeatherEffect[0])?
I know about that "One Effect Rule" but I can't see how that applies here as player specific weather effects are created across a null rect and shouldn't interfere with the other players' effects.
Opossum is offline   Reply With Quote
Sponsored Links - Login to hide this ad!
Old 05-15-2009, 03:54 PM   #2
rain9441
User
 
Join Date: Jan 2007
Posts: 195

rain9441 will become famous soon enough (61)rain9441 will become famous soon enough (61)rain9441 will become famous soon enough (61)

Default

Not sure if this relates 100% but it might.

The first weather effect you create will have an identification of 0. The second weather you create will have an identification of 1.

If you call RemoveWeatherEffect() on an array of weathereffects whos index has never been set, you will be removing the first weather effect you've ever added to the map.

EG, RemoveWeatherEffect(null) does infact remove a weather effect, and that weather effect is weather effect #0.

Are you following me?

Your culprit lies here:
Collapse JASS:
set Weather[p] = CappedInt(Weather[p]+i, 0, MAX_WEATHER-1) //makes sure the returned value is between 0 and MAX_WEATHER-1
    call RemoveWeatherEffect(WeatherEffect[p])

It's just a weathereffect gotcha
__________________
My latest project -- Still in development: Experience TD
rain9441 is offline   Reply With Quote
Old 05-15-2009, 03:56 PM   #3
Opossum
User
 
Opossum's Avatar
 
Join Date: Mar 2008
Posts: 205

Submissions (4)

Opossum will become famous soon enough (59)Opossum will become famous soon enough (59)

Default

Hmm didn't know that. So basically I have to check if that weather effect equals null before removing it?
Gonna try that. +rep if it works :)
Opossum is offline   Reply With Quote
Old 05-15-2009, 04:00 PM   #4
rain9441
User
 
Join Date: Jan 2007
Posts: 195

rain9441 will become famous soon enough (61)rain9441 will become famous soon enough (61)rain9441 will become famous soon enough (61)

Default

Quote:
Originally Posted by Opossum
Hmm didn't know that. So basically I have to check if that weather effect equals null before removing it?

Nope, a null weather effect actually probably is a weather effect. There is no valid test to find whether a weathereffect is "null" or even exists in the game, you have to make those validity tests yourself.

null is going to be an actual weathereffect almost every time.

I think what I did was create one single weather effect in a corner of the map that didn't do anything, left that at index 0, and made all my bounds checks start at 1. Thus you never remove weathereffect 0, nor do you see it.
__________________
My latest project -- Still in development: Experience TD
rain9441 is offline   Reply With Quote
Old 05-15-2009, 04:13 PM   #5
Opossum
User
 
Opossum's Avatar
 
Join Date: Mar 2008
Posts: 205

Submissions (4)

Opossum will become famous soon enough (59)Opossum will become famous soon enough (59)

Default

I just tried the null check before you posted and it pretty much proves your point.
The weather effects of different players didn't interfere anymore but I could never remove the first created weather effect as that one probably is null.
So I guess that null check will be ok if the first created weather effect is one that will never be seen by the players like you said or will other effects than the very first return null too? If yes then... wow that's pretty much screwed up.
Opossum is offline   Reply With Quote
Old 05-15-2009, 04:22 PM   #6
rain9441
User
 
Join Date: Jan 2007
Posts: 195

rain9441 will become famous soon enough (61)rain9441 will become famous soon enough (61)rain9441 will become famous soon enough (61)

Default

It isn't quite screwed up, you just have to think about it in a different way. weathereffects are actually integers, not handles.

The best way is probably to do something like this.

Have an array of weathereffects like you do

Collapse JASS:
  if (WeatherEffectIsValid[index] == true) then
    call DestroyWeatherEffect(WeatherEffect[index])
    set WeatherEffectIsValid[index] = false
  endif

  set WeatherEffect[index] = AddWeatherEffect(...)
  set WeatherEffectIsValid[index] = true

That would part of an approach of creating your own validity check. Then you don't have to deal with the (0|null) weather effect being destroyed accidently because you only ever destroy weather effects you know you've created.

Cheers!
__________________
My latest project -- Still in development: Experience TD
rain9441 is offline   Reply With Quote
Old 05-15-2009, 05:10 PM   #7
Opossum
User
 
Opossum's Avatar
 
Join Date: Mar 2008
Posts: 205

Submissions (4)

Opossum will become famous soon enough (59)Opossum will become famous soon enough (59)

Default

Well actually if a handle exists but returns null that feels pretty screwed up to me.

Anyway... that valid method won't quite work for me. I'm creating weather effects for all players but they are null for all players that are not supposed to see that effect because these effects are added to a null region.
Expand JASS:
I just tested that and it turned out that once again players remove each other's weather effects. I guess because all players except for the player who actually sees the weather effect have a null weather effect. So when removing that effect the effect #0 will be removed again. It's just pretty weird that this doesn't cause a desync though.
Opossum is offline   Reply With Quote
Old 05-15-2009, 05:42 PM   #8
rain9441
User
 
Join Date: Jan 2007
Posts: 195

rain9441 will become famous soon enough (61)rain9441 will become famous soon enough (61)rain9441 will become famous soon enough (61)

Default

I'm fairly certain weather effects are async. They have no impact on gameplay what so ever as long as you don't use them in your scripts as a test. Can you create weather effects for all players and only Enable the weather effect for a certain LocalPlayer? It seems right now that the way you are doing it you are only creating weather effects for one player, so all players will have a different weather effect at index #0.
__________________
My latest project -- Still in development: Experience TD
rain9441 is offline   Reply With Quote
Old 05-15-2009, 05:52 PM   #9
Opossum
User
 
Opossum's Avatar
 
Join Date: Mar 2008
Posts: 205

Submissions (4)

Opossum will become famous soon enough (59)Opossum will become famous soon enough (59)

Default

Creating weather effects and thus creating handles locally is causing desyncs.
Quote:
Can you create weather effects for all players and only Enable the weather effect for a certain LocalPlayer?
It works kinda and I wish I could use that but two players couldn't have the same type of effect (rain, fog, shield) at a time.
Currently I'm actually creating the effect for all players but only in a valid rect for the local player. And it seems weather effects that are created on a null rect are actually null themselves which complicates the whole issue pretty much.
I guess I'll have to include the validity variable into the local code as it seems that removing effects locally doesn't desync.
Edit: Ok removing effects locally DOES desync.

Last edited by Opossum : 05-15-2009 at 06:00 PM.
Opossum is offline   Reply With Quote
Old 05-15-2009, 06:15 PM   #10
rain9441
User
 
Join Date: Jan 2007
Posts: 195

rain9441 will become famous soon enough (61)rain9441 will become famous soon enough (61)rain9441 will become famous soon enough (61)

Default

What if you were to create one rain effect for all players and only enable it for the players who should see rain? Same for snow, etc.

It sounds to me like making the call to AddWeatherEffect with a null rect is equivalent to not making the call at all, so you may want to veer away from that solution entirely.
__________________
My latest project -- Still in development: Experience TD
rain9441 is offline   Reply With Quote
Old 05-15-2009, 06:27 PM   #11
Opossum
User
 
Opossum's Avatar
 
Join Date: Mar 2008
Posts: 205

Submissions (4)

Opossum will become famous soon enough (59)Opossum will become famous soon enough (59)

Default

Then I could only make one out of four rain effects etc. available to the players.
AddWeatherEffect with a null rect is not the same as not making the call at all because the creation of this handle is executed for all players and thus not causing a desync.

What I'm working on is a script called "AtmoUtils". It's a keyboard-controlled multiboard that can be activated for any player(s). You can change sky model, weather, fog settings and water color in real-time. Basically it's a testing tool to get the best out of one's terrain without having to save the map hundres of time to see how the settings work out ingame.
If I really can't get this to work then I guess I'll just let all players share the same weather.

What's weird is that besides having a strange nulling behavior is that the first ever created weather effect will be removed if the removed weather effect is null for ANY player without even causing a desync.
I mean this could be a great way to sync some values maybe but it's not useful here at all.

Last edited by Opossum : 05-15-2009 at 06:30 PM.
Opossum is offline   Reply With Quote
Old 05-16-2009, 07:54 AM   #12
Viikuna-
User
 
Viikuna-'s Avatar
 
Join Date: Feb 2009
Posts: 203

Viikuna- will become famous soon enough (44)Viikuna- will become famous soon enough (44)

Default

Why dont you just create weather effect for everyone normally, and then use GetLocalPlayer to diable/enable it?

If you need same effect for more than 1 guy, you could always create some force for and add those players who can see effect to it and do IsPlayerInForce(GetLocalPlayer(),force) or something.
__________________
No Marlo, no game.
Viikuna- is offline   Reply With Quote
Old 05-16-2009, 12:39 PM   #13
Opossum
User
 
Opossum's Avatar
 
Join Date: Mar 2008
Posts: 205

Submissions (4)

Opossum will become famous soon enough (59)Opossum will become famous soon enough (59)

Default

Because like I already said that "One Effect Rule" doesn't allow this kind of method.
You can only have one rain/shield/fog/ray/wind/snow effect per 512x512. So when the weather effect "ashenvale rain (heavy)" is created, you won't be able to create a different rain effect on the same region. That includes "ashenvale rain (light)", "lordaeron rain (heavy)" etc...
Opossum is offline   Reply With Quote
Old 05-16-2009, 02:45 PM   #14
rain9441
User
 
Join Date: Jan 2007
Posts: 195

rain9441 will become famous soon enough (61)rain9441 will become famous soon enough (61)rain9441 will become famous soon enough (61)

Default

I know this is possible to do, as DOTA does it. If DOTA does it, you can do it. There must be a way!

I'm thinking the only thing kickin' your ass right now is the fact that a null rect passed to add weather returns "null" which you don't know is null, and after everyone decides to add a weather effect, everyone has a null weather effect which isn't really null.

Have you checked the dota source maybe to see what they do? Its obfuscated but you can still probably make out whats going on around the AddWeather call(s)
__________________
My latest project -- Still in development: Experience TD
rain9441 is offline   Reply With Quote
Old 05-16-2009, 02:59 PM   #15
Opossum
User
 
Opossum's Avatar
 
Join Date: Mar 2008
Posts: 205

Submissions (4)

Opossum will become famous soon enough (59)Opossum will become famous soon enough (59)

Default

Does DotA make ALL weather effects available to all players or just one per type?

Also yeah that null rect really fucks it up. I'd need some sort of null weather effect id but effectID == 0 causes a crit error (nice to keep in mind if you need a crit error in the future though).
Opossum is offline   Reply With Quote
Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off


All times are GMT. The time now is 09:57 PM.


Affiliates
The Hubb The JASS Vault Clan WEnW Campaign Creations Clan CBS GamesModding Flixreel Videos

Powered by vBulletin (Copyright ©2000 - 2019, Jelsoft Enterprises Ltd).
Hosted by www.OICcam.com
IT Support and Services provided by Executive IT Services