Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - silnarm

Pages: 1 ... 51 52 53 54 [55]
1351
General discussion / Re: Ahoy there!
« on: 27 May 2009, 03:32:21 »
... hope to see much more of you in the future!
Count on it :)

Quote from: John.d.h
My mind is already RACING with possibilities for this!  Marines with amphibious landing craft, fish men attacking from the sea, giant sea serpents, ahhhh!  I think my head might explode!
Hmmm... fishmen.. might need another field or two...  In fact, we should nut out what fields we do want... a topic for next week perhaps :)

Quote from: John.d.h
So what does the amphibious field do?  Is that just units that can travel on both land and water, or is it a separate area altogether?
The former, it's the 'combination' of land and water fields.

1352
General discussion / Re: Ahoy there!
« on: 26 May 2009, 22:14:37 »
Quote from: assassin
... I think you should try and make it so that land units can walk in "shallow" water and sea units can travel in both shallow and deep water....

"land" units can still walk in shallow water... but the 'land' field is now the 'walkable' field, and boats can either define "any_water" which obviously gives them the behaviour you suggest, or "deep_water" which only allows them on non-fordable water cells (and there is also an 'amphibious' field).

Quote from: titi
But how to create such water units!?
If you create a water unit on land, what will happen?

Yeah, it's purely movement for the moment, to test it out I modified the technician to morph first into a intermediate unit, that travels in the field 'amphibious', to get out onto the ocean, then that unit morphs into the 'ocean only' version, to test the path finding.

So 'morphing' is the only way to do it at the moment, and trying to morph to a unit that can't move on the current terrain will throw up the "Invalid Position" message.

As I said, plenty of work to be done yet... probably first on the list is making it work without having to change any existing xml! I've, hopefully temporarily, broken xml compatibility to do this.

Quote from: ElimNator
you could have a dock that goes at at the edge of the water and spawns them in the water?

I was thinking a dock/shipyard style building that had to be built partially on land, partially over water. I've already added some things to the code to make this pretty straight forward, the mod maker would then specify which bits had to be on land, and which on water, probably in a manner similar to how cellmaps are done now.

But first I need to clean up the path finder and get that out...  boats are coming though, don't doubt it!


1353
General discussion / Ahoy there!
« on: 26 May 2009, 07:09:04 »

Forgive the crappy screen capture, but you get the idea...

https://www.youtube.com/watch?v=YXLDQOqBW2M



Still lots of work to be done yet, but a good start...

1354
Mods / Re: Texture help
« on: 25 May 2009, 23:11:18 »

It's there...


it's just to small to see...


I had to bump that all the way up to 1 to get the image above...

To avoid exporting everything from the scene, use 'Export Selected...' rather than 'Export...'

Cheers.

1355
General discussion / Re: Fixing PathFinder::aStar()
« on: 23 May 2009, 15:02:13 »
Whilst compiling, I get a whole load of errors  :(  :
...
And that's just the start.. all the patched files don't compile and at the end of compiling the gae binary is nowhere to be seen. I think that the problem is with the .patch file, so perhaps you could just upload the modified files (path_finder.cpp, path_finder.h, unit_type.h, unit_updater.cpp, unit_updater.h, world.cpp).

I'm sure we can eventually get this working   :)
Yikes...
The problem unfortunately is not the patch, it's my 'bad' C++, combined with the fact that I'm using windoze and the ms compiler is happy to let me do several things that are non-standard, gcc is being strict. Been programming in C# for a while, picked up some bad habits :)

Quote
glest_game/ai/path_finder.h:32: error: use of enum ‘Field’ without previous declaration
glest_game/ai/path_finder.h:124: error: ‘Field’ has not been declared
I was simply trying to forward declare this at line 32, so I could use it later (124). I'm very surprised this is not allowed... fixed by deleting offending declaration and including unit_stats_base.h
Quote
glest_game/ai/path_finder.h:74: error: qualifiers can only be specified for objects and functions
glest_game/ai/path_finder.h:79: error: qualifiers can only be specified for objects and functions
glest_game/ai/path_finder.h:97: warning: type qualifiers ignored on function return type
glest_game/ai/path_finder.h:109: error: qualifiers can only be specified for objects and functions
These are all (apparently) extraneous 'const' qualifiers. Fixed by removing 'const' from the declarations of AStarNode, PosTreeNode & NodePool (and the const in front of getMaxNodes() takes care of the warning).

Give it a try if you can be bothered... but there may be other problems. I'll have get a linux installation going, or maybe just use gcc under windoze, or try to cajole VC++ into behaving in a more standard fashion... either way I'll post a working patch soon... sorry for all the problems.

1356
General discussion / Re: Fixing PathFinder::aStar()
« on: 22 May 2009, 22:31:00 »
I get this error:

sorry about that, didn't have my directories set up correctly... first time I've used diff to make a patch :)

http://www.mediafire.com/download.php?mmyz4yytxbd

this one should do the trick, run patch with -p1

1357
General discussion / Re: Fixing PathFinder::aStar()
« on: 20 May 2009, 21:44:17 »
Um, whilst trying to download, mediafire tells me that the file is password protected.

Ok, not sure what that was about, but it should work now...

1358
Mods / Re: New pirate faction.
« on: 20 May 2009, 09:39:03 »
Quote from: softcoder
Currently Glest seems to support only air and land type surfaces, eventually I'll look at what it would take to add water (and other types).
Hi softcoder, if you're not aware, I've been working on the pathfinder recently and I'd love to help make these boats do more than just float in position :) We'll need to figure out more than just the path finding of course, but I believe I can have path finder working for water within days, so it's a good start :)

My first patch (just released) is a diff on the GAE, but if you would like to try it with Glest 3.2.2 I can send you the new pathfinder class files and instructions on what needs changing in the UnitUpdater and World classes (these have both been changed a bit in GAE, I think, so trying to 'drop them in' would be troublesome).

Quote from: softcoder
...Be patient with the models, these guys just started working with Blender a short while ago and are learning about the impact of vertices, etc. They are learning both static and skeletal animations and their skills are getting refined slowly but surely.
Very impressive work so far, for a couple of guys who just started :)
I look forward to seeing these mods mature.

Cheers

1359
General discussion / Re: Fixing PathFinder::aStar()
« on: 20 May 2009, 09:09:20 »
Well, it just gets better...

Turns out one of tricks I was employing, to see if the target position was accessible, was not checking
units, I'd commented out the lines when I copied them from the aStar routine... because it was initially
referencing a variable the new function didn't have, a subtle copy/paste error :)

Anyway, it perform those checks now.. and it's faster still...

http://www.mediafire.com/download.php?dj1gogmzmmm

Anyone who can compile, please try it out, if you can make it crash or you notice any bugs, please let me know...

Edit: Sorry, that's a patch on gae0.2.11, run it from the 'source' directory.


1360
General discussion / Re: Fixing PathFinder::aStar()
« on: 19 May 2009, 12:55:36 »

Ok, didn't get a patch on the weekend obviously, and I still don't have one for you. But it is coming... less than 24 hours... sorry to 'tease', but I wanted to report some more results, and I'm to tired to get a patch ready tonight.

I can't break it anymore (can't crash the game), and I'm happy with the performance, so I'll package it up tomorrow night, and some other people can try to break it. :)

A quick note: it's Faster, not Smarter.

It's essentially the same algorithm as before, I just changed how the tests were performed, how the open & closed lists are implemented, and introduced some preprocessing to try and quickly determine if the target is unreachable. 

That is what was really killing the path finder as it was, A* failing to find a path is the worst case scenario (for processing time), and when many workers are going for the same resources, they often block access to the 'destination position' another worker wants to go back to. That spot might be three tiles away, but because it's "blocked in" the resulting A* search exhausts 400 nodes trying to get to it, fails and picks the 'least heuristic' to go to (often where he is already standing), next update? repeat. This is what was causing 'the' Glest slow down.

I've played a few games through with the new path finder now, and I can report no sudden frame rate drops, and I was getting chronic frame rate drops before.

Here's some numbers from the log of my most recent timing test, 1 human, 3 AIs, a tampered with MagiTech techtree (to accelerate things a bit... I've been doing a lot of testing...), all on teams of their own, Teams 0 and 2 were hooked up to the shiny new annotated A*, teams 1 & 3 used the old A*. The 'average' and 'worst' are measured in 'clock ticks'.

23: Launching game
81:
Vanilla A* : Total Calls: 143, Average: 314, Worst: 23935.
Annotated A* : Total Calls: 129, Average: 86, Worst: 970.
111:
Vanilla A* : Total Calls: 366, Average: 1580, Worst: 43239.
Annotated A* : Total Calls: 341, Average: 76, Worst: 1930.
<snip>
261:
Vanilla A* : Total Calls: 2133, Average: 2290, Worst: 43239.
Annotated A* : Total Calls: 2337, Average: 41, Worst: 5946.
<snip>
411:
Vanilla A* : Total Calls: 3656, Average: 2803, Worst: 52071.
Annotated A* : Total Calls: 4701, Average: 28, Worst: 6039.
<snip>
651:
Vanilla A* : Total Calls: 7324, Average: 5329, Worst: 53211.
Annotated A* : Total Calls: 10736, Average: 18, Worst: 9355.
<snip>
831:
Vanilla A* : Total Calls: 8969, Average: 4044, Worst: 53211.
Annotated A* : Total Calls: 14464, Average: 18, Worst: 9355.

As you might imagine from the average call time, the speed up is rather substantial.

More details, and the all important patch, to follow tomorrow...

Perhaps some time in the distant future different conditions might affect movement or other qualities (like defence). For example if you were walking

knee deep in mud it's going to be slower than walking on hard ground. These things would need to be included in the pathfinding.

Yeah, that would obviously need to be taken into account by the pathfinder, I was thinking of doing influence maps (for better ai players) some point down the line, these too will need to be taken into account by the pathfinder, we can use the same mechanism, I'll make it (down the line) so the  pathfinder can be handed one or more influence maps when asked to calculate a path.

Keeps it nice and 'generic' :)


1361
General discussion / Re: Fixing PathFinder::aStar()
« on: 15 May 2009, 11:59:37 »
If you are working on the pathfinder, it would be nice if you would think about something like ships and water.
This would be a really nice thing to have in glest and I think it will effect the pathfinder too.( or am I wrong here? )

Yep, water craft will not be far away :)

Probably got too technical ... at the expense of being understood!

In the reply to wciow I mentioned that what I've done so far supports 'metric maps' for 8 'fields' or combinations, Glest currently only has two fields, land and air.

I'm trying to keep the pathfinding as generic as possible, so a future version of Glest might (for example) have land, forest, sea, and air fields, and keep metric maps also for the combinations 'land + forest' & 'sea + land'.
So it could then support units that can
1. only move on (open) land (big stuff that you don't want to let through forests)
2. only move in forest, probably don't need this one :)
3. only move on the sea
4. only move in the air
5. move on (open) land or in forest (typical infantry)
or 6. move on the sea or (open) land (amphibious units)

That's just an example of course, the fields and combinations would be set up for the given techtrees needs.

For any given field, the path finder just needs to be told initially which cells are not traversable, and informed when any cells traversability changes... it will handle everything else.

Regarding water... the Path Finder will support it almost out of the box, there are already functions in the Map class to determine if a cell is underwater or not (actualy two, under water and 'deep' underwater)...  But there will be plenty of other issues to deal with, buildings 'hanging out' over the water (docks), loading/unloading land units, rendering issues/decisions and more... So don't expect it to happen quickly, but do expect it to happen :)

1362
Looks like the problems are all with linking to the shared glest lib. You'll need to set up two projects, one for the 'game', containing everything from the namespace 'Glest::Game' and outputting an executable, and one containing everything from the namespace 'Shared' outputting a static library.

Add the shared lib as a dependency the game project.

Viola.... maybe.

Good luck!

1363
Project files:http://glest.codemonger.org/files/glest-vc2008proj.tgz
DEPS:http://glest.codemonger.org/files/win32-glest-deps.rar
3.22 Source:http://sourceforge.net/project/showfiles.php?group_id=127297
...
but,i don't find these files in 3.2.2.
i search with google,i find,these files is one of the project(glestadv-src-0.2.11).
i want know,is't these files drop in the project(3.2.2),or other?

who can tell me?
The project files (and deps) you downloaded are for the Glest Advanced Engine (GAE), not Glest 3.22.

So you can either get the GAE source and work with that or build your own project files for Glest 3.22.


1364
General discussion / Re: Fixing PathFinder::aStar()
« on: 14 May 2009, 06:03:59 »
Quote from: bork
Also, if you want a good speed up you could consider using hierarchical routing algorithms. There
will be difficulties with dynamical changing of nodes traversability, but if you could manage to
overcome them it will make path finding really fast. Although, I have some doubts that path finding is a bottleneck for game performance.
Unless you sort them into a tree as you insert then there's no option but a linear search.
Hmmm... I'm going to claim sleep deprivation...
Obviously it needn't be a tree structure... furthermore.. why is it a linear search?!? we can keep the open list sorted, or at least the 'best bit' of it, the low end.
Well spotted! This is going to provide another nice boost!

1365
General discussion / Re: Fixing PathFinder::aStar()
« on: 13 May 2009, 06:29:04 »
Wow excellent project, the path finding for workers/resources can get pretty bad at times. I'm gonna build some test maps to see how good this new pathfinding is  ;)

Will there be an option for an A* sandbox?

Any chance you could squeeze in an XML switch to make water walkable for some units?

There'll be no Sandbox I'm afraid, I can put some stats in the debug info, and allow you to change the algorithm used in the ini file...
A Sandbox mode for the game would be fantastic, would be very useful for testing, code and mods... and I'd love to make one, but to be realistic I've only just started looking at this beast, and it aint small! Just getting the pathfinder fixed up has led me to many places in the code I thought I wouldn't need to be tinkering, but I've still only scratched the surface... maybe one day... maybe

Water will be a 'Field' in the game soon enough, it will then get its own 'map' of clearance values, as will the combination land + water (for amphibious units). I've currently got the 'Metrics' (the clearance values for each field or combination) stuffed into 32 bits per cell, at 4 bits each (giving a maximum moveable unit size of 15) that's room for 8 fields (and any combos), which I imagine should be enough, but is easily increased anyway.
 

Do the vector growing really slows down algorithm??? Didn't you find out why it was resized so often?
How did you tested performance? As I can see open and closed lists memory never reclaimed until
destruction of PathFinder instance, so they should stop allocating/deallocating after few passes of the algorithm.

The precise re-allocation strategy would depend on the STL you're linking with, but I think you're right, it shouldn't shrink once it hits the node limit for the first time. It was probably the deletions actualy (?) vectors are only good (=fast) for deleting of the end, whereas we might need to delete any element from the open list each iteration.

I timed the calls to aStar(), and made an aStar2() that used a list, set the AI to use the vector based A*, while I got the list based one, timing stats were written to the log.

Quote from: bork
The thing which is really strange to me is why there is linear search inside minHeuristic at all, you
could get some speedup by changing open list to priority_queue (which requires vector or dequeue as backing store anyway).

Also, if you want a good speed up you could consider using hierarchical routing algorithms. There
will be difficulties with dynamical changing of nodes traversability, but if you could manage to
overcome them it will make path finding really fast. Although, I have some doubts that path finding is a bottleneck for game performance.

Unless you sort them into a tree as you insert then there's no option but a linear search.

I intend to implement hierarchical abstraction of the map at some point, that's stage two of the overhaul (and probably wont be a priority)... but clearance annotations will make it significantly faster than it is, and it's a severe problem at the moment for long paths. Though I tend to agree with you that, in general, it's not going to be the bottleneck.


1366
General discussion / Re: Fixing PathFinder::aStar()
« on: 12 May 2009, 03:56:24 »
Ok, quick update on the Annotated A*...

In a nutshell, it works...



There are still some minor issues to fix, and one major one.
I was held up by the inability to see what was going on, for which I required the clearance values to be drawn on the cells. Unfortunately, cells aren't rendered individually... 2 days and number of headaches later, I was able to render cell's individually, and I could start fixing things, but that was only yesterday....

should be a source patch ready by (or on) the weekend...

 

1367
General discussion / Re: Fixing PathFinder::aStar()
« on: 8 May 2009, 23:44:01 »
So, What is up with Glest's Path Finder?
The algorithm seems sound, so let's have a look at the implementation,
 here's the comments from inside the loop,
b1) is open nodes is empty => failed to find the path
b2) get the minimum heuristic node
b3) if minHeuristic is the finalNode, or the path is no more explored
   => path was found
b4) move this node from closedNodes to openNodes

and the inner loop (checking the neighbours),
//if node is not open and canMove then generate another node

Fairly straight forward, except of course b4 is the wrong way around, but the code is correct :) Of note are operations on both the Open and Closed lists and a call to minHeuristic(). In the inner loop (which is actually a loop in a loop in the code) our concern is the logical test in the if statement, containing calls to openPos() and map->aproxCanMove().
So we should have a look at minHeuristic(), openPos() and Map::approxCanMove() to see what they're doing... this is the route I initially took and has proved fruitful, using an Annotated A* we can eliminate the map->approxCanMove () call, which itself calls Map::isAproxFreeCell() at least once, three times if the move is diagonal. isAproxFreeCell() itself make further method calls, depending on certain conditions.
More on Annotated A* in a second... first...

What I didn't consider at first, possibly because it was hidden away in a typdef, was what data structure are we using for the open and closed lists???
The answer was most surprising...
   typedef vector<Node*> Nodes;
An STL Vector!!!
You know, the ones that are essentially arrays, that can dynamically grow as needed, by allocating new memory and copying the old contents to the new (bigger) location!!!  All this going on in the inner loop of the path finder!
<Edit: 20-May-09
As pointed out by Bork, this was not the reason the vector was causing a performance problem, rather it was removing elements from the vector from random positions, not just of the end.
>

This is big. Changing this to a STL list (implemented as a doubly linked list) is how I reduced the worst case processing time to a little over a quarter of what it was. Given the we have a maximum search node limit, I think we should actually just change this to a good old fashioned array, you can't beat a pointer for low overheads!

So that's the first Quick Fix.

Next Up: Annotated A*
I've already started implementing an Annotated A*.  Basically the first part of this article:
http://aigamedev.com/open/article/clearance-based-pathfinding/
The part dealing with 'true metrics'. (great article, I hope to implement the full HAA* in the not to distant future, should make Glest's Path Finder state of the art :) )
The only real issue implementing this, is we need to know when the map changes, specifically when a cell's “walkability” changes.

Here's the situation's I thought of so far, and where we can hook into them in the code:
//   Starting Buildings: in World::placeUnit() or Unit::Unit()
//   Built Buildings: in UnitUpdater::updateBuild () or Unit::Unit()
//   Destroyed Buildings: in Unit::kill() or World::doKill()
//   Building Grew Legs: in Unit::morph() ?
//   Resource/Tree Dissappeared: in SurfaceCell::deleteResource()


So, is that list complete? Does anything else modify cells, or make them walkable/not-walkable ?


1368
General discussion / Fixing PathFinder::aStar()
« on: 8 May 2009, 02:41:15 »
Greetings.
This topic is intended for the (technical) discussion of Glest's pathfinder, and specifically what's wrong with it and how to fix it.
I've been pulling Glest's implementation of the A* algorithm apart over the past few days, so I'll start this off with a very terse description of  “standard” A*, and then have a look at the A* in Glest, and see if anything is amiss...

Edit: 20-May-09
This contains a couple of small errors that I'm too lazy to fix.
Edit: 9-June-09
Ok, I've fixed them... and cleaned up the pseudocode.

Standard A*
For a standard issue A* we need a node structure with 4 pieces of information, the 'distance' to here, the 'heuristic' (estimated distance to destination), a 'vector' that points back to the (currently) best known node to get here from, and of course we need the map co-ordinates.
The other thing we need is a function to calculate the heuristic, we will just use, as Glest does, the 'Euclidean' distance to the destination (using trusty old Pythagoras).
Also, I'm ignoring the extra cost of moving diagonally, to keep things simple (as Glest also does).
With the node structure and heuristic function at hand and two initially empty lists, named Open and Cosed, the standard issue A* algorithm goes as such,

start with startPos and destPos // Our start position and destination position
set startNode.position to startPos
set startNode.heuristic to Euclidean distance from startPos to destPos
set startNode.distance to 0
add startNode to Open List
while Open List is not empty
  select node from Open List with lowest distance + heuristic
  // let's call it minNode
  if minNode is destination
    we found a path! :) (Follow the vectors back to start pos)
  else
    for each adjacent node // let's call it newNode
      if newNode is not on Closed List
        if newNode is on Open List
          if minNode.distance + 1 < newNode.distance
            set newNode.distance to minNode.distance + 1
            set newNode.vector to point at minNode
          else
            do nothing
        else if minNode->newNode is a legit move
          add newNode to Open List  // diag = sqrt(2)?
          set newNode.heuristic to manhatten distance to destination
          set newNode.distance to minNode.distance + 1 // diag = sqrt(2)?
          set newNode.vector to point at minNode
        else
          do nothing
      else
        do nothing
    //end for
    Remove minNode from Open List, add to Closed List
  // end if
//end while
If we get here, Open List is empty, Failure :( 

So, basically in each loop iteration we pick the 'best' node from the open list, this is the node with the smallest distance + heuristic. If this best node is the destination, we have found our path. Otherwise, we look at each of this nodes neighbours in turn, ignoring any on the closed list, possibly updating them if they're on the open list, and adding them to the open list otherwise.

Glest's A*
Glest's node structure looks somewhat different, the 'distance' to here is not stored, and as well as the vector pointing back (indicating the best known path to here) there is a 'forward' pointing vector. This forward pointing vector is only 'filled in' once the path has been found though, so it has been omitted from this description.
Glest's nodes also have a CellExplored member which I'm ignoring here, and the path finder has a node limit built in, which again, I'm ignoring... this is the 'bare bones' of the algorithm.

start with startPos and destPos // Our start position and destination position
set startNode.position to startPos
set startNode.heuristic to Euclidean distance from startPos to destPos
add startNode to Open List
while Open List is not empty
  select node from Open List with lowest heuristic
  // let's call it minNode
  if minNode is destination
    we found a path! :) (Follow the vectors back to start pos)
  else
    foreach adjacent node // newNode
      if newNode is not on Open or Closed List
      and minNode->newNode is a legit move
        add newNode to Open List  // diag = sqrt(2)?
        set newNode.heuristic to Euclidean distance to destination
        set newNode.previous to point at minNode
      else
        do nothing
    // end for
    Remove node from Open List, add to Closed List
  //end if
//end while
If we get here, Open List is empty, Failure :( 

As can been seen, it's a bit simpler than standard A*. With no 'distance to here' the best node at each step is simply the one with the lowest heuristic. Glest's version also doesn't consider nodes already on the open list, the standard version checks to see if the path to the (open) node is better through the current (best) node, and updates it if so. So Glest's A* may not find the optimal path, but it should execute much quicker.

OK, I think that should just about be enough for anyone to take in at once :)
I've made some further discoveries and tinkered a bit, and with a very simple optimisation I've managed to reduce the 'worst case' calculation time for a path to about a quarter of what it was.
I'll need to get 'clean' copy of numerous source files to make a patch, but I believe I can improve performance further with some not to drastic changes, so I'll try that out first.
For the moment, I need to take pause, and gather my thoughts :)
more soon...

1369
I wasn't enough clear i guess.
In our game, units move alone, and the player can only influence them by modifying the environnement. (For example, create a river, etc.)
Then, that's why this question is that important. We would need our code to modify units pathfinding everytime something is modified on the field.

So the question here was to know if Glest's engine would support it easily, or probably crash because it's too much to ask :P

Glest recalculates paths whenever necessary, if the original path was into unexplored territory and the unit encounters an impassable object the old path is thrown out and a new one calculated. If another unit gets in the way, a new path is calculated, whether this be another moveable unit or a building that wasn't there when the original path was calculated.

I just ran a quick game and collected some stats,
     4162 A* Calls, 879 of them recalculations.

Glest's Path Finder is not very quick, and it's absolutely terrible for long paths. The path finding in Glest at the moment is in need of an overhaul... hopefully it will get one soon :)

As to your needs, it will depend on your map size and typical path lengths, and how intelligent you want it to be... the Glest pathfinder can be 'hobbled' via PathFinder::pathFindNodesMax to make performance a non-issue, but it gets a bit 'dumber' because it's just doing a long path in segments, and it's not actually all that smart to start with :)


1370
General discussion / Re: Glest Advanced Engine
« on: 5 May 2009, 04:31:51 »
verarticus,
This problem is unrelated to the bugs modman pointed out.  I actually took a quick stab at fixing this and broke the red circles on other things so I backed out the change.  This is annoying because any time any unit issues a command with another unit as a target, a red circle appears, and it should only do that for orders that YOU issue yourself and not even for "auto-commands" (auto-repair, auto-attack, etc.)

This was irritating me somewhat, so I spent the weekend trying to make some sense out of the code...
Something I haven't done for a while, so much easier these days... how did we ever get by without "find all references" ?
Anyway, back to the point, the Flashing red circles...

Fixed.
Open up command.cpp, at around about line 70 (sorry, I've edited a bunch of stuff... but it should be about there somewhere)
find
if(unit && !isAuto())
and replace it with
if ( unit && !isAuto() && !unit->getFaction()->getCpuControl() )

This fixes the problem for the AI's buildings, but it might still happen on network games ? I haven't looked at any of the network code yet (and I didn't want to for a while yet, if ever!) but ideally this might actually be,

if ( unit && !isAuto() && !unit->getFaction()->getCpuControl()
&& !unit->getFaction()->getNetworkControl() )


Of course, someone would first need to add getNetworkControl() to Faction.

The reason you lag before a big attack is the path finder <img src="{SMILIES_PATH}/icon_sad.gif" alt=":(" title="Sad" /> that's on the list to be fixed.  When a lot of units are moving, they are all using the path finder and it's inefficient.
I'm not sure if I'm having the same problem, but I get a slow down usually after 5-10 minutes, sometimes it comes good again, only to slip back latter, and other times it just comes and stays :(
My initial investigations have left me stumped so far, but I can say it does not appear to be the pathfinder... will keep investigating and let you know what I find.

1371
General discussion / Re: Coders HERE!!
« on: 5 May 2009, 04:07:06 »

Hi all, I had intended to make models and mods when I joined up here, but I couldn't resist delving into the code, so I'll introduce myself here,

C++ Advanced, but rusty! I just dug out my reference, published 1997 :)

you guys still looking for (graphics) coders?
...

Hi Tasche, with that set of skills I'm positive your help would be most appreciated, although Glest doesn't do any per pixel shading.  If you think you'll have the time, between your job and doing a masters, and you're serious about helping out, then by all means download the source and start getting familiar with it.

1372
Mods / Re: Goblin Faction for Magitech and GAE.
« on: 5 May 2009, 03:52:54 »
Hi guys,

 Just wanted to say those goblins do indeed look good.  I drew myself some reference pics to redo the head, I wont inflict my horrible drawings on you, but they are based on the pictures from the wiki,

Code: [Select]
[url=http://runescape.wikia.com/wiki/File:Goblin_artwork.png]http://runescape.wikia.com/wiki/File:Goblin_artwork.png[/url]
I had planned to remodel it on the weekend, but I got carried away looking at source code...
Will get it done this week some time, I'll just put the new head on the old body, I can give him the hunchback effect once he's rigged easily enough, will post some pics soon.


1373
Mods / Re: Goblin Faction for Magitech and GAE.
« on: 28 April 2009, 03:11:36 »
Greetings one and all.

 I'm new here, having stumbled upon Glest while searching for a Free game to make models for, as an old fan of the RTS genre, I was quite amazed at how good it was, and that I hadn't heard of it before!

 Anyway, gAMeboy, I'd be quite interested in helping out here, as I too would like to see hoards of goblins in Glest, and if you've got some pansy Elves about for 'em to smash, all the better  :)

 Hadn't given too much thought to the tech tree myself, your ideas here so far look good, I've got a first hack at a goblin, texture still needs a bit of work, and it's not rigged yet, but it's coming along. We probably need some ideas/concepts for the buildings, I'm guessing it makes sense to get them done first??




Pages: 1 ... 51 52 53 54 [55]
anything