FeXoR
-
Posts
1.426 -
Joined
-
Last visited
-
Days Won
28
Posts posted by FeXoR
-
-
Here's a new version to keep compatible with the SVN version.
WARNING: The rmgen folder is mainly for people using alpha9. If you are using the SVN version use it with care!
-
1
-
-
In random maps the players are randomly distributed if they have no players in the same team.
If I start a random map with unassigned players I still have the right color and race, so everything works fine for me.
If there are no ther players what do you mean by unassigned slot?
4 players for example and you pick the second slot and all others to unassigned?
-
The engine supports those characters as well, it's just that there needs to be a font with them included added to the game
Is someone at it or could that be a job for one of the massively motivated translators?
-
In future ranged units will be going to have an additional melee attack for short ranges. Like age of empires 3.
Wonderful! For some ranged units melee stats are already shown in the game so I though they already could in principle attack but the unit AI didn't let them.
-
Ranged units, if chased, should be faster than melee units, and should know how to get a "comfort zone" that would give them enough time to fire and not be attacked.
And I think both units should 'run' until out of stamina and the melee unit should have more stamina.
I think the problem could be solved by removing minimum range from non-siege units.
I think the issue is more general in nature as I posted here
-
Position: RMS designer, AI developer, API developer (RMS, AI and balance testing)
Do you understand that Wildfire Games is a non-commercial project, work for 0 A.D. is volunteer, and work is done for free?
Yes, that's why I'm here
Do you agree to distribute all your work for Wildfire Games under Creative Commons Attribution Share-Alike license?
Yes, and I'm loving it!
Name:
Florian Finke
Email:
Please ask me in a personal conversation
MSN Messenger:
N/A
Location:
Köln (cologne), germany
Availability:
20 hours per week at least for the next 4 months, likely until the game leaves beta though perhaps less hours per week later on
Age:
33
Occupation:
Self-employed as private tutor (maths, physics, chemistry) and web-developer
Skills and Experience:
RTS gaming: I play and love RTS games in general and got vast experience with balancing, micro/macro management, tactics and strategies
RTS modding: I wrote mods for warcraft III (example: in-game random map generator and maps with in game race choice with all races supported by own AIs) and glest. I designed maps for nearly every game I played
Coding:
- Wrote a acquisition system for a multi-channel-analyzer developed at the institute for nuclear physics at the "Universität zu Köln" in python
- Developed a game where the player writes bots in python and let them play rock-paper-scissors against each other in python with bot API and GUI in QT
- The bots included neuronal network simulation, collective decisions by elections and other fancy stuff ^^
- Wrote an easy to use HTML-page-generator for simple web pages
- Made the wall_builder.js rmgen library for 0ad allrdy in svn.
- Made the deep_forest RMS for 0ad (Not finished)
Motivation:
I love open source, coding, RTS, creative common... how could I NOT come here???
Personality:
Socially clumsy but intelligent and "try to be objective", cooperative and forgiving but hard-hearted when it comes to the point and I never grew up in some ways... and I'm proud of it!
Though it's a second sentence I think I'd mention that Spahbod described my maps/code as I am: "very odd"
Short Essay:
I searched for open source RTS games and found this massively above-average game in that area
As said before, I have no choice but to love it and try to contribute to it ^^
I seek for the possibility to write code that is actually used, to put my work on something that is greater then any project I could possible do on my own, I seek to help making this game better than any based (slow-paced) strategy game after 'Age of Empire II - The Conquerers' (IMO the best, good new fast paced RTS are out there)
Interests and Hobbies:
I'm mainly interested in very general stuff like physics (methods and interpretation), philosophy (ontology), mathematics (countable and other infinite) and politics (human rights, enduring system stability). See more details in my profile.
I'm also playing pen and paper roll playing games ('World of Darkness - Werewolf - The Forsaken' at the moment)
My most loved PnP RPGs are Deadlands, World of Darkness - Magus - The Awakening and Earthdown.
Staff:
I don't get this part, it's optional anyways
Community:
None very frequently, only 0ad
Favorite Game:
Warcraft III(Blizzard), Age of Empires - The Conquerers(Microsoft Games),Diablo II(Blizzard), Warzone 2100(Now Open Source), Sacrifice(Shiny Entertainment), Starcraft(Blizzard), Total Annihilation(Now Open Cource), Glest(Open Source), Globulation(Open Source), Gothic(Piranha Bites) , Bos Wars(Open Source) generally in that order
Work Examples:
Most things are german, sry.
Some old stuff including an old version of ssp (Stone-Scissors-Paper (more commonly known as Rock-Scissors-Paper, I know... now)) can be found on my old web side (hosted on my server right next to me ^^)
In the HTML section the page generator written in python can be seen (it's an old version too.)
A newer version made this page
If you are interested in any new code please let me know and I'll provide it.
My wall_builder.js rmgen library is already in your svn
My Deep Forest map can be found here
Some of my remaining Warcraft III maps can be found here (lost many by headcrash)
'The Forgotten' for example allows in-game selection of race and all non-default races are supported by self written AIs (Though that's much easier in WC3 than in 0ad)
The multi-channel-analyser acquisition system WMCA for nuclear physics (Only some pics due to copyright):
-
1
-
-
Each unit type will focus on its goal only (infantry vs infantry, cavalry vs cavalry, skirmisher for support fire).
Please, don't do that! This will make more units chase each other and less damage will be dealt.
If you insist make it the default behavior but give the player the chance to change this in some kind of player options before the game.
I can only beg you to rethink this.
That is going the wrong way IMO and if you make it to be customized we'll see what players like, what is more efficient, how realistic fights look and how high the 'counter bonus' has to be to compensate.
Don't reduce the players options and order priority even more!
-
I disagree with changing the skirmish units
I think that is what skirmishers are meant for
Inf aren't meant to catch skirms thats the cavs job
Although it would be nice to be able to tweak unit priorities in game such as civilian/inf/cavalry/ranged/buildings
I'd prefer a better unit AI that looks for the closest target every time it gets hit.
-
When unit is aggressive or violent it does make sense.
If the player gave the order to retreat it should have priority anyway IMO.
-
If a player has an unfinished civic center and citizen soldiers he/she could still hypothetically win, or at least make a difference in a team game, so if anything that should be the criteria.
Agreed, just the bold 'and' is not the case ATM.
If a building is finished (like this.isReadyToUse = true/false) is helpful anyway. The possibility to trade with unfinished markets is a related problem.
-
This looks very nice!
The gulfs terrain texture and depth looks a little uniform to me but otherwise very cool!
The resources seam to be well distributed and despite the players next to the gulfs entrance (that's ok) it seams to be a very fair map.
With the shape similar to Mediterranean Cove the game might run into problems with pathfinding. Due to the less rough inner shape it might be less of a problem though.
And, by the way, I like maps with water but no divided land parts.
Well done!
-
Perhaps there should be a feature added that reveals all enemy units and/or structures.
If a player is nearly beaten it is annoying to search the hole map for a lost peasant (or until now an unfinished civil center which should be fixed IMO).
If a player has no (finished) civil center this could happen automatically but perhaps that's not good for more then 2 players left (free for all games for example).
So perhaps something like 'send spys to player [player name]' could be added that reveals the players buildings and/or units for a short period of time for some resources.
In AoE this was permanent and cost depended on the number of enemy peasants. I think still it was overpowered. Just reveal the buildings for a sec would do (independent of the scouted area). Price could depend on the number of civil centers (Like 250*(number of civil centers + 1) food and metal).
When a technology tree is added it could be reached very late.
-
-One, the case where something is unreachable but the AI asks to gather it anyway. In this case, the AI has no way of knowing that, and thus can't react. My best guess at fixing it would be to send to the AI an "unreachable_destination" event that would give the ID of the unit. Then the AI can process it (I dislike having UnitAI do that itself for the AI, as it can be too unpredictable/not react as wanted).
I just want to add that in case of a human player there should be a sound or some other feedback.And just a tweak, if not reachable and the target is an entity the unit should not start to walk towards it (an exception would be an garrison order to a ship for example) but if it's a point it should try to get near it as it is right now but still warn.
-Two, the "lone tree on the map with 50 villagers around" case. This is specific, it happens to qBot and Marilyn when chopping for wood. Sometimes, workers surround the tree, and then a new wave of workers surround the first wave, and so on, until everyone is stuck around the tree. Again, in this case, there is the "short term" solution of having an "unreachable_destination" event, but also a more long term solution which should, imo, be implemented:We need a way for the AI to know what a unit (entity at large) is targeting. This way, we could count how many units are gathering from a tree/attacking a unit. This can only be done efficiently at the unitAI level, because the player AI is fairly "abstract", and acts a lot like a player. Sometimes, units react autonomously because of unitAI, and right now the AI can't know that, so it might get stuck. Therefore, the UnitAI must store the target (I studied that script a bit, I imagine it would be "fairly" easy to do and pass to the AIs).
Sounds good to me
I also suggested an optimization: when setting a unit to a new target, add this unit to a list on the targeted entity, and remove it when it's unassigned from that entity. This would allow to, by checking from a tree, know how many units are gathering it, instead of having to recount every time.Oh, ok, you don't mean the tree should prevent a worker from gathering if too many peasants are working on it but just to make it easy to get the number of units (and their IDs) chopping it. That's ok! Sry, I got that wrong. When the unit AI changes the target by player order it still has to tell the old target that the unit is not targeting it any longer.
The best way IMO for the playerAI to have full control without to many checks would still need the unitAI to send an event like 'targetChanged(ID)' if the gathered resource entity runs out. In combination with target stored in unitAI and assigned gatherers stored in the tree this should work fine.
-
This is quite a different situation, because units are able to move from a passable area into an impassable area but can't get back out, due to a mismatch in the behavior of the long and short range pathfinders. It would be better if they couldn't move into the impassable square to begin with, but also if the pathfinder could be more accurate in determining the gap between the trees. Philip's new pathfinder takes a completely different approach and this is one of the things it should prevent, as described here.
OK, perhaps we are talking about different things here.
In the other post I meant the problem with units trying to chop trees that are so close to the border that they couldn't be reached.
As far as I get it the unitAI (perhaps because of the pathfinder) tells them to chop the nearest tree and that next tree was outside the reachable map area.
However, they didn't stuck there. You could select them and send them to the map center, no problem. The main problem was that the player AI didn't do that (Maybe because there's no way for the playerAI to tell).
That might change with the pathfinder if the unit AI tells to chop the tree because it's told by the pathfinder that it is reachable (I don't know how the unitAI uses the pathfinder
).But you told me you doubt it. (So I assume the unitAi acts not as I think
)In the OP its about 2 units inside a gap each small enough to pass but not at the same time.
This might change with the pathfinder as well because the unit facing the civil center could take another way and might recognize the block.
However, I have seen units blocking each other with no obstacles near just walking left and right to avoid each other in sync
They both used the short range pathfinder I think ^^.
What I meant here is that, if a player/playerAI (mainly qBot) has tons of peasants, many of them might try to chop the same tree.
The first 10 succeed and begin to chop. The next could reach the target before, but now can't because other units surround it.
After the first citizens got full loaded they try to bring the wood back, but they can't because the later units surround them
.That is a very similar matter to the map border issue IMO because the peasants not capable of reaching the tree (in the surrounding issue the outer/later peasants) didn't tell anyone and the playerAI has no chance to know (If I get quantumstate right).
I don't see how this should be resolved by the new pathfinder. Indeed there IS a way at the moment the unitAt tells to seek the next tree but later it's blocked by other peasants.
And Ykkrosh said himself "...assuming no dynamic obstacles (i.e. other units) get in the way...".
So what I mean is just that it isn't a good idea in my opinion to let the tree 'decide' whether a unit can gather from it or not (Like in Empire earth where only 6 or 7 workers could gather from one source). That's unintuitive and unrealistic. However it could be solved in different ways: The unitAI could seek another tree if the unit doesn't move fare since many rounds
or tell 'broke up previously accepted order 
', the pathfinder could cry out 'darn, i can't get through 
' or the playerAI could check how many of their units are chopping the same tree. All assuming the code allowed that of cause.I hope this did lower the chance of misunderstanding... and that the new pathfinding will solve it all
-
Hopefully I am understanding you correctly. Currently the problem is that the AI has no way to tell what the target of a unit is. More code needs to be added to the AI api to connect it with the UnitAI code.
Yes, there has to be a way to find out.
I just wanted to point out that IMO the unit should get some kind of 'getTarget()' function (or just a variable 'target' or 'tagetOfAction' or whatever) that returns (holds) the target object (Like: 'point', 'actor' or 'template' or so) or just information that grants access to the target object (like ["point", [x, z]] or ["entity", ID])
Within the information it returns (holds) has to be a way to find it's location or other information (if point maybe it's just point.x/point.z, if it's a unit maybe there's some way to find out with somewhat like 'map.getEntityById()').
I think this is much more intuitive than adding to the tree something like 'this.unitsGatheringFromMeIds([iD1, ID2, ID3, ...])'.
The unitAI don't need to be involved in my opinion. Though I seldom change my gather positions I never run into problems like 20 peasants chop the same tree and block each other trying to get to the tree to chop it or get to the next deposit. So it seams more like an playerAI problem than an unitAI problem to me. So if the playerID had a way to get this information (which may or may not be possible yet, no idea) would be ok. The playerAI has to be able to get information like that anyway for more improved versions that, for example, avoid chasing enemies half across the map or hunt chicken in an enemy base or try gather from enemy fields or this kinds of issues. Of cause that's a question of taste and priority but this information has to be available for the playerAI anyways. So in my opinion the problem can be solved there.
It would be nice though if the unitAI or the pathfinding routine would avoid this in the first place, of cause. But it seams to be under heavy development already at the moment.
-
I'll help translate to English.
And I'll translate it to assembler so it can be installed with a BIOS update
Oh sry, going OT
-
This approach works to some extent but you get issues when units you assigned to one tree finish gathering and automatically choose a nearby tree to gather from. In this case the AI has no reasonable way of finding out which tree the unit is gathering from.
Why? It can do something like:
For all own units add target to a list.
For all different targets in the list count the occurrence.
If the occurrence is greater than wanted and the own unit can 'gather from' the target unit, pick one of those units and send them doing something else (for example give explicit order to harvest from another tree)
What's wrong with that?
-
Hmm, I think this is an unexpected consequence of Atlas saving things into bogus locations, combined with the uninstaller assuming the cache directory can be safely deleted. (The uninstaller is doing what it should, but we should have a proper location for storing user-created content.)
Oh, I thought where atlas stores it by default IS the 'proper location'
And if it's not I can rename my post as it was called in the beginning:
'Where to put custom scenarios/random map scripts/AI s cripts?'
I found this ticket and tried (in many ways) if that works but it doesn't seam so.
And I can't find the code where it is set up???
Only 2 occurrences of 'scenario' searched 'case sensitive' but not 'whole word only' in the svn rep???
-
What could also help to solve such thing would be to have the game register entities interacting with each other. When clicking on a tree, the "tree" would remember the ID of the unit assigned to it until it's no more, so the AI can know at each time how many units are working on a resource. This could also be useful for attacks.
It sorta can be hacked in by the AIs using metadatas, but it's not nearly as efficient.
Why not have the unit remember the ID of the given order's target?
Would make more sense to me
-
That's actually nearly impossible to prevent given how the AI/UnitAI/Pathfinding is currently implemented. These issues, imo, could be solved by the improved pathfinding Philip is working on, and some sort of "target_unreachable" event for the AIs.
I perfectly agree!
But historic_bruno said to a similar matter: Post
I don't think pathfinding will have any impact on this, the new pathfinder is being designed to behave more or less identically to the old, except more precise and consistent.
-
After I installed the alpha9 the C:\Users\[user name]\AppData\Roaming\0ad\cache folder is empty.
I added a ticket for that. It will frustrate users loosing their work and makes bad publicity.
Edit: Renamed the post tough it's in the wrong place then. Hm, how to move it?
Just to say it, the custom maps are to be placed in:
Scenarios: %appdata%\0ad\cache\mods\public\maps\scenarios
Random map scripts: %appdata%\0ad\cache\mods\public\maps\random
This can be found here. I think it's a little hidden though.
I suspected something like that and gladly saved my work before so no one was harmed here ^^
-
Oh Whoops, Never saw that until now.
This got me thinking, Is there any chance the team might include the .deb package rules? (So SVN builds can be installed with APT). I feel like this could be done in a way that wouldn't hinder/malign packaging for other platforms, and it certainly would be handy for all the Ubuntu/Debian users here, which probably make up a majority of the Linux fan-base.
Yes, I had the same idea. And .dep packaging can be automated quite well. So it doesn't require that much of maintenance. Indeed I think less than helping people in the forum with problems that would have not occurred if a .dep package would have been available. -
hi, i've just dowloaded alpha 9 and found one problem, that you probably already know, about women get stucked
the map is Battle for the Tiber. If you want, i have also the savegame
As you can see, a woman try to reach the Civic Centre, while the other try to reach the field, and they get stucked with two trees
Yes, something like that often leads to piled up AI peasants at a single tree even if its in the middle of free space. AIs shouldn't send more then about 6 units to the same entity to gather there. That makes the game lag and prevents the AI from gathering anything.
-
You reminded me of something very important. I haven't placed non-starting-point berries in any map.
Well, but be careful with food sources that could be mistaken as wood resources.
At least I don't like them.
rmgen library.js changes
in Game Development & Technical Discussion
Posted · Edited by FeXoR
You are right if the coordinated are x (horizontal, right positive) and y (vertical, top positive), but they are x (horizontal, right positive) and z (vertical, top positive).
Since [x, y, z] are circular it's the same as if you'd use [z, x, y] or [y, z, x] (for rotation direction).
So for the plane you could use [x, y], [z, x] or [y, z] and where still right.
But fore some reason [x, z] was chosen, which is not part of any of the 3 possibilities above.
That means we look at the back of one of the planes. That leads to a different direction of rotation.
So indeed the old behavior was mathematically correct. [0, 0, 1] (x=0, z=1) has an angle of 0, [1, 0, 0] (x=1, z=0) has an angle of PI and so on...
It's the same with buildings: Placing it with a given angle of 0 let them face towards positive z, angle of PI face positive x.
In the (strange) chosen coordinate system it's correct.
IMO the best thing would be to choose [x, y] for the plane so that a point on a circle at the angle phi with radius 1 could be get by:
x = cos(phi), y = sin(phi).
But right now it is z = cos(phi), x = sin(phi).
That's at least confusing. Same with the rotation direction. It's clockwise which is unusual for a mathematician. too.
However, I strongly recommend to stay consistent whatever you choose!