Messages

26

Bug reports / Re: Cloaking units not seen at all when shaders are on.

« on: 30 May 2012, 11:10:20 »

Cool, this was fixed already...

  Need to catch up on other bug reports and get some fixes in, I was planning to go straight to 0.4 from 0.3.93, but given the immense time lapse another beta might be a good idea, give it a couple of weeks.

27

Bug reports / Re: Cloaking units not seen at all when shaders are on.

« on: 27 May 2012, 02:16:02 »

Can anyone who is having this problem please let us know if they are using nVidia or ATI cards.

28

General discussion / Re: Audio: Ambience bug?

« on: 27 May 2012, 02:01:20 »

Can confirm this is indeed broken for me too, on Windows though, unsure about Linux, but I'd say go ahead and push it... will need to be cherry-picked across to the 0.4.x branch too.

29

General discussion / Re: Adding Resource Generation in XML

« on: 15 May 2012, 10:53:52 »

GAE code is poorly documented and hard to understand. As I have stated elsewhere it practically requires the search half of search and replace to get anything done.

GAE code is documented far better than original Glest, whether its documented well I will not presume to make judgement on, but to say it is poorly documented is poor form.  It is not a small code base, but also not huge, and it could certainly do with some more refactoring to clean up the design, but if you're not familiar with the code, then of course it is going to be tough to understand.

I don't know what this search and replace program you talk of is, but if you are searching outside of the IDE, then you're probably doing it wrong. Visual Studio has 'go to declaration' and 'go to definition' in the context menus when you right click identifiers, Code::Blocks has similar functionality with different nomenclature, I recommend making extensive use of them.

If you think this is going to be significantly different in other projects of similar size (and in particular open source projects with few developers) then you are only fooling yourself.

Welcome to the real world.

Apologies if that seems harsh, just calling it as I see it.

30

General discussion / Re: Adding Resource Generation in XML

« on: 14 May 2012, 20:59:35 »

The 'balance' is not what you think it is 

Use getAmount() & setAmount().

31

General discussion / Re: UnitId In registerEvent

« on: 14 May 2012, 20:47:06 »

Not entirely sure I follow what you are trying to do, but the unit that triggered the event has its id passed to the handler, if using an XML embedded handler, the param is called unit_id.

32

General discussion / Re: GAE Website

« on: 30 December 2011, 23:53:54 »

We also have this now.

If you're willing to make some content for it Omega, go for it!

33

Bug reports / Re: Selecting.

« on: 26 December 2011, 05:17:48 »

Just to let peeps know, I've started on a solution but it will not go into 0.4, not messing with the Renderer for 0.4 now, too risky

I'm using FBO (Framebuffer Objects) and MRT (Multiple Render Targets) for this, and we will end up with a kind of 'constant pick', so we will always know what's under the mouse... I've been playing lots of StarCraft2 recently and when testing GAE now I keep hovering the mouse over other units expecting to get health/progress bars, which of course I don't currently get, but I will in the future

If you pre-compute (on load) the bounds of each model, and model it as a sphere you can cheaply check if it could possibly intersect the selection ray, and so avoid rendering any models unnecessarily

If softcoder is going to use glReadPixels() for this in MG, then I heartily concur, and recommend he do so.  I like the MRT solution better myself (only because I want those niceties from SC2!).

34

Feature requests / Re: Organized Upgrades

« on: 11 December 2011, 16:28:03 »

Doable now.

https://docs.megaglest.org/XML/Commands#Upgrade

35

Bug reports / Re: Selecting.

« on: 5 December 2011, 21:08:33 »

We use OpenGL's 'name' based picking, which is probably the same thing in a technical sense.  I think it is happening every render the mouse is pressed, but considering how light-weight a selection render is it shouldn't make a large difference, certainly no where near the less than half frame-rate of the OP.

For me, the time taken by model rendering was jumping up and down randomly with a new game, no camera movement, all idle units etc... Fixed-pipe and shaders, so something is definitely wrong with model render in general.

36

Bug reports / Re: Minor font / widget issues on 1680x1050 resolution

« on: 5 December 2011, 20:43:20 »

Made the dialog boxes size dependant on resolution, seems to work fine for me now, please point out any other widget scaling/sizing problems though

I cannot switch to "windowed mode", i.e. the tickbox is always empty, but the games runs fullscreen. When I click on the tickbox, nothing happens, i.e. it does not become ticked and the game still runs in fullscreen mode.
And the resolution field is also always empty, even when I select another resolution. The new resolution works, but the field is still empty.

Hmm, is the new settings screen complete yet, even?

Works for me on WinXP and Win7, I think hailstone had issues though (on Win 7?) and it is definitely not complete for linux, hence the problem in this case, does anyone on windows have problems with switching fullscreen/windowed and/or changing resolution?

37

Bug reports / Re: Selecting.

« on: 5 December 2011, 20:37:01 »

I notice two issues with selecting when playing recently. The first is the when selecting a group units and you hold down the the left mouse button, theit icons on the left flicker and switch places. It's not a big deal, but looks totally shocking.

Agreed, and fixed.

Also, when you hold down the right mouse button to select my frame-rate goes down by over ahalf. It usually sits perfectly at 60 fps but slips down to about 24. Is this for any particalur reason, or is it something which could use tighting up?

I just went to try this myself and model rendering in general is all over the shop for me... probably related, will investigate further as time permits.

38

Bug reports / Re: Minor font / widget issues on 1680x1050 resolution

« on: 13 November 2011, 18:48:01 »

Hi macuser,

  The following function needs modifying,

Code: [Select]

int WidgetConfig::computeFontSize(int size) {
float sz = float(size);
float scale = g_config.getDisplayHeight() / 800.f;
sz *= scale;
if (sz < 10.f) {
sz = 10.f;
}
return int(roundf(sz));
}

Can be found in source/game/widgets/widget_config.cpp @ line 270.

I haven't noticed such problems myself, but I normally run it in a window so I can get at the debugger easier, in any case it seems ok with a window 600-800 px tall, so maybe a "piecewise" function is needed with different scaling should the display be >= 900 or something.

If you can find an appropriate scaling factor, please let us know and someone will make the change in the repo, else you may have to wait for one of us to get around to it, and atm it seems this could take a while .

39

General discussion / Re: WIP: New TMP-based Network Messages (for programmers)

« on: 4 November 2011, 23:20:57 »

Looks fairly nice, though I wont be looking anything up to figure out all that boost::mpl stuff any time soon

Have you considered how to handle collections yet?

I was working on a 'generic' serialisation / value-visiting framework a while back, abandoned in the end because it got really ugly (it was all macro based), but something that might be nice from it is using Reader/Writer objects to do all the 'work', so the classes modified (made serialisable) don't need read/write function pairs for multiple things (ie, network-buffer, xml-reader, table in lua-state, etc).

it went something like,

Code: [Select]

class Serialiser {
public:
    virtual void visitInt(const char *name, int value) = 0;
    virtual void visitFixed(const char *name, fixed value) = 0;
    virtual void visitVec2i(const char *name, Vec2i value) = 0;

    // for collections and sub-objects
    virtual void pushName(const char *) = 0;
    virtual void popName() = 0;
};


Not sure if it going to even be possible to do such a thing with what you've got, but would be nice to have, once everything has been modified to use the framework, 'serialising' to a Lua state is as simple as implementing a class LuaStateSerialiser : public Serialiser { ... }

40

General discussion / Re: Discussion on Effects

« on: 4 November 2011, 23:03:20 »

What exactly is it that causes issues with a multiplier of zero? I'm assuming it's because in this example, the effect's stacking is set to stack? Would it be better overwrite/extend, or is this something entirely different?

Skill cycles can't be interrupted and they are pre-calculated, this 'base' value is then modified for whatever 'enhancements' a particular unit has, and that's how long each cycle will take. This is done at the start of a new skill cycle, so if a unit has a move-speed multiplier of 0, then the cycle will be infinitely long (in reality it is capped, at 4095 frames I think it is, but that is still over 100 sec!).

This pre-calculating was all added a while back for multi-platform compatibility, we could probably go 'partially' back to the old system, maintaining a progress counter for the unit and pre-calculating the progress per frame instead of the cycle length... let me think about it

Expanding even further off topic, if a the effects/emanations were expanded to be able to apply a shader or particle effect (not sure if they can do particles?) that would turn the unit blue... I'm getting over my head, though. Food for thought, I suppose?

Particle systems can be attached to effects (and emanations are effects, so them too).

41

Feature requests / Re: Lua functions and events for chat messages [Interface Discussion]

« on: 30 October 2011, 05:39:42 »

Tables can be returned... I had branched you on github a while back, but didn't update first and the branch is gone/renamed/something... not sure if a pull request would be more trouble now than its worth

https://github.com/silnarm/GAE/commit/c41c3a5650c18dffa3ed9edd0f2a39a6d519626b

Edit: Ha... Lua supports multiple return values btw!! probably would have been just as easy/effective for two values... oh well, will be nice to be able to return tables none the less.

42

General discussion / Re: Effects...not taking an effect

« on: 30 October 2011, 03:11:23 »

Hi geork.

  In the effect node, target="any" should read target="all".
  In the multipliers node, <movement-speed value=.../> should be <move-speed .../>

  Multipliers of 0 are not recommended, units will freeze up for longer than expected due the nature of how the game works, obviously this is not ideal and completely freezing a unit for a set time would be nice, but for now you'll have to live with it.

  Reducing attack-range is also not recommended, a unit with range = 1 will end up with fractional range and will be a close as he can be and still not attack...

  Here's a working version with a few things changed, (because they 'stack' you will still get the freeze up problem with this, it'll just take a little while to build up).

Code: [Select]

        <effect name="shred" bias="detrimental" stacking="stack" target="all" chance="100.0" duration="3" image="image/battle_machine.bmp">
          <static-modifiers>
            <hp-regeneration value="-20"/>
          </static-modifiers>
          <multipliers>
            <move-speed value="0.5"/>
            <attack-speed value="0.5" />
            <attack-strength value="0.5"/>
          </multipliers>
          <recourse-effects>
            <effect name="stand" bias="detrimental" stacking="stack" target="all" chance="100.0" duration="3" image="image/battle_machine.bmp">
              <static-modifiers>
              </static-modifiers>
              <multipliers>
                <move-speed value="0.5"/>
                <attack-speed value="0.5" />
                <attack-strength value="0.5"/>
              </multipliers>
            </effect>
          </recourse-effects>
        </effect>
      </effects>


43

Feature requests / Re: Lua functions and events for chat messages [Interface Discussion]

« on: 27 October 2011, 20:20:42 »

Nice work CruzR, I've been meaning to doctor up LuaArguments so you can return a table (the cleaner syntax of your original plan is much nicer), but have not had a chance to get to it yet Extra long week-end starting in 12 or so hours though, so I'll get that to you soon hopefully

I would imagine that a script ought to be able to filter message each message that is sent or received by a player: for each message in, it can let it through or replace it or suppress it.  And at any point in can choose to send new messages, with a choice of whether they are echoed to the player's own console.

Good idea, should only need a suppressChatMessage() and an addChatText(), although addDialog() could probably be modified to accept player names to handle the second.

And there should be shared state in the script for these different event hooks, so it can consume all sent messages and then, a while later, send them.  With this, it is not necessary for all messages that are understood by scripts to be one-liners.

You can imagine scripts that communicate with each other without their messages to each other being displayed to either player.  This might make very interesting team-based collective scripts possible; AI meta-players, even.

There is only one LuaState when the game is running anyway, so the engine doesn't need to do anything special here, it can be done from Lua already (or will be with the above added function(s)).

I've added the following query functions,

Code: [Select]

getPlayerCount()
getHumanPlayerIndex()
getPlayerName()
getPlayerTeam()
getPlayerColour()

These are meant to be helpful for Omega's "give orders to semi-AI players via chat" scenarios, hopefully there are 
There are also some undocumented AI helper functions I added some time ago, not going to reveal anything more than that at this point, because I'm not sure what state I left them in

44

Bug reports / Re: Flickering invisible units

« on: 10 October 2011, 19:34:15 »

Possibly fixed, could you git pull and try again please.

45

Bug reports / Re: Commandline argument -loadmap doesn't work

« on: 10 October 2011, 19:33:25 »

Should be fixed now, I was getting a crash when gae was called with -list-tilesets from the map editor, but the list was returned and it launched ok after that... :\

46

General discussion / Re: build_self problems

« on: 10 October 2011, 19:30:47 »

Hi geork,

  How do you  create these units in game? "Build self" was intended to be "the other end" of a transform command, though I guess it should/could function independently of that, I will think on that (but as of now this is the only way it will work, the build-self command will never be started otherwise).

  In Shibboleth workers can transform into farms and towers, the transform command's 'hp-policy' determines how many hp it 'starts' with, the information on the wiki maybe misleading on that parameter, I'll have to check that more carefully later.

  Sorry for the quick response, I gotta run, will check some things and get more details for you later.

Cheers.

47

Bug reports / Re: Flickering invisible units

« on: 2 October 2011, 21:34:07 »

fixed pipe rendering or shader (and if shader which one)? and this is/was with intel integrated graphics?

48

General discussion / Re: Reworking the editor

« on: 2 October 2011, 21:12:29 »

Should the coord values range from 0-63 or 1-64 for a map of the size 64*64?

0-63. Of note, the right most and bottom most rows are only used for height data, the 'tiles' don't actually exist in game.

What if the cursor is outside the map? Should the coords just be continued there (like: X: -15, Y: 68)?

It would certainly be nice if you could use the edges of a brush from 'off the map'

I'm kinda against a program that :
    "Makes it possible to create Scenarios, Factions, Techtrees and Tilesets with the editor"

It seems like a waste of time to me, xml isn't that difficult of a language. Especially since new features are added to the game all the time, plus then they would have to be added to the editor as well  .

The idea behind this was to have one tool with which you can change all aspects of the game, similar to the warcraft III world editor, because I think that's one of the reasons why war III was that successful.

I have similar ideas, but dislike the idea of doing it all in C++, the GAM and the more recent g3dhack and associated projects are a starting point (not so much the GAM, but the g3dhack solution has all sorts of stuff in it now, including much of the shared lib and the 'prototype' classes from the game, with some work done towards being able to display it all in a PropertyGrid.  Not sure if C# interests you at all, but if so clone the g3dhack repo and take a look.

49

Feature requests / Re: Selectable Difficult for scenarios

« on: 25 September 2011, 20:12:45 »

While I certainly prefer the engine callback, it would be best to have some mechanism so that a scenario could tell the engine what difficulty levels it supports, not all authors will be wanting to support all levels.

50

General discussion / Re: Options Menu

« on: 25 September 2011, 20:10:21 »

Looks really nice 

Might make the 'sections' foldable one day...
Fixed the scrollbar thing for OptionPanels (though I noticed the Keymap widget does it too...)