New Dynamic Script Ideas

[Ben]

That's what I meant: Just specify in the Readme to not place the in-game audio in the Remake sound folder-- or am I missing something?

[Lewin]

Krom and I have discussed it and decided we will support playing sounds with dynamic scripts. It will be implemented for RC3.
Planned features:
- WAVs only (simpler/faster to play with OpenAL)
- Sounds can optionally be positioned on the map
- Looping option (for e.g. waterfall ambient sound)

Maybe that gives people some ideas for their competition entries
Obviously you can't use a sound effect that you don't own without permission if you want your mission to be accepted into the competition or official Remake map list.

[Siegfried]

That's a nice addition. Imagine a map where you're sitting oceanside, watching the sunset, playing the wave crushing sound while your units are slaughtered just some tiles away

Seriously, there are some database with free sounds online, you can take one there. Most of them are CC licenced, so you can use them.
Well, a nice side effect would be if you use a the CC with non-commercial attribute. Then ZuXXeZ could get into trouble when they sell the remake again with this map included

[sado1]

I need a way to know the formation units are currently in. It's not a big deal, I just made a simple fog of war script, but it's not ideal and I'd like to improve it. The ways I currently can make the algorithm:
-now it uncovers fog for each troop - slower, but most consistent with the game, which is obviously uncovering fog for every troop
-I'd like to optimize it and just work with the groups - but the only thing I can do now is to know the position of the main troop in a group (flag-bearer)

If I was able to know the formation (well, the horizontal and vertical length of the rectangle's sides would be the best... I don't care about the amount of troops in last column, and it can be counted easily knowing the number of troops anyway), I could take the position of group leader, then make a FogUncoverCircle range based on half of the width.

It's not THAT important though, maybe the dumb way which checks each troop will work fast enough... need to try on Ambushed with 6 players, and then we'll know xD

[Krom]

@sado1: Knowing group formation would not help because there's a big difference between desired formation (6 columns, 3 rows) and factual state (group walks through a passage and stretched like a caterpillar).

What exact effect are you trying to achieve?

[sado1]

You're unfortunately right... I tried to implement fog of war in a way more efficient than that: (warning: pseudo Pascalscript)

  Code:

procedure onTick Units := States.PlayerGetAllUnits(Player); if Gametime mod 10 then Actions.FogCoverAll; for I := 0 to Length(Units)-1 do Actions.FogRevealAll(Units[i], radius);

The code works (obviously it has a few more lines than above), but I thought that checking each troop is quite stupid, so I tried to use groups, but now I see it wouldn't work. I guess there's nothing better that I can invent now. (Of course buildings would be handled in a similar but a bit simplified way)

[Lewin]

You could make your code more efficient by moving PlayerGetAllUnits inside the "if Gametime mod 10 = 0 then" condition (since it takes time to generate the list). But I think it should work okay like that because you're only updating it once per second. It depends on how many units there are in the game.

[Ben]

We've been testing it in several games. When Sado and I played Coastal encounter, the game lagged terribly but we suspect that it was due to sado's server lag (our FPS was fine).
We tried again with 5 players on ambushed, but Bence's computer was lagging like terrible (the others were fine; even mine!!). We tried to test it again, but it is hard because there are no dedicated servers for the r5562 or whatever it is called, and sado can't get his computer to get a working server half the time.

[Lewin]

Everyone is compiling from source now I see? That's the good thing about open source projects. Just be careful because it might sometimes be unstable and we tend to leave debugging/cheats enabled between releases. Also we don't regularly update the version number so it's easy to have two people with different versions which can cause crashes in multiplayer.

The pseudo code sado pasted here could possibly cause the game to lag. If you paste the actual code I can help you optimise it, you can spread the load between ticks so only 1 player gets updated every tick (I guess you're updating all players every 10 ticks?) That should make it more efficient.

[sado1]

Everyone is compiling from source now I see? That's the good thing about open source projects. Just be careful because it might sometimes be unstable and we tend to leave debugging/cheats enabled between releases. Also we don't regularly update the version number so it's easy to have two people with different versions which can cause crashes in multiplayer..

It's just me so far, but I don't mind sharing the .exe to someone Well, if I didn't do that, making/testing a script would be impossible without all the new commands, so I had to do that.

The pseudo code sado pasted here could possibly cause the game to lag. If you paste the actual code I can help you optimise it, you can spread the load between ticks so only 1 player gets updated every tick (I guess you're updating all players every 10 ticks?) That should make it more efficient.

No, the actual code was alright (everything was inside the time loop), I just made a mistake writing it off my memory. But there's another problem. You also need to deal with teams while you want the script to work in team-based games. I added VERY dumb teams support but it lags the crap out of the game. I guess I'd need to make a procedure for detecting teams and execute it OnMissionStart, but I didn't have enough patience yesterday to do that Also, nice suggestion about spreading the load between ticks ("if ( (States.GameTime mod 10) + P ) then"?).

  Code:

procedure RevealFog(Units: array of Integer; P: Integer); var I, X, Y: Integer; begin for I := 0 to (Length(Units)-1) do begin X := States.UnitPositionX(Units[I]); Y := States.UnitPositionY(Units[I]); Actions.FogRevealCircle(P, X, Y, 9); end; end; procedure OnMissionStart; var P: Integer; begin for P := 0 to 5 do Actions.FogCoverAll(P); end; procedure OnTick; var P, R: Integer; var Units, Units2: array of Integer; begin if (States.GameTime mod 10 = 0) then for P := 0 to 5 do begin Actions.FogCoverAll(P); Units := States.PlayerGetAllUnits(P); RevealFog(Units, P); for R := 0 to 5 do begin if States.PlayerAllianceCheck(P,R) then Units2 := States.PlayerGetAllUnits(R); RevealFog(Units2, P); end; end; end; procedure OnPlayerDefeated(P: Integer); var I: Integer; begin Actions.FogRevealAll(P); end;

[Lewin]

Check the latest log file for errors, sometimes lag is caused by logging a large number of errors from the script.

You're missing a "begin..end" after this line "if States.PlayerAllianceCheck(P,R) then". That will cause it to run "RevealFog(Units2, P);" even when Units2 hasn't been created.

Yes, you can spread the load like this:
if ((States.GameTime + P) mod 10 = 0) then

You'll also need to not run the main loop for players who have been defeated, otherwise the "FogRevealAll" will be overridden.

[The Dark Lord]

I think I've asked this before but the answer was negative back then: is it yet possible to have two allies not share their vision?

[H.A.H.]

TDL: it is quite easy to code that change. However, the problem at the moment, is that there is not yet a good way on to let users select these game modes/modifiers/etc. Also, there remains the question: which modes are good enough to be included? An extreme example would be, in case every suggested game mode gets added, that users would have a screen full of checkboxes for options to choose from (hey, I know that from Civilizations!), which is not what the avarage player needs.

Instead, imagine only a few game modes, and some of them have "sharing allied vision", while others do not. Now the player won't have to choose this option alone, as it is decided for each game mode if it makes sense or not. Consider, for example, the game mode where it is possible to change alliences mid-game. In such mode, non-shared vision makes very much sense.

However, as Game Scripts are now possible, it think it should be possible that certain configurations (the "many checkbox" problem) are not presented to the user, but are available to scripters, and to let them choose the modifiers, and to create sensible choices. Any advanced player always has the option to create and add his/her own game mode, so nobody is left out.

[Lewin]

I think I've asked this before but the answer was negative back then: is it yet possible to have two allies not share their vision?

It's on the todo list. My original plan was to have a .dat script command that lets you enable/disable it for each player (!DISABLE_FOW_SHARING 1 to disable current player from seeing player 1's revealed areas). But there could be a problem because if player 1 has already placed stuff like houses and map revealers then it will have revealed for all his allies too... I'm sure we can figure out a way around that though (putting it at the top of the file would be one solution)

@H.A.H.: As far as I know TDL wants this as a script option for special missions/campaigns (e.g. where an allied AI comes and rescues you and you shouldn't see them approaching). I doubt anyone wants this for regular situations/multiplayer.

[The Dark Lord]

What about something like Actions.ShareVision(Player1, Player2, True/False)? That would be much more flexible and would allow to change vision during the game (as I had planned ). Static script is... static. It could work but won't be as nice (and useful).