-
Posts
1.426 -
Joined
-
Last visited
-
Days Won
28
Everything posted by FeXoR
-
THX for the reply. Done: - Guadalquivir River: Removed Iberian civ bonus walls for Small map size. NOTE: I made a mistake in the code though (Fail by one, in the last post, not in the patch ^^)! The right code is: placeCivDefaultEntities(fx, fz, id, BUILDING_ANGlE, (mapSize/64 - 2 < 2) ? {"iberWall" : false} : undefined); - Phoenician Levant: Set max. player caps to [4, 4, 8, 8, 8, 8, 8]. - Pyrenean Sierra: I oversaw something here: If only one player is used he is placed so close to the water. So I choose to: Set the min. player cap to 2 and only add towers on small maps as civ. bonus for Iberians. NOTE: If 2 non-allied Iberian players are next to each other on the same side of the mountains on small maps towers will start shoot each other right from start! But if it is meant as a team map, OK ^^. (Just noticed that mapSize is set to getMapSize()+1 here so used round here) - All the "Unknown" maps: Set min. player caps to 2 and max. player caps to [2, 4, 6, 8, 8, 8, 8]. I agree with this mainly but still I see the problem: How to communicate this to the player? The player should know what civ bonus he gets IMO but can only find out by playing the map so far. Patch/files replaced in http://trac.wildfire...com/ticket/1834 Checking if this can easily be auto-added to the description... Not very readable I fear. Well. No more ideas ATM. I'd say add the patch and look how confused players get Oh, wait! It's not that bad! Adding patch... Done! (The minimum players caps (if present) as well as the maximum player caps by map size are now automatically added to the RMS description in gamesetup.js. Guess that's better than nothing...) Sorry for the string voodoo but I found no other way without looping (normally I try to avoid regular expressions): MAX_PLAYERS_BY_MAP_SIZE_RMS.toString().replace(/,/g, ", ") OK. Done! Please check the ticket and test if everything works as wanted and is self-explanatory enough. THX!
-
Resuming to finish this (was caught by carnival ^^): It would be nice to have a statement of a team member concerning the Iberian civ bonus walls. Well, the shortest I can think of is still quite some text and the description widget is not that big (it's fitting ofc. but needs scrolling in most cases): Tiny: 2 Players, Small: 4 Players, Medium: 6 Players, Normal+: 8 Players Information about the defaults are not needed? Done: - Gulf of Bothnia: Set min. player cap to 2. - Phoenician Levant: Set max. player caps to [4, 4, 8, 8, 8, 8, 8]. - Snowflake Searocks: Set min. player cap to 2. - All the "Unknown" maps: Set max. player caps to [2, 4, 6, 8, 8, 8, 8]. ToDo: - Guadalquivir River: On small maps with Iberians walls are placed for them but sometimes exceed the map border To reproduce: Guadalquivir River, Small, 1 Player (Iberian), Seed 0 To fix: Move the start positions further away from the map border or avoid placing walls for Iberian players on small maps. Replace line 145 with: placeCivDefaultEntities(fx, fz, id, BUILDING_ANGlE, (mapSize/64 - 2 < 1) ? {"iberWall" : false} : undefined); Waiting for a team-member to decide... - In General: Iberian civ bonus if towers should be reduced to 5 instead of 7 mainly because of the population increase. Number of towers and average distance to CC (radius) should be added as keyword arguments to misk.js placeCivDefaultEntities(). Default is 15 for towers, 20 for walls (That's OK). This will be another patch because not that close linked... - Phoenician Levant: On small maps with 6 players Iberian walls nearly touch each other. To fix: Reduce max. player caps to [4, 4, 8, 8, 8, 8, 8] or don't place Iberian walls in small maps. Replace line 180 with: placeCivDefaultEntities(fx, fz, id, BUILDING_ANGlE, (mapSize/64 - 2 < 1) ? {"iberWall" : false} : undefined); Waiting for a team-member to decide (though fixed by max. player caps for the time being)... - Pyrenean Sierra: Players start positions are placed to close to the water. Iberian walls extend beyond the shore sometimes. To reproduce: Pyrenean Sierra, Small, 1 Player (Iberian), Seed 0 To Fix: There is enough space on the map! Please move the starting locations so the walls have enough space to be placed. The RMS designer himself should look into this IMO... - Rhine Marshlands: Sometimes the Iberian Walls extend into water here as well. It's not that bad but I think the the amount of space granted for players bases could be slightly increased. Alternately to use towers instead of walls could work better here. The RMS designer himself should look into this IMO... - All the "Unknown" maps: I refuse to check them! However, I will try to add a function that enables loading from RMS inside other RMS. This will be another patch since not related... Updated ticket: http://trac.wildfire...com/ticket/1834 Waiting for a decision on Iberian civ bonus wall problems on Small map sizes and/or review of the ticket before proceeding with the other issues...
-
THX for picking up my clamoring
-
It's a pleasure! A question remains: If different maps have different number of players caps on different map sizes and it's about the same for the Iberian civ bonus how to make the player understand which map has which caps? Add a comment to the map description? Making him "try and error click" around in the GUI to find out which caps each map has seams hardly appropriate. Even worse with Iberian walls: The game would have to be started with iberians chosen to find out what type of wall the player gets dependent on the map, it's size and eventually on the number of players selected. Any suggestions? EDIT: It might be a good idea to add such things to the "advanced settings" window. Even if the player cannot change it there (though allowing him to change it would be better IMO) the default settings of the map could be shown/seen there. Not sure if that are more like game settings or map settings. Perhaps a new window specifically designed to choose such map settings would be better.
-
Thanks much! Deep Forests uses it's own path system that does not fail so no lower player cap needed here. I'll take a look at the pathPlacer function and the random maps where it is called. It should not fail in any case. I cannot even sleep... darn hangover... Where to find the GUI documentation? I want to hide the player number selection of the lower cap rather than remove them from the dropdown/ComboBox if possible to not worry about someone assuming the n-th entrance would be n players. (To be honest I do this myself in changeMaxPlayers() which ofc. is bad...) Yes, as I feared: if dropdown content index differs from the number of players it selects the number of player slots and the dropdown both have wrong values... Should be a bug in onGameAttributesChange() or updatePlayerList()... BTW: There is another file gamesetup_mp.js but it seams just to add some functions and override onTick() or so. So I assume there's nothing to change. Still network testing would be nice. Trying to change changeMaxPlayers() to not assume anything: This raises an error: Any idea what is wrong here? OK, found it. I shouldn't use push on gui variables it seams... This one works in general but for some reason if 8 players are selected the combobox shows nothing: Its the "if else" part that causes it but I don't get why... Never mind got it working in an other way. Fixed "assume" bug in onGameAttributesChange(). Mainly working but a bit buggy when lower caps on newly selected map is bigger than the actually selected value: http://fexor.dyndns....up/gamesetup.js Searching... Fixed! Whow! The entrances of the combobox are strings though I gave it a list of integers. My dear. Took me an hour to find the reason why I can't use it in Array.indexOf() ... Trying to change the code to assume as little as possible about the content of the number of players combobox... ToDo (when the top is done): - Remove DEBUG notes and code... Done! - Change the RMS json files to match the tests of luziferius... Done! - Generate a patch... Done! - File a ticket... Done! The version with both caps working: http://fexor.dyndns....up/gamesetup.js (like always ^^) Still not working sane if combobox values skip some numbers e.g. [2, 4, 6, 8] but I gave up on this for the time being... In the added functions it's only assumed that combobox data with lower index contain lower values. Changed files, zip and diff: http://fexor.dyndns....ps%20for%20RMS/ Ticket added: http://trac.wildfire...com/ticket/1834 (Just noticed the link to "trac-post-commit-hook" in http://trac.wildfire...SpecialCommands is dead) While testing the maps I found that: - Guadalquivir River: On small maps with Iberians walls are placed for them but sometimes exceed the map border To reproduce: Guadalquivir River, Small, 1 Player (Iberian), Seed 0 To fix: Move the start positions further away from the map border or avoid placing walls for Iberian players on small maps (Replace line 145 with: placeCivDefaultEntities(fx, fz, id, BUILDING_ANGlE, (mapSize/64 - 2 < 1) ? {"iberWall" : false} : undefined); ) - Gulf of Bothnia: Needs at least 2 players. - In General: Iberian civ bonus if towers should be reduced to 5 instead of 7 mainly because of the population increase. Number of towers and average distance to CC (radius) should be added as keyword arguments to misk.js placeCivDefaultEntities(). Default is 15 for towers, 20 for walls (That's OK). - Phoenician Levant: On small maps with 6 players Iberian walls nearly touch each other. To fix: Reduce max. player caps to [4, 4, 8, 8, 8, 8, 8] or don't place Iberian walls in small maps (replace line 180 with: placeCivDefaultEntities(fx, fz, id, BUILDING_ANGlE, (mapSize/64 - 2 < 1) ? {"iberWall" : false} : undefined);) - Pyrenean Sierra: Players start positions are placed to close to the water. Iberian walls extend beyond the shore sometimes. To reproduce: Pyrenean Sierra, Small, 1 Player (Iberian), Seed 0 To Fix: There is enough space on the map! Please move the starting locations so the walls have enough space to be placed. - Rhine Marshlands: Sometimes the Iberian Walls extend into water here as well. It's not that bad but I think the the amount of space granted for players bases could be slightly increased. Alternately to use towers instead of walls could work better here. - The Siege (Not yet added): Results in a quite unexpected fortress for one player but works ^^. - Snowflake Searocks: Min player cap has to be set to 2. - All the "Unknown" maps: I refuse to check them! However, I will try to add a function that enables loading from RMS inside other RMS. - All the "Unknown" maps (2nd): I forgot to add the max. player caps here, sorry. Fixing the list as far as I can (first only those connected to the player cap patch)... (OffTopic: I hat pasting things in post edits makes the field of view jump to the top. Same with refused, not shown or multiple added newlines, tabs and spaces. Please fix that!)
-
those maps need tweaking: they had different flaws with the default, like beeing largely unfair or otherwise broken layout (esp Migration, where all islands are connected with default restrictions) The Unknown scripts should get those, since some of the included variations may not work well with the default Thx! I'll do this. I think on Belgian upland even [2, 4, 6, 8, 8, 8, 8] would be good. If to many players are in there map generation needs long (because with bad player derivation the map is totally rebuild and it happens more often with more players on smaller maps). I drunk to much yesterday... got a headache. I'll finish this tomorrow and file a ticket.
-
I changed it perhaps after you checked. It works for me now. The changed code is marked with "DEBUG" comments to find it. There seams to be a failed by one though in changeMaxPlayers(). EDIT: changeMaxPlayers() seams to be ok, must be somewhere else. Searching... EDIT2: Oh, was ofc the function changeMaxPlayers(). Fixed. Testing welcome. http://fexor.dyndns.org/files/0ad/gamesetup/ Thanks for your help luziferius! Now checking with edited RMS json... Works perfectly AFAIK ^^ Yippie! Added the json for Belgian Uplands to test and set the default to less restrictive values. Put it to: AppData\Local\0ad\cache\mods\public\maps\random
-
I made a stupid mistake: I set the gui dropdown content in onGameAttributesChange() which is stupid. Should be done in selectMapType(), selectMap() and the point where the map size is changed (not sure where. Might still be onGameAttributesChange()...). Added changeMaxPlayers() to take care of the dropdown content.. http://fexor.dyndns.org/files/0ad/gamesetup/ Now i got it right. Just a fail by one somewhere (the selected number of players decrease when changing map size).
-
Removed and fixed ^^ Well it's a work in progress version. Can you see why the selected number of players (in the gui and maybe somewhere else too) is not lowered when the map size is lowered and results in less players possible than selected? To reproduce: - Select map type "Random" - Select map size Giant - Select number of players 8 - Lower the map size The number of players available in number of players dropdown as well as the player-slots will be lowered and the maximum possible number of players selected as expected. - Raise the map size again: Now the number of players is automatically raised so I assume there are still 8 slots filled. Not sure... http://fexor.dyndns.org/files/0ad/gamesetup/gamesetup.js
-
or: (shorter version without a variable) or: the shortest version that uses the specific values 'size' can have this one is fragile, you may use a variable for the calculation and error-check before returning the value function mapSizeToSizeIndex(size) { return (size/64-2); } Good suggestion. Indeed with the last example I don't need any function but just use it as index right away. Actual code now: ToDo: - Drop redundant players from g_GameAttributes.settings.playerData (at select map/size? Or just call selectNumPlayers() if to many players there?)
-
Good idea! (The last one) Analyzing the structure of g_MapData... Getting error: "onTick is not defined". Why ever. Searching... Fixed... Call order without clicking anything: Additionally called when switching map type to random map: So nothing to change for the call order AFAIKS... Final g_MapData (unevaled): Is there a way to avoid log() from being cut? Finalizing making getMaxPlayersRMS() arguments optional (I still need g_GameAttributes.map for the propper g_MapData key and there seams to be no way to avoid this. Same with map size: g_GameAttributes.settings.Size)... Done! This code additions should do (EDITED! The other was buggy. Still returning warnings at GUI initialization but returns correct values in any case): Grrr... again the error: "onTick is not defined". Why ever. Searching (again)... Fixed again! Searching where exactly to replace MAX_PLAYERS with getMaxPlayersRMS()... Oh, guessing always since if it's an scenario the scenario defines the number of players, not MAX_PLAYERS... Not really but I think I got it mainly right... Have to go now. I hope to finish this tomorrow (Likely without the "Random" random map case sanely implemented)... Comments/suggestions/criticism welcome! Seams to work somehow but the dropdown for number of players still contain 8 choices and lowering the map size does not result in lowering the number of player slots... I seam to need to change/update g_GameAttributes.settings.PlayerData as well. But doing this inside the function leads to problems when called from onGameAttributesChange (because it changes the game attribute again and run into an infinite loop)... Ah there's a g_IsInGuiUpdate variable (little blind FeXoR)... How to change the content of the number of players drop down? ...getGUIObjectByName("numPlayersSelection").list and list_data... It seams to be best to use the function for scenarios as well because setting PlayerData it not always mapType dependent(?) Work in progress...
-
Trying to figure out what information to use: g_GameAttributes or g_MapData ? Trying to figure out in which order things are called (or if at all have to be taken into consideration): initMain() -> selectMapType() -> selectMap() -> onGameAttributesChange() -> updatePlayerList() ? What to do if a "random" random map is chosen (default after switching to random maps)? The default maximum number of players for RMS should override the caps for the (later chosen) specific random map in this case??? Or should the caps be defined seperately for this case (more restrictive)? General notes on gamesetup.js: - Indentation in otherwise empty lines is sometimes missing: Fixed... - Many empty lines (I'll leave them though double empty lines inside functions seam excessive to me). - Last settings for this game type (single-player or multi-player) for each mod should be saved and be used the next time this type of game in the specific mod is chosen (Still find the mod design ugly... IMO a civ-build-tree (containing the wanted civilizations) including units, buildings, techs and their dependencies should be determined and loaded for each map. The map could leave it empty so a default civ-build-tree is loaded. The map could also specify if a specific civ-build-tree is needed for this map of if it can be chosen in the game-setup-menu). Actual file:
-
...as long as I don't need to chose a "real" formation after the tech is researched it's OK for me.
-
\binaries\data\mods\public\gui\gamesetup\gamesetup.js seams to be the file in question (function selectMap() line 745). Until now MAX_PLAYERS is a constant. Better to add another variable and do something like min(MAX_PLAYERS, max_players_rms) or change it to a variable entirely (I guess the first is best)? source\ps\scripting\JSInterface_Console.cpp handles autostart options but I'll leave them untouched (for testing player caps are not whanted anyway I guess). Still searching where the RMS.JSON file is loaded to add the "MaximumPlayers" and "MinimumPlayers" settings... EDIT: Should be binaries\data\mods\public\gui\common\functions_utility.js function parseJSONData() line 60. Seams just to load all data so no change needed here. Should be quite simple at first glance.
-
I'm still desperate of a "non formation" formation that just givers the order to every unit separately.
-
Physically Correct vs Simple Game Rules Combat
FeXoR replied to FeXoR's topic in Game Development & Technical Discussion
I noticed that many PPL like formations and I think it could turn out to be a good thing. But at the moment it is pretty much destroying my style of play. I can't order a vast amount of troops even to go to a point on the map without having them stupidly running far into enemy territory not to mention the time lost by the units stupidly tangling around instead of attacking. So I really want something like a "no formation" formation that gives the order to each selected unit individually at least. -
For some reason I can't log into track ATM. The function should take the entity type string e.g. athen_wall_long (The base name of the xml file) and return an associative array including the data. To pick the right mod it would be handy to have the mod path as a variable or constant (not sure here, see below) or another identifier that takes care the right xml from the right path is chosen. AFAIK it is planned to make a map enforce the use of a specific mod. So if the mod identifier should be a constant or a variable depends on when the RMGEN code is loaded (every time a RMS is loaded or only the first time?). Agreed. Where do I find the Gamesetup UI code and the code that loads the RMS JSON files?