Any additions to "Host Battle" dialog
Moderator: Moderators
Any additions to "Host Battle" dialog
Submit them here.
We could always change it later, but its a lot easier to do as much as we can now. The code generated needs to be inserted into the actual program before it becomes useful, and that does require a bit of work.
UPDATE:
Old host dialog
The question is: What else do you want it to have on it? (features wise)
NOTE: In windows, the color scheme will be your normal grey. The black color scheme is just my computer's.
We could always change it later, but its a lot easier to do as much as we can now. The code generated needs to be inserted into the actual program before it becomes useful, and that does require a bit of work.
UPDATE:
Old host dialog
The question is: What else do you want it to have on it? (features wise)
NOTE: In windows, the color scheme will be your normal grey. The black color scheme is just my computer's.
Last edited by Ace07 on 10 May 2005, 01:45, edited 1 time in total.
Something that let you change the map default params for metal/tidal/wind. I really want to play Core Prime with lower mine range and higher metal value (to compensate the lower mine radius).
I'm planing to distribute the smd file to every willing players, but this is a pain in the ass to have 2 diff versions of the same map.
So those littles options should not be hard to implement, and would greatly improve gameplay (you can have different gameplay with the same map layout).
I'm planing to distribute the smd file to every willing players, but this is a pain in the ass to have 2 diff versions of the same map.
So those littles options should not be hard to implement, and would greatly improve gameplay (you can have different gameplay with the same map layout).
We were talking about this in the general forum, and we figured that this wouldn't need it. Private game means that it doesn't show up on the server list, so your friends just have to know the name of the game itself.coryrc wrote:password field
We also want to impliment private messenging at some point.
I fixed the typo...heh....
@jensgb: That wouldn't be too hard to do, but we will work on that later. That has more to do with coding than with layout. I will add a field to indicate map size.
@NOiZE: I will add max units on there. Metal and energy can be in the room where people join before they play (it would be nice to be able to change as much as possible from that point).
@SinbadEV: I will add another button for that I guess. And, someone would need to get me the list for every single unit. (I won't include pictures, it will be text at first)
@Cheery: I am using wxGlade, which is similar to GTKGlade. wxGlade generates wxWidgets code however. Look here for more info.
@Kickban: I like the idea, but it will be harder to impliment for one reason: the data is inside the map file. There are no arguments that you can add to spring.exe to change this data as of late.
Wouldn't it be wise to wait with this feature till a mod selection-system is in place (including the posittion of modfiles), and let the "Host battle" dialog obtain the unit names automatically from the folder of the currently selected mod?@SinbadEV: I will add another button for that I guess. And, someone would need to get me the list for every single unit. (I won't include pictures, it will be text at first)
@Ace07 : When you choose a map in lobby, make the client read the .smd file, and set the lobby display according to this (it is already done in current client). If the host change those values, when the game start, it make a copy of smd file somewhere (in map folder for example under the name MyMap.smd.save), modify the smd file, and than launch the game. This should be done on all clients as well.
So all the client and server launch a modified smd file (the file being dicted by set values in lobby when the game is launch).
Wait some seconds, than the lobby (still at background) restore the original smd file (you only need to know how long it take for the game to parse the smd file).
Another thing is that the client should only show the values given by host. So if a client have modified .smd file, the host one will take priority.
This can also be used to prevent an exploit where i change my smd to raise the metal value. (didn't tried it yet, should provoke desync in game i think, will try it later today).
Another way to do this is to put new flags in the smd. Flags called BaseValues. When you launch the lobby, it read the base value. When you launch the game, it set the RealValues (current used flags) to the lobby value. So you don't have to make a copy of smd, because the default values in lobby will be the BaseValues set by map creator. If you launch without changing it, you get what the creator thought about. If you change them, you change the real values, you do a game with modified values, but next time you start a game, it read the BaseValue again, and so, you will always have the BaseValue as default, RealValues are only valid for curent game.
So let me resume :
-You host
-Lobby read BaseValues flags in map smd.
-You can modify or not the values
-You click launch, the lobby modify every smd files (host and clients) to match the lobby values (it change the current used flags, not the new Basevalue flags).
-The game start. Every host and clients have the same smd (prevent exploit).
-When you host again, it take the BaseValues, and so, the previous game have no incidence on the new one.
If you want me to be more precise, just tell :D
So all the client and server launch a modified smd file (the file being dicted by set values in lobby when the game is launch).
Wait some seconds, than the lobby (still at background) restore the original smd file (you only need to know how long it take for the game to parse the smd file).
Another thing is that the client should only show the values given by host. So if a client have modified .smd file, the host one will take priority.
This can also be used to prevent an exploit where i change my smd to raise the metal value. (didn't tried it yet, should provoke desync in game i think, will try it later today).
Another way to do this is to put new flags in the smd. Flags called BaseValues. When you launch the lobby, it read the base value. When you launch the game, it set the RealValues (current used flags) to the lobby value. So you don't have to make a copy of smd, because the default values in lobby will be the BaseValues set by map creator. If you launch without changing it, you get what the creator thought about. If you change them, you change the real values, you do a game with modified values, but next time you start a game, it read the BaseValue again, and so, you will always have the BaseValue as default, RealValues are only valid for curent game.
So let me resume :
-You host
-Lobby read BaseValues flags in map smd.
-You can modify or not the values
-You click launch, the lobby modify every smd files (host and clients) to match the lobby values (it change the current used flags, not the new Basevalue flags).
-The game start. Every host and clients have the same smd (prevent exploit).
-When you host again, it take the BaseValues, and so, the previous game have no incidence on the new one.
If you want me to be more precise, just tell :D
-
- Posts: 436
- Joined: 26 Aug 2004, 08:11
My previous post was not so clear, so i will repost it here, and add examples on how to do an override on map datas.
First of all, i just tested, and you can add custom tags in smd. They are just ignored by the engine.
So, to beging, what a 'normal' smd looks like ?
So now, the trick is to make the engine looks at our values for MaxMetal for exemple, but without losing the original values.
This can be achived by creating new flags, so the file looks like this.
Default values are defined by the map creator (or the client, as we will see later), and are NEVER modified. The client modify only the 'normal' values (MaxMetal for exemple).
So, when you host a game, let's see what would happen :
1. You host or you join a game
2. Client look at the smd file. If it find the Default flags, go to 4. else go to 3.
3. The client create the Default flags and copy the 'normal' values to the Default flags
4. The client read the smd file, and show the Default values.
5. You can modify thoses values
6. You start the game, all the clients modify the smd so the 'normal' flags match the lobby values.
7. When you rehost, the default values are taken, and so the previous game don't hurt all other games.
(Point 3 is for compatibility, so all the old TAS maps don't need to be modified).
This kind of modifications are invisible for the engine, and for the player. Only the lobby know something happened.
First of all, i just tested, and you can add custom tags in smd. They are just ignored by the engine.
So, to beging, what a 'normal' smd looks like ?
Code: Select all
[MAP]
{
Description=Battle on the red planet;
TidalStrength=20;
Gravity=130;
MaxMetal=2.6;
ExtractorRadius=30;
...
}
This can be achived by creating new flags, so the file looks like this.
Code: Select all
[MAP]
{
Description=Battle on the red planet;
TidalStrength=20;
Gravity=130;
MaxMetal=2.6;
ExtractorRadius=30;
DefaultTidalStrength=20;
DefaultGravity=130;
DefaultMaxMetal=2.6;
DefaultExtractorRadius=30;
...
}
So, when you host a game, let's see what would happen :
1. You host or you join a game
2. Client look at the smd file. If it find the Default flags, go to 4. else go to 3.
3. The client create the Default flags and copy the 'normal' values to the Default flags
4. The client read the smd file, and show the Default values.
5. You can modify thoses values
6. You start the game, all the clients modify the smd so the 'normal' flags match the lobby values.
7. When you rehost, the default values are taken, and so the previous game don't hurt all other games.
(Point 3 is for compatibility, so all the old TAS maps don't need to be modified).
This kind of modifications are invisible for the engine, and for the player. Only the lobby know something happened.
I agree with joun on this one. I think that having it in the "script.txt" file that is sent to the exe as a way to load the game would work better. In fact, it would probably be easier to do that. The map defaults can be inside the map, and script.txt can override them.
Also, changing the mod should change the available maps you can play it on.
Client modification of the map file would need to be checked in the client somewhere. We could probably add that to unitsync.dll. Mod management and checking would probably go under unitsync.dll also.
Also, changing the mod should change the available maps you can play it on.
Client modification of the map file would need to be checked in the client somewhere. We could probably add that to unitsync.dll. Mod management and checking would probably go under unitsync.dll also.
You write the code to do that and I will include it. I also plan on adding the option to push maps to people if they don't have the chosen one.Kickban wrote:1. You host or you join a game
2. Client look at the smd file. If it find the Default flags, go to 4. else go to 3.
3. The client create the Default flags and copy the 'normal' values to the Default flags
4. The client read the smd file, and show the Default values.
5. You can modify thoses values
6. You start the game, all the clients modify the smd so the 'normal' flags match the lobby values.
7. When you rehost, the default values are taken, and so the previous game don't hurt all other games.