historic_bruno
-
Posts
2.755 -
Joined
-
Last visited
-
Days Won
47
Posts posted by historic_bruno
-
-
Found the problem, at least in Windows it's a manifest issue, so I copied bits of http://svn.wildfiregames.com/public/ps/trunk/source/lib/sysdep/os/win/manifest.cpp to http://svn.wildfiregames.com/public/ps/trunk/source/tools/atlas/AtlasFrontends/ActorEditor.cpp and now for the first time, I can run Actor Editor O.o
-
Right, ActorEditor is not integrated into Atlas (yet?) only the ActorViewer (which used to be separate from both Atlas and ActorEditor). It is an integral component of creating actors. I use it often.
But how, I can't even get it to run? If it's something we use, then that needs to be fixed...
-
Suppose I have a ship loaded with units, but the ship is attacked and sunk. Currently, I believe all units on board will be miraculously left on the floor of the sea, unharmed. I'm trying to fix ungarrisoning as part of #893. Garrisoning and transporting are all jumbled together, which I don't like, but maybe that's sufficient for now.
The question is what should happen if a ship is sunk? Perhaps units who are near to land could be "shipwrecked" so they survive, but if it's too far away they die (say, more than 4 tiles which is the current max spawn radius). Or we could be pessimistic and assume they all die. Anyway, I think we'll need some kind of flag in the template like <GarrisonShip/> so this behavior is forced for ships and not buildings.
-
ok so here is my little debacle. I have the games latest svn, yet still I don't see any minimap colors for players or anything. My operating system is Ubuntu. could it be that a file hasn't gone on or been downloaded installed into the games files? I did get some weird message about the Atlas_UI thing.
Make sure your SVN checkout/update completed successfully (it will say "at revision: xxxx"). Also make sure your build completed with no errors (warnings are generally OK). No error or warnings when you run the game?
Does it seem anything like this? Maybe a screenshot can show what exactly you're seeing.
-
I'm back from holiday and will have some time for working on the remaining problems this week.
Today I've looked into the path issues with cxxtestgen and also the patch by historic_bruno (thank you!).
The root cause of the problem is that the relative path is relative to premake4.lua and not to the project files.
In those environments using customizations of premake for test-generation, this is no problem because premake handles it internally.
I'm suggesting a slightly different solution than historic_bruno which should keep working when moving premake4.lua or the project-directory and also is a bit more self-explaining in my opinion.
I've also discovered that the makefiles use an absolute path to cxxtestgen which is not good. Accessing cxxtestpath via prj.cxxtestpath instead of prj.solution.cxxtestpath changes this.
The changes from my previous patches are also included in this one. I've tested compiling on Linux, Mac and Windows. "premake4 embed" has already been done (script.c is included), but the prebuilt premake4.exe will have to be rebuilt and updated.
Could someone please review and apply the patch?
Welcome back, hope you had a good holiday
That sounds fine by me, I don't understand all the internals of Premake by any means, so my patch was more of a workaround. A proper solution is even better. I can test your patch on Windows and OS X, but my virtual Ubuntu machine has some problems running the game. And if anyone else is brave enough to test, that's good too 
Btw. I couldn't start 0ad on windows because it always failed calling JS_CallFunctionName with the "init" function.Is this a known bug?
Sounds like the /DELAYLOAD issue mentioned above. If you want to try the latest SVN revision, I've disabled delay loading of OpenAL. (Of course it will require update-workspaces, too.)
-
I encountered a problem when I tried to run the ActorEditor on linux. When trying to run the binary I get the following error:
./ActorEditor: error while loading shared libraries: ../../../binaries/system/libAtlasUI.so: cannot open shared object file: No such file or directory
I also get a similar error when trying to run the ColourTester
./ColourTester: error while loading shared libraries: ../../../binaries/system/libAtlasUI.so: cannot open shared object file: No such file or directory
I am compiling from svn. I get the same runtime errors regardless if I try either of the premake systems (the old default one or the new one).
running ldd ./ActorEditor gives me the following results
linux-vdso.so.1 => (0x00007fffa9dff000)
../../../binaries/system/libAtlasUI.so => not found
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007fa9220c7000)
libc.so.6 => /lib/libc.so.6 (0x00007fa921d43000)
libm.so.6 => /lib/libm.so.6 (0x00007fa921ac0000)
/lib64/ld-linux-x86-64.so.2 (0x00007fa9223ee000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007fa9218aa000)
I tried changing the LD_LIBRARY_PATH variable to include ~/0ad/binaries/system but it didn't help. The the libary libAtlasUI.so does exist in ~/0ad/binaries/system so I don't know why I am getting this runtime error.
I don't think either of those tools are being used anymore, so they probably haven't been maintained. In fact, I mean to delete ColourTester soon, since it has no use.
The Actor Viewer mode in Atlas is a rough approximation of those tools, though as far as I know, we have no UI for editing entities.
-
We also plan to, I believe, put the generic name, e.g. Thracian Peltast, in the UI, while putting the specific name (ethnic name) in the tooltip, e.g. Peltastes Thrakikos. We just haven't gotten around to it yet.
If it takes up too much UI space why not change the UI? Like make the specific name small and the generic name big. But I agree the generic name should be the most obvious for those of us who don't study ancient languages
-
Also, builders have to reach the dock, so the back of the dock (the part that faces land) can have at most a depth of 2m, but the front must be able to spawn ships, so it must have a depth of at least 1m (see simulation/data/pathfinder.xml for these definitions). Probably rather than hard-coding these values, they should be tied to the unit passability classes.
-
Dock placement seems a bit picky. It seems that it only allows a little part of the dock to extend into the water. How about as long as the dock is touching land it can be placed?
Yeah I've already got a fix for this (hopefully). Basically it was only including 3 tiles on either side of the land/water boundary, but now I'm making it so that all the water and the first 2 tiles of land are counted. This should make the dock placement a bit looser and also allow bigger foundations.
Also, it seems now that buildings can't be placed in water, even if that water is 1 millimeter deep and invisible to the player.
Yeah this is a tricky problem, I noticed some maps like Siwa Oasis have this (near player 1 starting area). There is a difference between what the renderer detects as being "underwater" and what a simple test like GroundHeight < WaterHeight reveals. But due to the terrain sloping, it could be that 1mm actually turns into a lake or river. Maybe it's enough to add some tolerance to the calculation, I'll test and find out.
-
WHY? WHY? WHY?
People disliked Age of Empires III partly because of the arbitrary building restrictions on everything. If people use buildings offensively, why is that such a problem? Let there be a vibrant churning of strategies instead of people being forced into certain strategies. It is inevitable that somehow a strategy emerges which you will not like because it's not the way you intended the game be played. That always happens. Let players have freedom.
Well I'm not sure which restrictions you're referring to, but for example, I envision territories and maybe build limits being options during game setup. Then you could play a less restricted style of game. I think territories and their nuances will be one of 0 A.D.'s main features, once we iron them out. The only other ones are obvious like not building docks in the middle of a desert or a house on the side of a cliff
-
so would it be worth a ticket? i think it looks really nice and adds something to it... the game would feel way more up-to-date
I think it's a valid suggestion
-
My only comment is that the dock should be restricted further into the water if possible, only a tiny piece of land should be occupied by the dock and this is for the workers to build it. The dock can in fact sit all on water, as long as a piece of underwater land is shallow enough for worker units to build it (think Belgian Bog). Just my tuppence worth
Yeah, boggy maps are a bit tricky, because shores aren't as well defined
I'm thinking you're right, a dock shouldn't strictly have to be built on "land", but in shallow water.i kinda got lost in the discussion, so im just gonna say this pertaining to building limits: perhaps these could be fueled or influenced by the number of civic centers that the player has
suppose that you start the game with one civic center, like usual. with just this, you can build 10 houses, 5 mills, 2 farmsteads, 1 barracks, and 1 temple. later on, you build a second civic center, which allows you to construct 10 more houses, 5 more mills, and so on. the numbers ive given here are just examples.
We had a concept like this for fixed territories (see http://trac.wildfiregames.com/ticket/687) but it has now been mostly scrapped. New territories are experimental, only time and feedback will tell if what we have now works
All of this doesn't apply to buildings like mills, farmsteads, fortresses, outposts etc., who could and should be built OUTSIDE of a city (civic centre radius).
This makes sense to me and is now quite easy to implement, it's just a matter of editing a few templates.
-
Hmm, in other RTS games, specifically AOK and AOM, it was simply understood very easily where you could place the dock---on the shoreline with a requisite water depth. The Dock's ghost would be red until you move it to a place that it may be placed. And when you moved it to a suitable place, the ghost "snapped" to a position perpendicular to the shoreline.
Well there was no snapping in AOK and the water texture appeared differently to indicate depth
I mean, the placement preview "ghost" will always appear red if not allowed to build, but how does the user know things like water depth? -
Here's a demonstration of the shore building restrictions for docks, as seen in Atlas. You could build them anywhere that's not red:
It shows the following:
1. Foundation obstructions (other buildings, trees)
2. Distance from shoreline
3. Slope of terrain
I think a map's terrain should reflect some of these criteria, so it's more obvious where a dock can be built.
-
#687 limits are not valid. They were derived from static territories and settlements.
In your example, where is the special allowance for it to build in neutral territory? Are we going to do it like this?
<Territory>own neutral</Territory>
I changed it to work this way, since it's more explicit
Right, so I think a disable="" attribute would be appropriate, much like the ones that already in place to disable parent components. I just think "magic" values like 9999 or something should be avoided, especially in a markup language as flexible as XML.
By the way, <BuildRestrictions> implies that multiple <XxxRestriction> elements may follow.
Actually I made the MinDistance and MaxDistance elements optional which seems to work fine (a simple undefined test in JS), if both are omitted nothing happens
BuildRestrictions is so-named because the component handles several types of restrictions (terrain, territory, obstructions, alignment). Philip explained the technical reason, but I think it's clearer that each limit has it's own unique name like PlacementType, Territory, Category, etc. If a certain building needs more complex restrictions, then maybe it's best to add a new element and/or handle it in the code, rather than complicating everything else.
-
Now that we have territories, we need more build restrictions. So I've gone ahead and got this working for territories as described in this post. This got me to thinking about other limits and restrictions we want, and it seems like a good time to fix those
I've found a few build limits in #687, are these still valid?
One new restriction is related to distance between civ centres. So I thought maybe we'd want similar restrictions for other buildings, why not make it flexible? So here's the scheme I came up with (to be added to the affected entity templates):
<BuildRestrictions>
<Territory>own</Territory>
<Category>CivilCentre</Category>
<DistanceRestriction>
<Category>CivilCentre</Category>
<MinDistance>150</MinDistance>
<MaxDistance>300</MaxDistance>
</DistanceRestriction>
</BuildRestrictions>That means the civ centre can only be built in the player's own territory (except it has special allowance to build in neutral territory), and it has to be at least 150 and no more than 300 units from another civ centre owned by the player (just an example, we may not want MaxDistance in this case
). Is this too complicated, too much functionality we won't use or does it make sense? If there are any other planned distance restrictions, feel free to list them. -
I assume the idea is that territories are still each owned by a single player, and computed independently of diplomacy, so the borders won't change as diplomacy changes, and the only new feature is that you're allowed to build on an ally's territory; as opposed to having a territory be owned by an alliance, where all the buildings of that alliance's members are summed together (as if they were effectively a single player) when computing the territories?
Right, I don't think building in ally territory should affect borders - only building in your own or neutral territories.
-
I didn't see any discussion of diplomacy yet, which is OK since we don't have proper diplomacy yet. But some scenarios have fixed teams, and we were discussing on IRC how to handle ally territories. The thinking is buildings except civic centres should be allowed in allied territories (without suffering loyalty drain) This creates an interesting tension between players IMO, as when alliances shift, and allows cooperative defense. Meanwhile civic centres would only be allowed in your own or neutral territory.
Proposed territory building restrictions:
Own Ally Neutral Enemy
Civic Centre X X
Fortress X X
Barracks X X
Scout Tower X X
Temple and Market X
Mill and Farmstead X X
Farm Fields and Corral X X
House X
Dock X X X
Walls X
-
There was a discussion in IRC about importing the game's models into Blender (.dae COLLADA files), some people are having problems with this. I installed Blender 2.58.1 to see what the process looks like. The built-in importer gave a message "cannot create image" but silently failed otherwise.
I'm not sure if it's a known problem, but apparently the importer doesn't like the absolute path(s) in <library_images>, so I removed that element from the test file and also the reference to it in <library_effects>. Then the file was able to import. Looks like a bug in the importer maybe, does anyone else have this problem?
-
What's the point of this tool and when's the last time someone used it? Just asking because it doesn't run properly on my computer, and I can't see its purpose since we have the actor viewer in Atlas
If there's no point we can delete it per http://trac.wildfiregames.com/ticket/666 -
Please make sure first that it will met notability rules in specific language edition where you going to create article. For example in dewiki it was already deleted number of times: Logbuch 0 A.D. (Computerspiel), Logbuch 0 A.D., so it is probably don't make sense to create it there until 0ad will reach beta or even 1.0 release or something.
Huh? How does the language of the entry determine notability of the subject? The only reference I see to language in that guideline is "sources may encompass published works in all forms and media, and in any language," which seems to confirm that. It would be ridiculous to claim, for example, that a famous event didn't occur in e.g. German or Finnish, just because it happened in an English-speaking part of the world.
-
This is something that will be fixed once we have conversion. If all the enemies are dead or out of range of the sheep or goat, then the sheep or goat would convert to the nearby enemy player. Another feature would be that goats and sheep (and cows, etc.) would convert to Gaia if out of range of any units (friendly or enemy) for too long.
I actually like this idea, you could capture your opponent's livestock (which is quite realistic) whether dead or alive.
-
Hello, I am a programmer and I spend a little of my spare time to play with 0.A.D's pathfinding logic.
I currently work on determining areas of homogeneous terrain tiles to speed up the long pathfinder. Such areas allow to not run A* on each tiles, but just looking at the ones necessary to go from an area to the other.
For the moment my code is not mature at all. Understand : hacky, buggy, don't respect coding styles and slow down performances. But if you are interested by such optimization/research, I can easily create a topic to give feedbacks about progresses. If you don't specially care I'll open a topic only when (and if) it really improve performances and get polished.
So, for the current topic, I just say that I am working on some area mapping. But it is not strategic areas nor currently usable at all.
Finally, to solve your AI problems. Isn't it sufficient to add (if not already exists) a pathfinder's API to get the long path cost of traveling from a point A to a point B with a unit class C ? Given A, B and C being parameters and long path cost the return. If so it seems not so hard to provide (but I can mistake, I'm not expert).
We look forward to hearing more
Also for very technical discussion and (sometimes) instant feedback, try joining our #0ad-dev IRC channel on QuakeNet. -
Saving a map with Atlas now causes Atlas to crash. Also the map is now corrupted, causing a crash when attempting to open in both Atlas and the Game. Oasis II is one such map. I reverted my working copy to a previous revision, but that's not a real solution. This happens on both my laptop and desktop local copies. Using auto-build.
How long have you been seeing this?
Working On Upgrade To Premake4
in Applications and Contributions
Posted
I'm getting the same problem in Ubuntu with gcc 4.5.2, even without using the -j option (old update-workspaces works fine, btw).