Say hello to Eaglestone!

[Hectate]

Will the mod support land units, or it will be only for naval war (which sound quite refreshing )?

Support for land units is natural, since it's an integral part of Glest. However, none of the units that I create or design will be land-based. All the units you have seen are "air" units except the shipyard of course.
Additionally, while it would be possible to add a land unit, there would be gameplay concerns. For instance, my Archipelago map is a string of islands of which it is not necessarily possible to "walk" between all of them (via shallow "passable water"). In that map, the use of land-based units would be severely limited - perhaps even to only the starting island in some or all player's cases.

So the short answer is "Yes, naval war only." (with the understanding that naval should really be read as "aerial".)

[ElimiNator]

how will you get resources? ???

[Hectate]

how will you get resources? ???

You don't.

Or to clarify, you don't harvest them. Each player is given a set quantity of "Production" at the beginning and it's up to them to use it wisely. This is where the armada building comes into play - your construction decisions are influenced by and (in turn) influence your strategy. Your upgrade choices (which are similarly limited) also will effect the choices you make.

[John.d.h]

I think "caravel" might be a more fitting name for your galleon, since they were lighter and faster.

http://en.wikipedia.org/wiki/Caravel

Regarding the shipyard, you know you can use both alpha transparency and team color on the same unit, right?  You just have to make the model in two parts, a one-sided mesh and a two-sided mesh.

Each player is given a set quantity of "Production" at the beginning and it's up to them to use it wisely. This is where the armada building comes into play - your construction decisions are influenced by and (in turn) influence your strategy. Your upgrade choices (which are similarly limited) also will effect the choices you make.

Wouldn't that make every game really short?  It seems to me like the player would frantically try to build as many ships and upgrades as fast as possible, and then production would come to a screeching halt.

Negative. Since they're just replacing regular "objects" in the map, they're completely static once generated and placed by Glest in the map.

Maybe you could animate them to look like they're "moving" but still staying fixed in place?

All the units you have seen are "air" units except the shipyard of course.
Additionally, while it would be possible to add a land unit, there would be gameplay concerns. For instance, my Archipelago map is a string of islands of which it is not necessarily possible to "walk" between all of them (via shallow "passable water"). In that map, the use of land-based units would be severely limited - perhaps even to only the starting island in some or all player's cases.

You could have some stationary cannon towers to protect the base.  You could start with a couple (maybe about three), but none of your units would be able to build or repair them, so you'd have to take good care of them.  Just a thought.

[ElimiNator]

The tileset textures will need to be smaller if the ships are going to be so small (and the trees and all the other objects)
You will just half to make a new tile set. 

[tiger]

make your mods bigger

[Hectate]

I think "caravel" might be a more fitting name for your galleon, since they were lighter and faster.

http://en.wikipedia.org/wiki/Caravel

Actually I recently decided to go with Frigate instead.

Regarding the shipyard, you know you can use both alpha transparency and team color on the same unit, right?  You just have to make the model in two parts, a one-sided mesh and a two-sided mesh.

I didn't know that, I assumed I could only export a single mesh from blender. I've got some space in the UV for teamcolor on a flag which was originally desired - thanks for the tip!

Each player is given a set quantity of "Production" at the beginning and it's up to them to use it wisely. This is where the armada building comes into play - your construction decisions are influenced by and (in turn) influence your strategy. Your upgrade choices (which are similarly limited) also will effect the choices you make.

Wouldn't that make every game really short?  It seems to me like the player would frantically try to build as many ships and upgrades as fast as possible, and then production would come to a screeching halt.

The mod isn't about producing the most units, but using your units wisely. Production time will be rapid when compared to Glest because I want the emphasis on strategy rather than resources. Also, upgrades don't use the "production" resources. They have their own "Upgrades" resource that limits how many upgrades each player can utilize. This is to help generate alternative strategies and accommodate differences in playing styles.

Negative. Since they're just replacing regular "objects" in the map, they're completely static once generated and placed by Glest in the map.

Maybe you could animate them to look like they're "moving" but still staying fixed in place?

Not with the current style, but it's a thought for the future.

All the units you have seen are "air" units except the shipyard of course.
Additionally, while it would be possible to add a land unit, there would be gameplay concerns. For instance, my Archipelago map is a string of islands of which it is not necessarily possible to "walk" between all of them (via shallow "passable water"). In that map, the use of land-based units would be severely limited - perhaps even to only the starting island in some or all player's cases.

You could have some stationary cannon towers to protect the base.  You could start with a couple (maybe about three), but none of your units would be able to build or repair them, so you'd have to take good care of them.  Just a thought.

My next unit is going to be along that lines mostly. Also I can always let the shipyard defend itself if needed by adding an attack skill.

The tileset textures will need to be smaller if the ships are going to be so small (and the trees and all the other objects)
You will just half to make a new tile set. 

Yes, a completely new tileset is in my to-do list and has already been started.

[John.d.h]

I didn't know that, I assumed I could only export a single mesh from blender. I've got some space in the UV for teamcolor on a flag which was originally desired - thanks for the tip!

You're welcome.  I didn't know about it either until I was playing around with the Swordman texture and added some alpha to his shield.  It showed up as transparency in the g3d viewer, so I imported the model to Blender to figure out what was going on.  Surely enough, his body, shield, and sword are three different objects and only his body is double-sided.  It can actually be quite handy to have them as separate meshes when animating, like one of my units that drops his shield when he dies.

The mod isn't about producing the most units, but using your units wisely. Production time will be rapid when compared to Glest because I want the emphasis on strategy rather than resources. Also, upgrades don't use the "production" resources. They have their own "Upgrades" resource that limits how many upgrades each player can utilize. This is to help generate alternative strategies and accommodate differences in playing styles.

Ah, I see.  That's an interesting take on it, I suppose.  "Do I want better armor or better weapons?  Decisions decisions!"

[Hectate]

make your mods bigger

I don't understand what you are trying to convey here. Make a larger mod (more units, factions, etc?) or make larger models (as the context of discussion might indicate)?

"Do I want better armor or better weapons?  Decisions decisions!"

Exactly. Each player will have to decide what will be best for their particular situation. Of course, since the upgrades can be done anytime and take effect immediately, a player could choose to wait and see what it seems their opponent is doing before making the choice. But then you get into mind-games and spying/scouting and everything like that. All sorts of fun stuff.

[gameboy]

I don't understand what you are trying to convey here. Make a larger mod (more units, factions, etc?) or make larger models (as the context of discussion might indicate)?

I think he means the models, i wish he would stop doing that, he's been calling the models, "mods", in almost all his posts.

[Hectate]

Well, I'm having trouble reconciling my vision with what Glest will enable me to do. Obviously I knew that I would have to tweak some as I went along. Unfortunately I've come to the conclusion that Eaglestone won't be what it should have been without extreme intervention in the source code base. The following details the issues that I've encountered and their effect on the mod.

1. Apparently air units cannot be repaired, even by other air units. While my air-based repair barge will quickly and willingly move-to and begin repairing any "land" unit (including the frigate if I modify it to be land-based), it will not repair any aerial units.
2. Units must stop and turn to face the target before firing. This leaves no ability to perform broadsides, turret-style cannons (another issue as well), and "drive-by" attacks. This devalues the various units down to a strict numbers game of having the most of the biggest.
3. Damage dealt can not be influenced by the attack vector (weaker armor in the rear, for instance). This means that flanking provides no tactical value, devaluing the use of surprise attacks, and resulting again in a numbers game of the most of the biggest.
4. Movement commands given are inaccurate. The plane of movement and placement for aerial units is significantly different than the actual surface of the map. Since the view is always at an angle (instead of top-down), movement commands have to be adjusted or the units arrive at a cell different than what is intended - generally over-shooting the target. (similar to right-clicking to attack a specific enemy unit, but the click being interpreted as a move-to command instead)

Perhaps Eaglestone was just too ambitious at this time. There will always be problems when trying to change a game significantly from its design. In time I will probably re-visit the idea, most likely when I have the ability to re-code the needed alterations myself. Until then Eaglestone is on hold.

I will finish a few things and then release it as an alpha-stage development release. Thanks for the suggestions and interest. Following this I have other ideas to try, as well as other projects that I can assist.

[ultifd]

Warning: this topic has not been posted in for at least 120 days.
Unless you're sure you want to reply, please consider starting a new topic.

Yeah I know... sorry. 
---------------------
Is this still being worked on? 
My excuse for bumping this topic is that the pics/screenshots look so cool and nice! 

[Hectate]

No problem on my part. It is the way of a forum for things of interest to float to the top while the less useful sink. I'm sure that it won't be long until this hits the bottom again.

In the post prior to yours I detailed why I put this mod on indefinite hold. While the concept remains viable, Glest and its derivatives are not yet the ideal engine(s) for it yet.

There is a thread elsewhere that contains information, images, and links to the "alpha" content - but I may have deleted the actual files from my website. Someone else here may have them.

Thank you for the compliments on my work though. It was a great learning experience and the mod's "failure" is only such in a sense that it never came to full fruition. I always hope that others will benefit from and enjoy my efforts. Thanks again.

[ultifd]

Aww, that's what I thought. 
Yeah, maybe sometime in the future Glest will be ok... but probably not. 
Yeah, maybe someone has the "alpha" content, we'll see. 
Thanks for replying...and so fast. 

[jda]

I catheced this at the time Hailston posted the said "alpha" content.

It would be magnificient.

I love the concept of the Eagleston and of aerial ships.
I love the really cool so very low polly models and textures.
I love how it all mixes so nicelly together graphically (though I'd say the clouds did need some work, looking at the posted pics).
I love the very original (for Glest) limmitation of resources and the quite diferent ganeplay it implies.
I would love this to be released someday.

Some of the obstacles you posted to completing this are planned for not so far ayway in GAE 0.3 series. That's where I got the link back to this thread! See ticket #54. And that's just one example.
Maybe it won't be so long from now. 

[Gabbe]

Will the files ever appear?

[Hectate]

While I'm fairly certain I deleted them off that hard-drive, I haven't used that particular computer here recently very much. As a result, I may be able to retrieve the files with an "undelete" program of sorts. It won't be anytime immediate, but I'll look into it.

On the other hand, if anybody has the archive and is willing to return a copy to me, I'll be glad to re-host it as before. Ditto if I can successfully retrieve it off the original computer.

And on the THIRD hand, the models weren't anything terribly complicated. In fact, I'd dare to say that I could re-create them in significantly less time than it originally took, and they'd turn out better. The "Galleon" in particular was rather crappy (if I do say so myself) and I'd re-do it differently if I ever did this mod again. Originally it was a stretched and heavily modified sphere primitive - which had drawbacks.

[Hectate]

I catheced this at the time Hailston posted the said "alpha" content.

It would be magnificient.

I love the concept of the Eagleston and of aerial ships.
I love the really cool so very low polly models and textures.
I love how it all mixes so nicelly together graphically (though I'd say the clouds did need some work, looking at the posted pics).
I love the very original (for Glest) limmitation of resources and the quite diferent ganeplay it implies.
I would love this to be released someday.

Some of the obstacles you posted to completing this are planned for not so far ayway in GAE 0.3 series. That's where I got the link back to this thread! See ticket #54. And that's just one example.
Maybe it won't be so long from now. 

Sorry for the double-post, but I just now saw what you'd said. Where exactly was it linked/stated? I'd like to see this discussion and the changes that may enable this mod to continue. I'm guessing the "ticket 54" you refer to is on the code tracker?

Also, I didn't really understand your first sentence...

[John.d.h]

http://sourceforge.net/apps/trac/glestae/ticket/54

It looks like the milestone is something along the lines of "don't hold your breath".

[Hectate]

Thanks John, that clarifies the post for me significantly. I hadn't realized that somebody noticed my "feature idea" and put it down in the "TODO maybe someday" list, lol.

It would be a cool idea to implement, not to mention realistic and useful.
Tanks, for instance, have traditionally been less armored on their top and rear (and to some degree on the sides as well). Specific anti-tank weaponry and tactics have been designed to take advantage of this very fact. For example, mortars launched with a very high arc so they'd strike at a more perpendicular angle - or infantry targeting the tracks to reduce it's mobility.

I wonder - from a purely theoretical standpoint - what kind of coding approach would be good for this. We'd do best to start a new thread though, rather than keeping this thread in a zombie state any longer.... haha.

[jda]

I catheced this at the time Hailston posted the said "alpha" content.

(quote snipped by jda)
Also, I didn't really understand your first sentence...

Nevermind, it's irrelevant anyways but the second word on it was supposed to be 'catched', 'saw'.

Thanks John, that clarifies the post for me significantly. I hadn't realized that somebody noticed my "feature idea" and put it down in the "TODO maybe someday" list, lol.

It would be a cool idea to implement, not to mention realistic and useful.
Tanks, for instance, have traditionally been less armored on their top and rear (and to some degree on the sides as well). Specific anti-tank weaponry and tactics have been designed to take advantage of this very fact. For example, mortars launched with a very high arc so they'd strike at a more perpendicular angle - or infantry targeting the tracks to reduce it's mobility.

I wonder - from a purely theoretical standpoint - what kind of coding approach would be good for this. We'd do best to start a new thread though, rather than keeping this thread in a zombie state any longer.... haha.

Actually I agree only partially to that.
There was also some ticket I commented on the GAE tracker (don't remember the number now) that mentioned different kinds of armor for different different pieces of a given model.
I disagreed with that one because:
1. You would have to define, most likely in the .g3d not the XML, what parts had what armor-type. That would be a pain to mod and would actually be mostly irrelevant to a RTS game (more apropriate for a FPG). It could be done through the apha channel's and different predefined alpha exact values for each part of armor but the alpha channel is already taken up by the teamcolor (which you can make more or less proeminent through the said alpha value, I do that just for the proper looks ).Your 'sides' aproach however doesn't require that, so it's alright so far.
2. You would also have to do something similar on the attacker's side, to define which part of the object would actually be attacking (on a non projectile-based attack) and in what part of the motion (e.g. 'at frame 3' or 'between frame 3 and 4'). And both this and point 1 above would need tho test for specific mesh-parts collision... Regarding this point for your aproach:
 - Mesh-parts collision would be just as messy and irrelevant as stated in point 1.
 - Mesh collision would not be needed for the "which horizontal side is the attack coming from?" because you just need to know what part of the target is "facing" the attacker. But you would need it to determine whether an attack was coming from the 'top' or the 'bottom'.
 - The above paragraph applies to mellee attacks period.
 - Regarding projectile-based attacks regarding the same paragraph mentioned before, they are currently always set to hit the center of the unit (I think but am not completelly sure this is determied both by the target unit's size as well as the height and also the field values); but this could be changed more easily I guess, maybe setting it on the attacker's .xml ...? So... again, for which horizontal side the attack was coming from... feasible. For determining whether it came from above or bellow... I think not really.
 - On top-bottom hiting projectiles, I guess you could alter that to somewhat offset the target-point relative to the target unit's center. Though on moving units and attack coming from above might actually hit the target in the foot... Again, in a modders perspective, you did not really need to work on "sprites" (mesh collision), the engine could actually determine if the projectile had arrived at a fixed object and if not determine what third of the unit's vertical height it actually hit.

In brief, my opinion:
- Mesh parts collision test is unfeasible/unpractical/mostly unneeded.
- "Horizontal side attacked?" rather easy to implement (from a moddder's POV, not necessarilly a coder's one ).
- Attacked on top or bottom not really feasible with current targeting mechanics but I guess could be coded around.

What do you think?

BTW... if you do post another thread on this, let me know, I'll copy this to a reply to that thread and delete it from here.

[wyvern]

There could be marines and a dreadnought

[Hectate]

I wasn't actually suggesting that we allow "top" and "bottom" armor values. For Eaglestone, which is what originally I had in mind, everything is on the same plane of attack and there aren't any "high" or "low" attacks.

I was thinking you could easily have a set of XML definitions along the lines of...

Code: [Select]

<armor> (existing armor code?)
<directional armor>
<armor type> (for multipliers)
<start angle 315>
<end angle 45>
</directional armor>
[additional directional armors as needed]

It is important to note that this code applies to the angle that a successful attack strikes from - and does not apply to explosive damage. Obviously this is assuming the unit is facing "North" and the internal code will need to calculate any translations (unit orientation) into the mix prior to determining if the armor benefit applies or not. With the above settings, it gives the unit a 90 degree (-45 to +45) arc of a different armor type. Of course, if there aren't any additional directional armors, this particular code would mean the standard armor for the unit would apply from degrees 46 to 314 instead. That way it's not required to apply directional armors to the whole unit.

Here is an example sketch from MSPaint Green is the custom directional armor that overrides the standard (yellow) armor type.

Code: [Select]

[URL=http://img532.imageshack.us/i/armorvalues.gif/][IMG]http://img532.imageshack.us/img532/6301/armorvalues.gif[/img][/URL]
Note that of course, since attacks go toward the center of the unit (as noted above) this system would work despite the first thing everyone thinks of - that being "What about side-moving attacks that hit close to the FRONT?". It wouldn't matter because it's the angle of the attack, not the location of the strike.

Feel free to quote this in a new topic if desired. It'd probably be best but I don't know which forum would be appropriate.

[jda]

I'll post this to both the GAE and Megaglest's boards. Each team might want to implement this in a different way, or not. Though I myself would prefer them to be as mutually compatible as possible, it's not my plase to decide that so...

EDIT: Well, I was feeling bad about double-posting this to two different boards. And I think it's kind of a bad principle to be posting any new feature request to both GAE and MegaGlest.
So... GAE had a ticket open for this one already and I actually updated that same ticket to point to the new thread in the GAE board, so I guess that's the best place for this.

So I removed the MG thread from its board (no replies yet anyway) and kept only GAE's. If the MG team wants to add this feature to their TODO list or whatever, I'm sure they will anyways.