gae 0.2.13-development

[titi]

I checked out the current 2.x version. It builds and works fine under linux. i also used the original GAE data from the svn.

Now for the problems we found so far ( only single player of course ):

- there are no death animations shown at the moment.

- We had a strange behaviour of a horse, I think its maybe a pathfinder problem.
  The CPU attacked me in the map Fourrivers  and we fighted at the river. There were too many units fighting at the river so they got stucked.
 One of them was a horse. This horse  was standing sideways and was always showing the running animation, also it didn't moved.
 when all the units in front of it were killed, the horse still was standing sideways and running on the place. Then it suddenly( after about 3 seconds )    started to with its normal behaviour and started the attack.

- I think we need a linux startscript like original glest. this adds libs to LD_LIBRARAY_PATH and so on and changes to the right directory for the start.

- CameraZoomReset  is not set to a key in keymap.ini by default and it doesn't work :/  . I would vote to set it to "Space" as a default.
Why is the keymap.ini always written/touched when gae starts?
( By the way, are really all those things in keymap.ini useful ? and do they all work ? )

- when attacking someone with there is shown a red arrow at the upper left corner of the attacked unit, I think this is a bug too.

( I update this post until someone else posts )

[softcoder]

For the sake of sanity ( a picture is worth a thousand words) could you take a screen shot of the situation and point out what is happening that way. I think it will be easier to fix this kind of issue if we can see the terrain and units, etc.

Thanks

[silnarm]

- there are no death animations shown at the moment.

Not sure what has happened here, they play in 0.2.12 though, so hopefully it wont take too long to track this one down.

- We had a strange behaviour of a horse, I think its maybe a pathfinder problem.
  The CPU attacked me in the map Fourrivers  and we fighted at the river. There were too many units fighting at the river so they got stucked.
 One of them was a horse. This horse  was standing sideways and was always showing the running animation, also it didn't moved.
 when all the units in front of it were killed, the horse still was standing sideways and running on the place. Then it suddenly( after about 3 seconds )    started to with its normal behaviour and started the attack.

Ok, I noticed some similar behaviour when issuing build orders to a (largish) group of workers, I thought it might have been something in the build command, but it would seem the Pathfinder is telling lies again.

- I think we need a linux startscript like original glest. this adds libs to LD_LIBRARAY_PATH and so on and changes to the right directory for the start.

Sounds perfectly reasonable

- CameraZoomReset  is not set to a key in keymap.ini by default and it doesn't work :/  . I would vote to set it to "Space" as a default.
Why is the keymap.ini always written/touched when gae starts?
( By the way, are really all those things in keymap.ini useful ? and do they all work ? )

Good idea,

CameraCycleMode was actually set to 'F' previously, this is the same as from Glest, toggles between 'game' and 'free' mode, obviously that doesn't make much sense for GAE anymore, I'll get rid of CameraCycleMode, and have just one 'reset' which goes back to the default camera orientation & height.

I borrowed the 'F' key as 'capture the view frustum' while I was working on the scene culling, (this was done with lots of ugly conditional compiling in various places, most of which is gone now, I'm doing that sort of thing through Lua now, much cleaner) and I forgot to change it back, but I think the space bar would be best, then F could default to a hotkey for the follow command.

The keymap being saved at start up I think was a fix for hotkeys not working on the first run (ie, if there is no existing keymap.ini found).  It could probably be in an 'if', will have a closer look...

As to if it's all needed and if it all works, not sure... but probably not and probably not   We should probably go through them and cull any that aren't really needed.

- when attacking someone with there is shown a red arrow at the upper left corner of the attacked unit, I think this is a bug too.

You don't mean the 'command arrow' do you? Which shows the target of the current command if you have only one unit selected (and only when the target is close)?? If so, that's no bug... if that's not what your talking about, I might need a screenshot, I've been unable to notice anything odd like this.

[titi]

here is  the screenshot:

[-Archmage-]

I think the arrow should be placed in the center, but if a unit is there, have the arrow displayed above the model.

[softcoder]

Good news everyone... I just finished the initial port of the networking code from mega-glest to gae and from a few tests it looks great!

I'll get the boys to do a full 4 player LAN game (4 network'd players) and see if we get any issues.

I tried mixing my mega-glest network code with what was already in GAE but found that something wasn't working right in GAE.. not sure if it was the circular buffer or something else but performance and synch issues were killing any hope, so I mostly ported the socket as well as additional network messages.

I'll post another update once I know for sure that it is stable, then I'll get instructions for getting the code into SVN.

[titi]

@Archmage: No, I think there should be no arrow!

@softcoder: What do you use to develop c++ in linux? I have serious problems setting up eclipse for GAE. There are so many needed switches to compile and mabe other things I don't know yet. 

[silnarm]

Good news everyone... I just finished the initial port of the networking code from mega-glest to gae and from a few tests it looks great!

Awesome... my fingers are crossed.

I tried mixing my mega-glest network code with what was already in GAE but found that something wasn't working right in GAE.. not sure if it was the circular buffer or something else but performance and synch issues were killing any hope, so I mostly ported the socket as well as additional network messages.

It's quiet possible the circular buffer is not entirely correct, there was no TDD, no tests written after the fact, it was 'seat of the pants' programming, my bad. If you have it working without, ditch it! I'll write a test plan for it though, as I would like to not be peeking on sockets, at least under windows.

@Archmage: No, I think there should be no arrow!

Yeah, thats the 3D mouse cursor, it should show up when you first issue the command, then fade away, it should not be staying... and indeed it doesn't for me   Softcoder &| Yggdrasil, are you also getting this effect under linux?

[Yggdrasil]

No, it's fading away here too. I'm not able to get it staying.

@titi: Could you provide steps to get to this situation.
Or maybe we misunderstood you and you don't want this arrow in the first place, even fading after some time. I think there should be one. Maybe the position is not the best.

[titi]

Its fading away here too, but if you click on a building and the transparent red arrow shows to the middle of the building, this red arrow shows the upper left corner of the unit. In my opinion thats not good and it should be like in original glest where this non transparent arrow doesn't show up.

[softcoder]

Anyone know if this is a known bug in GAE... the particle system does not "flow" the particles from units in magitech like it does in glest... the particles seem to turn into "dots" instead of flow like a stream of fire or whatever else the particle is. I did some checking into the particle code but see much has changed and I can't find an obvious reason?

If required I'll send a screen shot but anyone should be able to confirm this.

EDIT:

Also noticed the following crash in GAE:

Crash
Version: Advanced Engine v0.2.13
Time: Fri Feb 12 06:25:46 2010
Description: SIGSEGV: address not mapped to object
Address: 0x89
Backtrace:
./glestadv [0x819f1f2]
[0xae8410]
/lib/tls/i686/cmov/libc.so.6(_IO_vfprintf+0x3971) [0xbd24b1]
/lib/tls/i686/cmov/libc.so.6(__printf_chk+0x86) [0xc718f6]
./glestadv [0x80bf8fe]
./glestadv [0x80bd54c]
./glestadv [0x80bd7a8]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6) [0xba8b56]
./glestadv [0x804f821]

Is what shows in the crash log. Unfortunately there does not appear to be reproducible steps to know how it was done.. both me and one of my sons got this (without network play) after playing against the CPU for a while.

Doing a little looking around this seems to be a memory fault (in windows that would be an access violation). This sounds nasty and may a challenge to track down.

[-Archmage-]

Well, I did an upgrade(headdesk ) and the Linux computer I upgraded(from Kubuntu 9.04 to Kubuntu 9.10) got some similar errors while running GAE...

[silnarm]

Anyone know if this is a known bug in GAE... the particle system does not "flow" the particles from units in magitech like it does in glest... the particles seem to turn into "dots" instead of flow like a stream of fire or whatever else the particle is. I did some checking into the particle code but see much has changed and I can't find an obvious reason?

If required I'll send a screen shot but anyone should be able to confirm this.

I recall someone else had a problem with particles not looking right, but I can't find the topic now, so I don't know if there was any resolution, but if memory serves they were using linux...

This is what I get on windows, looks the same...

Also noticed the following crash in GAE:

...

Is what shows in the crash log. Unfortunately there does not appear to be reproducible steps to know how it was done.. both me and one of my sons got this (without network play) after playing against the CPU for a while.

Any chance one of you could try out 0.2.12b and see if the same errors occur? The pathfinder was extensively worked on again recently, this is probably my doing, I haven't had a chance to stress test it yet.

What tech-tree were you using? or did this occur with multiple techs?

Doing a little looking around this seems to be a memory fault (in windows that would be an access violation). This sounds nasty and may a challenge to track down.

I'll be out all day (sister's birthday) but I'll try to rig up some stress tests tonight if I get the time.  If I can get it to happen here, I'll find and fix it.

[softcoder]

The crash happens with any tech (we tried multiple techs including stock gae megitech). I'll try to compile the 0.2.12b branch and see what happens.

Regarding the particles... hopefully someone can give us a heads up.. seems to be a linux problem.

[ElimiNator]

Here is a screen shot of GAE particals in linux.

I didnt modify the partical_progs in any way and it works fine in Mega_Glest.

[softcoder]

Update on the particle display issue in linux:

Ok the problem is in sharedlib\sources\graphics\particle.cpp

I replaced the contents of the method:

void ProjectileParticleSystem::update()

with the version from mega-glest and particles are back to normal in linux.

Looks like some new stuff was added for trajectory (random etc..) which might be hte culprit.

[-Archmage-]

I don't get it, the particles are fine in 0.2.12b. ???
On both Windows and Linux.....

[softcoder]

Here is "a version" (mix between glest and gae) that seems to work fine. I didn't test anything with random particles as I don't what which tech has that?

Code: [Select]

if (state == sPlay) {
if (target) {
endPos = target->getCurrVector();
}
lastPos = pos;

Vec3f flatVector;

if (trajectory == tRandom) {
Vec3f currentTargetVector = endPos - pos;
currentTargetVector.normalize();

float varRotation = random.randRange(0.f, twopi);
float varAngle = random.randRange(-pi, pi) * trajectoryScale;
float varPitch = cosf(varRotation) * varAngle;
float varYaw = sinf(varRotation) * varAngle;

float d = Vec2f(currentTargetVector.z, currentTargetVector.x).length();
float yaw = atan2f(currentTargetVector.x, currentTargetVector.z) + varYaw;
float pitch = asinf(currentTargetVector.y) + varPitch;
float pc = cosf(pitch);

Vec3f newVector(pc * sinf(yaw), sinf(pitch), pc * cosf(yaw));

float lengthVariance = 1.f;//random.randRange(0.125f, 1.f);
//currentEmissionRate = (int)roundf(emissionRate * lengthVariance);
flatVector = newVector * (trajectorySpeed * lengthVariance);
} else {
flatVector = zVector * trajectorySpeed;
}

flatPos += flatVector;
Vec3f targetVector = endPos - startPos;
Vec3f currentVector = flatPos - startPos;

//if (endPos.dist(flatPos) <= flatVector.length() || endPos.dist(pos) > endPos.dist(lastPos)) {
// pos = endPos;
// state = sPlayLast;
// model = NULL;
//} else
{

// ratio
float t = clamp(currentVector.length() / targetVector.length(), 0.0f, 1.0f);

// trajectory
switch (trajectory) {
case tLinear:
                {
pos = flatPos;
}
break;

case tParabolic:
                {
float scaledT = 2.0f * (t - 0.5f);
float paraboleY = (1.0f - scaledT * scaledT) * trajectoryScale;

pos = flatPos;
pos.y += paraboleY;
                }
break;

case tSpiral:
                {
pos = flatPos;
pos += xVector * cosf(t * trajectoryFrequency * targetVector.length()) * trajectoryScale;
pos += yVector * sinf(t * trajectoryFrequency * targetVector.length()) * trajectoryScale;
                }
break;

case tRandom:
                {
                    if (flatPos.dist(endPos) < 0.5f)
                    {
                        pos = flatPos;
                    }
                    else
                    {
                        pos = flatPos;
                        //pos += xVector * cos(t*trajectoryFrequency*targetVector.length())*trajectoryScale;
                        //pos += yVector * sin(t*trajectoryFrequency*targetVector.length())*trajectoryScale;
                    }
                }
break;

default:
assert(false);
}
}

direction = pos - lastPos;
direction.normalize();

//arrive destination
        if( flatPos.dist(endPos)<0.5f ){
state= sFade;
model= NULL;

if(particleObserver!=NULL){
particleObserver->update(this);
}

if(nextParticleSystem!=NULL){
nextParticleSystem->setState(sPlay);
nextParticleSystem->setPos(endPos);
}
}

/*
if (state == sPlayLast) {
if (particleObserver) {
particleObserver->update(this);
}

if (nextParticleSystem) {
nextParticleSystem->setState(sPlay);
nextParticleSystem->setPos(endPos);
}
}
*/
}

ParticleSystem::update();


[wciow]

The random particles was added by Daniel to try to make a lightning type attack for FPM. Not sure if it was entirely succesful and is marked as 'experimental' in the wiki.

Did you remove the new particle blend methods? These were added to allow black particles and other interesting stuff thru opengl.

https://docs.megaglest.org/GAE/Projectile_Particle_XML

[hailstone]

In 0.2.x I've made it so when a crash occurs it takes a screenshot of just before it crashed. It might be good to save last input too (mouse click or keyboard).

[softcoder]

The ONLY thing I changed was the method I mentioned (which I am pretty sure doesn't affect most of the new stuff that I saw all over the place. I "think" it might have fixed the red arrow lingering around also that was mentioned by Titi (but haven't confirmed 100%).

So far I have fully ported all the work I put into mega-glest including:

- Full network play
- Chatting supporting when connected in the lobby
- Optional data synch check (checks server vs client to see if the map, tileset and XML content matches on both server and clients)
- New no_recoup property for static resources (previously discussed in the forums)
- Fixed up particles

All this is being done on the 3.2.2_network branch. I hope to confirm everything as working in the next few days.

EDIT:

Ok, so its becoming impossible to reliably test the networking code as we constantly have GAE crashing with:

SIGSEGV: address not mapped to object

There is definitely a stability issue with the 3.2.2_network branch (not sure if there is a problem with other branches, but I have all my network code merged into this one).

Does anyone else have crash problems with GAE (windows or linux) and if so (or not) please tell me what version you are running.

P.S. Titi:

@softcoder: What do you use to develop c++ in linux? I have serious problems setting up eclipse for GAE. There are so many needed switches to compile and mabe other things I don't know yet.  Undecided

I use CodeBlocks as my C / C++ editor, and I compile using jam commandline.

Thanks

[silnarm]

There is definitely a stability issue with the 3.2.2_network branch (not sure if there is a problem with other branches, but I have all my network code merged into this one).

Does anyone else have crash problems with GAE (windows or linux) and if so (or not) please tell me what version you are running.

I've just played a game through with 0.2.x branch and another with 3.2.2_network, no crash. I then rigged up my working copy of 3.2.2_network to render nothing but the debug info, setup an all AI scenario, and cranked the update fps up to 200.  When the game started I promptly set it to fastest speed and watched the numbers... it ran for over 250,000 frames before player2 emerged victorious, that's the equivalent to about 105 minutes of play at normal game speed.  This is on windows of course.

I'll try some more tests with different maps and tech-trees, but I don't seem to be able to get this crash on windows 

[jda]

I think we need a linux startscript like original glest. this adds libs to LD_LIBRARAY_PATH and so on and changes to the right directory for the start.

Do you mean like the one Ubuntu places in /usr/games/?
If so, I did something like that a while back, when I first installed GAE, compiled from source. Here it is:
https://forum.megaglest.org/index.php?topic=4375.msg30327#msg30327 (scroll down to the GAE script)
It's basically the glest script renamed and with directories' locations changed (as well as one or two specific to gae added in). It's incomplete  (namely regarding the language files) but it may be handy to start off from and has been working in my system just fine.

Its fading away here too, but if you click on a building and the transparent red arrow shows to the middle of the building, this red arrow shows the upper left corner of the unit. In my opinion thats not good and it should be like in original glest where this non transparent arrow doesn't show up.

No! I think it's useful and I like it and I'll make a BIG FROWN if it's removed! 
But to be honest, I don't need it if I'm just directing the unit to another unit or building. So, if that presents a problem, instead of placing it above the unit as Archmage suggested, I'd rather have it removed (I personally think placing it above the unit would actually make it look a lot worse and confusing).

BTW, very glad to see you working on GAE, titi (and softcoder too) and bringing the goodness of megalest to gae!
Also, as wciow (I think) said on a topic about megaglest, I fear the two forks may stear too far away from each other and be a loss to both.
I did follow, rather scarsely, the birth and development of megaglest and am glad it was started though I haven't had the time to comment or even download it...

[titi]

For the red arrow problem: I'm only talking about the red arrow when ATTACKING a unit! In general this is a good arrrow that helps playing. I would only remove it in the case of a an attack command.

For the particle problem found by softcoder:
I don't have these problems here with gae ( latest 0.2.x )

For my particle works:
Currently I'm using megaglest, because I still have serious problems with GAE in eclipse . I had to finish it, because I cannot take a break in the middle of my work. Now its working
features are:
- you can define particles for every skill of a unit
- you can set teamColor for color and colorNoEnergy
- you can set an offset for the partikles ( useful for a unit with a flamethrower for example which has real flame , or dust behind the units )
- you can choose if this offset is bend to the rotation or not
- you can give a direction for the particles
....

currnently there is only a flamelike particle system available. Maybe i will add more after its migrated to GAE.
here is an example xml-file for setting up unit_particles:

Code: [Select]

<?xml version="1.0" standalone="yes"?>

<unit-particle-system>
     <texture value="true" path="../dark_mage/images/particle.bmp" luminance="true"/>
<primitive value="quad"/>
<offset x="0" y="0" z="0.5"/>
<direction x="0" y="1" z="0"/>
<color red="0.0" green="0.0" blue="1.0" alpha="0.8" />
<color-no-energy red="0.0" green="1.0" blue="0.0" alpha="0.6" />
     <radius value="1.0" />
     <size value="0.3" />
     <size-no-energy value="0.3" />
     <speed value="4.5" />
<gravity value="0.5"/>
     <emission-rate value="5" />
     <energy-max value="50" />
     <energy-var value="0" />
     <fixed value="false" />
     <relative value="true" />
     <teamcolorNoEnergy value="true" />
     <teamcolorEnergy value="false" />
</unit-particle-system>
Now for my eclipse setup problem:
I still get compileerrors in eclipse and I think any kind of switch is still not set :/  

Anyone has ideas for the following?
Its an error which is marked in line 186 in file game/types/flags.h

Code: [Select]

Multiple markers at this line
-instantiated from 'void Glest::Game::XmlBasedFlags<E, max, T>::
load(const Shared::Xml::XmlNode*, const std::string&, const Glest::Game::
TechTree*, const Glest::Game::FactionType*, const char*, const Shared::
Util::EnumNames<E>&) [with E = Glest::Game::Property, unsigned int
max = 3u, T = unsigned int]'
-instantiated from 'void Glest::Game::XmlBasedFlags<E, max, T>::
load(const Shared::Xml::XmlNode*, const std::string&, const Glest::Game::
TechTree*, const Glest::Game::FactionType*, const char*, const Shared::
Util::EnumNames<E>&) [with E = Glest::Game::EffectTypeFlag, unsigned
int max = 22u, T = unsigned int]'
-instantiated from 'void Glest::Game::XmlBasedFlags<E, max, T>::
load(const Shared::Xml::XmlNode*, const std::string&, const Glest::Game::
TechTree*, const Glest::Game::FactionType*, const char*, const Shared::
Util::EnumNames<E>&) [with E = Glest::Game::Field, unsigned int max =
5u, T = unsigned int]'
-instantiated from 'void Glest::Game::XmlBasedFlags<E, max, T>::
load(const Shared::Xml::XmlNode*, const std::string&, const Glest::Game::
TechTree*, const Glest::Game::FactionType*, const char*, const Shared::
Util::EnumNames<E>&) [with E = Glest::Game::Zone, unsigned int max
= 3u, T = unsigned int]'
-Line breakpoint: flags.h [line: 186]
-instantiated from 'void Glest::Game::XmlBasedFlags<E, max, T>::
load(const Shared::Xml::XmlNode*, const std::string&, const Glest::Game::
TechTree*, const Glest::Game::FactionType*, const char*, const Shared::
Util::EnumNames<E>&) [with E = Glest::Game::AttackSkillPreference,
unsigned int max = 5u, T = unsigned int]'

[ElimiNator]

Yes that needs to get fixed, I hate it that the arrow goes to the top left corner.
It should go in the midel.