Messages

1251

General discussion / Re: Merging Glest 3.2.2

« on: 6 July 2009, 13:17:50 »

Code: [Select]

if(repaired && !repaired->isDamaged()) {
   unit->setCurrSkill(scStop);
   unit->finishCommand();
   //MERGE ????
   scriptManager->onUnitCreated(repaired);
}

This concerns me... as scenarios that count units produced could easily be fooled.  But I guess that's how it is in 3.2.2 atm.

I had a look at Gui::mouseDownLeft()... it certainly looks cleaner in 3.2.2, but if the old code is working, I say leave it... we'll be wanting to replace that soon hopefully anyway.
The showMessage problem probably falls into the same category, will have to be looked at when we change the gui.

Colour switching in the console was removed because the patches said so... I wasn't actually to sure what it was at the time, so I just did it.

class TotalUpgrade is an interesting one, upgrades have unfortunately been changed in both codebases... this should be looked at in depth...

I'll look at the rest tomorrow

...and I'll get the old loading screen back tomorrow or Wednesday night.

1252

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

« on: 5 July 2009, 05:47:12 »

Recently discovered Glest's A* is not A* at all, but a 'greedy best first search'. I've implemented a proper A* and optimised it to the best of my ability... I'm happy with the running time, but haven't tested it extensively yet. I think for the next GAE I'll make it an option to use either the greedy algorithm or A*.

The right Heuristic...
I spent plenty of time reading Amit Patel's pages on A*, and I'm confident that it's pretty much as fast as it can be.  The heuristic needed to be changed though, the euclidean distance that was being used causes problems with proper A* on a grid, because it lies about the true distance to a goal node. At 45 degree angles things look fine, but in between it underestimates and causes A* to expand nodes closer to the start...

Shown here, on the left, is the old heuristic on a path at a roughly 22.5 degree angle, the Yellow nodes are the 'frontier' of the search (the open list), the red nodes are the expanded nodes (the closed list).  Expanding nodes is a relatively expensive operation.  Shown on the right is a similar path, calculated with the same algorithm, but with a 'diagonal distance' heuristic, the 'correct' one for us... note that (in this case) every expanded node ended up on the path, it's as fast as the greedy search when obstacles are not present....



Note that this heuristic is still admissible (at least until we add some more interesting terrain types) so the search will still find the optimal path, it just won't 'fan out' if it doesn't need to...

1253

General discussion / Re: Merging Glest 3.2.2

« on: 5 July 2009, 03:12:02 »

Ok, I just tried out the 'basic tutorial' the scenario XML for disabling default units isn't working, but disabling default resources seems to be working.

As far as could be seen, most of the simple LUA functions seem to be working...

disableAi(), createUnit(), setCameraPosition(), unitPosition(), giveResource(), showMessage() and setDisplayText() all work as advertised.

The 'hooks' for events (ie. <unitCreatedOfType type="worker"> ) do not seem to be working, but I haven't tested this much yet.

I'll be chipping away at it today, if you're about this evening hailstone, I'll be on IRC... have to go out briefly soon, but once back I should be online and hard at it, until the Blues-Freo game at least, and hopefully afterwards.

Edit: Just completed the basic tutorial... trying the advanced...

Edit2: Advanced tutorial worked like a charm...

1254

General discussion / Re: Merging Glest 3.2.2

« on: 3 July 2009, 22:19:05 »

All this merging sounds very promising! Hopefully we will end up with a stable GAE version!
What about multiplayer? Which one did you choose for now? The original one from glest 3.2.2 or the one from daniel ?

Some-where in between   For now, we have whatever was in 0.2.11, which as best I know is mostly multiplayer from early version 3, modified somewhat by Daniel, but from before the complete re-write.

BTW: an idea for the future: should lua be able to control some settings like day-night time, fog of war, weather, etc;

All sound like things a Scenario author may want to control...

1255

General discussion / Re: Merging Glest 3.2.2

« on: 3 July 2009, 07:55:41 »

Any chance you could leave the old style unit loading menu the way it is. I Prefer it to the new one.

This has already been changed but it can be changed back later.

I was careful to leave everything to do with this 'commented out' not deleted, I want it back too! Scenarios use the same mechanism to show messages in game though, so I've just changed it for now. I will separate them at some point though, so we can have our old loading screen back.

When Lua script is read it processes them all at once so it doesn't wait for the first message box to be responded to before the next one is processed. So when I set the first one not enabled the second also became not enable but is still shown on the screen.

The 'MessageBox' is more functional than it used to be, and we appear to missing some of that functionality

I'll leave it with you for now, if you don't mind... almost got the pathfinder ready... abandoned the treap, just using the STL heap algorithms for the open list, but I've introduced a most annoying bug, which only manifests itself in release build...

1256

General discussion / Re: Merging Glest 3.2.2

« on: 2 July 2009, 09:34:19 »

It now runs as expected...

Sweet...

There were some paths missing from MenuStateNewGame::loadGameSettings(). Might also be an issue with MenuStateScenario::loadGameSettings(). Would it be better to put the strings in game settings like?

GameSettings got changed somewhere along the way... the diffs obviously didn't help us much on that one. The 'new way' is to store just the name, then append path and extension when needed.  That scheme you propose gives us the best of both worlds, nice one!

- Still need to test the Lua scripts.
- The exit window asks if you want to quit and then only one button saying No. (Probably need changes in GraphicMessageBox::init(... , ... , ...) )

If it's up and running, there is the menus issue to sort out... I didn't want to change the menu sequence so I skipped the diffs for it...  the sequence of menus to there and the normal new game screen has changed in 3.2.2. I didn't want to mess the gui much because it might be next on our hit-list anyway...

Edit: I 'dodged up' the rest of the path problems, scenarios load, but we're not getting any messages.

1257

General discussion / Re: Merging Glest 3.2.2

« on: 2 July 2009, 03:50:03 »

How are you using Lua?

I'm getting this error using the Windows binary when trying to run:
LDR: LdrpWalkImportDescriptor() failed to probe H:\GAE_0.2.11\lua5.1.dll for its manifest, ntstatus 0xc0150002

Hmmm... I installed 'lua for windows'
http://luaforge.net/frs/?group_id=377

and am linking against 'lua5.1.lib'

Gave me no issues at all...

1258

General discussion / Re: Merging Glest 3.2.2

« on: 1 July 2009, 10:41:38 »

Sorry, didn't notice the message before the quote...

Got rid of the compilation errors now, and the first couple of runtime errors...

names and directories of tilesets/maps/ etc are handled differently though... the current crash is in Checksum::addFile(), if you want to set a break point there and start investigating, I think I'm done till at least tomorrow some time

1259

Translations / Re: Turkish 3.2.2

« on: 30 June 2009, 13:04:58 »

AntiVir call's it HTML/Infected.WebPage.Gen HTML script virus

the language file is clean though

1260

General discussion / Re: Unit Testing

« on: 30 June 2009, 12:58:25 »

I've made a template with CPPUnit (see trunk/test). I was wanting a tests folder in each directory and then have a project that compiled all the tests (only for includes in shared_lib). Shared_lib and game need to have individual test projects because game relies on shared_lib. It would be easy to add "tests" to the Glest dirs in the Jamfile.

I'm not sure how to cleanly organise it in VS. Maybe there is a way to use the compiled object files of the other projects without needing to add the source to the test project? Also need a place to store the files that you use for testing such as a ini file when testing the properties class.

EDIT: I found out that obj files that were compiled from other projects can be added to Additional Dependencies. The test files are the only files needing to show for the project then. The other project will be a dependency for the test project.

Cool, I'll have a proper look when I get a chance... if it all works out I'll add a 'template' test project to the VC solution file, or feel free to beat me to it .

1261

General discussion / Re: Merging Glest 3.2.2

« on: 28 June 2009, 11:41:15 »

I'm not sure that it's necessary to use all the comments because a diff will tell you the changes that were made (although that might be tedious too). We'll start out doing the comments and see how we go.

Yeah, I actually stopped doing it for some stuff, if I was sure it wasn't going to cause problems...

EDIT: In source/glest_game/graphics/renderer.cpp you have //MERGE ADD then //MERGE DELETE on the next line. Did you forget to add the new line or is not meant to be there?

Good question! Don't happen to know the answer do you ?

Anyway, it's all in there now... and I'm down to 49 errors...
I'll mail through all the patches so you've got a reference for investigations, but at this stage it's probably easier to just check the 3.2.2 files.  There are a few spots where the code-bases had diverged a bit... so there's going to be plenty of investigative work to be done

Will commit everything within an hour or two... it wont compile

1262

General discussion / Re: Merging Glest 3.2.2

« on: 28 June 2009, 02:48:00 »

Ok, the shared lib is looking good. Compiles cleanly and the game runs.

Now for the fun part 
As with shared lib, there will be more stuff in the diffs than is actually missing. Unfortunate perhaps, but at least we don't have to add more code that could break things

Here's what I'm thinking, do the files one at a time (or two, if there are changes in header and module file).

Upon adding some code, tag it with a merge comment...

Code: [Select]

//MERGE ADD START
addedNewCodeHere ();
//MERGE ADD END

Where deletion of code is called for, just comment out the code and tag it thus

Code: [Select]

//MERGE DELETE START
/*
   someOldCode ();
   thatWeDontWant ();
*/
//MERGE DELETE END

Edit: for one line additions/deletions, use //MERGE ADD, or //MERGE DELETE, immediately before the line, omit the START and corresponding END.

Once you've done the file, try to compile it. If it compiles move on, if not then find the offending undeclared function call(s) or variables or whatever they are, and comment it(/them) out...

Code: [Select]

//MERGE ADD START
//addedNewCodeHere ();
//butItWontCompileYet ();
//MERGE ADD END

Probably best to keep

Code: [Select]

//MERGE ADD START
//MERGE ADD END
//MERGE DELETE START
//MERGE DELETE END
in the clipboard, the idea is changes will be easy to find later with a grep/find all. So, no typos!
It'll be a bit tedious, but I think a bit of care here will help a lot later.
We'll do the "bit's and pieces" first, and the 'world' and 'game' directories last,
I'm going to start on the 'facilities' and 'menu' directories now, let me know when you're ready and I'll mail some patches through...

PS: diff just pulled the files in alphabetically, so afile.cpp comes before afile.h, make sure to check for header changes before you try to compile a *.cpp.

1263

General discussion / Re: Merging Glest 3.2.2

« on: 26 June 2009, 09:50:58 »

Yeah, I should have realised that argument was flawed... the only way the test is going to be false is if it points to NULL, and deleting NULL is apparently perfectly safe.  And you are quite correct about logical tests, in C/C++ a zero is false, anything else is true... so if you didn't initialise the pointer to NULL, didn't allocate anything to it, and then did this, the test would be true (the pointer will have a 'junk' value) and you proceed to delete the memory from a 'junk address', then the OS would crack it. Of course without the test you get the same result... the real lesson here is, Always initialise pointers!

Edit: another top link hailstone, I've already found something else I've been doing wrong ...

1264

General discussion / Re: Merging Glest 3.2.2

« on: 26 June 2009, 04:57:30 »

Edit: I noticed Daniel checks if a pointer has memory before deleting. Is there any reason for this.

Code: [Select]

NetworkManager::~NetworkManager() {
if(gameNetworkInterface) {
delete gameNetworkInterface;
}
}

That's because modern operating systems don't take well to you trying to delete memory you didn't allocate
You should always do this if there is a chance it doesn't point at something you allocated...
In short, if you're using them locally (in a function) and you know you allocated the mem, no need to test.
if it's a member variable, probably best to test it.

Fantastic! I tried to simulate a timer by using the os.time() lua function, but for some reason, Glest only seems to get the start time, and will never update. Is lua run real time or statically at the start?

Sounds like it's not hooked up... either way, wont be hard

1265

General discussion / Re: Online Mod Maker -- Now Underway!

« on: 25 June 2009, 23:20:17 »

Simple enough? Sure a bit of code will be needed to recognize the magitech files... Hmm, should we have magitech recognization or not? Perhaps it would be better not to. It would simplify as well as prevent confusion.

Yeah, may get confusing... I'd say just go with the modder supplies the name, and puts the files in place his/her self.

Maybe later you could add the 'option' to use a magitech model, click a checkbox, and the 'model name' text-box becomes a combo-box, that'd be the most user friendly, and then you wouldn't need to worry about trying to figure out if a supplied model name was magitech or custom.

1266

General discussion / Re: Merging Glest 3.2.2

« on: 25 June 2009, 23:06:08 »

I'll be happy to test it once you are finished.

Thanks!

Because 3.2.2 has lua, I assume this means you are adapting lua into GAE (at last)? Would this make GAE version 3 now?
Also, will you consider adding a few new lua features into GAE while you do the Lua?

I'd be happy to add new features for scripting, but only after the merge... we don't want to be changing things as we integrate them. After we've got it all working again, and it appears to be stable, then we can look at extending it.  Your request for timers has not fallen on deaf ears, it will be straight forward to implement, but it will have to wait until the merge is complete.

1267

General discussion / Re: Online Mod Maker -- Now Underway!

« on: 25 June 2009, 11:31:07 »

It won't happen for sure in v1, and I'll have to give every update a great deal of thought. Not sure how on earth a texture generator would work, and I wouldn't expect that. This really only does the XMLs, and everything else is up to the modder...

Yeah, the texture 'generator' was a joke, forget about that
Aim for XML for now, all I was trying to say was don't upload magitech models.. allow people to use them as place holders , but instead of having the model and texture in the new factions directory, just use relative paths in the xml.

So, if I'm making 'MyFaction' and adding it to the magitech tech-tree, and I make a unit I call 'MyInitiate', instead of copying the models into the new faction directory and have the XML point at "models/initiate_standing.g3d" etc, have no models directory, just have the XML point at "../magic/units/initiate/models/initiate_standing.g3d"
A little nastier if it's in a different tech tree, but not to bad,
ie. "../../../magitech/factions/magic/units/initiate/models/initiate_standing.g3d"

But don't worry about any of that for now... just focus on the XML part, using models the modder supplies names for.

1268

General discussion / Re: Merging Glest 3.2.2

« on: 25 June 2009, 11:07:44 »

Nice. I don't think glest_game will be as easy though.

I can assure you it wont ... the diff is huge, but I haven't pruned it properly yet... I made sure line endings matched, but there was still a lot stuff that was identical that I stripped out of the shared lib diffs... not much fun

That's the first time I've heard of that data structure. I've studied binary search trees and heaps before but not as one data structure.

It sure is a nifty one, and with a very simple modification we can send the tree out of balance deliberately, favouring a low height 'to the left' where the 'good' nodes are, and letting the tree balloon out to the right, where the crappy nodes are kept. Worth a little effort I reckon

Should we use another branch or just commit to trunk?

Yeah, the path finder doesn't need to be merged now, it's fairly well self contained anyway, so it should be easy to merge later anyway.
LUA is embedded in the XML, so maybe we should get it working with xerces so you have a 'reference' for any changes made to the xml parser.

So go ahead and branch if you want to get started, I'll be in there come Saturday 

1269

General discussion / Re: Merging Glest 3.2.2

« on: 25 June 2009, 05:31:37 »

@silnarm: Were you wanting to lead this project?

Ok, I'll 'lead the charge'

Perhaps start at shared_lib and note any interface changes. Also it might be good to have a diff of Glest 3.2.2  and an earlier version of GAE (to get a reference) with latest GAE trunk.

shared_lib would indeed be the place to start, and I've already cleaned up the diffs.  There really isn't too much new in shared lib, lua of course, but we can just 'drop' that in.

Good idea on diffing against an earlier GAE and current trunk... I'll set up some local repositories and do some more diffs.

Happily, I have today and tomorrow off, and then the weekend

Unfortunately, upon discovering just days ago Glest's modified A* is really just a (Greedy) Best First Search and thoroughly undeserving of the name A*, I've implemented a proper A*, and it needs a tiny bit more tweeking...

I have however already decided on the ideal data-structure for it, a 'Treap' which is nice and simple (relatively, perhaps). So I should be 'done' with that tonight or tomorrow.

If you wanted to get started on the merge, here's the cleaned up and annotated diffs for shared lib,

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

Cheers.

1270

General discussion / Re: TinyXML Branch Ready for Testing

« on: 23 June 2009, 08:10:20 »

I've done up some tests if people want to try. Modify the xml and see if the errors are what you expect.

Sweet, I'll have a crack at it, I'm good at breaking things

1271

General discussion / Re: Online Mod Maker -- Now Underway!

« on: 23 June 2009, 03:40:12 »

What I'm considering will be to have all the glest models that I can get uploaded, and you can choose one of these to include...

Please do not do this... I was going to have a gripe about this rampant copying of models on the mods board, and probably still will at some point, but if 'standard issue' models are to be used, please assume the existence of the default magitech techtree and use relative paths to the models & textures (if it's not re-skinned for the mod).

1272

Mods / Re: How do i install the .g3d Export script in blender?

« on: 23 June 2009, 03:05:43 »

I've tried everything, looked everywhere, i can't find the scripts folder in blender, no tutorials are working.

can somebody PLEASE help me??

Newer blenders will expect scripts in,
C:\Documents and Settings\YourUserName\Application Data\Blender Foundation\Blender\.blender\scripts

older blenders might want them in,
C:\Program Files\Blender Foundation\Blender\.blender\scripts
[assuming blender was installed in the default location.]

Windoze of course doesn't do Python by default, so make sure that's set up too

Cheers

1273

General discussion / Re: Buildable/Walkable/Not Walkable

« on: 22 June 2009, 22:52:24 »

Yes, the idea could be good, though GAE's primary focuses should be in new previously mentioned new features (TRANSPORT UNITS!!!)

Ahhh.... transport units....

It's actually kind of difficult to keep all these ideas in mind, I'm going to recommend using the 'Feature Requests' tracker on sourceforge,
http://sourceforge.net/tracker/?group_id=241094&atid=1114830

Now, I never saw the trackers on codemonger before the bugs server went down, so apologies to anyone who painstakingly added stuff there... but if you put it up on the sourceforge tracker, we're never going to loose it.

I don't want to discourage talk on the forums, indeed you should talk about it on the forums, I'm not expecting people to use the tracker to discuss features (and I'd rather they didn't anyway) but it is a very good idea to discuss ideas with other modders.  When you think you're 'on a winner' throw it on the tracker. It will get prioritised (and I can't guarantee you'll like the priority your idea gets, but these things take time, and time is unfortunately a resource that can only be harvested at a fixed rate )

You can always go back and add more comments, or upload example pics etc... just try to keep it concise if possible (but not vague!)... The less time we're looking at the tracker, the more time we can actually bash bits about and try to make some of it happen.

I have added a few things that I've come across on the forums over the last week or two, but bearing in mind the paragraph above this one, I could probably be using that time better

Cheers.

1274

General discussion / Re: Engineering the GAE Website

« on: 21 June 2009, 12:30:09 »

If this is the case, then maybe GAE should be vanilla-glest independent. (i.e. with it's own data packages, so that downloading the original glest is not compulsory.)

Down the track perhaps, I can't see GAE being compatible with the current map file format in the future, and while we could change that without breaking XML compatibility, frankly the tileset format needs a reworking too.

Of course, we'll need to get FPM back on track if we plan to provide our own data

Couldn't you have the GAE "unstable" multiplayer and the normal glest "stable" multiplayer both in GAE?

Could, yes... but I'm personally not willing to lift a finger re-integrating code that we're just going to throw away later in any case.

1275

General discussion / Re: Buildable/Walkable/Not Walkable

« on: 21 June 2009, 12:16:42 »

You would be able to walk AND build on to of it. (being able to make real tunnels would be nice too).

Nice idea, could be tough to implement... are you proposing buildings that can have other buildings on top of them, as in on the model, above ground level?

Real tunnels would indeed nice, I'm not sure if this was discussed in the map format thread, and couldn't be bothered checking just now But we should probably revive that thread.