Deiz
-
Posts
76 -
Joined
-
Last visited
-
Days Won
1
Posts posted by Deiz
-
-
How about making it so that players only hear UI sounds related to their own units
Also I would like a way to control voice and/or UI volume independently of the other volume controls, I don't see a way to do that yet. Music shouldn't cut off abruptly when a game starts, and it shouldn't continue playing in Atlas after the simulation ends (ambient sounds do the same thing IIRC). Music shouldn't just loop forever IMO, periods of silence are not a bad thing. Most of the music code should be stripped out of the UI scripts. Adding sounds to the UI would be nice (button presses, etc.) Double click selection of units plays multiple voice responses in succession. Battles sound terrible with all the repetitive death grunts.There's a few ideas for you, but the biggest problem is sounds not respecting the camera position/zoom. With the new shared ally LOS, I can hear units dying on the opposite side of the map.
The UI sound issue should've been fixed in r12553. Are you sure about distant sounds? Presently I don't hear any non-selection sounds if they aren't on-screen (tested training, gathering, death).
-
I agree the tooltips are too long, but keep in mind that prior to adding that info, there was absolutely nowhere in the UI that allowed us to see attack and armor stats before training the unit. There is currently no mention of range anywhere, so I have no idea if my unit has a longer range than an enemy fortress or tower. This is really important info and should be shown somewhere. Also we have a lot of distinct units with difficult names, it's not always clear to me if a unit is ranged or melee - sometimes that's all I want to know!
I propose the following:
- Add an info / help button in the corner of each training / construction button (or use a modifier/hotkey)
- Clicking the new info icon opens up a well-organized stats sheet with everything the player could possibly want to know about said entity and a large portrait
- Link to list of entities and stat sheets elsewhere in the menu
- The training/construction tooltip shows only: unit name, description and iconified costs
- Clarify in the description(?) whether a unit has ranged or melee attack - could be as simple as showing an arrow / sword icon after its name
- For already existing units and buildings, add attack type and range to the stats tooltip
A modifier sounds like a better idea than a small icon on each button. However, it's then a hidden feature that needs to be shown to players, particularly existing players who may not read the 'Learn to Play' dialogue every release.
A separate GUI page that shows exhaustive information seems like a good idea. Ideally it should be Wesnoth-style, having a list of all of a civilization's units so players can quickly compare different units.
I'm not so sure about stripping down the training/construction tooltips. I don't think it should be necessary to go view the exhaustive information simply because you've forgotten a basic attribute of a unit, e.g. which of a civ's ranged units is fastest. The current tooltips make it quite easy to determine that because the stat rows are relatively consistent and you can just move your mouse across the whole row to see the speed for each unit.
- Add an info / help button in the corner of each training / construction button (or use a modifier/hotkey)
-
I'm not sure there is a particularly clean way to do it.
The nicest way I can think of would be to keep a list of objects to update each frame in session.js, along with an anonymous function that adjusts them when needed. The objects would be inserted and deleted as necessary by unit_commands.js, resulting in something like this:
var updateOnTick = {
"unitQueueProgressLamp[0]": function(obj) { obj.hidden = (Date.now() % 1000 < 500) },
"unitQueueProgressSlider[0]": function(obj) { obj.hidden = (Date.now() % 1000 >= 500) }
}Which session.js would invoke with something like:
for (var objName in updateOnTick)
{
var obj = getGUIObjectByName(objName);
updateOnTick[objName](obj);
} -
Generally speaking, the various Wikipedia projects tend to have an inherent bias against free, open-source software. Their sourcing policies are stuck in the pre-Internet era, focusing heavily on professionally-edited publications that are rare in the FOSS niche (particularly when it comes to games).
The German Wikipedia is reputed to be the worst of the lot when it comes to notability, so it's unsurprising that 0 A.D.'s article was deleted. As far as I know, the project was taken over by deletionists a few years ago and they've been on a heavy-handed rampage ever since (note the huge swath of Linux distributions also up for deletion on that same archive page).
-
1
-
-
Shift --> perfect, have been wanting that
Alt - what do you mean by matching? It would be really great if you e.g. could easily select all idle units standing around a specific resource dropoff point or something, but that seems like it could be difficult to implement 
I wouldn't want to e.g. select all idle archers or something though as they might be on different ends of the map, but I doubt that's what you're thinking of (I don't fully understand what you mean by clobber though, a quick google search didn't do much to enlighten me, but then 1 AM might not be the best time to learn new words )Clobber as in overwriting the old data, rather than to appending to it. Alt would do what you mentioned: It would select every idle unit that had one of the specified classes.
It's really just a shortcut, as holding shift and the relevant idle selection key would eventually accomplish the same thing as alt-select (Alt being the hotkey for off-screen selection, e.g. alt + double click will select all units of a given type on the map).
-
Acceptable classes for 'idleworker' are ["Female", "Trade", "FishingBoat", "CitizenSoldier", "Healer"], while 'idlewarrior' is ["Hero", "Champion", "CitizenSoldier", "Siege", "Warship"].
So really, 'idleworker' is kind of a catch-all for non-military units. I think it'd be better to have idleworker restricted to builders and gatherers, with a third key for the rest, i.e. traders and healers, at present.
I also don't find much utility in the current 'clobber selection with one idle unit' behaviour. I think I'll add proper hotkey support to the function, e.g. shift will add the found idle unit to the selection, alt will add all matching idle units.
-
Oh, whoops. I was thinking of another thread where somebody was reporting AI OOMs.
Yes, the AI and RMS runtimes are separate. The RMS runtime is 96 MB, but some random map scripts still OOM frequently, even at rather small sizes. I'm not sure if it's due to massive memory usage or massive amounts of memory fragmentation (though it's probably a combination of the two).
-
Of course, but since the game isn't that smart yet, the choices we have are to either hardcode an arbitrary value, or to expose it as a config setting. gameboy's bug report is an excellent example of why the latter might be a better solution at this stage in development: instead of telling him he can't use the map size he wants, we could have told him to change a value in the config.
It still ends up being a probability game, though. I've had a few transient OOMs with the 32 MB AI runtime and then it'll get GC'd back down to ~10 MB. The bump to 32 MB mostly alleviates entity collection creep (as more units exist the longer the game goes on).
I think that permanently tackling the terrain analysis OOMs will require a) reworking that code to be friendlier to SpiderMonkey's mark-and-sweep GC,
possibly waiting for SpiderMonkey to get a generational GC. -
I don't think knee-jerk reactions are useful here. We haven't incorporated content from a billion-dollar game development company with an over-eager legal team that sends out dozens of cease-and-desist notices a day and gets its jollies kicking puppies. Rather, we've borrowed content from a volunteer-driven encyclopedia which happens to share the same license we use for our own content, and which the entirety of the game data is distributed under.
We've simply failed to attribute the few pieces of content that we've used from Wikipedia. It's an unfortunate oversight, and should be rectified for alpha 12, but it's not a massive threat to the project that demands legal consultation or threatening team members with commit right revocation.
Attribution on the forums is likely inadequate for content used in-game, anyhow. A better solution would be to finish the work-in-progress in-game credits display. Once that's done and we've sorted out which bits of content come from where, an list of third-party content and its authors can be shipped along with the game and viewed via the main menu. That ought to satisfy the Creative Commons attribution requirements handily.
Licensing is invariably a pain. Chances are that for every project that gets it right, there are several that get it wrong. A degree of good faith must be assumed, especially between freely-licensed projects, or the entire ecosystem would collapse in a huge fireball of litigation.
-
1
-
-
You could deal with the desync by moving the population counter blinking into onSimulationUpdate. It seems odd to have the GUI flashing while the simulation is paused, anyhow.
The second sprite isn't a very nice solution, but it's unfortunately the nicest solution available. Sprites aren't exposed to Javascript at all and I believe they're designed to be immutable. There is the "colour: r g b a" sprite hack that's used in a few places, but as far as I know there's no way to turn a named colour like "orange" into separate RGBA values that you can then make a new sprite with. Perhaps in the future this'll change - it's quite a mess at the moment.
Your indenting in unit_commands.js is somewhat wonky, other than that the patch looks good.
-
I've discovered what the problem is. It turns out that most of what I've been attempting has been irrelevant: It's not a renderer bug, it's a loading bug. I was about to give up when I decided to strace 0ad while it loads with no cache, to see where it's actually sourcing files from.
The reason nobody else seems to be able to reproduce this? It requires both the internal/ and public/ trees within binaries/data/mods, and it requires the former to have newer mtimes than the latter.
The only real content of note in internal/art/actors are the Iberian props. They use the old texture element format, like so:
<texture>props/iber_prop_shields.dds</texture>
Meanwhile, the public/ version of that same file uses the newer format:
<textures><texture file="props/iber_prop_shields.dds" name="baseTex"/></textures>
Apparently, the "internal" mod is being loaded and when files exist in both public/ and internal/, the one with the newer mtime is preferred. If I touch every file in internal/art, all of the Iberian props are screwed up. If I touch every file in public/art, everything is fine.
This has been quite the bug odyssey. I, for one, blame Mythos Ruler (he's the one who created the internal/ props, back in 2009).
-
As a stop-gap, I think it would be adequate to have repair function like construction. That is, once a unit finishes its current repair order, try to find another nearby unit that can be repaired.
That'd at least allow you to repair a bunch of siege units with a single click, rather than needing to spread them all out and do each one manually.
-
I'm strongly doubting this is a hardware issue, as it wasn't present in alpha 10, I've never seen anything similar in other games, and it's heavily influenced by the actor XML, plus it occurs in both GLSL and ARB mode.
One more data point: Perhaps it's AO-related? At the very least it seems tied to the new materials and/or textures. The Iberian house (art/actors/structures/iberians/house.xml) uses this material: <material>player_trans_ao_parallax_spec.xml</material>. When I clear my art cache, in both GLSL and ARB modes, the wood pile in one of the variants is covered by a stretched stone texture. Removing that material line and clearing the cache, though, and the issue disappears. I've confirmed that this behaviour is 100% reproducible on my end.
-
My nvidia-settings options are (to my knowledge) vanilla, and it doesn't seem that any settings fiddling changes things for the better. Some options do have visual affects, though - e.g. forcing 16x AF and FXAA simultaneously seems to make the texture mappings cycle more rapidly with zoom.
My binary is definitely linked against current libraries:
libnvidia-tls.so.304.43 => /usr/lib/libnvidia-tls.so.304.43 (0x00007f4842bd4000)
libnvidia-glcore.so.304.43 => /usr/lib/libnvidia-glcore.so.304.43 (0x00007f48407eb000)I just noticed something very interesting: art/actors/props/structures/iberians/market_01.xml is what contains the various crates and barrels of wares that populate the market. It only has one texture, "baseTex". Simply duplicating the normTex and specTex from another actor seems sufficient to make the issue disappear (tested with a few different props).
However, undoing that change and blowing away the art cache (~/.cache/0ad/art) seems insufficient to bring back the buggy behaviour, though other buggy props do persist after wiping the cache out. Is there some redundant caching I'm unaware of?
-
It could well be that Nvidia botched the 302.17 release (dates to mid-June). I'll upgrade my packages later today and see whether these issues remain reproducible.
Well, so much for that - now running 304.43 and still able to reproduce the issues. Now that we're frozen for release, I suppose time will tell whether others are also experiencing the texture mapping issue.
-
It could well be that Nvidia botched the 302.17 release (dates to mid-June). I'll upgrade my packages later today and see whether these issues remain reproducible.
-
In r12636, with shadows = false and shadowpcf = false, textures in ARB mode vary a lot with camera distance, GLSL textures are mostly gold or black stripes.
Here's your second helping of "WTF": This just happened in GLSL mode. Note how the structure textures are all fine... but most of the HUD has disappeared.
-
I definitely did rebuild - I saw source/renderer/ModelRenderer.cpp go by in make's output and then linking proceeded without issue.
Anyhow, I have a bit of "WTF" that might provide some insight, confirmed on both r12630 and current r12636: Shadow filtering makes a difference. In both ARB and GLSL mode, toggling shadow filtering without moving the camera whatsoever will result in a complete change in the texture mapping - it's clearly not just a shade change, as I've seen a rough sandstone texture be replaced by crisp grey and black lines.
-
No dice with r12630. In both ARB and GLSL modes, the incorrect textures change with the zoom level.
There are some differences in behaviour between the two modes, though. With GLSL, the texture mappings generally change rapidly with zoom, but notably the textures are often mapped correctly at the default camera h eight. In ARB mode, I usually only have two mappings no matter how extreme the zoom level, yet both are wrong - one is either white or black and the other is usually gold.
-
I have a Nvidia 9600 GT and run the proprietary driver, 302.17 presently.
The issue presents itself in the exact same way in both ARB and GLSL modes. For what it's worth, the Iberian Sandbox triggers the issue immediately and 100% of the time, for me.
-
No, that seems to drastically worsen the issue, but in a different manner - certain portions of meshes turn completely white when zoomed out, and completely black when zoomed in.
Is this perhaps related to a particular material? It presently impacts most of the props on various Iberian structures, e.g. drying racks and wood piles on houses, containers in the market - but not the basic Iberian stone texture itself, nor the market canopy, etc.
-
-
This is probably due to r12563.
Formations used to disband when the controller reached its destination, but that lead to some issues (like units staying in FORMATIONMEMBER.WALKING indefinitely if the controller never moved, or not moving properly for short walk orders). Now they disband when the controller reaches its destination and the units reach their intended destinations within the formation. The latter is also satisfied if movement fails for some reason, e.g. a unit being obstructed.
You can see the latter by turning the obstruction overlay on and walking a large formation into a building; they'll bunch up but then the formation will disband when they're all done moving.
I think I know what causes this, though. I made a 20-unit formation and boxed one unit in between four siege rams, and as such it failed to even start moving. So, the formation size is 20, but only 19 units actually moved, and thus 19 units stop and that's not sufficient for the formation to disband itself.
Edit: Should be fixed in r12613.
-
This is fairly common.
Units in formation are allowed to collide with each other, and formation spacing more or less ignores the formation members' obstruction sizes. Additionally, when entities are actively colliding when they shouldn't be, they're allowed to move through each other (generally to get un-stuck).
It's just a sort of convergence, really. In formation the obstructions will overlap like a Venn diagram, and then you break formation by giving the units an attack order and they move to attack and end up completely on top of each other, appearing to be one unit.
Resource icons in tooltips
in Game Development & Technical Discussion
Posted
I initially preferred the "[amount] [icon]" layout, but "[icon] [amount]" probably makes more sense as that's what the top bar already uses.
As padding in the image itself would effectively shrink it in both width and height, I think that's a bad idea. A trailing space or three ought to do fine.