Leaderboard

Right, so I'm trying to expose how far the scrollbar's scrolled down, so that when it nears the edge, I query the server for more replays. This is part of my project to make a Replay Database for 0ad. Alas, I'm getting this evil error: WARNING: IGUIObject: setting scrollbar_percentage was not found on an object ERROR: JavaScript error: gui/rdb/replay_menu.js line 203 Error: Invalid GUIObject property 'scrollbar_percentage' onTick@gui/rdb/replay_menu.js:203:1 __eventhandler125 (tick)@__internal(0) tick:0:1 Now, for sake of ease for the reader, I've boiled down my 6k line diff file to these 3 short excerpts, the first a diff file, the second an example of the html used and the final is an example of the js: Index: binaries/data/mods/mod/gui/gui.rnc =================================================================== --- binaries/data/mods/mod/gui/gui.rnc (revision 21928) +++ binaries/data/mods/mod/gui/gui.rnc (working copy) @@ -74,6 +74,7 @@ attribute offset { pos }?& attribute readonly { bool }?& attribute scrollbar { bool }?& + attribute scrollbar_percentage { xsd:decimal }?& attribute scrollbar_style { text }?& attribute scroll_bottom { bool }?& attribute scroll_top { bool }?& Index: binaries/data/mods/mod/gui/gui.rng =================================================================== --- binaries/data/mods/mod/gui/gui.rng (revision 21928) +++ binaries/data/mods/mod/gui/gui.rng (working copy) @@ -315,6 +315,11 @@ </attribute> </optional> <optional> + <attribute name="scrollbar_percentage"> + <data type="decimal"/> + </attribute> + </optional> + <optional> <attribute name="scrollbar_style"/> </optional> <optional> Index: source/gui/COList.cpp =================================================================== --- source/gui/COList.cpp (revision 21928) +++ source/gui/COList.cpp (working copy) @@ -33,6 +33,9 @@ AddSetting(GUIST_CGUISpriteInstance, "sprite_asc"); // Show the order of sorting AddSetting(GUIST_CGUISpriteInstance, "sprite_desc"); AddSetting(GUIST_CGUISpriteInstance, "sprite_not_sorted"); + AddSetting(GUIST_float, "scrollbar_percentage"); + + GUI<float>::SetSetting(this, "scrollbar_percentage", 0.0); } void COList::SetupText() @@ -119,6 +122,14 @@ GetScrollBar(0).SetY(rect.top); GetScrollBar(0).SetZ(GetBufferedZ()); GetScrollBar(0).SetLength(rect.bottom - rect.top); + + GUI<float>::SetSetting( + this, + "scrollbar_percentage", + GetScrollBar(0).GetMaxPos() == 0 + ? 1 + : GetScrollBar(0).GetPos() / GetScrollBar(0).GetMaxPos() + ); } } <object name="replaySelection" size="0 35 100% 100%-24" type="olist" style="ModernSortedList" sortable="true" selected_column="months" selected_column_order="-1" font="sans-stroke-13" auto_scroll="true" scrollbar="true" > <action on="SelectionChange">displayReplayDetails();</action> <action on="SelectionColumnChange">displayReplayList();</action> <action on="mouseleftdoubleclickitem">startReplay();</action> <!-- Columns --> <column id="id" color="172 172 212" width="10%"> <translatableAttribute id="heading" context="replay">Save Id</translatableAttribute> </column> <column id="months" color="172 172 212" width="11%"> <translatableAttribute id="heading" context="replay">Date / Time</translatableAttribute> </column> <column id="players" color="192 192 192" width="40%"> <translatableAttribute id="heading" context="replay">Players</translatableAttribute> </column> <column id="mapName" color="192 192 192" width="12%"> <translatableAttribute id="heading" context="replay">Map Name</translatableAttribute> </column> <column id="mapSize" color="192 192 192" width="9%"> <translatableAttribute id="heading" context="replay">Size</translatableAttribute> </column> <column id="popCapacity" color="192 192 192" width="9%"> <translatableAttribute id="heading" context="replay">Population</translatableAttribute> </column> <column id="duration" color="192 192 192" width="9%"> <translatableAttribute id="heading" context="replay">Duration</translatableAttribute> </column> </object> if (!g_WaitingForQueryResponce) { var replaySelection = Engine.GetGUIObjectByName("replaySelection"); if (replaySelection.scrollbar_percentage > 0.9) { RdbQueryForReplayList(); warn("Requery"); } } I've attached the full diff file bellow for those it interests. 0ad-diff

Yes, op players (@borg-, @Feldfeldand @ValihrAnt) should be involved in balancing, right now long range siege is too op

Hello again everyone! Link to the last thread : This is a follow-up to the last thread I made; Our project supervisor wanted me and my partner to consolidate all the information from the beginning, so I will go again and explain our problems regarding the project we are developing. Our main idea is to develop machine-learning capabilities within the AI in the game. To do so, we are planning to use a work environment (probably TensorFlow) that works with python. Therefore, we need to find a way to connect our ML code that will be written in python with the AI files that are written in JavaScript. So far, we have been offered to use interfaces that are already found in the game code in C++, write the data that we need to a file that we can use ML on, and calling the JavaScript functions using python server in a way that could make us access the valuable API. We have also been offered TensorFlow.js, but unfortunately it turns out that the mathematical libraries essential to ML are not included with it. At the end, we have chosen the third option, and started working on a server that will fulfill our objectives in creating the link. However¸ we have ran into some problems regarding the JavaScript connection. We tried to use jQuery to create requests with the server, but spiderMonkey does not come with it. At the end of the day, we really want to use the server as a connection between JS and Python, and we would like to ask for any way for us to do so. Even so, if there are any other good ways that exist and can work with the game, we would be happy to hear. Thank you to all for your help and patience with us so far! It is really not that obvious. EDIT: Some more insight on what we have done so far: We want to extend the existing AI code, written in javascript, with machine learning code written in Python. To do so, we need to invoke our Python code from within the javascript code. We have been offered to make this connection via http (i.e. AJAX), but the game's spidermonkey engine doesn't seem to support AJAX.

I do not know if anyone has already had this idea, but I would like to share it with the community. My native language is not English and I did not find forums for specific languages (although I believe there are a large number of Portuguese speaking players) My idea is basically the creation of a world with all civilizations living and battling for territories. In this world the player can join some civilization. The goal is for battles to be rare and their results affect the entire world geopolitics (a scriptwriter will be required for those tasks). Battles need to be scheduled for participants, leaders or parliaments of each player-controlled society can make decisions outside the game and will also affect the geopolitics of the world. There are many other points that can be said here, but the ultimate goal is that there is a dynamism in the battles, an idea of continuity and a greater immersion in each game.

These People Are Not Real—They Were Created By AI https://motherboard.vice.com/en_us/article/mby4q8/these-people-were-created-by-nvidia-ai https://medium.com/syncedreview/gan-2-0-nvidias-hyperrealistic-face-generator-e3439d33ebaf The truth is… wait for for it… both images are AI-generated fakes, products of American GPU producer NVIDIA’s new work with generative adversarial networks (GANs). The research was published today in the paper A Style-Based Generator Architecture for Generative Adversarial Networks, which proposes a new generator architecture that has achieved state-of-the-art performance in face generation. Since GANs were introduced in 2014 by Google Researcher Ian Goodfellow, the tech has been widely adopted in image generation and transfer. After some early wiry failures, GANs have made huge breakthroughs and can now produce highly convincing fake images of animals, landscapes, human faces, etc. Researchers know what GANs can do, however a lack of transparency in their inner workings means GAN improvement is still achieved mainly through trial-and-error. This allows only limited control over the synthesized images.

I was wondering whether it would be feasible/practical to implement a way to target a group of units instead of only one? For example if you have some archers, you might want to tell them to hit the skirmishers instead of the melee soldiers in front of them. It could be also useful to counter players making their hero dance. The units doing the actions would only ignore other units until the one which were targeted are all dead...

I wish we had grass like that tho.

also for term of use , term of service and policy please make it in 1 shot for the user instead of 3 separate screens and accept

The revision is indeed correct (21935), it's the date that is funky: 21935 was 30th of November. Apparently, (ps/scripting/JSInterface_Debug.cpp:64) // To be exact, the date/time returned is when scriptglue.cpp was last compiled, but the auto-build does full rebuilds. but that hasn't been the case for a very long time. JSInterface_Debug.cpp (yes that is the current name of the file ) is touched regularly, hence why we didn't notice before. Thanks for noticing

Difficult to say if more armor would be sufficient. It would create an incentive to have more of course, but ranged units would still be more effective at making damage. I think that a metal cost would make archers even less attractive. Metal is always a scarce ressource, it is needed for all upgrades and on some map, it might be a problem to be relying so much on it. Ptolemies have this issue too, but they also have the option of relying on stones too for sieges and slingers when metal run out. Archers would still need something more to become more attractive.

thanks to elexis for guiding a novice pc man. seems like game is good. Except the same ogg error and one that says handlefade line error. Mod working, MP 4v4 is fine. SP is fine too on regular skirmish and random map.

Groves? Yeah, I need them garrisonable for the battalions.

Yes you can by editing the ~/Library/Application\ Support/0ad/user.cfg file and adding those lines: Don't forget to delete the entries once the re-release is out.

Well, 'passing events one-by-one' is exactly what is 0ad code actually doing. void CComponentManager::PostMessage(entity_id_t ent, const CMessage& msg) { PROFILE2_IFSPIKE("Post Message", 0.0005); PROFILE2_ATTR("%s", msg.GetScriptHandlerName()); // Send the message to components of ent, that subscribed locally to this message std::map<MessageTypeId, std::vector<ComponentTypeId> >::const_iterator it; it = m_LocalMessageSubscriptions.find(msg.GetType()); if (it != m_LocalMessageSubscriptions.end()) { std::vector<ComponentTypeId>::const_iterator ctit = it->second.begin(); for (; ctit != it->second.end(); ++ctit) { // Find the component instances of this type (if any) std::map<ComponentTypeId, std::map<entity_id_t, IComponent*> >::const_iterator emap = m_ComponentsByTypeId.find(*ctit); if (emap == m_ComponentsByTypeId.end()) continue; // Send the message to all of them std::map<entity_id_t, IComponent*>::const_iterator eit = emap->second.find(ent); if (eit != emap->second.end()) eit->second->HandleMessage(msg, false); // look, just calling HandleMessage() function. // Main threads is actually calling HandleMessage() of all receivers. One-by-one. // When you send a message you have to wait for all of your receivers to process it. Correct me if I'm wrong. } } SendGlobalMessage(ent, msg); } How would you notice CCmpUnitMotion class that async pathfinding is done and pass result? Actually all these messages are interface, because HandleMessage() function is interface function. But if you just call interface function from worker thread it will execute in worker thread(If it won't, if it will somehow execute in main thread, then this topic is quite pointless). Interface of pathfinder worker thread in main thread. This way pathfinder thread couldn't tell main thread about finished pathfinging. Main thread would have to check if worker thread already done it. This means it would have to check if pathfinder already finished computing path. This actually seems to be not that bad solution. CCmpPathfinderWorker would have it's local 'result queue' and main thread would lock pathfinder worker thread and check if there is something in that queue. But when would it check that?(where in code?) Main advantage of PostMessage() function is that receiver is getting your message instantly. With that queue it wouldn't be instantly. Then maybe it's not you who are all these questions to. Anyway thanks for your answer. EDIT: Another thing just came to my mind. When we send message about path result to CCmpUnitMotion, then it only does some updates. Whet would happen if we just lock main thread, send message, have it processed in worker thread, do all updates to CCmpUnitMotion in worker thread, and then unlock main thread and continue work? Only thing that I'm not sure of is what would happen if we lock main thread, and can we even do that? Won't it result in a deadlock or something?

The Release Candidates for the re-release of A23 are ready! https://releases.wildfiregames.com/rc Please test them as much as possible to ensure a great release. You can test everything you can think of, not only the points listed by Stan above. In case you find a bug, please make sure to tell us on which platform, including the version (for example, Windows 7, or Debian Stretch, or macOS High Sierra). Thanks in advance!

Angry Spartan circa 362 BC

I like your analysis, but this paragraph is key: This is the "real world" difference that's not accounted for in your analysis (to give you credit, you admit this). The different movement speeds for shuttling compound the economic impact shown in your data. Now, previously, some folks said, "Let's just give every soldier the same walking speed. That should solve it!" which I think is not a comprehensive solution, and the "combat balance" of the game, so much as it is, takes into account these walking speeds, so if you did that then the balance would be off again. No, I think the best, comprehensive solution is to have a ShuttleSpeed element for the unit templates. We can set all gatherers to the same ShuttleSpeed, something like 6.5 for the base game. Doing this then removes this problem. That's because Skiritai are basically Elite Citizen-Soldiers from the get go. They also have a high Walk Speed. Yeah, we shouldn't want that. So, let's all get on board with ShuttleSpeed! One of the byproducts of throwing out hard counters is now you have 3 ranged infantry units with no clearly defined roles (their stats are just slightly different and players just figure out which one has the best stats and spams those), so that now you have side issues like this economic question. Let's have ShuttleSpeed so the economic consideration is removed and players can choose units based on their combat prowess and strategy, and not be disincentivized by shuttling speed.

Assuming the information in the in-game civ structure trees is accurate, the only soldier that does not have 0.6 Food 0.8 Wood 0.5 Stone 0.5 Metal gathering rates are the Skritiai Commandos which I personally am okay with because their combat ability makes up for it. And then also each soldier type has slower rates as they rank up. I did an experiment hoping to show how much the movement speeds affects wood gathering. The results were less drastic than I expected. I created a scenario where you start with a CC, a storehouse next to an oak woodline (28 trees - total 5,600 wood), some houses, 2 soldiers, and enough resources to build 20 additional soldiers. To make it somewhat realistic I created soldiers in batches of 5. I set the gathering point for all to the same initial tree and did not micromanage which trees they cut. I then recorded how long it took for the last soldier to drop the final piece of wood for each unit type (except Skiritai Commandos and Clubmen). I repeated each unit type twice and got the same results. Here they are: Skirmishers (12.6 Walk) - 09:39 Slingers (10.8 Walk) - 09:51 Archers (9.9 Walk) - 10:01 Swordsmen (9.4 Walk) - 10:19 Spearmen (8.5 Walk) - 10:20 Pikeman (7.2 Walk) - 10:53 Women (9 Walk, 0.7 gather rate) - 10:13* I got 10:13 the first time, the next two times were 10:23-ish but the final woman kept walking back and forth and wouldn't go around the women in front of the storehouse. Here is a minute by minute breakdown of how much they gathered. The last number in parentheses for each unit type is the time at which they had deposited all 5,600 wood. Minutes 1min 2min 3min 4min 5min 6min 7min 8min 9min 10min 11min Skirmishers 80 410 1,030 1,800 2,550 3,280 3,970 4,650 5,270 (9:39) ~ Slingers 60 390 980 1,720 2,470 3,190 3,850 4,520 5,140 (9:51) ~ Archers 70 370 970 1,710 2,480 3,180 3,820 4,450 5,060 5,593 (10:01) Swordsmen 60 390 1,000 1,720 2,420 3,100 3,750 4,380 4,970 5,478 (10:19) Spearmen 50 370 940 1,680 2,400 3,070 3,690 4,310 4,900 5,440 (10:20) Pikemen 30 350 910 1,570 2,240 2,900 3,530 4,110 4,680 5,220 (10:53) Women1 110 520 1,210 1,900 2,610 3,280 3,890 4,530 5,100 5,532 (10:13) Women2 110 520 1,210 1,880 2,620 3,260 3,900 4,510 5,080 5,541 (10:23) As expected, it is the case that the faster the walk speed the faster the wood collection. (The women are an exception because they are created faster.) However, much of the difference occurs towards the end of the woodline when more walking is required. So for the first 5 minutes the difference is at most 80w among the ranged units. Pikemen, though, even in the first 5 minutes pikemen are at least 160w behind other melee units. As the game goes on though the effect does become more pronounced. The end times in the data are important as they show how long it takes to catch up. It takes longer to catch up as the game goes on. For example, at minute 1, skirmishers are ahead of slingers by 20, but the slingers actually make up the 20 within 1-2 seconds. Real game factors - Due to path-finding, the workers move in unpredictable ways that can be inefficient. So faster units can randomly under-perform (as can slower units). - These results do not take into consideration soldiers moving from gathering to defend from a rush or to go on a rush and go back to gathering. On the one hand, if defending with archers instead of skirmishers the archers have longer range and would not have to walk as far from the resource to attack the invader. So theoretically they can get back to gathering faster. On the other hand they deal damage slower and may have to fight longer, especially against spear cav. In fact, the enemy rush could force the weak archers to garrison in the CC. It is not obvious to me if archers or skirmishers would get back to wood gathering sooner. Seems like it would depend on the enemy unit composition. I bet defending with slingers would turn out the best. Obviously melee units that have to chase the enemy down while walking slower would lose the most gathering time. If you go on a rush units with faster walk speeds will get back to gather faster. - Also, it is important to keep in mind that the faster you have resources, the faster you can produce more units, the faster you can gather more resources, and so on. This means that in a real game where you are continually producing units the advantage will increase non-linearly if you have faster workers. So you get more workers sooner, and the new workers you get are again faster moving than the opponent's new workers when he gets them. So how big of a deal is it? Does it matter if archers cutting wood for 10 minutes are 22 seconds behind skirmishers cutting wood for 10 minutes? It doesn't seem that bad looking at the data on the chart but it would feel bad if you were trying to build a ram and had to wait 22 seconds for the wood. Entering a battle with a hero or a siege unit can have a big impact on the outcome. And again, because of what's discussed above in real game factors, the advantage/handicap will be more than just 22 seconds worth of gathering. And if for some crazy reason instead of archers you made mostly melee units you'd be worse off yet economically. At the end of all of this I ask: Do we really want a game where you are both economically and militarily incentivized to produce mostly ranged units instead of melee? If archers must be worst of the ranged units economically, shouldn't archers have some other advantage to make them viable?

actually, slingers are perfectly mid-way between archers and skirmishers on : range, speed, and attack. That's theory. But in practice, while slingers can use their bigger range to escape quick enough inter-bumping skirmishers ; archers move just too slow to move away in time (at least on long distance) . Its seems that slingers occupy a really tiny piece of land and bump in each other very few. In my opinion, slingers should be the fastest unit moving but providing less damage than archers (which is reality quite obvious). So rather than making slingers simply a mix between archers and skirmishers ; rather make archers the best ranged ; the slingers the fastest and the skirmishers the most harmful. To summarize > Now its : (1 is the best , 2 middle, 3 the worst) skirm sling archer speed 1 2 3 range 3 2 1 attack 1 2 3 > it should be skirm sling archer speed 2 1 3 range 3 2 1 attack 1 3 2

0 A.D. needs an Age of Mythology-inspired mod. The major hurdles with be some GUI stuff and the god powers. Otherwise, things like myth units should be easily doable. Including the classic rps dynamic of Monsters<Heroes<Humans<Monsters, easily doable with the class feature.

Some tweaks, removed the barrel and the grid.