176
Forum discussion / Re: Forum cleanup
« on: 14 January 2014, 01:00:16 »
I ran a quick query on the table, and it looks like we have 688 members who haven't reset their password.
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
177
MegaGlest / Re: Installation crushes, game won't start...
« on: 9 January 2014, 21:39:34 »
Or perhaps a simpler approach, run MegaGlest with megaglest --verbose > output.txt. This redirects the standard output. Thus, the text that is currently being printed to the console will instead be printed to a file named "output.txt" (in the current directory). Copy and paste the contents of that file here.
Easier than working with pictures and nothing is truncated.
Easier than working with pictures and nothing is truncated.
178
MegaGlest / Re: Installation crushes, game won't start...
« on: 7 January 2014, 20:34:56 »
Odd.
At any rate, it's not necessary to use the installer. You can download the binaries here and the data here.
You'll need an archive program such as 7-zip to unpack these archives. The contents of both archives should be in the same folder. If you haven't used a tar archive before, you'll note that the data package is basically "double archived". The xz format only works on single files, so the files must be bundled in the tar format. Thus, when you open the xz file in 7-zip, you'll see a tar file. Open that in 7-zip, too, and the contents of that tar file are what you'll copy to the same folder you placed the binaries.
Long story short, the folder should look like this:
Anyway, the megaglest.exe file is the game's binary.
At any rate, it's not necessary to use the installer. You can download the binaries here and the data here.
You'll need an archive program such as 7-zip to unpack these archives. The contents of both archives should be in the same folder. If you haven't used a tar archive before, you'll note that the data package is basically "double archived". The xz format only works on single files, so the files must be bundled in the tar format. Thus, when you open the xz file in 7-zip, you'll see a tar file. Open that in 7-zip, too, and the contents of that tar file are what you'll copy to the same folder you placed the binaries.
Long story short, the folder should look like this:
Code: [Select]
data/
docs/
lua/
maps/
plugins/
scenarios/
techs/
tilesets/
tutorials/
7z.dll
7z.exe
g2xml.exe
glest.ini
glestkeys.ini
libvlc.dll
libvlccore.dll
megaglest.exe
megaglest_editor.exe
megaglest_g3dviewer.exe
OpenAL32.dll
servers.ini
xml2g.exeAnyway, the megaglest.exe file is the game's binary.
179
Feature requests / Re: particles bound to models
« on: 4 January 2014, 00:19:57 »
Instead of changing the model format, could we not provide a separate model that is which the particles are bound to? And then in the XML file, we can add any number of "particle models" to each skill. The particle models are not actually displayed, but merely serve as an "outline" for binding particles.
To use an example, we could have the regular battlemage model as it is, but also add a model that is just the battlemage's hands as they move during his attack animation. We'd add a link to this model in the attack skill, allowing us to bind particles to this model. Syntax could be something like:
In addition to not requiring changes to the G3D format, this approach would allow us to be modular in creating particle bounds. We could have a base model and then models for different bounds which could be used for different skills (eg, we might have particles bound to the hands of a unit for their attack animation only, with different particles for a different animation, and no particles bound for other animations).
However, the G3D viewer should also be updated to be able to load these particle bounds in. This is a little more tricky given that we'd have to load in both a model AND a particle XML.
Side note: perhaps it should be possible to point the G3D viewer at a unit XML and it would be able to load all the animations as they would appear for each skill? This would provide an easy way of loading models with many particles in, and allow previewing units rather than individual models?
To use an example, we could have the regular battlemage model as it is, but also add a model that is just the battlemage's hands as they move during his attack animation. We'd add a link to this model in the attack skill, allowing us to bind particles to this model. Syntax could be something like:
Code: [Select]
<skill>
<!-- ... -->
<animation path="models/archmage_attacking.g3d"/>
<particle-bounds>
<model path="models/hands.g3d" particles="particles_hand.xml" />
</particle-bounds>
<!-- ... -->
</skill>In addition to not requiring changes to the G3D format, this approach would allow us to be modular in creating particle bounds. We could have a base model and then models for different bounds which could be used for different skills (eg, we might have particles bound to the hands of a unit for their attack animation only, with different particles for a different animation, and no particles bound for other animations).
However, the G3D viewer should also be updated to be able to load these particle bounds in. This is a little more tricky given that we'd have to load in both a model AND a particle XML.
Side note: perhaps it should be possible to point the G3D viewer at a unit XML and it would be able to load all the animations as they would appear for each skill? This would provide an easy way of loading models with many particles in, and allow previewing units rather than individual models?
180
Bug reports / Re: Invalid unitToAttackId in Island Survival Scenario
« on: 28 December 2013, 22:43:45 »
I'm not sure if this is a problem with MegaGlest so much as the Island Survival scenario.
It's unfortunate that the error messages don't specify the line of the Lua script that made this invalid call. I imagine this is a case of a giveAttackCommand call that is using the ID of a dead unit as either the target or source.
If one of the devs can verify that this is indeed due to the scenario, I'll merge this into the island survival thread.
Perhaps these kinds of errors should state the location of the error in the script, however? The error message posted doesn't seem very useful to scenario developers.
@SlowMO, could you upload your save file? I imagine that Tiger will find that useful in tracking down where in his scenario this occurs.
It's unfortunate that the error messages don't specify the line of the Lua script that made this invalid call. I imagine this is a case of a giveAttackCommand call that is using the ID of a dead unit as either the target or source.
If one of the devs can verify that this is indeed due to the scenario, I'll merge this into the island survival thread.
Perhaps these kinds of errors should state the location of the error in the script, however? The error message posted doesn't seem very useful to scenario developers.
@SlowMO, could you upload your save file? I imagine that Tiger will find that useful in tracking down where in his scenario this occurs.
181
Forum discussion / Re: problem with blocked IPs
« on: 28 December 2013, 03:48:20 »
Has this not been resolved already?
The IP address he was using was also used by a known spammer in the past. But I later allowed that IP in when it was caught (or so I thought?). Tom also redirected CyberRock to where he or she could fill out a form to remove their IP from the database of spammers.
The IP address he was using was also used by a known spammer in the past. But I later allowed that IP in when it was caught (or so I thought?). Tom also redirected CyberRock to where he or she could fill out a form to remove their IP from the database of spammers.
182
Bug reports / Re: 3.9.0 & f06d474.4541: game results time does not account for game speed changes
« on: 25 December 2013, 19:41:57 »
I don't consider this a bug. The game timer shows real world time, even if game time is accelerated.
183
Feature requests / Re: Game Timer
« on: 17 December 2013, 03:35:36 »
I believe he wants that game duration clock on the game over screen to be accessible in-game (I think the pause menu would be a good place).
184
Maps, tilesets and scenarios / Re: Island Survival. (Adventure Scenario)
« on: 16 December 2013, 02:40:29 »I think I might have used all the current tileset and normal resources up. So that can't be a way to fish. But I was thinking maybe spawn in a unit that is a model of fish swimming and have a cell event that kills the fishing unit when you go near it, then respawns it again in 200 seconds or something.You could probably do that. There's a limit to the number of tech resources due to the map's limitations, but I don't believe static resources have a limit. You could use a Lua event to detect when a fish unit is killed and provide food on death.
To prevent your units from automatically attacking the fish, you could assign them to a neutral faction. Give them no move or attack skill so they can't leave the shallow waters.
185
Maps, tilesets and scenarios / Re: Island Survival. (Adventure Scenario)
« on: 16 December 2013, 00:09:10 »Oh you could make fishing... Just place an invisible resource at the edge of the water... and you harvest this resource using fishingInvisible would suck, though. Too hard to find. A model of fish swimming around that renders under the water should work.
186
Feature requests / Re: Ability to easily take screenshots without HUD
« on: 15 December 2013, 23:02:57 »a screenshot with hud but without minimap ? What should this be good for ? Just click on the ground to select "nothing" and take your screenshot, or do I miss the point ?Hmm? No. No HUD. HUD includes the minimap, the resource display, etc. You already have photomode. This request basically flips photomode on, takes a picture, and flips it off (or perhaps something more efficient).
187
General discussion / Re: An inquiry!
« on: 11 December 2013, 03:58:10 »a) Is it possible to make units unselectable, then? What would probably happen with the emanations is people would just camp out their sergeants and use them as mobile production centers (albeit with limited range), to say nothing of what a micro nightmare that could pose.No. Technically, size zero units are unselectable, but they're also immune to all damage (except regen), which is not generally desirable.
b) Given the above, is there a way to eh, tighten the formation? To make units prioritize following over breaking off from the group and attacking forlorn enemies? Or is that already the case?Not without changes to the engine.
c) I recall reading something about multiproduction someplace, where you could state that unit x has to be produced in multiples of two or three. I have no idea if any relation can be made here, but could one set it up so a unit spawn with several pets when constructed? I imagine the main problem there would be setting an owner.https://docs.megaglest.org/GAE/Multiproduce
d) Does there exist a method for editing the selection circles for units? If not, can they be made larger artificially?They can't be edited, no. The size of the circle will correspond to the size of the unit (roughly).
Also, last question, I swear: does geometry for structures have to be open bottomed? It seems like that's a trend and I just want to be sure it's not due to a technical limitation.There's practically no limitation on the model. You could even give a small, size one unit a massive castle as a model and that will work. It is not necessary to have an open bottom. That is just a common choice because in most cases, the bottom cannot be viewed.
All of your desires, of course, could be done by changing the engine itself (open source C++, if you're wondering), but would take considerable skill as a programmer.
188
General discussion / Re: An inquiry!
« on: 10 December 2013, 23:15:20 »
Yes, pets are selectable. In fact, for the most part, pets are completely normal units except for their pet flag. By using this flag with emanations and effects, we can make pets act differently around their master.
For example, the original "Four path magitech" techtree that was supposed to demo GAE (and was never completed) had a pet which had negative HP regeneration. However, the master had an emanation that made nearby pets gain a boost to HP regen. Thus, while the pet was near its master, it gained HP. If it got too far from the master, it lost HP.
So yes, you could have an army hierarchy based on these pets, using a long range emanation to keep HP regen positive while the master survives and slowly killing the units off if their master dies.
I can't recall whether or not pets follow their owner and attack the same targets. I believe not, and that the GAE devs planned to add such a functionality, but the engine's development has died again.
Regarding your side note, the sounds for selection are listed in the selection-sounds XML element. There can be any number of sounds and the one played is chosen at random. See: https://docs.megaglest.org/XML/Unit
For example, the original "Four path magitech" techtree that was supposed to demo GAE (and was never completed) had a pet which had negative HP regeneration. However, the master had an emanation that made nearby pets gain a boost to HP regen. Thus, while the pet was near its master, it gained HP. If it got too far from the master, it lost HP.
So yes, you could have an army hierarchy based on these pets, using a long range emanation to keep HP regen positive while the master survives and slowly killing the units off if their master dies.
I can't recall whether or not pets follow their owner and attack the same targets. I believe not, and that the GAE devs planned to add such a functionality, but the engine's development has died again.
Regarding your side note, the sounds for selection are listed in the selection-sounds XML element. There can be any number of sounds and the one played is chosen at random. See: https://docs.megaglest.org/XML/Unit
189
Off topic / Re: Ludum Dare
« on: 9 December 2013, 09:54:18 »Stop wasting time this weekend, stop playing on your new xboxone/ps4, stop socialising with family, stop browsing reddit! There are more important things to do:B-but exams, man... I'm interested in what you'll pump out this time, though
190
Feature requests / Re: Bugs with negitive EP Regen
« on: 1 December 2013, 18:39:09 »
Perhaps we could add an option somewhere in the XML (which would make this a feature request) for that behavior. I'm not sure having negative EP should prevent the usage of zero-EP skills.
191
MegaGlest / Re: Move repo to git?
« on: 27 November 2013, 23:31:15 »I agree, given how we often tend to get bug reports from new members that are caused by problems on their end (and are resolved in the FAQ).We should also evaluate whether or not we need to continue having issue trackers on both forums and GitHub.We could keep the bug reports forum so poeple who are uncertain if something is a bug or not can post there first, and if it has been confirmed open an issue on GitHub then
192
Feature requests / Ability to easily take screenshots without HUD
« on: 26 November 2013, 05:42:43 »
We can currently take screenshots without HUD by switching to photo mode and then taking the screenshot. However, in the heat of the battle, you don't want to remove the HUD, but you still might want to take a photo of your all out assault. It would be beneficial, in my opinion, if we could somehow take an ingame screenshot that contains no HUD with a single button. Since the 'e' key is the regular screenshot key, I propose that either shift + 'e' or ctrl + 'e' would take a screenshot without the HUD. ctrl + 'e' is probably preferable, since then we could perhaps allow screenshots while in the chat dialog (or not, if the implementation of the chat dialog doesn't make that easy).
To elaborate, "taking a screenshot without the HUD" should take a screenshot as though we had enabled photo mode, but it should not hide the HUD in the game window (only the screenshot is affected).
To elaborate, "taking a screenshot without the HUD" should take a screenshot as though we had enabled photo mode, but it should not hide the HUD in the game window (only the screenshot is affected).
193
MegaGlest / Re: Move repo to git?
« on: 26 November 2013, 05:36:34 »Thanks Debian Games Team! The import worked a charm.Awesome! SVN is a pain to work with sometimes, especially if you are used to git's convenient branching and tagging.
194
MegaGlest / Re: Rock Solid Stable - Release Time
« on: 17 November 2013, 19:09:29 »A lot of developers for this purpose have second "frozen branch", and commiting to it only backwards compatible patches and per some (short) time they doing based on this branch the next stable version e.g. X.X.0 > X.X.1,That's what SMF and JQuery do. Both currently have a version 1.x and 2.x. The older versions only get bug fixes. However, I don't feel that's a good idea for MG: takes up too many resources and we want players to have the latest and greatest version.
195
MegaGlest / Re: Rock Solid Stable - Release Time
« on: 17 November 2013, 05:33:23 »http://semver.org/Is there any plans to use this? I'm a fan of semantic versioning because of its consistency (actually, I stole this link for one of my own software projects).
196
MegaGlest / Re: Mega Glest is a kind of "Cookie Clicker" actually
« on: 11 November 2013, 07:38:07 »
Is it really necessary to dig up two month old posts?
197
MegaGlest / Re: balancing changes for magic faction
« on: 10 November 2013, 10:35:00 »I think you are right. Every time I play with bots magic is always the first one out.I disagree. Magic is a strong faction. The AI just sucks at it. Magic is played a bit differently from other factions.
198
Mods / Re: Undead faction [UPDATED!] WIP
« on: 4 November 2013, 19:06:09 »
I'm afraid it looks like the download link has broken. Unfortunately, I don't have a copy of the faction myself. Does anyone else?
199
Mods / Re: Imperial 2 tech tree (***Full Release*****)
« on: 4 November 2013, 07:09:48 »Is this for GAE (water units?) or are they just in scenarios?He explained elsewhere that it's just a scenario. If I recall correctly, he used opaque shallow water to allow units to "walk" in the water and create ripples. The water units are separated from the land units with "cliffs".
200
MegaGlest / Re: Network game stats gathering
« on: 31 October 2013, 07:11:12 »
Looks like these changes aren't compatible with the auto-update script. Will you be fixing that too? Also, what's with the "abc" in the top left corner? And "Divtag"? Was this tested?