luziferius
-
Posts
64 -
Joined
-
Last visited
-
Days Won
1
Posts posted by luziferius
-
-
you should attach the logs(as stated in your quote)
you can find them that way: http://trac.wildfiregames.com/wiki/GameDataPaths
afaik those logs are overwritten each game start, so you should save them directly after you run into a crash
about the missing textures: you have an Intel GPU, those have pretty bad linux drivers…
-
because of the perspective the complete map shots are elliptic, using square images would add much black space that doesn’t contain any information other than "it’s black"
when designed images are used, it would be ok
-
yeah, it reminds me of that Unigine tropics benchmark, really nice
when do we get that into main/trunk? A11 or more likely A12?
-
Hooray double post. Found another bug, submitted as ticket 1531. Currently, it is impossible to replace wall towers once they are destroyed without first destroying all connecting wall segments.
when you place a wall tower, it snaps to nearby wall towers. you may try to implement that it also snaps to nearby loose wall ends, that would solve the problem
-
Graphics Card : ATI Mobility Radeon HD 3470
you have an ATI GPU in your notebook…
It shouldn’t brick your system, when you use the newest stock driver package from AMD/ATI http://amd.com
(I had no problem doing that, but you use Windows, so it may or may not work)
-
just put it into the upper left corner and fill the rest with transparency(or whatever).
when using a compressing image format it (almost) won’t use any more disk space
-
you may consider to implement something like the autobuild system in xonotic.
http://forums.xonotic.org/showthread.php?tid=1863
the whole thing works like this:
the server does a svn/git update, compiles the game and puts everything together as a package
the client uses rsync to resolve the differences between his and the newer server version.
using that the client is always up-to-date but uses minimal bandwidth to achieve it
-
I think the simplest way doing it is(programming wise):
- pathfinder always sees gates as open(units would stuck in front of gates) and
- not doing any automation; only let the player open/close gates
(but that somehow shifts problems into the AIs, since then they must know how to use gates)
- pathfinder always sees gates as open(units would stuck in front of gates) and
-
about the problem with the pathfinder and closed gates blocking own units:
you would need a player-dependant obstruction map for player-dependant pathfinding
own gates are always passable for own units(unless gate is locked, so units would walk through gates as the pathfinder finds a path through it) and only passable for enemies when it is in 'open' state(maybe even when in LOS too, but thats LOS dependant pathfinding, probably a bad idea)
What would be the advantage of "opening" gates if your own units can pass them anyway? Pathfinding is already hard to do, so I don't think complicating it further would be wise.
that wasn’t about really opening the gates, but a trick(a hack?) to get the pathfinder working with dynamicaly opening gates:
when the door is closed, it blocks tiles->the pathfinder sees blocked tiles->doesn‘t find a way through the door(since it is closed atm of the pathfinder query); you see the problem!?
so your(as a player) pathfinder should see the gates as always open(until force-close or something is triggered) to allow routing through them.
in reality the gate is opened when the units arrive and closed when they go away, and only in this timeframe the door is really open(so enemies could pass)
but the enemy shouldn’t see your gates that way, because if the enemy pathfinder would, you would almost always stuck your units at enemy gates(and vice-versa)
-
This was mainly discussed on irc. You can take a look at http://irclogs.wildf...et-#0ad-dev.log . That is the main discussion I found with a quick search but there are quite a lot of other mentions.
thanks for pointing to the irc log
your link seems to be broken for me, i‘ve digged a bit, the working one (for me) is here: http://irclogs.wildf...-%230ad-dev.log
for anyone interested: i’ve searched through that log and here’s some sort of summary:
21:02 < Mythos> For gates, do we want them to act like AOK or AOM?
21:03 < quantumstate> I would say AoM
21:03 < Mythos> Okay, maybe we should be more specific.
21:03 < quantumstate> since then you remove the concept5 of opening and closing gates except for graphical purposes
21:04 < quantumstate> in AoM gates are permanently open for allies and permanently closed for enemies
21:04 < Mythos> Gate construction: (original 0 A.D. concept) Auto-placed when wall is built? or: Select long wall segment, click button, gate is placed? or: Select "gate" from worker UI and place it on the wall segment (AOK)?
21:05 <@Philip`> How would it know where to auto-place a gate?
21:05 <@Brian1> I think gates should be placed like in AoE3, but act like AoK
21:05 < quantumstate> auto placement sounds annoying, trying to get a computer do do the sensible thing is a bad move
21:05 < Mythos> Philip`: I assume it would alternate between 2 long wall segments and the gate segment.
21:06 <@Philip`> That sounds likely to annoy players when it auto-picks a stupid place
21:06 < Mythos> That was the original idea. Of course, we've ignored a lot of the original concepts over the years.
21:06 < quantumstate> Brian1: why do you say AoK style?
21:07 <@Brian1> So you can lock your allies out if they try to steal all your gold.
21:07 < Mythos> Alright, so, select a long wall segment, click the button in the UI to place gate. Does it place a fully-formed gate magically (AOM-AOE3), or does it lay down a gate foundation and we task units to build it (AOK)?
21:08 <@Brian1> Ideally, you'd just click on an acceptably long wall segment rather than the UI panel, but that may be too hard to implement.
21:08 <@Philip`> Selecting a wall segment then clicking an 'upgrade' button sounds to me like it should be easier for players than using the worker UI, since there's fewer steps and fewer opportunities to get confused, and it reduces clutter in the worker UI
21:08 < quantumstate> Brian1: That doesn't sound compelling to me, and AoM style is simpler to implement
21:09 < Mythos> Philip`: Agreed. But does it just swap out the wall segment for a fully-built gate, or does is swap the wall segment with a gate foundation, that then requires construction?
21:10 <@Brian1> Well, AoE3 gates would often left enemies in when my units went out to fight them. Changing the stances on all my units to prevent that is a lot more trouble than just locking the gate.
21:10 < quantumstate> I say directly switch to a gate
21:10 < Mythos> Let's stick to one problem at a time. We're at gate construction now.
21:10 < Pureon> I agree, swap out for a fully built gate
21:10 <@Brian1> Yes, switch directly
21:11 <@Brian1> Maybe for a small cost
21:11 < Mythos> Alright. Long Wall segment gets swapped directly for fully-built gate.
21:11 < Pureon> Small cost is good
21:11 < Mythos> For a cost, definitely.
21:11 < quantumstate> Brian1: AoM isn't like AoE3, enemies can never go through a gate
21:11 < Mythos> Alright, so now, how will a gate work?
21:11 <@Brian1> Well, only part of the long segment, not the entire segment.
21:12 < Pureon> Enemies should be able to walk through a gate if its open
21:12 < Mythos> Brian: A gate segment will be the same length as a Long Wall segment, for ease of swap.
21:12 < Mythos> Right. In AOM enemies can never walk through a gate, even when it's "open." Looked dumb to me.
21:12 <@Brian1> (Although I still prefer AoK style gates, I could probably live with AoM style)
21:13 < Mythos> Plus, I liked in AOK how you could rush your army through the enemy's gate.
21:13 < Pureon> Yeah me too
21:13 <@Brian1> Yeah, or lure them in... then have a trap...
21:13 <@Philip`> For pathfinding simplicity, I think it helps if passability is the same for every player
21:13 < Mythos> Alright, Philip just decided it for us.
21:14 < Mythos> But, a gate should not auto-open for enemy units.
21:14 < quantumstate> because a closed but unlocked gate is passible to the owner but impassible to enemies
21:15 <@Philip`> If you tell a unit to walk from one side of enemy's wall to the other, and there's a closed gate in the middle, what should the unit do?
21:15 < quantumstate> walk round the wall
21:15 < quantumstate> if there is a way round
21:15 < Pureon> It opens automatically for owner, but passability is the same for all
21:16 < quantumstate> Pureon: yes, but for path planning we can't treat it that way, otherwise your units would never walk through a gate since it would be impassible when they started moving
21:16 <@Philip`> quantumstate: If so, that's a bit annoying
21:16 < Mythos> Now you can see why AOM's gates are the way they were.
21:16 < Mythos> Even if they looked dumb
21:16 < quantumstate> Philip`: it is inevitable
21:17 < quantumstate> gates are fundamentally player dependent
21:17 <@Philip`> Mythos: AoM sounds like it has the same difficulty, since passability is still player-dependent
21:17 < quantumstate> Philip`: yes, it is simpler by virtue of not being time dependent
21:18 < Mythos> Philip`: in AOM, the enemy pathfinding treated your gate like any other wall segment.
21:18 < quantumstate> Philip`: so units will take fewer stupid paths
21:18 < Pureon> It's almost the same as a wall piece being destroyed and then rebuilt - how does passability work there?
21:19 < quantumstate> Philip`: How does your pathfinding deal with dynamic changes while walking?
21:23 <@Philip`> quantumstate: It doesn't - the unit will just crash into any new obstruction and then stop and compute a new path
21:23 < quantumstate> Philip`: That sounds reasonable
21:24 < quantumstate> Philip`: since it will be fairly rare
21:24 <@Philip`> Pureon: Changes over time are not a problem - it'll just recompute whatever internal data structures it needs
21:25 <@Philip`> My only concern is that I don't want to have to duplicate all the internal data structures for every player (since passability will be slightly different for every player) and use 8x as much memory, so the pathfinder will need to be made less dumb
21:26 <@Brian1> (So walls with all the necessary features is about a week-long task, or possible double that?)
21:26 < quantumstate> Philip`: you can just change the accessibility of the gate regiosn if that is fast enough
21:27 <@Philip`> quantumstate: That may be possible, depending on how long it takes to do those updates
21:27 < Pureon> I don't think it matters if the attacking force walks up to the gate to find it locked - it either finds another route or begins to attack the gate
21:28 < Pureon> gates will have less hp than walls right?
21:28 < quantumstate> I don't know if it would be possible to group a certain players pathfinding together
21:28 < Mythos> We could make gates one of the few infantry-attackable buildings.
21:28 < Mythos> (since you wouldn't "capture" a gate the same way you capture a house)
21:29 <@Brian1> Hmm, I'd say not, but it's not a big deal, to me either way.
21:29 < quantumstate> Mythos: I would say you would be more likely to try and capture a gate than a house
21:29 < Mythos> quantumstate: Right, but you would need to get *through* the gate first.
21:30 <@Brian1> I kind of think I'd rather force enemies to use battering rams, etc. rather than worry about my gates being captured.
21:30 < quantumstate> yes, in real life people tend to climb and stuff like that
21:30 < Pureon> I wouldn't like walls or gates capturable
21:30 < Mythos> right, I don't think defensive structures should be capturable anyway. They'd need to be destroyed.
21:31 < Mythos> I was just saying, we could allow non-siege units to attack gates. lol
21:31 < quantumstate> yes, that sounds reasonable
21:31 < Mythos> Where with a Barracks or House or something, they would try to capture it instead.
21:31 < Pureon> Yes, that works
21:32 < Mythos> A wall segment or turret? No, you need a siege weapon.
21:32 <@Philip`> Attackability would only help the pathfinding difficulties if enemy units never attempted to walk more than perhaps half a screen width to get around a gate, and always just walked up to the gate and attacked it instead
21:33 <@Brian1> That would preclude automatically generating gates as that would essentially allow enemies to attack any wall segment. Not that I like automatically generating gates anyway.
21:33 <@Brian1> By "enemies," I meant non-siege.
21:34 < quantumstate> Philip`: I think units should walk around where possible
21:35 <@Brian1> (You know what, It might be good to implement walls before finishing the pathfinder. (Hey, I have to try.
)23:13 < historicbruno> (reading the logs) about gates, I like how AoK gates worked, I would say the best (not the easiest) way of handling gate pathfinding, is enemies should walk up to the gate nearest the point inside the enclosed town they want to enter (of course if it's not perfectly enclosed they can just go around)
about the problem with the pathfinder and closed gates blocking own units:
you would need a player-dependant obstruction map for player-dependant pathfinding(I don’t know hard to implement that would be)[multitheading idea: 1 pathfinder per player with it’s own obstruction map]
own gates are always passable for own units(unless gate is locked, so units would walk through gates as the pathfinder finds a path through it) and only passable for enemies when it is in 'open' state(maybe even when in LOS too, but thats LOS dependant pathfinding, probably a bad idea)
-
I think there would still be an issue with maneuverability in the minimal space on the wall.
only when units obstruct each other, when they can go through each other it might not be a problem
-
Hi there,
I‘ve searched a bit(Forum, Trac), but didn‘t find much about how the wall gates should work(high level).
only found the ticket #1385
Since there doesn’t seem to be any implementation currently, I think it is the right time to think about how those gates should work on a high-level base.
There are many possibilities how they could work/what features should be there(UI buttons to control behavior and such things)
I‘ve collected some points(the list below), that might be considered when implementing the gates.
Maybe the devs could rule out some of them that are impossible/very hard to implement,
for the others I would like to initiate some sort of discussion to get the best out of this planned feature.
- should open gates magically block enemy units?The open gate could just operate like the farms do where allied and enemy units could just walk right through. This seems more sensible to me then AoE/M's way of having an open gate still block out enemies as if they were vampires or something.
- UI controls: force close/force open
- should your gates auto-open/close when own units are near? maybe only when those are following a path through it
afaik in TA:Kingdoms you needed to open/close the gates by yourself, when you forgot to close them the enemy could easily invade... - only operational when a unit is garrisoned in it?(I wouldn’t like that, someone might find it to be more realistic)
- what should happen when your and enemy units are near? should the gate let your units out to fight the enemy or should it keep closed to not let the enemy in?
maybe 2 "stances":
permissive: it opens when your units are near even when enemy units could pass the gate, maybe default
strict: stay closed when enemy is in LOS,don‘t allow your fighting units to retreat into your territory, maybe overwrites force-open - UI controls: fine-tune what can pass the gate, "diplomacy stances"(that would include point 2):
block nothing:let everything through(basically as if the gate doesn‘t exist, force-open)
block enemy:(well, you know...)
block neutral:blocks enemy and neutral units like animals and neutral players when diplomacy is designed to allow neutral players, maybe default stance
block allies:only let your units through(prevent the allied AI from raiding your resources if you want to do such things)
block everything: force-close - how long should it take to open/close the gate
those gates from around 0ad aren’t instant-on/off-energy-shields… they need some time to open or close, but maybe not 30minutes(definitely not) - a global button/menu, apply the settings of the currently selected one on all gates
- when(if) pathfinding based on LOS is implemented, should enemy gates be treated as closed even when they were open the last time seen(since they wouldn’t open for you normally)
- to be continued…
- should open gates magically block enemy units?
-
[spider Base]
- build houses/towers in a row to enlarge the territory and reach resources/choke points
- (more or less)cheap base expansion, save the cost of civil centres for not-so-far resources
- risky in 0ad, since destroying the arm base cuts of the territory and damages every building in the arm
- using towers gives nice defense against enemy infantry(even more with double fire rate tech)
quick atlas pic:
[Resource-Guard]
- send some archers/(or whatever) in stand-ground stance to every metal/stone mine found
- very effective against a not-so-intelligent AI that uses only females to gather from those out-of-base resources
- EDIT: well, thats more or less defensive guerrilla...
- build houses/towers in a row to enlarge the territory and reach resources/choke points
Previewing a map in the game setup screen.
in Game Development & Technical Discussion
Posted · Edited by luziferius
edit:
do you want the game to auto-generate the pics or manually do them and link them in the XML?