Sun position adjustment system

[jj]

At the moment i'm programming a tool that adjust the SMD file of a map.

It works like this:

• it ask you where you live and it needs the exact position of that.

• You have to enter your timezone

• You choose the map you want to play

• It calculates the position of the sun

• an option is to enter the direction of YOU, sitting behind your computer. Then it adjust the sun position in comparison with your direction. So, if you look to the right and see the sun, then the sun will be at the right side ingame.

• It extract the SMD file from the sd7 map file and it makes a backup of it.

• It adjust the Sun position in the SMD file and all the light settings, if it is night the map will become darker

• another idea is to grap the weither info of your location from the internet, then it can adjust the cloud density and light enviroments.

• after the game, when you're back in the lobby it will restore the backup file

I'm looking for some code to get info about the selected map in the lobby.
Then selecting the map is not needed anymore.

This is really a huge project, but i can grap some code from another program i made, a home automation project that already calculates the sun position, sunset and sunrise to automaticly turn lights on or off.

another suggestions, tell me

[Targ Collective]

Sounds good, but Spring doesn't support dynamic lighting - you could see problems with the sun below the horizon.

[jj]

yes, i now that.
The lowest sun pos height i can use is 0.
At night the sun intensity becomes 0.
When the sun height goes down, then the sun intensity goes down.

problem solved!

[AF]

interesting, but it would bugger up the map for network games.

Say your map has been changed for your timezone, everyone else would have todo the same else the Maps Hash would change and the lobby would label everyone as desynced.

Also, what language? Will this be available for Linux users?

[jj]

No, you are wrong.

If you make a new map and play with it then only the first time your comp will do the path calculations.
If you adjust the smd later then its not needed to do the path calcs again.

If you adjust the max metal for example, then you have a real problem.
the game will desync, but the light and sun position dont cause desyncs as far as i now

[AF]

No.

As soon as you change any part of the map itself it's map hash changes.

This means that your map with modified sun settings will no longer play against the standard map.

This has nothign todo with pathfinding calculations, it is a lobby/sync/unitsync thing.


The lobby will ask UnitSync to generate a hash representing the map. This hash is then comapred to all the hashes sent by the other people in the battle. If the hash doesnt match the host then the other player is deemed to have a different version of the file. This is to protect against desyncs from people who release new versions of a map without changing the maps name.

When you change the sun settings this has an effect as it changes the hash that UnitSync will generate for the lobby

[jj]

I will check that, if so, this project is doomed.
But maybe i can inplement it in the next release of TA spring.
It would be nice to add this to the lobby client code

Does someone knows a TA spring (lobby)coder who can help me with this?

[Tobi]

AF, AFAIR, you're wrong. The pathfinding checksum isn't the checksum unitsync and stuff uses, it's a internal checksum based on the map's heightmap and some other stuff (probably typemaps, unit speed factors etc.).

Unfortunately this doesn't make this project less doomed, because spring (and possibly lobby too, not sure if Betalord implemented that) checks map checksums before starting the game (to rule out sync errors due to differences in maps). These checksums _are_ actual CRCs over the zipped file, so not much chance you get around it.

There's one way tho (I don't guarantee it will exist long..): have your tool remove the map archive temporarily and put the map in extracted form in the maps folder. The checksumming functions just return 0 in that case (because there is no archive to calculate a CRC over) so it should be possible to play with differing maps then. Downside is that either no one or everyone in the battle must use your tool.