Messages

1

General discussion / Re: Status of Pets code?

« on: 27 August 2013, 02:43:57 »

I was aware the limit is not enforced, and will get that fixed soon, as to what else it is meant to do (master/pet behaviours) I was never really aware of what was implemented, if anything.

Certainly the behaviour you suggest seems reasonable.  Maybe best to implement as instead of a default stop command (when it has no other commands) the pet gets a guard command (on the master) instead of stop (or a follow, or a move, whatever is available). Will have to think on this one a bit more.

2

Bug reports / Re: 61f0c81: Minor display bug with debug options checkbox in game

« on: 27 August 2013, 02:40:04 »

Sorry if this seems pedantic. Not exactly a game breaking bug, just something I noticed 

A bug is a bug. This one is now fixed.

3

General discussion / Re: Problem Compiling 0.3.93 on Linux

« on: 19 August 2013, 11:23:20 »

... and there are serious selection issues: clicking a single unit often selects multiple units of different types, or a building, double-clicking a unit often selects just this unit or deselects it, right-clicking on the map is often actually registered where a building is placed or another friendly unit stands, making your units not harvest and not attack properly, drawbox selection will often select units outside of the drawbox. Much of this should be due to GLSelectBuffer.

about time to replace that ancient selection code me thinks, thanks for the report

4

General discussion / Re: [NOPE] Please read: Is the Glest Advanced Engine project dead?

« on: 19 August 2013, 11:20:28 »

So will this entail having an AI script continuously running in the background?

Yep, each AI running in its own 'Lua state'.

Welcome back Silnarm. I've done a rewrite of the networking stuff to use turn based lock-step networking which is working for the local interface but it needs some more work for the server/client interfaces. I'm not sure if my commits have been pushed to the server yet.

Sounds most interesting, this rewrite replaces/heavily-changes the Commander class and command queuing system I assume? Would love to take a look, get it pushed, may need to reset the remote (as Frank mentions here) or clone from the new repository and patch serial, if you're still on the old repo.

5

General discussion / Re: [NOPE] Please read: Is the Glest Advanced Engine project dead?

« on: 12 August 2013, 08:35:21 »

What stuff have you thought about working on? I think Hailstone or someone wanted to do multiplayer. Any other major changes planned?

Graphics (particle systems & shaders + modernising GL use).
AI (interface to Lua, reimplement current AI in Lua, and then start teaching it to use transports, boats, teleporting units etc)

As was my want previously, I am likely to 'wander' a bit

6

General discussion / Re: [NOPE] Please read: Is the Glest Advanced Engine project dead?

« on: 11 August 2013, 20:19:29 »

Depending on your progress, I may need to take glest up again.

I'll be spending what time I can on it, but that will probably not be much so progress is not likely to come fast. It is was it is.

... Particularly, what was the difference between master and the 0.4.x branch and why did we need that?

I think the idea was to keep 0.4.x for fixage only while new work could go on on master, probably could be merged up, will peruse the logs sometime this week and make sure nothing to dangerous is in there.
 

7

General discussion / Re: Please read: Is the Glest Advanced Engine project dead?

« on: 3 August 2013, 05:46:30 »

It does indeed.

8

Mandate Engine / Re: Event Sytem

« on: 3 August 2013, 02:30:16 »

Nothing to frown upon, you will do it the way you want, and if it works, it's good!

This does seem to me that it would be more versatile if it was implemented with scripting, but that's just my opinion :-)

9

General discussion / Re: Please read: Is the Glest Advanced Engine project dead?

« on: 3 August 2013, 02:21:42 »

Open source projects never die.

GAE was sleeping.

10

General discussion / Re: Profiling Information Regarding The Minimap

« on: 3 August 2013, 02:16:21 »

I haven't profiled or looked at this since I started poking around in the code again, but I do recall a profiling anomoly from before, namely that PatchMap<> and TypeMap<> getInfluence() methods were showing up in profile output, these were meant to get inlined through template magic, but because I used the curiously recurring template I think it's too confusing for the compiler, removing the base class and duplicating its (limited) functionality should improve things measurably.

  I let you know when I get around to it, or if try it out yourself, do let us know how it goes.

11

General discussion / Re: Compiling Glest 3.2.2

« on: 2 August 2013, 05:58:03 »

I believe those instructions are good, but the dependencies package it links is long gone.  The current deps pack will have most of what you need, sans xerces.  If you have little experience with VC++ project maintainence and the subtleties of linking against the CRT (and how your libraries have done so) you will almost certainly have problems that you will not be able to figure out easily.  You'll be much better off starting with GAE or MG.

12

Mandate Engine / Re: Event Sytem

« on: 2 August 2013, 05:49:22 »

Hi,
  Is this adding to the existing triggers and Lua callbacks, or a whole new system?  It seems to me you can do most of this already, by maintain your flags in Lua. Not that I know exactly what you're planning (description a bit vague so far) but extending the current TriggerManager and friends would get manu thumbs up from me.

13

MegaGlest / Re: cegui

« on: 7 October 2012, 23:45:22 »

I started using librocket in a personal project about a month or so ago, really impressed so far. If you're going to do a GUI overhaul, I would strongly recommend it, if just for the html/css basis of rml/rcss.

14

Bug reports / Re: 5de8487: Should not freeze in case of a SIGSEGV

« on: 5 July 2012, 10:04:18 »

<techy>
Yup, I added support for framebuffer objects a while back, it requires a 'reset' per frame before any drawing, which I seem to have foolishly decided should be done by each ProgramState implementation, rather than just in Program::render(), CrashProgramState wasn't calling it, so it was rendering to the default frame buffer, not our own, then that was all being overwritten in Renderer::swapBuffers() which copied our custom frame buffer (which still had what was last rendered before the crash) to the default
</techy>
Fixed.

15

General discussion / Re: How do farms work?

« on: 5 July 2012, 09:55:47 »

0.4.x is merged back to master now, so master has it (and some other new goodies) and compiling yourself would be preferable anyway, as 0.4 won't have the new stuff in master...

Will release another 0.4 beta imminently, for windows only, I'll probably spend another week or so testing & hunting bugs on *nix.

16

General discussion / Re: 0.4 beta 3

« on: 5 July 2012, 09:49:01 »

I just downloaded GAE from the link on above (first post), and whenever I try to load GAE it closes/crashes instantly without any bug report. So I was wondering... Do I need to download a previous version, or is there some fix I can get (Btw I'm on Windows XP)

Hi there, could you please navigate to C:\Documents and Settings\USERNAME\glestadv (replacing USERNAME with your user name of course) and post the contents of files stdout.txt and glestadv-error.log here.

17

Bug reports / Re: Effect/emanation particles aren't visible

« on: 25 June 2012, 17:42:42 »

So, whenever a unit is supposed to emanate particles (such as from an effect or emanation) to show that something is being applied to it, it doesnt show those particles (so I cant tell if the effect/emanation is working or not).

EDIT: after some testing, it appears that the emanations arent even working! (effects work fine, though, minus the particles). I have a unit that's supposed to be a structure that buffs nearby units, but there's absolutely no effect on the guys near it. Whatever you guys removed in the last update, put it back! it was working just fine before!

working for me, including particle systems on the targets, occurs that a system (or systems) for the emanater might be good too, so you can now also have...

Code: [Select]

<source-particle-systems value="true">
   <particle-file path="emanate_particles.xml"/>
</source-particle-systems>

in an emanation.

18

Bug reports / Re: When loading into a resource building, units should drop off their resources

« on: 25 June 2012, 17:38:42 »

Just a little something I noticed when playing around with Project Red's Tech faction -- my version of the Castle can store units, so I sent a bunch of my Workers inside for safe keeping.  When they came out, some were still carrying their bags of gold.  You'd think they would have dropped those off when they were inside, right?

This was on revision 28d071.

done.

19

General discussion / Re: How do farms work?

« on: 24 June 2012, 07:37:10 »

To remove storage rules for a resource,

Code: [Select]

<resource>
   ...
   <infinite-store value="true" />
   ...
</resource>

To set the damage done per interval for missing consumables,

Code: [Select]

<resource>
   <type value="consumable">
   ...
   <damage absolute="x" percent="y" />
   ...
</resource>

Either an absolute, a percent, or both may be present. (note that 'percent' isn't super-accurate, because of fixed point math).

20

Bug reports / Re: Upgrades: Effecting Multiple Units Overwrites

« on: 24 June 2012, 07:22:59 »

I'm gonna have to throw this on in the to hard basket for now, not that it would be hard to code as such, but because it would be 'finicky' and need a bunch of testing time...

whine some more if you really want it, and it will get done (...eventually), for now you'll have to just specify everything by unit if you need to get that complicated, sorry :'(.

21

General discussion / Re: How do farms work?

« on: 20 June 2012, 15:54:30 »

Infinite storage would indeed be a relatively simple addition, barring any unforeseen problems that make it less simple than it seems, I'll add it (for all resource types) imminently.

Changing the damage done when consumables are lacking seems like it shouldn't be overly cumbersome either, will have a look and report back (in a day or two).

22

General discussion / Re: libxerces-c.so.27: cannot open shared object file: No such file or directory

« on: 20 June 2012, 15:50:44 »

That's an ancient version of GAE you are trying to compile, if your package manager no longer has xerces 2.7 (extremely likely) you probably need to download and build it yourself.

A better idea might be to try a more recent version of GAE, the xerces dependency was removed a long time ago now.

23

General discussion / Re: How do farms work?

« on: 17 June 2012, 08:35:58 »

The consumable resource's 'interval' determines how frequently 'costs' are applied.  Both negative and positive costs are applied each interval, a negative cost is of course how you produce consumables.

The tech farm does produce food, 10 food every 30 seconds (on normal game speed).

From farm.xml 'resource-requirements':
<resource name="food" amount="-10"/>

and from pig.xml 'resource-requirements'
<resource name="food" amount="-5"/>

There is no difference here except in the amount produced.

Consumable resources must also be stored, like all resources, and this is where the farm and pig/cow differ, the farm allows you to store 20 more food, the pig/cow simply produce.

24

Bug reports / Re: anim-progress-bound not working?

« on: 17 June 2012, 08:17:46 »

That was just what it was called when originally implemented, in the ensuing discussion titi suggested 'anim-progress-bound' as an alternative, and more descriptive, name.  I agreed and meant to change it, but apparently never did.

I just added it now (as an alias, so 'anim-stretch' will still work).

25

Bug reports / Re: anim-progress-bound not working?

« on: 17 June 2012, 07:04:24 »

<anim-stretch value='true' />