captBluesky

I think what we're seeing is that anything that threatens *massed formation combat* philosophy is nerfed to impotence in 24b. Cat's don't seem to want to target units anymore. Ships can be sunk with archers (ridiculous). Cat's and bolts are easily killed by archers as well. I'm seeing others talking about limiting the use of walls because again, it seems to interfere with/mitigates the *mass formation combat* centric thinking. This is very frustrating to me as I prefer engineering attacks (using buildings, defensive structures to hold ground), and forts to press into enemy territory. With naval landings in 23b one could hold a beachhead with garrisoned ships. With romans, you could build camps, then siege under naval protection. All that's gone now and such concepts as naval bombardment have been reduced to a bad joke in 24b. I think part of the problem is limited categories of damage. 0ad should have another category of damaged called *structural*. Archers, slingers, and melee would not cause *any* structural damage. In one of the older 0ad manuals it quite clearly said *only siege could destroy buildings*. Somewhere along the way 0ad departed from that ideal. If the 0ad really wants to see foot, and horse units cause damage to certain wooden structures, a more thoughtful implementation of *fire based strucutural damage* might be implemented. In 23b slingers could level stone forts, clearly ludicrous.

OMG, what have they done to my Romans?!! Cat's don't seem to target soldiers anymore. Ships are now laughably impotent and can easily be dispatched by archers (really?), while ships garrisoned with cats do nothing against their attackers in return. Roman champ cav seems to have lost all its tech upgrades, and now are easily dispatched. **about the only defense Rome had against ramSpam was fast, tough champ cav. That's gone now. Rome still has no defense against long range ground units (archers, slingers) save for seige, which now is so fragile as to be nearly useless. **Romans need mercenary archers/slingers option (like other factions do). Rome had strong walls, and strong buildings ("had" being the operative word), which helped offset horde attacks. It only took a few games against the ai horde attacks to realize just how badly nerfed Rome had become in 24b. 24b seems to cater to the spam-fast-and-hard crowd (the celtic-only wonder boyz). Romans had been very strong, but range disadvantaged, slow (to build), and structurally expensive. But with engineering techniques, they could hold, and gain territory. No longer. With their camps they could project power that offset other limitations. Now even that capability has been emasculated. Non-spamming type thinking seems to have displeased the prior celtic-horde old-boy network. In 24b that sort of inappropriate thinking appears to have been corrected, preserving the status quo. I'm sure we'll read and hear how all this was *necessary* and clearly a *fair* change, if we would only be reasonable and accept the mandates imposed on us by our black hooded masters. And that any descent is indicative of some kind of character flaw of anyone who would dare criticize these changes. For those who might rebel against what is clearly tyrannical conspiracy, I suggest the following.. We, the oppressed, should mandate that everyone involved in pushing our beloved developer team to implement this ludicrous perversion of Rome (and other factions I fear) be made to play only the Roman faction (and no other) for the duration of 24b, until version 25 arrives. I mean, since all these changes are fair, balanced and just, they should have no objection and gladly accept this edict as a token of good will and to promote 0ad social cohesion. Note: My comments are in no way intended to disparage the development team. Those folks work very hard for low pay ($0.00), and are about the kindest, most agreeable folks (except for wraitii, but he's still ok) I've ever encountered. Please drop some kind words on the wildfire team!

Chrstgtr's apparent disdain for naval games notwithstanding, I feel there are some ideas we might look at for improving vessel operations. Again, referring to SuddenStrike/II game play, ships/boats did'nt go chasing after land units trying to figure out where to intercept them. Instead, boats were *docked*. And while docked they could be loaded/unloaded. Anyone who's tried to use boats on naval maps has probably felt a common frustration at vessel's behavior when trying to use them for transport. What I propose: 1. boats must be docked to load or unload This does'nt mean the vessel has to have some kind of dock construction or be at a prebuilt dock, it only means it's in a docked state (moored/beached) in proximity to the shore to facilitate load/unload opperations. Once docked, the boat/vessel *does not move* until un-docked. 2. If units are to be picked up by a vessel, the land units must be *at the shore* for them to be designated as target for pickup No trying to guess the best place to do a pickup. Put the units at the pickup point, then command the boat to pick them up 3. And of course a docked vessel can be made a garrison target for land units to board (assuming the dock is located on the same landmass as the units in question). For further concept development, we might look at virtual docks or dock rally points (pick your nameOlogy) where a virtual dock location is designated (like a rally point) and stays until cleared. A vessel might be granted automated behavior to shuttle units between two such virtual docks (possibly a tech upgrade, command automation for a fee). Units could be made to rally at a virtual dock on one shore, and a boat/vessel could automatically transport to a destination dock on another shore. This could be repeated as long as units rally at the docks. To keep units from being sent back to where they just came from, units would be given an automatic move command to move off the destination dock. Some of these ideas resemble OpenTTD. Too much automation might take gameplay in a direction we don't want to go, but I think we do want to reduce micro-management workload so the player can focus more on strategy.

I'd like to open a discussion about possible changes to ram implementation. In comments about 24b, there's talk about ram issues, why rams don't attack soldiers anymore, etc. My proposal would be to modify ram's along the lines of mechanized units found in other games. One of these is a german tank battle game called SuddenStrike and SuddentStrikeII. In that game tanks, jeeps, trucks, apc's were *manned* and could not operate without a crew. The crew could be killed, or the crew could leave the vehicle, leaving the vehicle essentially inert and *neutral* (meaning anyone/team could capture it). Vehicles could be damaged unable to move until repaired. A minimum crew compliment was required to operate a given vehicle. Vehicle fighting efficiency varied depending on how completely the vehicle was crewed. My understanding of ancient rams is that they were manned, the men inside not only operated the ram, moved it, they also fought off attackers from within. So I propose something similar for 0ad. 1. rams don't move and are inert without a crew 2. rams are owned by whomever crews it. 3. rams can break down (made unusable) but can be repaired. 4. rams can (still) be destroyed. 5. crews in rams can inflict damage on enemy units in the vicinity.

I'd like to open a discussion about possible changes to ram implementation. In comments about 24b, there's talk about ram issue, why rams don't attack soldiers anymore, etc. My proposal would be to modify ram's along the lines of mechanized units found in other games. One of these is a german tank battle game called SuddenStrike and SuddentStrikeII. In that game tanks, jeeps, trucks, apc's were *manned* and could not operate without a crew. The crew could be killed, or the crew could leave the vehicle, leaving the vehicle essentially inert and *neutral* (meaning anyone/team could capture it). Vehicles could be damaged unable to move until repaired. A minimum crew compliment was required to operate a given vehicle. Vehicle fighting efficiency varied depending on how completely the vehicle was crewed. My understanding of ancient rams is that they were manned, the men inside not only operated the ram, moved it, they also fought off attackers from within. So I propose something similar for 0ad. 1. rams don't move and are inert without a crew 2. rams are owned by whomever crews it. 3. rams can break down (made unusable) but can be repaired. 4. rams can (still) be destroyed. 5. crews in rams can inflict damage on enemy units in the vicinity.

I've actually complained about this on several occasions both in Lobby and on #0ad-dev. This is what I call the multi-sampling of the mouse (and possibly kb) inputs. This evident when the game is heavily loaded and update rates bog down. (lag but not graphics lag). Ideally, as soon as a player selects a destination/command for a group of units (chop wood, build structures etc) the mouse data (button states and mouse position) should be recorded *once*, and stored for subsequent use in the mod js for that command. But what seems fairly obvious to me is that several routines are going back to the mouse interface and asking for mouse button state, and position over and over. In 23b it was bad in heavily loaded games. In 24b it is far worse. Now it appears that not only is the js code multi-sampling the mouse IO (not an SDL issue Stan), it is re-sampling the mouse raw data for *each unit in the group selected for the that command*. That is evident in the case of *unit spreading*. If you push the operations rates (like you need to, to stuff as many commands in unit time as possible) you can end up with a group of units spread out in a fan pattern (across the map)and stopped/idle instead of converging on command destination. Again, evidence that for each unit in the group the code is going back to raw mouse data and sampling raw mouse data. And of course since the player had long since moved on to the next command, the js code is seeing a moving mouse position and a different position for each unit.

Build: <git clone https://github.com/0ad/0ad.git> <cd 0ad/build/workspaces> <./update-workspaces.sh -j3> -had to install "rustc" <cd gcc> <make -j3 config=debug> -or- <make -j3> fails with: " rwas@rwas-Aspire-E5-576G% make -j3 ==== Building mocks_real (release) ==== Creating obj/mocks_real_Release mocks_real.cpp Linking mocks_real ==== Building network (release) ==== Creating obj/network_Release precompiled.h In file included from ../../../source/lib/precompiled.h:111:0, from ../../../source/pch/network/precompiled.h:19: ../../../source/ps/CLogger.h:28:10: fatal error: fmt/printf.h: No such file or directory #include <fmt/printf.h> ^~~~~~~~~~~~~~ compilation terminated. network.make:137: recipe for target 'obj/network_Release/precompiled.h.gch' failed make[1]: *** [obj/network_Release/precompiled.h.gch] Error 1 Makefile:76: recipe for target 'network' failed make: *** [network] Error 2 " Mind you I have successfully built 24a before (4 mo ago with devr channel help) Quakenet. For some reason Quakenet is *G-line* ing me. I see a message about botnets not being allowed, but not sure if that's just part of the MOTD. There appears to be *no way to reach an admin* unless you are on the server. Soft of a chicken and the egg kinda deal. captBluesky

He attempted several attacks in which all his units were destroyed quickly. The game abruptly ended after the last such attack. There was no sign of him in the lobby after that. I'm following the instructions in the lobby's MOTD. I'm not sure if I need to supply any game files at this point.