1
Mods / Re: Terra Centauri: Last Stand
« on: 14 April 2015, 11:46:30 »
A lot of them look like turds with legs or wings attached
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.
Pages: [1] 2
2
MegaGlest / Re: Objective attack
« on: 28 December 2014, 00:45:22 »
Where is it handled? I've been poring over the source since I made this topic, but I don't have the familiarity with the methods called to really do so effectively (yet to find anything). Although the code is commented in places and the text isn't the gibberish to me it was a year ago I still remain perplexed.
3
MegaGlest / Objective attack
« on: 25 December 2014, 06:54:24 »
I realize moving while attacking isn't really a thing and probably won't be for megaglest's near future, but I was wondering if there's any way to remove the prerequisite for the unit to turn and face an object prior to attacking it? I'm a novice at programming but if someone could kick me in the right direction that'd be great.
(what I want to do is have the unit utilize the attack_stopped type instead to simulate the effect, without the turning giving it away)
(what I want to do is have the unit utilize the attack_stopped type instead to simulate the effect, without the turning giving it away)
4
Mods / Re: Terra Centauri: Last Stand
« on: 16 May 2014, 04:06:17 »
I have to say I really love your UI. Any procedure in particular you used there?
5
Mods / Re: Terra Centauri: Last Stand
« on: 9 May 2014, 20:31:12 »
If I may ask what purpose they serve atm?
6
Mods / Re: Terra Centauri: Last Stand
« on: 9 May 2014, 18:25:28 »
I really love the quality here and the direction you're taking your gameplay; my only concern is that your second faction seems a mite generic and could very well end up being underplayed. I'm not advising to copy them wholesale, but Starcraft's Zerg seem like a good reference point, at least as far as making them as intriguing as they are.
7
MegaGlest / Re: WIP: dabascht's QT4/5 based map editor
« on: 4 May 2014, 04:52:44 »
What does that mean, though? Better cross compatibility?
8
MegaGlest / Re: WIP: dabascht's QT4/5 based map editor
« on: 2 May 2014, 18:57:11 »
I'm an idiot, what does this mean?
9
Mods / Re: How to Sensor?
« on: 20 April 2014, 01:36:22 »
Yeah I've messed with it, just really not into the TA style of things it sets as a precedent. Oh, and LUA anims. Those are a pain in the ass, too.
I plan to move to another engine later on (this whole thing is just me rounding out my skillset) but for now I'd like to get the proof of concept done in Glest because it's by far the most intuitive & friendly platform when it comes to rts.
I plan to move to another engine later on (this whole thing is just me rounding out my skillset) but for now I'd like to get the proof of concept done in Glest because it's by far the most intuitive & friendly platform when it comes to rts.
10
Mods / How to Sensor?
« on: 19 April 2014, 17:48:03 »
I was thinking about interesting ways to handle the RTS game trope of 'fog of war' in way that'd be authentic to my setting and what seemed to be pretty cool is implementing a radar of sorts.
Not anything too tricky, just having units be able to 'spot' enemies in a radius outside their usual view range without having a positive ID on what exactly it is. So, for instance, infantrymen A will be able to convey there are enemies nearby, but the commander will have to either risk units or get something with moar view to figure out just what the threat is. This would add a nice dimension to gameplay, I think.
My inspiration, SC2's sensor tower, handles it like so:
You can see pretty clearly that the red Warning Icons are indicative of zealots converging in on the Terran player's position.
In effect what needs to happen is for warning icons to appear over enemy units within a certain radii of friendly units - basically a secondary view range. In Glest, I'm not really sure how to do something like this. It might not even be possible. Given that, I'd be willing to try to code it in myself but I don't know where to start - my programming knowledge amounts to some basic lua and java at best. Any recommendations as far as that, or finding some Macgyver way to make this work?
Not anything too tricky, just having units be able to 'spot' enemies in a radius outside their usual view range without having a positive ID on what exactly it is. So, for instance, infantrymen A will be able to convey there are enemies nearby, but the commander will have to either risk units or get something with moar view to figure out just what the threat is. This would add a nice dimension to gameplay, I think.
My inspiration, SC2's sensor tower, handles it like so:
You can see pretty clearly that the red Warning Icons are indicative of zealots converging in on the Terran player's position.
In effect what needs to happen is for warning icons to appear over enemy units within a certain radii of friendly units - basically a secondary view range. In Glest, I'm not really sure how to do something like this. It might not even be possible. Given that, I'd be willing to try to code it in myself but I don't know where to start - my programming knowledge amounts to some basic lua and java at best. Any recommendations as far as that, or finding some Macgyver way to make this work?
11
Closed feature requests / Re: Select multiple buildings at once
« on: 8 April 2014, 23:44:24 »Multiple selection is specifically disabled for buildings because it's usually used to select units via drag and drop, and if you also selected buildings, you wouldn't be able to tell your units to move (as they lack a common move skill).
Well this could easily be addressed by some logic where if any units are selected, no buildings are added to the selection.
Furthermore, you shouldn't be able to select different types of buildings at once (ie: you can only select multiple buildings of the same type). Otherwise it wouldn't make sense to select a barracks and a town hall at the same time since they do different things.
I could be wrong, but I'm pretty sure the current method exists to avoid doing those.
12
Closed feature requests / Re: Select multiple buildings at once
« on: 8 April 2014, 21:59:05 »
That's something specified in the unit's xml, I believe. Meaning you'd have to mod your own version of the Megapack with that alteration in order to do what you propose. I have absolutely no idea how glest handles production from multiple selected units, though.
13
Mods / Re: Terra Centauri: Last Stand
« on: 7 April 2014, 22:24:54 »
Well, here's something for you. Evolution, a mod for SpringRTS, just passed Steam Greenlight, so that's something.
http://store.steampowered.com/app/291150/?snr=1_5_9__205
It is however free, so that does leave more up to debate. There are commercial Spring mods, but none of them have made it on Steam.
http://store.steampowered.com/app/291150/?snr=1_5_9__205
It is however free, so that does leave more up to debate. There are commercial Spring mods, but none of them have made it on Steam.
14
Mandate Engine / Re: Mandate Update Thread
« on: 4 April 2014, 18:38:28 »
You're only releasing after you finish your game, right?
15
Mods / Re: Terra Centauri: Last Stand
« on: 4 April 2014, 18:36:49 »
Well, fuck me. I've been working so undiligently on a sci fi mod and this just absolutely blows what I have out of the water.
Thanks for crushing my hopes & dreams
Seriously though, those screenies are bloody amazing. How are you going to do a commercial release while open source, though? It seems like indie games that don't make it on Steam are wildly unsuccessful these days.
Thanks for crushing my hopes & dreams
Seriously though, those screenies are bloody amazing. How are you going to do a commercial release while open source, though? It seems like indie games that don't make it on Steam are wildly unsuccessful these days.
16
Feature requests / Re: Ability to easily take screenshots without HUD
« on: 13 February 2014, 21:37:45 »
Dear sir, I urge you to read your text again if revise it if your intent was to relay anything other than that ("no one has time to click a button in the heat of battle!"), because that's what it conveys at the moment.
Sincerely, your friend Tiel.
Sincerely, your friend Tiel.
17
Off topic / Pyrogenesis vs. Glest/Megaglest (as an engine)
« on: 13 February 2014, 21:35:23 »
Because according to tomreyn this kind of thread is really necessary.
Both are open source, and are thusly really easy to mod, though Pyro takes the lead here since you can export directly into opensource COLLADA format as opposed to g3d. Both engines use the really easy xml standard to define characteristics, which is tops. I haven't compared any of the xmls I've worked on with this engine with those of Pyro's; by the looks of things the only difference is there's a bit more subdivision regarding folder structure.
As far as content goes, it's really a matter of taste between Megaglest's default techtree and the ten or so available in Pyrogenesis's own flagship game, 0AD. The assets in the latter are indubitably higher quality, but there's also a bit less of them and balance is a mess at the moment. Additionally, more of an engine fault if anything is the fact that Pyro seems to be choppy on machines that should meet its system requirements, which are a bit higher than its opponent here, but should you meet them it just kicks Glest's requisite low-poly style out of the water.
So that said, is there really any reason to consider Glest as a platform for development when Pyrogenesis offers a lot more graphical flexibility? I'd like to hear thoughts on this; while a ton of people are going to obviously be very biased on this subject matter given the forum's mission, anyone's experience with Pyro compared to Glest would greatly contribute to the topic of this thread.
Both are open source, and are thusly really easy to mod, though Pyro takes the lead here since you can export directly into opensource COLLADA format as opposed to g3d. Both engines use the really easy xml standard to define characteristics, which is tops. I haven't compared any of the xmls I've worked on with this engine with those of Pyro's; by the looks of things the only difference is there's a bit more subdivision regarding folder structure.
As far as content goes, it's really a matter of taste between Megaglest's default techtree and the ten or so available in Pyrogenesis's own flagship game, 0AD. The assets in the latter are indubitably higher quality, but there's also a bit less of them and balance is a mess at the moment. Additionally, more of an engine fault if anything is the fact that Pyro seems to be choppy on machines that should meet its system requirements, which are a bit higher than its opponent here, but should you meet them it just kicks Glest's requisite low-poly style out of the water.
So that said, is there really any reason to consider Glest as a platform for development when Pyrogenesis offers a lot more graphical flexibility? I'd like to hear thoughts on this; while a ton of people are going to obviously be very biased on this subject matter given the forum's mission, anyone's experience with Pyro compared to Glest would greatly contribute to the topic of this thread.
18
Feature requests / Re: Ability to easily take screenshots without HUD
« on: 13 February 2014, 12:57:15 »
The quoted text basically states 'ain't nobody got time fo dat' in regards to pressing a single button while still evidently being in support of a single button screenshot option for the very same reason.
That's doesn't sound...off, to you?
That's doesn't sound...off, to you?
19
Off topic / Re: 0ad doing a kickstarter
« on: 13 February 2014, 01:00:05 »
I know this is an old thread, but does anyone have an idea of how pyrogenesis stacks up to the glest flavors?
20
Feature requests / Re: Ability to easily take screenshots without HUD
« on: 13 February 2014, 00:50:32 »you don't have time to do other stuff than winning honestly you almost dosn't have time to press the screenshot key
So the point of this would be...?
21
General discussion / Re: An inquiry!
« on: 12 December 2013, 01:11:38 »
Megaglest doesn't have a lot of features that are essential to the gameplay experience I'm planning out.
22
General discussion / Re: An inquiry!
« on: 11 December 2013, 22:30:19 »
It's not something you plan on supporting though, right?
I could use Mandate in its current form (if it works over mp), but it depends what's there right now.
I could use Mandate in its current form (if it works over mp), but it depends what's there right now.
23
General discussion / Re: An inquiry!
« on: 11 December 2013, 12:55:37 »Most of this is available in my fork of GAE. While the game I am working on is not finished, and has been further delayed by my plan to hit 1trillion isk a year in income in EVE Online, individual features are functioning properly.
As far as "squads" go, I don't use the GAE pet behavior. Its quite limited. Rather you will specify behaviors for units in a special AI file. For instance the defend behavior causes units to, assuming it has the highest priority, attack units which are attacking their owner. The rest behavior causes units to load themselves into their owner, where they then heal, which although not appropriate for squads of humans, could work for a carrier, or a spaceship with drones and so forth. There is not currently a follow behavior to be paired with the defend behavior or a behavior which causes units to attack their owners target, but this would be trivial to implement. Note that these are not commands, and you cannot control a unit that follows AI routines. Well, you can because I haven't added the flag to block hide commands and block right click orders, but that is a small change I am waiting to make after I finish some stuff.
Units can be assigned owners, based on a flag in the produce command, and owners have specific caps for how much of each unit type they control. Automatic generation of units and manual produce commands will not function if the control limit is capped. Note also that units can be set to automatically create other units, which they can own and to which their cap applies. Spawn of controlled units is based on a timer which you can set.
IIRC Hailstone is possibly working on multiplayer for GAE, I don't think there are any plans to add other features in the mean time.
I'd love to use Mandate given all the features it has, but to be honest no multiplayer kinda kills me. GAE itself only has the most rudimentary of networking functionality, but it's important for the project I'm working on. At least now. If I ever get off my lazy bum and brainstorming a companion singleplayer experience I'd love to go the route of MoH 2010 as far as SP vs MP in engines.
24
General discussion / Re: An inquiry!
« on: 11 December 2013, 02:03:35 »
Thank you for the response.
I found out on an earlier thread for GAE that pets automatically are set to Guard the unit that produces them, which I'm according to the wiki "is a new command in GAE using existing skills. It causes the unit to follow another, attacking nearby enemies, but always returning to guard that unit." Which is absolutely perfecto for what I'm thinking of. And just to be sure I'm being understandable here, here's the idea -
So that leaves a few things up in the air for me:
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.
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?
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.
d) Does there exist a method for editing the selection circles for units? If not, can they be made larger artificially?
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.
I found out on an earlier thread for GAE that pets automatically are set to Guard the unit that produces them, which I'm according to the wiki "is a new command in GAE using existing skills. It causes the unit to follow another, attacking nearby enemies, but always returning to guard that unit." Which is absolutely perfecto for what I'm thinking of. And just to be sure I'm being understandable here, here's the idea -
- Barracks produces a squadleader of a given unit type
- He has the ability to produce squadmembers (pets) up to a cap designated in the XML file
- Squadmembers follow their squadleader and do things already implemented for pets like attack nearby enemies and such
- On death they can be replenished at a slow rate (again, functionality already there)
So that leaves a few things up in the air for me:
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.
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?
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.
d) Does there exist a method for editing the selection circles for units? If not, can they be made larger artificially?
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.
25
General discussion / An inquiry!
« on: 10 December 2013, 19:57:27 »
So I've been really lazy lately but just started generating ideas in el cabeza, when the prospect of squad combat inevitably broke the surface of the murk. Naturally, I furiously googled the subject to find that GAE's pet system might offer a solution!
Basically, a pet is a unit made by another unit for maximum unitception. So, okay, what if instead of making a unit, the barracks created a Sergeant instead, who could then create lesser units up to a cap before charging into combat? And if they fell it's only natural that the squad would be 'broken', in keeping with all pets dying upon owner death!
My question here is whether pets are selectable, if they follow their 'owner', and if there's a way to rectify those two issues with my little scheme if the answers are yes and no, respectively.
(Also, as a sidenote, is there a way to have multiple sounds per unit on being selected, etc?)
Thank you for your time, this community is awesome, and I am hyper as all hell right now.
Basically, a pet is a unit made by another unit for maximum unitception. So, okay, what if instead of making a unit, the barracks created a Sergeant instead, who could then create lesser units up to a cap before charging into combat? And if they fell it's only natural that the squad would be 'broken', in keeping with all pets dying upon owner death!
My question here is whether pets are selectable, if they follow their 'owner', and if there's a way to rectify those two issues with my little scheme if the answers are yes and no, respectively.
(Also, as a sidenote, is there a way to have multiple sounds per unit on being selected, etc?)
Thank you for your time, this community is awesome, and I am hyper as all hell right now.
Pages: [1] 2