Author Topic: To Do List & Bugs  (Read 40620 times)

John.d.h

  • Moderator
  • Airship
  • ********
  • Posts: 3,757
  • I have to go now. My planet needs me.
    • View Profile
Re: To Do List & Bugs
« Reply #50 on: 7 January 2009, 22:22:24 »
Quote from: "daniel.santos"
So like a bridge to travel across bodies of water, or gullies (the new cliff feature we're talking about for 0.3 & the new map format)?
I think bridges are a MUST when it comes to the cliff feature.  "Should they be build-able/destructible or should they come with the map?" I wonder.

mictes

  • Guest
Re: To Do List & Bugs
« Reply #51 on: 8 January 2009, 13:47:28 »
They should come with the map, but the should be destructible. The technician / archmage could repair bridges.

RTSman

  • Guest
Re: To Do List & Bugs
« Reply #52 on: 11 January 2009, 23:06:13 »
you should be able to build them.  if they a crop of gold they you build bridge and you get there faster.  otherwise you have to walk around the river or if its a ditch then that instead.

daniel.santos

  • Guest
Re: To Do List & Bugs
« Reply #53 on: 14 January 2009, 02:53:35 »
methinks two solutions are necessary for proper game play.  First, there should be indestructible bridges that you can add to a map.  Second, the support for "walk-able units" (originally targeting defensive wall type of units) should be used to support mods who wish to allow bridges to be built.  So it mainly sounds like the new map format will need support for bridges.

Also, adding cliffs does not *mandate* that bridges be supported, although I would concur that it would be limiting not to have them if you could make cliff walls in a game.  Most probably, bridges (in a map) should be implemented such that they do not need to have the same start and ending height, and probably need fairly broad definitions to allow them to arch and such.  That concept will have to be discussed and refined.

@kukac@

  • Guest
Re: To Do List & Bugs
« Reply #54 on: 14 January 2009, 14:25:57 »
What will be the main function of bridges? Solute transfer between cliffs? Will we be able to use it between normal hills? Will be building possible on a bridge?
« Last Edit: 17 January 2009, 17:33:42 by @kukac@ »

hailstone

  • Local Moderator
  • Battle Machine
  • ********
  • Posts: 1,568
    • View Profile
Re: To Do List & Bugs
« Reply #55 on: 19 January 2009, 00:27:23 »
Will building be possible underneath a bridge?
Glest Advanced Engine - Admin/Programmer
https://sourceforge.net/projects/glestae/

@kukac@

  • Guest
Re: To Do List & Bugs
« Reply #56 on: 19 January 2009, 16:54:30 »
Well, I think under the bridge isn't something different than the normal terrain: if there is enough place, of course!

modman

  • Guest
Re: To Do List & Bugs
« Reply #57 on: 20 January 2009, 02:37:21 »
I think I like the idea most of some bridges being default with the map, but also bridges should be built as well.
Workers should build them with the "build advanced" command, and Initiates with the ritual.
Maybe the two could look different.  That way it would be possible that you can only go over bridges of your faction.

Anyone could go over a bridge that came with the map.

@kukac@

  • Guest
Re: To Do List & Bugs
« Reply #58 on: 20 January 2009, 16:55:58 »
Oh, one more thing: can units shoot through the bridges?

modman

  • Guest
Re: To Do List & Bugs
« Reply #59 on: 21 January 2009, 02:18:45 »
Not allowing that would require quite an advanced physics engine and also a bunch of info about coordinates of bridges.

Daniel, you spoke of creating bonuses for terrains and a revamp of the attack formulas; those are really only good for turn-based games, I believe.

Archmage

  • Guest
Re: To Do List & Bugs
« Reply #60 on: 26 January 2009, 23:22:28 »
This might be off topic, but i have an idea...

make it so that the different times of the day will give attack and defense bonuses. (like wesnoth)

So at night Knights (soldiers) are weaker and bemoths are stronger...

modman

  • Guest
Re: To Do List & Bugs
« Reply #61 on: 27 January 2009, 02:56:46 »
This was covered somewhere...
That is mainly used for turn-based games where aspects like that are more relavent.  In an RTS game, you would more likely just wait out the night to attack.  Plus, Tech and Magic are already out of balance enough.

gameboy

  • Guest
Re: To Do List & Bugs
« Reply #62 on: 27 January 2009, 14:19:25 »
The idea was give by me.
Also i think continuous attacks should be implemented, like for the flamethrower.

modman

  • Guest
Re: To Do List & Bugs
« Reply #63 on: 28 January 2009, 22:38:19 »
Another thing dearly needed: minimum attack range.  It's rediculous that an archer is still shooting at a swordsman once it reaches the Archer.  This would force the AI to use secondary attacks, for instance like in Aryin's model; I believe he had a secondary sword.  There are so many times I thought of this, but this is the first time it has been mentioned by me.

John.d.h

  • Moderator
  • Airship
  • ********
  • Posts: 3,757
  • I have to go now. My planet needs me.
    • View Profile
Re: To Do List & Bugs
« Reply #64 on: 29 January 2009, 06:48:17 »
Another thing dearly needed: minimum attack range.  It's rediculous that an archer is still shooting at a swordsman once it reaches the Archer.  This would force the AI to use secondary attacks, for instance like in Aryin's model; I believe he had a secondary sword.  There are so many times I thought of this, but this is the first time it has been mentioned by me.
I agree.  I thought about this when I played Demonionic (or whatever it's called).  One of the ranged units has a bayonet attack, but he only uses it if you tell him to, even though it would be to his advantage to do so.  It could go the other way around, too, where the unit's melee attack would be weaker than its ranged one.  Most archers probably wouldn't have a sword anyway, but maybe a dagger or a hatchet or something.  This would make highly-mobile units like cavalry even more effective against archers.  The sooner you can get into melee range with the archer, the sooner he has to stop shooting you and pull out the brass knuckles.

gameboy

  • Guest
Re: To Do List & Bugs
« Reply #65 on: 29 January 2009, 10:49:11 »
in my elf faction the archers have a melee attack, they use The White Knives the one which Legolas uses in LOTR.

modman

  • Guest
Re: To Do List & Bugs
« Reply #66 on: 31 January 2009, 03:41:41 »
Importance: RED!  Very Important.

modman

  • Guest
Re: To Do List & Bugs
« Reply #67 on: 9 February 2009, 02:55:48 »
Another thing is that I want Glest to terminate only after it finds all the errors in a faction, then save a file to the Glest directory.  This would help sooo much with faction making.

hailstone

  • Local Moderator
  • Battle Machine
  • ********
  • Posts: 1,568
    • View Profile
Re: To Do List & Bugs
« Reply #68 on: 9 February 2009, 07:24:18 »
I agree. Another common thing game developers do is have obvious stand-in textures for missing ones so they can be visually seen and fixed without getting in the way of other testing.
Glest Advanced Engine - Admin/Programmer
https://sourceforge.net/projects/glestae/

@kukac@

  • Guest
Re: To Do List & Bugs
« Reply #69 on: 9 February 2009, 17:22:22 »
Make a debug mode for Glest. It's harder to make, but can save more time later. (But who am I to give orders for anyone  ::) )

daniel.santos

  • Guest
Re: To Do List & Bugs
« Reply #70 on: 15 February 2009, 10:32:19 »
Another thing dearly needed: minimum attack range.  It's rediculous that an archer is still shooting at a swordsman once it reaches the Archer.  This would force the AI to use secondary attacks, for instance like in Aryin's model; I believe he had a secondary sword.  There are so many times I thought of this, but this is the first time it has been mentioned by me.
It is already possible to configure a composit attack command that will execute different attacks based upon things like range to target.  Take a look at the battle mech and Lich in the FPM mod for example XML.  However, I want support for ranged units to actually back away from their targets and attempt to fire at max range!  I can't remember if I've already opened  an enhancement request for that or not. But I do know that I have already begun to accomodate this functionality in 0.3 in the new AttackSkillPreferences class (see https://glest.codemonger.org/svn/repos/gae/branches/0.3/source/game/types/command_type.h and also the TargetingRules class in https://glest.codemonger.org/svn/repos/gae/branches/0.3/source/game/types/skill_type.h for an idea of the flexibility that's coming)

Another thing is that I want Glest to terminate only after it finds all the errors in a faction, then save a file to the Glest directory.  This would help sooo much with faction making.
Yea, I agree, but it's a real pain in the arse!  The issue is that the initialization of one object is often dependent on the initialization of an object before it.  But I know it makes things a real pain when modding because you have to keep restarting the game to find each new error! :(  So maybe you can open an enhancement bug for this idea please.

On a related topic, you may be glad to know that 0.2.12's will support telling you which files do not match when playing a network game rather than just saying that your files don't match!

Make a debug mode for Glest. It's harder to make, but can save more time later. (But who am I to give orders for anyone  ::) )
Yea, maybe this is the solution.  Maybe if you define DEBUG_XML when compiling then it will support this?  I don't want this in two different places though because that would be a maintenance nightmare.  Perhaps if DEBUG_XML is defined and an option is added to the .ini then it will attempt to accumulate all of the errors and display them at the end.  However, there are a lot of issues that can happen if one load fails, it can create cascading problems, so it may be easiest to implement if we have the basic contract that it may not be as stable with that .ini "debug xml" setting on.

I agree. Another common thing game developers do is have obvious stand-in textures for missing ones so they can be visually seen and fixed without getting in the way of other testing.
Yea, that sounds like a good idea.

Finally, Bridges:
My answer is that I don't really know right now (to most of the questions).  This is probably best discussed in the Requirements: new map format thread.

MirceaKitsune

  • Technician
  • ****
  • Posts: 147
    • View Profile
Re: To Do List & Bugs
« Reply #71 on: 3 June 2009, 22:48:41 »
I found a rare bug which permanently disables keys in the GAE 0.2.11 engine (Windows). Since I'm not sure which bugtracker is currently used and should avoid making a topic for each bug, I thought to post about it here too if that's ok. These are the steps to reproduce:

1 - Set MiscDebugKeys=true in glestadv.ini. Not sure if it changes anything but DisplayWindowed=false here.

2 - Start the game normally and enter a custom match. Make sure all your keys work and the console prints Key = Command every key press.

3 - Press the right Windows logo key (it must be the right key not the left one). The game should pause and the windows start menu will appear over the game. Left click back into the game and the start menu disappears as the game is resumed.

4 - Press the esc key while watching the console. Instead of going into the "Exit game?" menu nothing happens and keys don't work any more. The console now prints Meta+Key for every key you press, meaning that it sees an nonexistent button (meta) being held down. If this doesn't happen from the first key keep pressing many buttons especially esc.

To repair this issue you must follow the same steps, press the right windows logo key and let the start menu pop up then go back and the keys are toggled fixed. Nothing else seems to repair the issue once it happens, not even reinstalling the game or restarting the computer makes the imaginary button go away. I'm not sure if this might be based on the keyboard model too, mine is an Apollo multimedia keyboard though I don't think it's related to that. Here's a screenshot of the issue:


hailstone

  • Local Moderator
  • Battle Machine
  • ********
  • Posts: 1,568
    • View Profile
Re: To Do List & Bugs
« Reply #72 on: 4 June 2009, 02:59:57 »
I'm not sure if that was the intended behavior but it occurs in share_lib/include/platform/input.h

bool isMetaDown() const      {return GetAsyncKeyState(VK_LWIN) || GetKeyState(VK_RWIN);}
changed to
bool isMetaDown() const      {return GetAsyncKeyState(VK_LWIN) || GetAsyncKeyState(VK_RWIN);}

Seems to solve it. With that it requires you to hold down the RWIN key to have Meta+ . Is this the behavior people want?

http://msdn.microsoft.com/en-us/library/ms646301(VS.85).aspx
http://msdn.microsoft.com/en-us/library/ms646293(VS.85).aspx
Glest Advanced Engine - Admin/Programmer
https://sourceforge.net/projects/glestae/

MirceaKitsune

  • Technician
  • ****
  • Posts: 147
    • View Profile
Re: To Do List & Bugs
« Reply #73 on: 4 June 2009, 11:20:37 »
I'm not sure if that was the intended behavior but it occurs in share_lib/include/platform/input.h

bool isMetaDown() const      {return GetAsyncKeyState(VK_LWIN) || GetKeyState(VK_RWIN);}
changed to
bool isMetaDown() const      {return GetAsyncKeyState(VK_LWIN) || GetAsyncKeyState(VK_RWIN);}

Seems to solve it. With that it requires you to hold down the RWIN key to have Meta+ . Is this the behavior people want?

From my understanding that's how it should be I think. Probably there was a typo and Async got forgotten last time.
« Last Edit: 4 June 2009, 11:22:22 by MirceaKitsune »

hailstone

  • Local Moderator
  • Battle Machine
  • ********
  • Posts: 1,568
    • View Profile
Re: To Do List & Bugs
« Reply #74 on: 6 June 2009, 08:53:31 »
I've committed the change now and closed the bug. r33 in trunk
Glest Advanced Engine - Admin/Programmer
https://sourceforge.net/projects/glestae/

 

anything