Messages

76

Feature requests / Re: Attack Location

« on: 27 June 2011, 11:12:00 »

Yeah, I thought it might be wise after we added cloaking, and it obviously have other uses... like big missles 

Existing ticket: 267.

77

General discussion / Re: Time and production speed

« on: 27 June 2011, 11:07:57 »

The code you found for production time is actually the code to "calculate" the text for the tool-tip. That's the best you're gonna get though, if you want a one liner. The actual relevant calculations are the number frames per skill cycle, which is modified by a 'total enhancement' that is cached within the Unit class via inheriting from EnhancementType.

 In the snippet hailstone posted The 'speed' is the 'incoming' skill-speed (from xml) and unit->getXxxxSpeedMult() and unit->getXxxxSpeed() are the cached total multipliers and static modifiers of all current upgrades, level, effects, etc on the unit.

And yes, the 40 you found should indeed be WORLD_FPS, thanks for pointing that out (the ini option doesn't do anything these days though, its always 40, I meant to change it back for the debug edition, but don't think I ever got around to it...)

Some of this was touched on here, will try to dig up what I had for that sometime.

78

Bug reports / Re: [Fixed] BUG - Unseen objects still harvestable/selectable

« on: 27 June 2011, 10:49:46 »

fixed, those tiles are now stripped of objects and the corresponding cells marked as untraversable in all fields (so no units walking or building there either).

79

Feature requests / Re: Making better looking environments

« on: 20 June 2011, 21:36:04 »

The downfall of glest's environments I think is because the tile system is so obvious, one way to change this is with tucho's idea:

If Glest had only 4 'surface types' rather than 5, then I reckon I would have done this shortly after tucho suggested it. Even then I was concerned with the extra memory it would eat, but I was thinking inside a box... see reply to Philip below.

Can a ticket please be made for these two features? I'm not a coder but they sound relatively straight forward. 

You'll get your tickets (although I think there is already one for a new terrain render/splat system), but beware the "I'm not a programmer, but this seems simple" comments. Nothing is a simple as it sounds, a good idea is worth little compared to a good implementation, and the former does not guarantee the later.

Another thing which has been suggested before, bump maps on ground textures. Normal maps are already implemented in GAE so I'm not sure easy it would be to implement. But I beleive it would be far more worthwhile than putting bump maps on units, I could cite many examples of how nice this would be; but I'm sure you all know already.

Yes.  This.  Terrain with depth looks amazing compared to the flat, painted-on stuff we have.

I'm happy to get it rigged up and let people experiment, but considering the terrain will generally fill the entire field of view, the performance hit which be much more noticeable.

The renderer then just looks for all tiles that share some particular texture, picks the appropriate alpha-blending shape for tiles adjacent to the ones with that texture, sticks everything into a VBO with the base texture using one set of texcoords (allowing arbitrary scaling and rotation just by transforming those texcoords) and the blend texture selected from an atlas with another set of texcoords, then repeat for every base texture in the map, and render by drawing each layer on top of the previous ones.

Multi-pass... of course! I feel a little foolish now, I was blindly seeking a one pass solution and the amount of extra UV coords I would need to make that work was a major issue, and it also would have required the 'tile type' as a vertex attribute and then numerous conditionals in the shader (not a good thing).

Building the texture up in multiple passes removes both these problems, and indeed the need to implement it using a shader.

Many thanks Philip!

80

Forum discussion / Re: SMF 2.0 - First Looks

« on: 17 June 2011, 08:07:03 »

My personal recommendation is to wait, to ensure the board is still the board we remember, and not a generic hospital theme.

+1 ... It looks too nice as is, the generic 'no theme' would be a massive disappointment now

81

General discussion / Re: Documenting Widget.cfg

« on: 17 June 2011, 08:04:49 »

Is there any documentation for the widget layout code? I made a bit of a mess of the options tabbing using trial and error.

I have been meaning too, honest! 

Looks like you did a pretty good job anyway, the buttons didn't have anchors set (see commit 6bdde7749) which was causing them to wander off when the frame was moved.

I found most of the errors I made were due do not setting SizeHints or Anchors, or setting them incorrectly.

Will get a overview on using CellStrips together, but I have mate visiting until Sunday... so I'll probably mostly have an xbox controller in my hands for the next couple of days , hopefully get it done on Sunday.

82

General discussion / Re: 0.4 beta2 (windows installer)

« on: 17 June 2011, 07:58:02 »

Ok, there appears to be something wrong with terrain renderer 2,

disable in options menu, or if like cds this proves impossible, manually change in glestadv.ini

Code: [Select]

RenderTerrainRenderer=1

@Psychedelic_hands
Could you please post the contents of glestadv.log & stdout.txt (both found in you config dir, one folder up from addons).

83

General discussion / Re: [Fixed] Sight upgrade won't upgrade detection radius

« on: 16 June 2011, 22:23:21 »

Yes, the new beta has the fix

The commit hash (d59c4b4..) identifies which code revision the fix was in, you don't really need to worry about it, its more for future reference for us, if it appears the fix is not working correctly then we can go straight to the revision and double-check the changes (or just revert them and try again ).

84

General discussion / Re: 0.4 beta2 (windows installer)

« on: 16 June 2011, 22:17:52 »

I'm not getting the crash on return-to-menu either, and hadn't noticed any odd looking tileset objects... but probably just need to try some other tilesets for that.

What video cards are you guys using?  I haven't tried on an NVidia in a while, will try that later.

@Omega: The build date is provided by the OS, it should be correct, I have no idea what is going on there! (Its correct for me in debug & release).

85

General discussion / 0.4 beta2 (windows installer)

« on: 16 June 2011, 16:00:30 »

0.4 Beta 2

Windows Installer (~70MiB)

Important: If you have gae-0.4-beta1-data.zip in your  addons folder, delete it!

86

General discussion / Re: Documenting Widget.cfg

« on: 16 June 2011, 15:38:23 »

Also someone needs to make a standalone installer for GAE 0.4 for people who don't compile. I'm currently still using the 0.4 beta snapshot which is bolted to an old install thru the addons folder  and is really buggy. The wierdest bug is that tilesets only load the first model in each set and align them all in the same way, kinda annoying as I'm trying to design a new tileset atm 

Ooops, don't know how I missed that.. Fixed. and a 0.4-beta2 with installer is on the way.

87

General discussion / Re: Problem with turning turrets after attack command

« on: 16 June 2011, 12:29:09 »

I recall having been  frustrated in the past that you couldn't select targets with the attack-stopped command... this would be a good feature request I think.

88

General discussion / Re: Documenting Widget.cfg

« on: 16 June 2011, 12:25:49 »

Just one question, it says the colors can be written as:

(0xRRGGBBAA, or #RRGGBBAA, or RRGGBBAAh).

The last one has a rather out of place looking "h" at the end. Just checking whether this is supposed to be there or if it's a typo.

That's just one of numerous semi-standard ways to write a hexadecimal number, I chose to support as many common ones as I could think of

We can expand on it later, now that it's at a publicly editable location, where everyone can edit without even making an account [Wiki advertising goes here].

Thanks for getting that up, I'll certainly look to add to it myself as time permits, but in the meantime if anyone else is playing around with widget.cfg, please feel free to help out!

PS: I see we have a page for translations now too, Thanks!

89

General discussion / Re: Sight upgrade won't upgrade detection radius

« on: 16 June 2011, 03:31:22 »

Yep, that's a bug alright  

You assumed correctly, it is meant to be tied to sight.

Thanks for the top-notch bug report

Edit: Fixed with commit d59c4b4..

90

General discussion / Re: WxWidgets

« on: 16 June 2011, 03:29:39 »

This will result in link errors, we static link the crt which is not the norm, the libraries distributed with wx will dynamic link it.

Use the windeps_tools we provide (extract with the other deps).

91

General discussion / Re: Documenting Widget.cfg

« on: 16 June 2011, 03:25:29 »

A bit rough, and possibly with an error or two, but here's a start,

Code: [Select]

=Setup functions=

==addColour(name, colourString);==
  Add a named colour. The name should be unique and the colourString is a hexadecimal
  representation of the colour (0xRRGGBBAA, or #RRGGBBAA, or RRGGBBAAh).
 
==loadTexture(name, path, mipmap);==
  Load a named texture. The name should be unique and path is the complete path to the
  desired image file from the 'root' glest directory.  An optioinal boolean 'mipmap'
  tells the engine whether to generate mipmaps for the texture or not, if omitted the
  defualt value is true, and this is generally appropriate, textures with 'fine detail'
  (such as those used for borders) being the exception to the general rule.

==setOverlayTexture(type, texName);==
  The three texture overlays used on auto-command toggles are set via this function,
  it should be called three times with type 'tick', 'cross', & 'question'. The texName
  parameter is a previously loaded texture.

==loadFont(name, path, size);==
  Load a named font. The name should be unique and path is the complete path to the
  desired font file from the 'root' glest directory. The size parameter sets the size
  in points. NOTE: size will not be exactly respected, and is scaled based on the
  window size/resolution the user is playing the game with.

==setDefaultFont(type, fontName);==
  Set default and fallback fonts, should be called four times, with types 'menu', 'game',
  'title' & 'version'.  The menu and game fonts are fallbacks for text styles that are
  missing fonts, while title and version are used only for the 'advanced engine' and
  version labels on the root menu.

=Style definitions=

WidgetType = {
Default = { --[[ Style definition for default state ]] },
States = {
Disabled = { --[[ style definition (or 'overrides') for disabled state ]] },
Hover = { --[[ style definition (or 'overrides') for hover state ]] },
Focus = { --[[ style definition (or 'overrides') for focus state ]] },
Selected = { --[[ style definition (or 'overrides') for selected state ]] },
},
}

The default state determines a widgets 'normal' look, the tables within the States table
determine their appearance in various behavioural states, any individual style elements
that are not specified in a special state are copied from the default state.

A style definition consists of a table each for borders, background, highlight, text and
overlay.

==Borders==
Type: A border style must contain a Type field, which must be one of 'none', 'invisible',
'raise', 'embed', 'solid', 'custom-sides', 'custom-corners' or 'texture'.
Sizes: If the Type is anything other than 'none', then a sizes table should be included,
if not type texture it should contain four integers for the left, top, right & bottom
border respectively, for type texture it should contain two integers for the side and corner
size.
Colours: A table of one to four named colours, used where type is solid (single colour), raise
or embed (two colours, light and dark respectively), custom-sides or custom-corners (four
colours, [left, top, right, bottom or top-left, top-right, bottom-right, bottom-left). Not
used for types none, invisible or texture.
Texture: A named texture, used only for type texture.

==Background==
Type: A background style must contain a type, which should be 'none', 'colour', 'custom-colours'
or 'texture'.
InsideBorders: boolean value indicating whether the background should be rendered only within
the widgets borders, or over the entire widget's size.
Colours: A table of one or four named colours, used where type is colour (single entry) or
custom-colours (four values: top-left, top-right, bottom-right, bottom-left).
Texture: named texture to use if type is texture.

==Highlight==
Type: Style type, one of 'none', 'oscillate' or 'fixed'.
Colour: a named colour for the highlight.

==Text==
Font: A named font that this widget should use for any text.
Colour: A named colour to render the font in.
Shadow: boolean value indicating whether text should be shadowed.
ShadowColour: a named colour the shadow should be rendered with.

==Overlay==
Texture: a named texture identifying the overlat image.
InsideBorders: boolean value indicating whether the overlay should be rendered only within
the widgets borders, or over the entire widget's size.

=Widget Types=

The folloeing is a list of tables the engine looks for to style certain widgets,

StaticWidget
Button
CheckBox.Checked
CheckBox.UnChecked
TextBox
ListItem
ListBox
DropList
ScrollBar
ScrollBarButtonUp
ScrollBarButtonDown
ScrollBarButtonLeft
ScrollBarButtonRight
ScrollBarVerticalShaft
ScrollBarVerticalThumb
ScrollBarHorizontalShaft
ScrollBarHorizontalThumb
Slider
SliderVerticalShaft
SliderVerticalThumb
SliderHorizontalShaft
SliderHorizontalThumb
TitleBar
TitleBarCloseButton
TitleBarRollUpButton
TitleBarRollDownButton
TitleBarExpandButton
TitleBarShrinkButton
MessageBox
GameWidgetFrame
ToolTip
ToolTip.Header
ToolTip.Main
ToolTip.Item
ToolTip.RequirementMet
ToolTip.RequirementNotMet
ColourPicker
ColourButton
TickerTape
InfoWidget
Logger
Logger.Header
Logger.LogLine
CodeView
CodeEdit
ResourceBar
MiniMap
Display
Console
GameStats


92

Bug reports / Re: Addons cannot change menu model, about models, language strings, etc...

« on: 13 June 2011, 07:50:00 »

Where are you putting the addons ?

Addons are expected in,

 $(CONFIG_DIR)/addons

93

General discussion / Re: How the "tip" on <name> works?

« on: 11 June 2011, 22:02:24 »

hi lazyanttu,

  The 'tip' strings are looked up in the faction lang file, this is a separate lang file that is located in techs/my_tech/factions/my_faction/ and should be named my_faction_en.lng,  changing "my_faction" and 'en' as needed, of course

  You can also include a tech wide lang file, techs/my_tech/my_tech_en.lng, in theory when a unit/command/level/etc name needs translating, it is looked up in the relevant faction lang file first, if not found there then it looks in the tech lang file, and if its not there then it would be looked up in the global lang file.

  I say 'in theory' because there are likely numerous places where this doesn't happen atm, so if you notice anything you think may be wrong, please don't be shy, take a screen-shot and post it up, chances are it is an error and simply hasn't been noticed yet.

Cheers.

94

Mods / Re: bit of help with wheels and rotors please?

« on: 3 June 2011, 11:48:04 »

Oh wow, I can answer a blender question...

In blender meshes marked as 'two sided' will be exported as team-colour meshes, and those not so marked will just use the regular rgba from the texture (both will result in two-sided meshes in Glest).

https://forum.megaglest.org/index.php?topic=6501.msg66401#msg66401

95

General discussion / Re: How to specify version

« on: 3 June 2011, 11:16:19 »

Anyway we already set the version in cmake through projectConfig.h, so maybe it's better to do it in cmake. Something like this:

I think the big problem doing it that way is the overhead of modifying a header each build. The script way completes in under a second.

Edit:
It might be good to add other information like build_platform and build_configuration.

It might also be good to write build_git_sha into the log files too (and send to stdout as well maybe).

96

General discussion / Re: Addons can't overwrite global language string?

« on: 3 June 2011, 11:12:35 »

0.4beta1, the Military addon does not seem to be able to overwrite the global language string. I even tried removing the language file in the upgrade addon for 0.4, with no success. It just seems to be completely ignored.

Are you sure they are named correctly ("en.lng")... the ones in your beta were not so named...

97

Bug reports / Re: [Fixed] Latest GIT: Texture Rendering Delay?

« on: 3 June 2011, 11:10:49 »

Problem was that the team colour wasn't set (or initialised with anything sensible) until in-game or until the about models were rendered.

Fixed in git#357d7cc.

98

Mods / Re: bit of help with wheels and rotors please?

« on: 3 June 2011, 10:07:13 »

<partial-off-topic>

Interesting fact:  Glest once supported animated texture co-ordinates.

I discovered this while building G3dHack, the only model in magitech with such data is wicker_behemoth_morph.g3d, but you wont see the effect in game because support for it was removed in the engine. (But I implemented it in G3dHack, because I was very curious, so if anyone wants to check it out, load up wicker_behemoth_morph.g3d, set anim speed to about 50 and press play).

Doesn't look fantastic for the wicker behemoth, but I bet it would be great for this: ie, static wheel geometry, with animated texture on the sides.

Of course the blender exporter doesn't support this anyway, so its largely a moot point. But maybe something to consider bringing back in the future.

</partial-off-topic>

Edit: Will actually beat me to this, but I missed his thread from dec... .https://forum.megaglest.org/index.php?topic=6291.0

99

General discussion / Re: Building the Git-Master for Military

« on: 3 June 2011, 09:57:39 »

Cloaks need to specify a 'group' they belong to (this determines which detectors can see them).

Code: [Select]

<cloak type='permanent'>
   <group value='stealth' />
   <!-- . . . -->
</cloak>

Detectors need a type now, but for now it must be 'permanent', and they need either a group node or a groups node, indicating which cloaks it can detect.

Code: [Select]

<detector type='permanent'>
   <group value='stealth' />
   <!-- . . . -->
</detector>

If you wish the detector to detect multiple cloak groups, specify <groups> instead of <group> and then put all required group nodes within that.

100

Bug reports / Re: [Fixed] GUI bugs, git master

« on: 3 June 2011, 09:51:07 »

Should be fixed now (git#36bbe7d..).