Messages

1326

Linux and other ports / Re: Glest wont open!

« on: 6 June 2009, 01:33:52 »

im running Ubuntu 32 bit version.  I have all the files installed but when i choose to run the "glest" file it does nothing. I tried to run it in a terminal and it wont open the terminal either.  Help anyone?

Does trying to run it from the terminal give any message? or just dump you back at the command prompt?

Have a look in "glest.log" and if that doesn't help you, post the contents here.

1327

General discussion / Re: Fixing PathFinder::aStar()

« on: 5 June 2009, 04:35:55 »

Apologies, the debug textures were set up to show the forward and backward paths, which would have only been happening when start and destination were at least 15 cells apart.

I've changed it to show the end path...

The weird behaviour when pathing to the south or east edges of the map remains, I'll try to sort that one out on the weekend, pathing to the west or north edge was seg faulting, that one's been fixed.

Edit: ...and I've changed the game project file to link with zdll.lib, rather than zlib.lib

Edit2: south and east edge bug found and squashed...  looks like I might be able to start looking at the whole shipyard/dock thing on the weekend

1328

General discussion / Re: Running GAE (and four_path_magitech) from SVN

« on: 5 June 2009, 00:06:29 »

I have but the issue is still there. Only reference I found and modified in libglest is in C/C++ -> General where I have one ../deps/include.

alright, just remove the reference to glprocs.c from libglest, then right-click libglest and go Add->Existing Item and then navigate your way to your copy of glprocs.c

1329

General discussion / Re: Running GAE (and four_path_magitech) from SVN

« on: 4 June 2009, 23:44:42 »

... all are ../deps/ in the project properties.

For the game project perhaps, but clearly not for libglest

Do everything you did to the 'game' project to the 'libglest' project.

1330

General discussion / Re: Running GAE (and four_path_magitech) from SVN

« on: 4 June 2009, 23:05:54 »

I got zlib and placed it in the include folder. It now compiles for much longer (2 minutes or so) but still fails with the error "LINK : fatal error LNK1104: cannot open file 'libglest.lib'". That file doesn't seem to exist anywhere though...

'libglest' needs to be built first... but VC++ should be doing that... do a clean then rebuild, libglest should compile first, all the messages relating to that project while have '1>'  before them, if this does not successfully compile, you'll get no libglest and the game obviously wont be able to link to it.

Update - If I try compiling again right after this, it seems to behave differently. It now fails after 1 second with the message "c1 : fatal error C1083: Cannot open source file: '..\..\..\deps\src\glprocs.c': No such file or directory".

hmm... this is because you've put the deps somewhere else, and there is still a reference somewhere to the 'expected' location, you need to locate any remaining references to ..\..\..\deps and change them to ..\deps

1331

General discussion / Re: Running GAE (and four_path_magitech) from SVN

« on: 4 June 2009, 22:06:42 »

Code: [Select]

1>------ Build started: Project: libglest, Configuration: Debug Win32 ------
1>d:\glest\glest_advanced_svn\trunk\source\shared_lib\include\pch.h(97) : fatal error C1083: Cannot open include file: 'zlib.h': No such file or directory

2>d:\glest\glest_advanced_svn\trunk\source\glest_game\pch.h(95) : fatal error C1083: Cannot open include file: 'zlib.h': No such file or directory


Crystal clear, you need zlib...

If you have it already, make sure the header is accessible, deps/include would be the obvious place, put the lib file in deps/lib.
You don't need any of the sub-directories of 'deps/include' on the include path.

1332

General discussion / Re: Fixing PathFinder::aStar()

« on: 4 June 2009, 11:03:06 »

The only problem I found was when moving a unit to the corner it goes in the opposite direction.

I had some issues with units heading off in the wrong direction a few times, thought I'd cleared that all up, but obviously not

Could you provide instructions for compiling with the path textures?

There are some defines at the top of pathfinder.h for timing and logging various things, but most of them aren't hooked up anymore, only PATHFINDER_TIMING still works now.  For the map metrics and paths you need PATHFINDER_DEBUG_TEXTURES, I couldn't find a good spot to put this in a header, as it's needed in various places that otherwise have nothing to do with each other (ie, primarily the PathFinder and the Renderer), so it's easiest to define it on the command line. You will of course also need,
http://www.mediafire.com/download.php?z242om2eunt
plonk them in data/core/misc_textures [I guess these should actually be in the repository...]

I think the code style should be more like the other Glest code but since we have no coding standard in place this is up for discussion.

I suppose it makes sense to have the code look alike, although it is nice to be able to tell who wrote what just by looking at the code. Daniel's code certainly looks similar to Martino's, but you can tell Daniel is little (only a little) more liberal with his use of whitespace... If you've looked at my code you'll be aware I'm a big fan of the space bar.
I'm not to fussed about it myself, I can set VC++ up to reformat all my code before I commit if you like, but I can't write code like that Fairly set in my ways when it comes to brace positioning and such.

What do you think of using an online code review tool?

Certainly a good idea, but do we have the numbers to make it work?

1333

Off topic / Re: Off Topic - Main

« on: 3 June 2009, 13:50:06 »

Also, looking at the second pic, if you observe where the sun is shining from, where the sword is relative to archmage, and the colour of his t-shirt... well, it all kinda makes sense doesn't it... swords are shiny after all, and shiny things reflect light, colours and all

1334

General discussion / Re: Running GAE (and four_path_magitech) from SVN

« on: 3 June 2009, 11:14:14 »

Is there any estimation as to when a new SVN will be up and the engine will be developed again?

The sourceforge SVN is up to date, development is continuing, there'll be some shiny new code in a branch called 'pathfinding' in an hour or two...

I'm still new here myself, and also hope Daniel is ok... and comes back.

1335

General discussion / Re: Character Modeling Tut for Noob Modelers

« on: 3 June 2009, 11:00:50 »

Ahh... some one else discovered Ben Mathis!

That guy's videos are awesome, not really tutorials as such, but if you want to see a pro in action and you've got bandwidth to burn, his video series on 'Delilah' is outstanding... I think the playback is at 15 times real speed (or something like that).  Very educational, very good viewing, very highly recommended.

1336

General discussion / Re: Fixing PathFinder::aStar()

« on: 2 June 2009, 05:41:38 »

Regarding the slow down, I've done some more testing and I have it nailed down now, OpenGL is blocking on SwapBuffers()

This latest misinformation brought to you by my passing 64 bit integers to sprintf().  The numbers I was looking at for swapBuffers() were infact the numbers for render3d().  But render2d() also blows up at the same time, everything will be running smoothly, then the renderer will choke, sort itself out, repeat...
bah... I'm giving up on this for now, I'll never get anything done if I keep chasing this thing.

Better Paths, Dirt Cheap!

So, back to the pathfinder, I'm happy that it goes suitably fast now, so I thought I'd look at trying to improve the path quality a bit.  Glest's A* algorithm (which isn't very A* like) returns bad paths primarily because it tries to shoot straight at the target, and if something gets in the way, it just edges it's way around, whereas proper A* will be consider many many more positions, and can hence realise there's a better way around the obstacle. Full blown A* is out of the question though, for too 'expensive'.

I've been reading 'Near Optimal Hierarchical Path-Finding' [Adi Botea et al] in preparation for phase 2 of the overhaul, while that's not happening just yet, I did notice that they (optionally) 'smooth' their paths, to improve quality, by replacing sub-optimal path pieces with straight lines. Sounded good to me, and it would fix up most of our dodgy paths.  Unfortunately they only really dedicated a paragraph to explaining this in the paper, so I downloaded the source and had peek... Yuck. I thought they might have come up with cool and efficient means to do this, but I'm now guessing rather it was an 'afterthought' and tacked on.

Then I thought, this thing is pretty fast... why not run it twice for each search ?

Shown below is on such search, the yellow cells are those on the path from the start to the destination, the red ones are the path from the destination to the start, yellow and red ones are on both paths.


So, run it once each way, where they diverge start counting how long each segment is, and pick the better one to 'stitch in' to our final 'solution' path, voila, quality paths...


I haven't timed it much yet, but calculating a path from one corner of "Conflict" (64x64 map, [that's 128x128 cells though]) to the other took just over 2ms on my 'first go', the return journey was almost bang on 3ms [on a 2GHz AMD Turion64x2, release build]. So it's still quick enough for our purposes I think.

I'm calling Phase One complete. (barring bugfixes, of course)...
It'll be on the SVN tomorrow probably, just need to make sure it all compiles under linux.

1337

General discussion / Re: Ahoy there!

« on: 1 June 2009, 02:59:04 »

My concern (minor) is that the fields will hardly be used.  There are not a lot of things for all three fields.

For the underwater field, will you be able to see the units there, because otherwise it will be downright confusing!

I just want to keep it as flexible as possible, who knows how the engine might be used in the future...

And yes, seeing underwater units would be an issue that would need to be dealt with, but the sub-surface zone doesn't exist yet... let's just get stuff floating on the water first

1338

General discussion / Re: Ahoy there!

« on: 1 June 2009, 02:04:27 »

Some ideas like a unit moving from the aquatic field to the land will not work.  So no alligators, for instance.

Amphibious field?

And if/when we add the sub-surface zone, we can have an underwater field, and combine it with other fields as we see fit, so John's fishmen coming out the a sea could be a reality...

'switching' fields is no problem.

1339

Mods / Re: New unit ideas for Magitech

« on: 1 June 2009, 01:53:39 »

Nice bump, I hadn't noticed this thread

When I first discovered Glest I was toying with the idea of a kind of summoner faction, I decided in the end it would be too much like magic, and while I hope I can still contribute a few models here and there, It doesn't look like I'll be making any entire mods of my own soon

One idea I had that might be useful to you as a 'training building' for some of these creatures  (maybe the bigger stuff?) is a summoning ring (or sphere, perhaps), summoners could summon 'small stuff' like they do now, but bigger creatures would have to be summoned at the  ring. Of course, I was envisaging creatures of a more 'fantastic' nature for this, I not so sure it makes sense to 'summon' and Minotaur for example.

1340

General discussion / Re: Ahoy there!

« on: 1 June 2009, 01:04:27 »

I'm not too keen on the idea of a maximum slope per se, since somebody might want to make a unit that can climb (think Colonel Burton from C&C:Generals) or step over cliffs (like the Protoss Colossus from SC2), so I was thinking those unit would just be defined for the unwalkable field.  Maybe there would be a way to define whether or not a unit was affected by maximum slope?  Then I think that would work just fine.

How about have maximum slope defined on a per unit basis? We'll set some reasonable default, so if a unit's xml doesn't specify it'll get the default value, otherwise it could do something like:
<max-slope value="0.75" />
Which would only let that unit type 'climb' slopes up to a gradient of three quarters.

Edit: Today, I came up with another idea.  Instead of having a bunch of water fields, could we define units as being able to traverse certain heights, dependent on the water level of the map?  For example, if h is the water height of the map, a unit might be able to go anywhere between h-2 and h-4 (shallow water), while another might be able to go anywhere above h-1 (I think this is the way land units behave already).

I didn't like this at first thought, as I thought it would complicate the pathfinding horribly, but then I thought, we can just store the depth of a water cell in with the metrics and use it in the same way (it currently tells us how much 'space' is around a cell, do determine quickly if a unit of a given size can occupy the cell).  We'll still need a water field, but we can now get by with one.

Then there would be a variable for travel type, where a unit would be either walking, floating, or flying.  Walking units would always stay on the ground (if its underwater, it would walk along the bottom like a lobster), floating units would stay at h when on the water and stay at ground level when on land, and flying units would always stay in the air.  This way, water might not have to be a field at all.

The rest sounds 'kinda-sorta' like what I've done already
What was "Field" has effectively been replaced by two types,
Zone: This is the 'zone' the unit occupies, current 'attack-fields' now specify zones, and I have
two zones defined: 'surface' and 'air' (and a commented out 'sub-surface').  To restore xml compatability the code still expects <attack-fields> with embedded <field> elements, and 'land' is interpreted as 'surface', if it can currently attack land, it will now also be able to attack water units (because water and land are in the same zone, surface).

Field: This is now strictly a field of movement, atm I have 'walkable', 'air', 'any_water', 'deep_water' and 'amphibious'. A Field indirectly specifies a zone, obviously the 'air' zone/field match and all the other (current) fields 'map' to the surface zone.

Then instead of your travel type for a unit, I had a terrain (or surface) type for each cell, with values 'land', 'fordable', & 'deep_water'.  The walkable field is then essentially the surface zone + land and fordable terrain types. any_water is the surface zone + fordable & deep_water types, etc.

It might seem overly complicated, but it is flexible...

Of course, given the discussion above, maybe this level of flexibility can be obtained easier...

1341

Linux and other ports / Re: One stop guide to compiling glest and GAE

« on: 1 June 2009, 00:20:44 »

Sweet!
I've had some issues getting linux working to my satisfaction, and will probably have to reinstall with a newer/better distro, but it'll be nice to have this all laid out for me when I get around to it.

Cheers !! 

1342

Mods / Re: Ancient Egypt Faction

« on: 30 May 2009, 13:45:26 »

Hey weedkiller, spend some more vertices for the wheel, I think it will a good idea.

Definitely, hexagons aren't the roundest of shapes out there Otherwise looking good!

And try to keep the length of the whole unit as short as possible.I think it will look too ugly when a long thin units changes the direction in the game.

This issue has been noted and added to my task list, unfortunately it has for moment been assigned 'low priority', but an old friend 'catmull-rom' will fix this at some stage.

1343

Mods / Re: Mod Megapack V4 is released

« on: 30 May 2009, 03:05:30 »

Yes, I suppose that would work, but it would take up lots of server space and might be confusing if there were too many different releases.

Would take up very little server space, we're talking about source code here... and the SVN isn't really meant for everyone, developers are likely to know what's going on in each branch.

One way would be to make everything "stable" before incorporating it into GAE. Another option would be to provide patch files that people could choose to add or not. However, this would mean that lots of people would have slightly different types of glest, and so to play a new mod, you might have to recompile glest. I think the easiest thing to do would to get every new piece of code stable before adding it to GAE.

As an end user, all you really need to worry about is the trunk 'stable' release.  Unless you want to help testing new features... for which you will indeed need to be able to compile. All these other branches is simply how (or perhaps, 'where') we get things stable before moving them into the trunk.

Apologies to titi for the unintentional hijacking of this thread.

To go back OT, Great job compiling this titi, and to everyone involved in the mods.
And I'll throw my hat in for 'incremental' updates too, it is getting big...

Edit: Apologies to titi again, I didn't realise this was all your work, incredible job!

1344

General discussion / Re: "New Game Screen" Redesign

« on: 30 May 2009, 02:52:53 »

The game should only load the techs that you picked.
It lakes so long to load all 18 of them. (thats how many I have)

I have already made a fix for this. I'm not sure if it only got into Glest or GAE. I shall have a look.

Yep, GAE only loads those factions used... Vanilla glest loads the whole tech tree.

1345

General discussion / Re: Project Status and Changes

« on: 30 May 2009, 02:51:14 »

2. The bug tracker on Daniel's server isn't functioning so we'll need to abandon it and start using the bug tracker on Sourceforge

Yeah, this would be nice to have working.

3. Create a new branch for upgrading to the latest Glest (add Lua etc)

This should really be a priority... I might have a look at it after I'm done with my current 'sub' projects, unless anyone else wants to... anyone?

5. Make a stable version that people are able to compile on Linux and Windows (and downloadable binary packages)

0.2.11 is not stable ?  Seems pretty good to me.  I never got it to crash (before I starting hacking it up, that is!)

In general this will all be very good, having a branch for the pathfinder would be handy, would be nice to get some feedback from people, as I'm not likely to spot every bug myself...

I was hoping this Daniel chap would turn up soon, but I guess we need to get things moving, so let's get to it!

1346

General discussion / Re: Ahoy there!

« on: 30 May 2009, 02:36:56 »

Instead of having an amphibious field, maybe you could just enable multiple fields for the unit?  There could be for example shallow water, deep water, fordable water, air, and land.  Regular land units would only have land and fordable water; semi-aquatic units like crocodiles would be defined with shallow water, fordable water, and land; small boats with fordable, shallow, and deep water; battleships with deep water only; and some truly amphibious thing would be defined for everything but air.  These are just examples, of course.

The problem with this approach is potential inefficiency with the 'map metrics'. If we allow any combination of fields to be specified then we need to keep 2^(n-1) individual metrics for each map cell, where n is the number of fields. For your example, you specified 5 fields, so that's 16 'metric fields', which is precisely how many my current code will accommodate. Do we really need to support, say, a fordable water + air combination?

Although... come to think of it, we might be able to build just the combinations we need at runtime, so we have the basic fields all pre-calculated, and when we load a unit with a combination of fields (that we haven't already seen yet) we build the metrics for it from the base ones.  Hmmm... I think that should work, but I just thought of it, so let me think some more and get back to you

While we're at it, an "unwalkable" field could be useful for cliffs and other obstructions, and maybe an "impassable" field for barriers that couldn't be walked through or flown over.

I might be able to go you one better here, and add a 'maximum slope' variable. So any sufficiently steep inclines will automagically be impassable. Could probably even be defined by the map, if/when we get around to a new map format.
We can already make areas unwalkable with the 'invisible wall' tileset object, something for the air might be good. Is this what you meant?

1347

General discussion / Re: Fixing PathFinder::aStar()

« on: 28 May 2009, 22:49:05 »

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.

I should have known better than to make such bold claims on the basis of a few test games...
It does seem to be better (drops go away quicker), but I think I might be imagining things

The slow down was not related to the path finder, of course the old one was misbehaving and frequently 'blowing out', doing exhaustive and fruitless searches where no path was possible, for example.  So this was all worth while... and when I throw some hierarchical abstractions over the top, we'll be able to play on BIG maps.

wciow and others, I've got a linux box up and running, so hopefully on the weekend I'll get some time to have a play on it, and make my MS C++ into standard C++. I didn't want to release binaries myself, being new here and something of an unknown.. but it appears, for windows at least, I may have to. Give me a day or two to get things organised.

<technical>
Regarding the slow down, I've done some more testing and I have it nailed down now, OpenGL is blocking on SwapBuffers() (which I'm pretty sure it shouldn't be). I'll have to do some reading (well, probably a lot) and play around a bit more, the linux box has a NVidia card, so it'll be interesting to see if it behaves the same (this machine has ATI), I'll test it out on my gfs laptop too, which is using some Intel chip.
</technical>

1348

General discussion / Re: Ahoy there!

« on: 28 May 2009, 22:27:17 »

Could you make the die skill a morph skill and turn a horse man into a spear man?

Certainly an interesting idea, but I'm afraid I'm looking at too many things at once already...
Might look into it later though.

1349

Bug report / Re: trouble loading evil dragon from the megapackv4 mod

« on: 28 May 2009, 04:34:07 »

because dragon.xml is referencing "evil_dragon", you need to remove the morph command
from dragon.xml

Cheers.

1350

General discussion / Re: Can I run Glest by using DirectX for graphics instead of OpenGL

« on: 27 May 2009, 03:39:37 »

I changed the factory graphics setting in the ini to DirectX9 and it seemed to work. Of course, I have openGL on my computer too, so its always possible that it merely used open GL regardless, but do try and tell me if it worked!

GraphicsFactory *FactoryRepository::getGraphicsFactory(const string &name){
   if(name == "OpenGL"){
      return &graphicsFactoryGl;
   }
   else if(name == "OpenGL2"){
      return &graphicsFactoryGl2;
   }

   throw runtime_error("Unknown graphics factory: " + name);
}

It should have crashed! Are you sure you saved the ini ?