1
MegaGlest / Re: 3d printed mage tower
« on: 5 January 2019, 13:25:45 »
Those are really awesome! Would love to see more of these prints 
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.
2
Mods / Evolution faction
« on: 6 May 2018, 13:27:16 »
It's been a good while since I wanted to finish and share this... several years to be precise. A discussion on the ZetaGlest Discord group reminded me about it last night, so I thought to myself "why not pack and share that old thing already"?
This is the Evolution tech. It's a little something I created based on a game I played briefly in my childhood called Rise of Nations: It's a RTS in which you start in the stone age then make upgrades until you work yourself up to modern day. My mod tries to achieve a similar goal in Glest: You start with a group of people living in huts, reach the medieval age, work your way up to modern day technology, then even go beyond into a futuristic space age. The system relies heavily on unit upgrading, as once you upgrade your base to the next age your objective is to morph every existing unit into its evolved equivalent. I achieved this by combining assets from various MG factions created by the Glest developers or community, typically using an unique faction to represent each age... more precisely I used the following faction packs:
Right now this mod is still very unpolished and unfinished: There are missing textures, inconsistent icons, and reaching the last age takes over 2 hours of playing (much more than a typical game lasts). Worst of all, the AI cannot play it yet: They won't get past the first age due to a bug that makes the AI not morph buildings, as it doesn't analyze the advantages of production but only those of attacking when morphing to another unit. I should be able to fix this later by adding a fake attack skill to each unit.
You can try this tech out by cloning it from its Github repository into your user_settings/megaglest/techs directory, then renaming the cloned folder to just "evolution". The tech is available here:
https://github.com/MirceaKitsune/glest_techs_evolution
This is the Evolution tech. It's a little something I created based on a game I played briefly in my childhood called Rise of Nations: It's a RTS in which you start in the stone age then make upgrades until you work yourself up to modern day. My mod tries to achieve a similar goal in Glest: You start with a group of people living in huts, reach the medieval age, work your way up to modern day technology, then even go beyond into a futuristic space age. The system relies heavily on unit upgrading, as once you upgrade your base to the next age your objective is to morph every existing unit into its evolved equivalent. I achieved this by combining assets from various MG factions created by the Glest developers or community, typically using an unique faction to represent each age... more precisely I used the following faction packs:
Code: [Select]
Age 1: Megapack - Indians, Egypt, Persian
Age 2: Megapack - Romans
Age 3: Magitech - Tech, Magic
Age 4: Imperial - Imperial, Warlords
Age 5: Enemies & Allies - Enemies & Allies
Age 6: Annex - Alliance, Shadow
Age 7: Scifi Pack - Industrators, MartiansRight now this mod is still very unpolished and unfinished: There are missing textures, inconsistent icons, and reaching the last age takes over 2 hours of playing (much more than a typical game lasts). Worst of all, the AI cannot play it yet: They won't get past the first age due to a bug that makes the AI not morph buildings, as it doesn't analyze the advantages of production but only those of attacking when morphing to another unit. I should be able to fix this later by adding a fake attack skill to each unit.
You can try this tech out by cloning it from its Github repository into your user_settings/megaglest/techs directory, then renaming the cloned folder to just "evolution". The tech is available here:
https://github.com/MirceaKitsune/glest_techs_evolution
3
Mods / Re: Elf Faction 0.9.7 & 2.0A (Both MG Compatible)
« on: 15 June 2017, 11:36:54 »
I took a rather brief look at this faction, as I didn't dive into a full game yet. All I can say is, incredible work! This has to be one of the most professional factions for MG out there.
Dear Megaglest developers: When this faction is ready, could it please be integrated into Magitech or Megapack? It will certainly meet every quality and beauty standard to be defaulted by far.
Dear Megaglest developers: When this faction is ready, could it please be integrated into Magitech or Megapack? It will certainly meet every quality and beauty standard to be defaulted by far.
4
Mods / Re: Elf Faction 0.9.7 & 2.0A (Both MG Compatible)
« on: 21 May 2017, 12:10:38 »Nice improvements as always, Archmage.
Hopefully this and the Woodland techtree can finally be on the ModCenter.
There is a mod center now? I actually never knew!
5
Mods / Re: Elf Faction 0.9.7 & 2.0A (Both MG Compatible)
« on: 17 May 2017, 08:46:25 »That was me, Gameboy hasn't been around in years.
Right. Sorry for not replying in so long then... I had a reminder to check out the version of the time, just kept getting busy with other things and never getting into it. I shall really try to change this soon!
6
Mods / Re: Elf Faction 0.9.7 & 2.0A (Both MG Compatible)
« on: 16 May 2017, 20:07:23 »
Oh gosh... I've had the elves-8.3.16 package sitting on my drive for ages, yet didn't get to take a look at it in months. I don't remember if it was you or the original author (gameboy) who emailed them to me. This time I really need to give the update a shot, it looks really awesome
7
Mods / Re: Unit capturing
« on: 27 November 2016, 13:36:49 »I don't see how. You kill a unit and spawn your own faction's version. If you kill a unit that you don't indicate in the XML, you don't spawn a unit. So the unit would just die instead of being captured. So yeah it wouldn't work right but it wouldn't break the game somehow. If you were going to the level of modding that involves swapping factions around you should be able to handle this. You could even just bump and error if capture failed to the error log. If people are moving around factions but can't read error logs that's not really your fault.
Yeah... like that. My idea was this, to exemplify: Suppose that in your tech tree you have 3 factions, A B and C. In faction A, you define an unit that you want to make possible to capture. You want the unit to only be captured by: The same tech it's from (A), and tech B. So you simply say the following in the unit's definition: "If killed by an unit from tech A then: Become the same type of unit from tech A" and "if killed by an unit from tech B then: Become this here tech-B unit". However if you leave the tech C definition out, the unit just dies normally and doesn't become anything for its captor.
8
Mods / Re: Unit capturing
« on: 25 November 2016, 18:30:36 »same type of unit? not from own faction? then you have high chance for unexpected problems like
e.g. instant dying > because no food > because your faction doesn't use food etc.
No... I was understanding incorrectly. He's referring to the dependency of specifying a unit of one tech in the definition of a unit in another tech, which is indeed the case with my idea. Like I said I don't see a problem with it myself... it does add the extra responsibility of fixing this definition in case you ever move a tech out of the same techtree, but I think tech developers who decide to use this can definitely learn to keep an eye out for such.
9
Mods / Re: Unit capturing
« on: 25 November 2016, 18:27:05 »
Sorry for having to correct myself so early! I kept thinking you're referring to a dependency issue in the code, caused by trying to convert an existing unit to a different faction, hence why I kept suggesting a "delete old / spawn new" approach. I just realized you were in fact referring to the dependency in the definitions... since indeed, every unit that used this would have to name a unit from every other faction in the techtree that it can be turned into within its xml.
Personally I don't see that as a problem. Unless as you mentioned, someone decides to move techs in and out of tech trees, and forgets to also update this definition. That would however be a developer error, the same as say moving a common asset and forgetting to replace it in an unit's definition. It's also not something I believe people should do normally, as techs are balanced against one another and would have to be thoroughly re-checked in case of such a move anyway.
Personally I don't see that as a problem. Unless as you mentioned, someone decides to move techs in and out of tech trees, and forgets to also update this definition. That would however be a developer error, the same as say moving a common asset and forgetting to replace it in an unit's definition. It's also not something I believe people should do normally, as techs are balanced against one another and would have to be thoroughly re-checked in case of such a move anyway.
10
Mods / Re: Unit capturing
« on: 25 November 2016, 18:17:00 »You would need a mapping which unit to spawn for which unit. By this you get a dependency of one faction to another. Up to now there is no such dependency and you can move factions around.
I dont really want to introduce this dependency, but if it would exists it is possible to implement somehting like you suggested.
( completly offtopic but please test this and give feedback: https://forum.megaglest.org/index.php?topic=9837.0 )
What I'm still confused about is: Code to spawn any unit for any faction at any time exists... summoners and builders use it after all! So why can't the defeated unit simply be erased, and a completely new and independent unit added separately... only creating the illusion that it's the same unit having transformed? Why would there be a dependency in between the two, even in an approach where they're two completely separate entities? I just see it as using the following steps:
1 - Unit X for faction A is simply erased out of existence.
2 - The code remembers what the location and orientation of unit X was, storing them as a vector and a float somewhere.
3 - A completely new unit Y for faction B is spawned, just as if a summoner from that faction would have spawned it.
4 - Unit Y is instantly given the stored position and orientation that unit X had.
11
Feature requests / Re: Spawn on death
« on: 25 November 2016, 16:35:16 »New features are never in master as this is our release branch. To try new things always use branch "develop".
Ah... I remember now, and I think I am on the "develop" branch. For most GIT repositories the experimental branch is always "master", so my brain is set to assuming that
12
Mods / Re: Unit capturing
« on: 25 November 2016, 01:25:34 »Wouldn't you just define the unit conversion in the XML and then kill the one unit and spawn the proper replacement in the same location? In what way is this complicated?
In fact wouldn't this just be a copy of the spawn at death feature which you did in fact implement? You don't literally have to modify a given unit to another type.
I was wondering the exact same things, to be fair.
13
Feature requests / Re: Spawn on death
« on: 21 November 2016, 18:20:01 »Another thing my son sugested is sadly not possible at the moment as the information is missing:
A "spawn at enemy" like its possible for attack spawns. So if a unit A is killed by a unit B the spawned units surround unit B. This would be nice, but is not possible. I think I leave it like it is for the moment.
( btw you can try things by either building for yourself https://docs.megaglest.org/MG/Development or more simply get the data and binaries from here: http://snapshots.megaglest.org )
I can see the use in that, even if it doesn't feel quite as important as simple spawning on death (at the location of the victim). And I always build Megaglest from GIT, so if the feature is in master I should have no problem trying it.
14
Mods / Re: Unit capturing
« on: 21 November 2016, 18:17:23 »I understand it, but as I said too complicated to do for the benefit you get. Saying: I will not do this at this point
Ok. You're a core developer so you know best how it would work! Hopefully either another dev could look into it, or you could put it on your list for later on when you believe possibilities might change
15
Mods / Re: Unit capturing
« on: 21 November 2016, 12:59:41 »This is quite complicated to do and in my eyes a too special feature. It would mean you need a transition map of which unit is mapped on which unit while capturing and so on.
I don't think I want to add something like this and I think these kind of things should be done with scenario code.
Why would that be needed though, compared to my initial idea: When an unit dies or is under a certain HP, check who the attacker is, and if a capture definition exists then delete the unit and simply spawn an unit for the attacker? In a sense this should be similar to how a summoner spawns other units... though more like a summoner from one faction spawning an unit for another faction.
I imagine this can be easily done in scenario nodes for now. But then it would only work for scenarios, not for random matches... which would be very limited, and not make it possible to have this as a real feature of the tech tree.
16
Feature requests / Re: Spawn on death
« on: 21 November 2016, 12:54:22 »Start time is the moment based ont he death animation when the unit spawns. By this you can get a better timing to let the technician "exit" the catapult for example.
You cannot let spawn differrent types of units on death like this, you can just set teh number of spawned units. Multiple types ( like your syntax suggested ) was a bit more complicated and I skipped it. Do you really think its needed ?
That makes sense and is a good idea! And nah: I don't see myself using multiple types of unit spawns per death, and mostly suggested that for completion. The important feature exists, and I definitely cannot complain!
17
Mods / Re: Unit capturing
« on: 20 November 2016, 15:44:05 »
Any thoughts on this from the developers? I'm curious if it's something everyone agrees to, and that could be done in a simple way.
18
Feature requests / Re: Spawn on death
« on: 20 November 2016, 15:41:22 »
Thank you titi! I shall definitely try it later, once I get back into working on MG. The syntax looks good, just two questions: What is start-time, and can you define multiple unit type spawns?
19
Feature requests / Spawn on death
« on: 5 October 2016, 22:36:55 »
Another basic feature I would like to suggest, which I also plan to use personally. Would it be possible to let units spawn other units upon death please? I'm imagining a definition among the lines of:
This would allow useful mechanics such as: A technician emerging out of every catapult / ballista / battle machine that's destroyed (the operator walks out of the wrecked device), drake riders turning into summoners (implying the drake died but the rider survived), workers emerging from castles that have crumbled, and more types of logical unit conversions.
Code: [Select]
<spawn-on-deaths>
<spawn-on-death>
<unit type="my-unit"/>
<count value="5"/>
<health value="25%"/>
<probability value="50%"/>
</spawn-on-death>
</spawn-on-deaths>
This would allow useful mechanics such as: A technician emerging out of every catapult / ballista / battle machine that's destroyed (the operator walks out of the wrecked device), drake riders turning into summoners (implying the drake died but the rider survived), workers emerging from castles that have crumbled, and more types of logical unit conversions.
20
Mods / Unit capturing
« on: 5 October 2016, 22:23:49 »
This is a feature I want to use in one of my techtrees, so it would be appreciated if it could please be considered for inclusion. I remembered I made a thread about it long ago, but it seems I never actually have.
I'd like to suggest a simple way of implementing unit capturing: A system to allow specific units to be converted by their attacker instead of being destroyed. This would allow enemy troops to surrender to their attackers and join them when killed, or for enemy buildings of interest to be conquered instead of getting leveled to the ground.
Example: Suppose I want to make the worker from Tech an unit that can be captured. I define an xml block in the following form:
This says the following: If the unit is hit by an enemy that's part of the Tech faction while its health is below 10%, there's a 50% probability that it will become an unit of type worker (same unit in this case) for the attacker, with 25% of the unit's normal health. Whereas if the unit is damaged by an enemy from the Magic faction while its health is 0% (the unit died), there's a 25% possibility that it becomes an acolyte for the attacker, with 50% of the acolyte's normal health.
The feature would make it possible to create strategic techs in which players can capture each others units, grabbing them for themselves (if part of the same tech) or turning them into compatible versions of an own unit (if part of another tech). I can't imagine much difficulty in implementing this... since all the code would need to do is check the conditions and the attacker's identity when an unit is damaged, then erase the unit and spawn one for the attacker at the same position.
I'd like to suggest a simple way of implementing unit capturing: A system to allow specific units to be converted by their attacker instead of being destroyed. This would allow enemy troops to surrender to their attackers and join them when killed, or for enemy buildings of interest to be conquered instead of getting leveled to the ground.
Example: Suppose I want to make the worker from Tech an unit that can be captured. I define an xml block in the following form:
Code: [Select]
<captures>
<capture>
<faction type="tech"/>
<unit type="worker"/>
<health-threshold value="10%"/>
<health value="25%"/>
<probability value="50%"/>
</capture>
<capture>
<faction type="magic"/>
<unit type="acolyte"/>
<health-threshold value="0%"/>
<health value="50%"/>
<probability value="25%"/>
</capture>
</captures>
This says the following: If the unit is hit by an enemy that's part of the Tech faction while its health is below 10%, there's a 50% probability that it will become an unit of type worker (same unit in this case) for the attacker, with 25% of the unit's normal health. Whereas if the unit is damaged by an enemy from the Magic faction while its health is 0% (the unit died), there's a 25% possibility that it becomes an acolyte for the attacker, with 50% of the acolyte's normal health.
The feature would make it possible to create strategic techs in which players can capture each others units, grabbing them for themselves (if part of the same tech) or turning them into compatible versions of an own unit (if part of another tech). I can't imagine much difficulty in implementing this... since all the code would need to do is check the conditions and the attacker's identity when an unit is damaged, then erase the unit and spawn one for the attacker at the same position.
21
Feature requests / Re: Randomly generated maps
« on: 4 October 2016, 23:35:07 »
There are indeed some points I haven't thought of; Generating roads between player's starting points would be tricky, especially when this random terrain may produce rivers (which units can't cross) and needs to cut through forests! One idea would be to randomize starting positions first, then build roads in between them, then generate the terrain (ensuring the road stays above water and below high mountain tops), and lastly produce the forests and other resources in safe areas.
22
Feature requests / Re: GUI based unit editor
« on: 4 October 2016, 23:25:52 »
Just to be clear: I'm not saying that having to edit xml files manually is a stopper or something I lack knowledge on. It's simply something that feels like it's making things much harder than they could be. There are mainly two reasons: The first is that you need to do a lot of searching or copy-pasting, which is a rather tedious task when you have a lot of files. The second is that you're bound to make errors in the editing process, including xml syntax or file referencing... which you only notice when you start up a new game and Megaglest shows an error screen (then crashes a second later). Even when you have to edit simple values, you need to go through several long files and spot what you want buried between other values... but before that you must configure the skills and attacks of units to begin with, so you usually copy-paste and modify a lot of large code blocks.
Here's an example from my own practical experience: I copy the worker from the Tech faction in a faction that I've made. I then decide I want to give him an attack! So I open the xml of the swordsman, and I copy-paste the attack skill and attack command. Then I edit the paths to the model and icon and sounds, the files often having to be moved or copied in between directories. Then I launch Megaglest and test; I get approximately 3 errors for my unit... either because I forgot to include a model or icon or sound or particle file, or because I made a format error like forgetting to close a function with />. After that it finally starts: I test out the unit's attack, but after a long match find that it's too weak or strong in relationship to other units! So I open a dozen xml files (that of every unit with attacks) and constantly go up and down spotting and tweaking numbers like health / armor / attack speed / attack damage / etc. If for all this I could have used fields and buttons in a window, hours lost on writing functions and copying files and pinpointing values could have been spent on testing or improving other aspects.
Using an interface like GTK or QT5 (ideally the later) would definitely be best. Throw in a library for reading xml files, then simply tie certain interface elements to given xml elements! If someone already started such a project, perhaps they can share the source code and it can be ported for MG?
Here's an example from my own practical experience: I copy the worker from the Tech faction in a faction that I've made. I then decide I want to give him an attack! So I open the xml of the swordsman, and I copy-paste the attack skill and attack command. Then I edit the paths to the model and icon and sounds, the files often having to be moved or copied in between directories. Then I launch Megaglest and test; I get approximately 3 errors for my unit... either because I forgot to include a model or icon or sound or particle file, or because I made a format error like forgetting to close a function with />. After that it finally starts: I test out the unit's attack, but after a long match find that it's too weak or strong in relationship to other units! So I open a dozen xml files (that of every unit with attacks) and constantly go up and down spotting and tweaking numbers like health / armor / attack speed / attack damage / etc. If for all this I could have used fields and buttons in a window, hours lost on writing functions and copying files and pinpointing values could have been spent on testing or improving other aspects.
Using an interface like GTK or QT5 (ideally the later) would definitely be best. Throw in a library for reading xml files, then simply tie certain interface elements to given xml elements! If someone already started such a project, perhaps they can share the source code and it can be ported for MG?
23
Feature requests / Randomly generated maps
« on: 1 October 2016, 13:00:31 »
Kind of an obvious feature to suggest, but surprisingly I'm not seeing other threads about it so might as well make one: Considering Megaglest maps use simple heightmap terrain and real unit positions are always 2D. Would it be difficult to allow automatically generated maps, computed by the engine before the game starts?
When setting up a match, the user would have two options: Select one of the existing maps like you do currently, or have the engine generate a map for you. When choosing the second option, you may optionally edit a few extra fields such as: The X and Y size of the map, how extreme the terrain should be (smooth plains vs. rough mountains), the frequency of trees and other resources, decoration density, etc.
I imagine this should be easy to achieve using perlin noise: Use a random seed for the terrain and for each resource, then scale its brightness to determine height / frequency and its contrast to determine concentration. Then place each player's starting point in the areas which are most open and closest to all resources, and there you have it! This would be fun for people who are bored of the existing maps, and just want something new each time they click the start button.
When setting up a match, the user would have two options: Select one of the existing maps like you do currently, or have the engine generate a map for you. When choosing the second option, you may optionally edit a few extra fields such as: The X and Y size of the map, how extreme the terrain should be (smooth plains vs. rough mountains), the frequency of trees and other resources, decoration density, etc.
I imagine this should be easy to achieve using perlin noise: Use a random seed for the terrain and for each resource, then scale its brightness to determine height / frequency and its contrast to determine concentration. Then place each player's starting point in the areas which are most open and closest to all resources, and there you have it! This would be fun for people who are bored of the existing maps, and just want something new each time they click the start button.
24
Feature requests / Re: Human-only simulation
« on: 1 October 2016, 12:39:03 »
Unless making this possible is too much work, I believe it's a good idea. It would be especially useful for testing, whereas scenarios where you control multiple allied factions at the same time also make a lot of sense! I mean, even if you want to play a game against yourself, why should you be limited?
25
Feature requests / Re: Possibility to disable the vanishing corpses
« on: 1 October 2016, 12:30:23 »
Hmmmm... I support this feature. I think there should still be a limit, but perhaps it can be made customizable via a setting?