historic_bruno
-
Posts
2.755 -
Joined
-
Last visited
-
Days Won
47
Posts posted by historic_bruno
-
-
@historic_bruno Thank you for putting me in CC of the ticket http://trac.wildfiregames.com/ticket/969
So, how do you think AI should handle territories ?
The patch includes some API changes, so I wanted to make sure all active AI devs are aware of that before they are implemented (they aren't certain, we may be making even bigger, more fundamental changes - stay tuned
)Territories have multiple aspects. There's the building restrictions which are fairly simple, see the second patch in that ticket for an example (I combined foundation obstructions and territory restrictions into a boolean concept). I haven't look into Split Bot's implementation, so I can't say what changes you need to make, but if it's based on Testbot/Jubot there should be a similar process.
Territory expansion is another problem, like building new civ centres when needed and in strategic locations. I haven't even thought about that, the AIs are overall lacking in strategy.
-
For some reason, it seems that newer RTS games don't include saving for multiplayer anymore, but only for single player
Really? I would think the most useful time to save a game would be during multiplayer games. Maybe the devs are just too lazy to account for all the special cases...
-
And they pop out as adults!
We should add children to 0 A.D. if only as eye candy.
Hmm I could see people getting very upset about children being killed if they are regular units
Maybe if we have "animated" buildings, with people walking in and out, doing chores etc., then children could be included like props. -
Saved games is generally needed, I would consider it a high priority feature
-
Herd animals should behave more acceptably now
-
Those two options might suffice, without requiring any additional logic in the installer.
I think the point of this thread was that even people who aren't developers (and don't want to mess with SVN or wait for an extra multi-GB download), should be able to use a simple installer and have a portable install. They wouldn't have to extract the files to Program Files, it could be the Desktop or a thumb drive or whatever
But at least the paths issue needs to be fixed, it's a higher priority IMO. -
- the error I see is much much bigger than an approximation, since it is allowed to build (but not finish, only the foundations) over the civic center - see the attached screenshot (look closely, there are 2 different foundations under the CC)
- it did not do that with alpha 6
Currently it's the AI's responsibility to determine where it can build based on the obstructions map. In Alpha 6, the simulation would also do its own checks for all players, to prevent them building where they shouldn't. This will be reinstated once problems like http://trac.wildfiregames.com/ticket/969 are fixed, it shouldn't be long, but until then the AI can do almost anything (but note that your AI should still do its own checks correctly). It may be the simulation check was simply masking problems in the AI build logic.
-
About this ticket, which has been an annoyance for some time but easy to fix if we come to an agreement. First, what are the exact differences between herd passive and hunt passive animals (besides coralling, which we don't have yet)?
If one of my units attacks a goat, should it run away or stay in place? I think for wild, huntable animals (like deer) it is clear they should run away, but not for herd animals regardless of who owns them.
Also, I think goats/sheep have a max HP that is way too high. They should not be as hard to kill as human units
-
Some questions/comments about the patches (haven't tested the build yet, and won't be able to for a week or so):
Why do you include ps/Pyrogenesis.h in several source files?
Why the #undef _T in UniDoubler.h? (_T is a macro for wxStrings and shouldn't be mixed with engine definitions in any case, Atlas doesn't know about CStr, which I believe is intentional. Any strings shared between Atlas and the engine use std::string or std::wstring instead).
As a general question, does your build support precompiled headers?
In Memory.h, it's conventional to name the macro guard after the file, so MEMORY_H.
In AtlasUI, I notice several files have changed <> includes to "", any particular reason for that?
Why is RGBColor renamed to RGBColorVector? (The engine seems to build fine in my tests and Atlas shouldn't conflict with engine code).
-
I've noticed you quickly posted a fix for this problem, which is good news. Can I test this fix using a binary (and perhaps post my system_info.txt)? Or would it be best to wait for a new release?
There won't be another release until Alpha 8, so if you want to test the fix sooner that would be great
You'd need to check out the latest SVN: either compiling it yourself or waiting for the next autobuild (should be soon). -
I don't think any of our developers are familiar enough with Xcode and OS X development to do that. I personally only have a virtual Mac and have only spent a small amount of time on build issues. Then there are questions of which versions of OS X and architectures do we want to support. I don't see any reason why it can't work, the Xcode projects are just text files and we need to make sure the right bits get thrown in.
Thinking more about the dependencies, I believe we can bundle pre-built libraries for OS X, like we do already for Windows.
-
The question is whether we value the Windows Software Logo requirements, which very explicitly forbid writing data in Program Files and demand Appdata instead:
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=3859
Oh, I think some things like cache should be in AppData and maps/logs/etc. in My Documents (like this discussion)
-
Confirmed on Ubuntu 11.04. I notice there are GL Errors when starting Atlas from the command line but not from the main menu. Sounds like a good starting point
-
I noticed it sometime this week for the first time, I am running the most recent svn version. (I never encountered the problem before). I think it may have happened when atlas was split into different threads. Anyways this is pretty minor since I can get the water back to normal by starting a new map or running a script.
Doesn't sound minor to me and I have no idea why that would cause water rendering to fail
I'll boot into Ubuntu and see if it's reproducible there. -
I followed the debug instructions (which all went fine). You can find the output here: http://users.telenet...game_start1.txt
Interesting, can you make a Trac ticket for this? (updates can be sent to you via email, in case we need more info)
I'd say attach your debugger output and also %appdata%\0ad\logs\system_info.txt if you have that.
-
I found recently that Atlas does not initialize water correctly when started from the command line. It works fine when it is started through the main program and also if you let Atlas reinitialize the water by selecting new... from the file menu.
The only time I encounter this bug is if I start Atlas via ./pyrogenesis -editor and then immediately start edditing the default map; i.e. lowering a bit of terrain and then raising the water level. I get water that looks black as shown in the attached picture.
How long have you noticed that, and which version of the game are you using?
-
Hello and welcome steggy
There's some ongoing, relevant discussion on AI taking place in this forum, if you want to get a feel for the current state of things
-
I believe Atlas in particular requires source\tools\atlas\AtlasUI built as a shared library (libAtlasUI) that ends up in binaries\system and which is dependent on source\tools\atlas\AtlasObject and source\tools\atlas\AtlasScript and of course source\tools\atlas\GameInterface (gets built in any case). All the rest is optional as far as I know, but if you want you can include the ActorEditor project which should create a separate binary. Hope this sheds some light on the situation
-
progress on atlas.
got most of it to compile after some work, remaining problems:
• whats with the DEVIL dependency in DDT.cpp, is this really necessary?
• XMP.cpp, whats all this xercesc stuff?
• archiveviewer.cpp:464, gcc complains:
The Atlas code is shared among several utilities (such as AoE3Ed) which aren't built by default. I would guess all the above are optional.
/Users/julian/Desktop/trunk/build/xcode/../../source/tools/atlas/AtlasUI/ArchiveViewer/ArchiveViewer.cpp:464:0 /Users/julian/Desktop/trunk/build/xcode/../../source/tools/atlas/AtlasUI/ArchiveViewer/ArchiveViewer.cpp:464: error: no matching function for call to 'std::set<std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >, std::less<std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > >, std::allocator<std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > > >::insert(wxCStrData)'
Looks like the problem where we want to initialize a std::wstring with a wxString and use c_str() instead of wc_str(). Possibly worth fixing, but see the above
-
Could make auras only show on selection or alternatively, toggle them with a hotkey.
-
I am also a bit puzzled by the debug instruction page. Is the Windows binary a debug build by default?
The releases include debug symbols for just this situation
-
Hmm that sounds a bit like another problem with DELAYLOAD, but more information is needed. Are you comfortable trying to debug the game, to find out what it's doing?
-
What's the dark purple area?
-
The AI's are given a list of allies and enemies currently.
I was looking at how to properly implement the AI's Entity.isEnemy() and Entity.isFriendly(), but I couldn't figure out how to hook up the arrays you mention. Maybe instead of being part of the the Entity class they should be somewhere else that has access to the game state. It would be nice to have that, so the AI could attack real enemies instead of massing at allies' civ centres
The JuBot Thread
in Game Development & Technical Discussion
Posted
Can you confirm the CC build plan is actually executed? That's when it looks for a valid position, but I think it will always come up with something.