Merging Glest 3.2.2

[silnarm]

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...

[hailstone]

I found this in the readme.txt of 3.2.2

=================
HISTORY
=================

3.2.1
- Auto tester
- Fixes in River Crossing map
- Resource bug fixes
- Fixed compile errors on GCC 4

3.2.0
- LUA scriting
- New tileset: Dark Forest
- Tutorials
- Improved text rendering
- Added sound effect for chat messages
- Changed loading screen
- Removed IP from new game screen
- Removed Api Info screen

3.1.2
- Fixed slow building placement in ATI cards with catalyst 7.10 or newer
- Fixed fog of war smoothing
- Improved position picking when giving orders
- Fixed some glitches in shadows
- Added red colored building cursor when trying to build in an invalid location
- Fix for empty chat messages
- Reduced Drake Rider morphing time from 120 to 80 and reduced splash radius attack of a few units
- Improved battlemachine death animation
- The game now checks that all players are using the same binaries

[silnarm]

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...

[hailstone]

@silnarm : If you confirm that the following files are done then we can call the merge completed (minus networking) and go into a beta phase (make binaries for testers, clean the code, etc).

game.cpp
stats.cpp/h
particle_type.cpp
skill_type.cpp/h

gui.cpp/h :
- look at mouseDownLeft

script_manager.cpp :
- investigate the showMessage bug (would be nice to know why but not so important since it works now)

console.cpp/h :
- why was the colour changing removed?
- maybe double check the speed code

upgrade_type.cpp/h :
- is total upgrade used for anything?

faction_type.cpp/h :
- checksum in load?

logger.cpp/h :
- put the loading back how it was if you want

[silnarm]

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.

[silnarm]

I had some time to kill this morning, so the loading screen has been restored.

I found another bug too, onUnitCreated() doesn't seem to be firing if the original worker is not the one who 'finishes' the build... given the code snippet from my last post, very strange!

[silnarm]

- maybe double check the speed code

Same constant, pulled from a different location.

faction_type.cpp/h :
- checksum in load?

Seems to be using the checksum object it's passed, but I'm not sure how the they're used or checked...

I think we're pretty well good to go for now... Still a few things to check on, we may be missing some bug fixes, but everything appears to be working.

If I can convince you to change the scenarios folder to something along the lines of "gae_scenarios" or whatever you feel appropriate. As is the scenarios need to be laid out differently for glest and gae, the glest layout crashes gae, and the gae layout crashes glest... so if we just use our own directory, people can just create the new directory (and sub-dirs) and then copy scenarios into them, and our layout will not crash vanilla glest, nor vice versa.

[hailstone]

Seems to be using the checksum object it's passed, but I'm not sure how the they're used or checked...

I think it's only used to check that the files are the same in a network game, not sure though.

If I can convince you to change the scenarios folder to something along the lines of "gae_scenarios" or whatever you feel appropriate...

Good point and not only the layout but I assume any new tags or Lua we introduce will cause problems in vanilla Glest.

I think we're pretty well good to go for now... Still a few things to check on, we may be missing some bug fixes, but everything appears to be working.

Not much we can do about hidden bug fixes.

It's time for a post sub-project TODO list:
- (done I think) Should work on Linux and Windows (need to fix up the project files)
- Clean up code
- Compile and upload binaries for testers
- (mostly done) Simple documentation for Lua scripting (and scenarios if it doesn't exist) : single line description, parameter/attribute descriptions, example

That's all I can think of. Once they are done, and other people have tested it, it can be merged with trunk (or replace might be better in this case?).

PS: Thanks for working with me Silnarm. Keep up the good work. I'm going to create a topic for project contributions and add a file to the repository with the same info. This will include beta testers.

UPDATE:
- I merged the Linux project files and have it compiling and running (as much as I can in a virtual machine) on Linux
- I've done some API style documentation at https://docs.megaglest.org/Scenario_Editing (different to Omega's guide) . I left what was originally at the bottom.
- scenarios dir is now gae_scenarios

[Omega]

Whohoho! Looking at that wikia page, I'm impressed. Just gotta clear things up with you though.

You stated that the coordinates go from 0-the size of the map, meaning a 128x128 map can have 0-128. But then if this is cells, then cell 0 is the first cell, and cell 128 does not exist. This brings another question, what happens when I try to take my unit to this non-existant 128th cell?

Also, the queries look absolutely incredible. Just what I needed. Particularily good for artificial path finding (send a unit to point A, then check if they are on point A, if so, have them go to point B).

First question about the queries: I don't know programming well at all, and don't know the format of the vector returns. Will it be in the '{x,y}' format or is it 'x y' or even 'x,y' or what?

The getUnitFaction(int unitId) will return a 0 - 3 depending on the faction NUMBER, right?

getLastCreatedUnitName(): is the string returned as the unparsed version of the unit name (ie: ghost_armor) or is it as the parsed version (ie: Ghost Armor). Because Glest will take out the underscore and capitalize, so I'm curious about the returns.

A few things I'd like to point out that Vanilla Glest shouldn't have had in Lau: firstly, there seemed to be some weird limit of size. My scripts didn't work if they were too big (ie: 8kb). Of course, I still use the beta, so that may be the cause, though I doubt, since there was no word of such a fix, and no news if anyone discovered it. Secondly if a title or string from the .lng wasn't there, it would display ??? in front and behind the string/title name. This should be taken out to all people to have a title that can be done with just the lua file, and in case of error, the title can be displayed. No biggy though.

- Compile and upload binaries for testers

Goody! I am going to test that Lua to the limits. Everything from every function in Vanilla Glest to every new one you described in the wiki, and will test in a mix and match!

EDIT// Say, I just realized, what about a timer? Or will that be added into a later release of GAE? I do hope that it could be done though. Lua does have a timing system though, such as os.time() -- Returns seconds since jan 1 1970 (theres a special name or that date, but can't remember). This could be useful in making the time, as well as the variables that can be passed into os.time() to make it return different values. Check this out, as it could be very handy. The difftime might be possible, but I'll leave such up to you.

http://lua-users.org/wiki/OsLibraryTutorial

[silnarm]

You stated that the coordinates go from 0-the size of the map, meaning a 128x128 map can have 0-128. But then if this is cells, then cell 0 is the first cell, and cell 128 does not exist. This brings another question, what happens when I try to take my unit to this non-existant 128th cell?

I've updated that section of the wiki.

First question about the queries: I don't know programming well at all, and don't know the format of the vector returns. Will it be in the '{x,y}' format or is it 'x y' or even 'x,y' or what?

An array, 'x' in the first element (starting at 1 in LUA), 'y' in the second.
ie...

Code: [Select]

unitPos = unitPosition ( lastCreatedUnit() );
msg = "Unit is at " .. unitPos[1] .. ", " .. unitPos[2];
showMessage ( msg, "..." );


The getUnitFaction(int unitId) will return a 0 - 3 depending on the faction NUMBER, right?

Correct.

getLastCreatedUnitName(): is the string returned as the unparsed version of the unit name (ie: ghost_armor) or is it as the parsed version (ie: Ghost Armor). Because Glest will take out the underscore and capitalize, so I'm curious about the returns.

Try them out then

I'll look into the size limit thing and timers in due course

[hailstone]

I've updated that section of the wiki.

That's good. All I did was stick in a coordinate and see which way the unit went.

Secondly if a title or string from the .lng wasn't there, it would display Huh in front and behind the string/title name. This should be taken out to all people to have a title that can be done with just the lua file, and in case of error, the title can be displayed. No biggy though.

The language files are meant to provide text in multiple languages. I don't think it would be a good idea to be able to circumvent this.

For timers I was thinking they are events so have something like:

Code: [Select]

setTimeout(timeInMiliseconds,'eventname')
setInterval(timeInMiliseconds,'eventname')

<timer name="eventname">
[insert lua]
</timer>

Sort of like a function but I think it simplifies it a bit and stays consistent.

I'm eager to call the merge complete though. Then we can start adding more features like this.

[Omega]

Oh, god... the thing is complete, and I don't have an OS to try it on... Good timing, eh?

I'm really not so sure about that timers code. It is javascript equivilent, but why should it reference a xml tag? What's wrong with having it reference a function. ie:

Code: [Select]

setTimeout(3000,'sendAttack')

function sendAttack()

  createUnit('swordman',1,{35,50})
  givePositionCommand(lastCreatedUnit(),'attack',startLocation(1))

end
Is the location codes right, btw?

[silnarm]

I'm really not so sure about that timers code. It is javascript equivilent, but why should it reference a xml tag? What's wrong with having it reference a function.

Because that's how the other 'events' work... <startup>LUA</startup> etc.
It's consistent. A timer going off is an event, it should work the same as other events.

[silnarm]

Lua does have a timing system though, such as os.time() -- Returns seconds since jan 1 1970 (theres a special name or that date, but can't remember).

The 'epoch'.

os.time() seems to work just fine for me...

[Omega]

Hmm, dunno how you got it to display os.time() correctly. Is that the new modified version? Of course, since I still have the beta (which will probably change) I can't be sure that my glest is perfect. Might have been a hidden bug patch in 3.2.2 that fixed that.

The reason I liked the code the way I showed was because I'm used to javascript, which uses that EXACT syntax. While Lua is nothing like Javascript, the format for the setTimeout() is the javascript method (maybe a few other languages as well?). It's up to you though, since you're coding it!

EDIT// One question: how come timers (as an event) would have a XML code while detecting the death of a unit doesn't get one then? Is that not an event? And no, the unit-died tag does NOT detect the deaths. You have to go 'if lastUnitDead() == xxx then' to do that. Just not sure how a timer should get the tag. The only other 'event' that gets a tag is one for checking if a unit is created, and I never use it so I can't even remember what it is... Of course, its up to you, though may I propose that it will either check for a function or a tag? (everyone happy?)

[silnarm]

upgrade_type.cpp/h :
- is total upgrade used for anything?

It was used (and is in 3.2.2) to calculate stats based on the unit's base stats and all applicable upgrades... Daniel moved that functionality to EnhancementTypeBase, which our Units derive from.
All good in the 'hood.

EDIT// One question: how come timers (as an event) would have a XML code while detecting the death of a unit doesn't get one then? Is that not an event? And no, the unit-died tag does NOT detect the deaths.

I believe it's <unitDied>, and I can assure you it works.

[Omega]

But can't I check for a unit death anywhere? I believe I can put in the code in lua, and glest won't care for it. For example, I NEVER use unitCreated tag. I'm not sure how much such tags are really needed. Must do some testing...

Although the unitDied tag won't detect the deaths themself, since that's done in a lua code such as

if lastDeadUnit() == xxx then

so what exactly do startup, unitCreated, and unitDied do?

[silnarm]

...
so what exactly do startup, unitCreated, and unitDied do?

They 'fire' when that 'event' happens...
That's why os.time() wasn't 'working' for you... you were presumably only calling it in the one event handler, probably <startup> ? which executes precisely once, at the start of the game... calling lastDeadUnit() in <startup> is meaningless, no units have died yet.

If you want to know when a unit dies, you must use the <unitDied> event handler, it 'fires' every time a unit dies in the game, you can then do what tests you need in there, ie,

Code: [Select]

<unitDied>
if ( unitFaction ( lastDeadUnit () ) == 0 ) then
  -- Unit belonged to Player 1
  if ( lastDeadUnit () == mySpecialUnit ) then
    -- It was an important unit, whose ID I stored in 'mySpecialUnit' in the <startup> script
    -- this might end the game with loss, or trigger some other action...
  end
else
  -- Unit belonged to one of Player's 2-4
  -- check victory conditions and/or respond according here
end
</unitDied>

I'll be doing some more updates to the wiki, hopefully with lots of little example snippets like that, as time allows me

[hailstone]

If you're busy with the pathfinder branch I could clean this one and merge it with trunk and make a tag? Then I can remove the branch and call the merge complete.

[silnarm]

If you're busy with the pathfinder branch I could clean this one and merge it with trunk and make a tag? Then I can remove the branch and call the merge complete.

Definitely, go ahead... let me know when you're done, if the A* is still dodgy, I'll just put the optimised greedy search in, whatever we tag needs at least the GraphSearch::canPathOut() function so that large numbers of workers going for the same cells doesn't "blow up" like it used to.

I know you don't have long 'til uni starts again, but I have prepared a task if you're interested, it's mostly all typed up and ready to go... check out the refactoring topic...

[hailstone]

I've reintegrated the branch now without tagging it.

[silnarm]

I've reintegrated the branch now without tagging it.

Ok... Can you confirm that pathfinder branch is 'shuddery' for you on a release build ? (preferably without any debug texture defines... that code is NOT fast) On a debug build it will be very ordinary, the path finder used to be optimised even in debug mode, I had to turn that off to actually debug it...

If it is doing this on a release build, can you make your way to path_finder.cpp line 173 and change it to,
      bool result = search->GreedySearch ( params, pathList );

Then rebuild and test again...
For me, it is quiet horrendous in debug, but I haven't got any problems with it on a release build.

[hailstone]

In release build with FIELDMAP_DEBUG_TEXTURES on it only renders the terrain and without it nothing is rendered. Also in Gui::mouseMoveGraphics , map->FieldMapDebug.clear (); needs to be surrounded with an ifdef.

[silnarm]

In release build with FIELDMAP_DEBUG_TEXTURES on it only renders the terrain and without it nothing is rendered.

Ok, cheers... plenty to do tonight then 

Also in Gui::mouseMoveGraphics , map->FieldMapDebug.clear (); needs to be surrounded with an ifdef.

Oops... 

I'll be able to play with the path finder soon, if you're going to be working on anything this evening I'll jump on irc probably in a couple of hours time... in case we need to coordinate activities...

[Omega]

...
so what exactly do startup, unitCreated, and unitDied do?

They 'fire' when that 'event' happens...
That's why os.time() wasn't 'working' for you... you were presumably only calling it in the one event handler, probably <startup> ? which executes precisely once, at the start of the game... calling lastDeadUnit() in <startup> is meaningless, no units have died yet.

If you want to know when a unit dies, you must use the <unitDied> event handler, it 'fires' every time a unit dies in the game, you can then do what tests you need in there, ie,

Code: [Select]

<unitDied>
if ( unitFaction ( lastDeadUnit () ) == 0 ) then
  -- Unit belonged to Player 1
  if ( lastDeadUnit () == mySpecialUnit ) then
    -- It was an important unit, whose ID I stored in 'mySpecialUnit' in the <startup> script
    -- this might end the game with loss, or trigger some other action...
  end
else
  -- Unit belonged to one of Player's 2-4
  -- check victory conditions and/or respond according here
end
</unitDied>

I'll be doing some more updates to the wiki, hopefully with lots of little example snippets like that, as time allows me

Wow, and all along I couldn't figure out what the tags where for... I feel so stupid!

Is it possible to exclude tags like 'unitCreated' though, especially since most scenarios produce some units at the start, and the rest are controlled by deaths. Also, can we have multiple 'unitDied' tags? Now that I see how they work, I take back my objection to using a tag for the timer.

*Ah, yes, that must be why the time was wrong in os.time()! It still recognizes the death with the lua script, but it isn't executed at the right time I guess!

BTW: Concerning your code sample, I support you adding a lot a code samples to the wiki, especially for the new parts, to clear up some of the questions. Of course, I guess I'll have to get into the habit of using the wiki...
However, you have two unneccessary lines in your code. You check the faction of the last dead unit, which is unneccessary, because there can only be one unit with that ID, which will be the faction that you stated (0). Checking the faction isn't neccessary when checking for the last dead unit by an id. No biggy though.