1 Reply by SyberSmoke

(12 replies, posted in Feature discussion and requests)

1. all missiles from one launcher will always exhibit a guidance failure
- Your making an assumption that a statistical variable can not be placed with in the math to allow for the 10% failure chance.  As I said before your only worried about the total damage, to get a random number from four values, and then see if there was a fail or not is not that difficult.  Shoot, I do it all the time...with DICE!  And a computer is way faster then a percentile roll.

2. 4 missiles are fired but only one taken from cargo to reload
- Already covered this, changing ammo from the singular: Missile.  To the plural: Missile Pack.  Would fix this issue since any amount of missiles can be in a pack.

3. client cannot randomise the launcher animations in advance, since hit is calculated when it lands while LOS when firing.
- Your making an assumption about the time frame of an effect.  Given the simple truth that all the mat is probably done with in one, may be two cycles, AND that your operating with a latency of 50ms...I have 200ms by the way.  There really is plenty of time.  I was in a team that was looking to do Terrain Deformation based on an impact...they were all worried about it eating to much time on the hit.  They forgot that the particle occlusion from the hit would last a few seconds, more then enough to make the calculations with in a few frames.  This math is far simpler.

-----
As for the tubes, never really saw the alternating effect.  In fact when the medium launchers have always fired I have typically seen four missiles launch with one occasionally fly into the sky.  Interesting thing to look for next time I am on thought.

Go to forum: Feature discussion and requests

2 Reply by SyberSmoke

(12 replies, posted in Feature discussion and requests)

Annihilator wrote:

yeah, but for a single voley from a gropho it would multiply the server load for damage calculation by a factor of 4! (differences between what the UI shows and what the Server does are BAD and starts spawning bug reports on forums because player start seeing things...)


Not true, to the server the damage would be the total damage applied to the opposing target, not the individual damage of the missiles.  The division of the damage would be a client side effect of the launcher.  So the server would have nothing to do with it.

Really, all the server would need to say is how much damage was done and if there were any misses out of the total missiles the launcher can fire.  That is about it...

Go to forum: Feature discussion and requests

3 Reply by SyberSmoke

(38 replies, posted in Feature discussion and requests)

Norrdec wrote:

They can already do hybrid bots, but it's close to impossible to balance them wink Or so I heard.

Balance...bah.  Who needs balance in a world where none exists any way.  yarr

Actually balancing is not to hard if you get away from common processes of thought.  In this context though I do not know what their thinking is so can not come to a conclusion of whee they could go with it.

Me, I would break the bot into pieces then assign the bulk of the attributes to the "Core" of the robot.  Then each part attached to the core modifies the core, altering some attribute positively, while also altering other attributes negatively.  It is in truth a simple and a tried and true system.

Go to forum: Feature discussion and requests

4 Reply by SyberSmoke

(12 replies, posted in Feature discussion and requests)

Annihilator wrote:

the chance to hit is calculated at launch, but the damage dealt is applied when it hits. (exception: final blow is instant)

mix that up with missiles that hit you one after another not doing any damage. thats confusing.

Depends on the application of damage.  If each tube, and the missile there in, has a potential damage, then each hit would of coarse take off a chunk of HP.

So say you have a four tube launcher, a missile pack for that launcher does 200 damage.  TO make it easier, client side (since server side it is just numbers any way) the UI shows each hit as applying 50hp of damage instead of one lump of 200.  That allows a staggered missile launch, but does not effect back end math.

Go to forum: Feature discussion and requests

5 Reply by SyberSmoke

(38 replies, posted in Feature discussion and requests)

To be honest I do not think a module would work well in this case.  While the LWF is changing the frame of the robot, it is not actually restructuring the bot.  A cargo module would be more of an expansion or serious alteration to the robots design, something that looks to be out when compared to modules.

What I could see though is if the developers get a system working where you can swap out full design elements like the legs, the head, and other things.  That the Industrals could have a backpack slot...for lack of a better term.  Where for a hit tot he robots weight, it gets mo internal space to work with.  This would then be feasible, but really only in that context.

Go to forum: Feature discussion and requests

6 Reply by SyberSmoke

(12 replies, posted in Feature discussion and requests)

Alexander wrote:

1. They should make missile animations make more sense. Small should be two missiles two missiles together twisting around. Mediums would be 4 missiles twirling around. This would be graphical of course but would solve why small launcher have two tubes and mediums have 4.

2. I don't really get this entire idea. It sounds rather like changing missile mechanics and starting again. It is one solution but I don't see the problem that the solution is for. Launchers are meant to be heavy but simple tech with the ammo being the complex part of the weapon.

3. You can shoot weapons with F1 through F8. Space is just an alpha strick. Each weapon still performs independently. There is no way to tell if you're alpha striking or staggered fire so there is no way to make an animation for each choice. If you want to stagger your fire then do so. It does have advantages.

1. I do agree on this one, it would make more sence and instead of loading "Missiles" you could always rename them Missile Packs so the ammo does not need to change nearly as much.

2. The idea was for larger launchers with a multiple missile system.  There is no REAL problem, but since this is a suggestions and ideas forum...it was an idea.  That being additional launchers that would not be destabilizing.  Well not unless you also allow dual and tri beam lasers, rapid fire EM cannons, and Vulcan style machine guns.  But I would still like to see more launcher designs and capabilities.

3. Staggered fire would be an animation effect.  So missiles would launch one by one instead of all at once.  It would have nothing to do with the actual weapon, instead just spreading out the launch effect.  TBH I never did like the "anime" style missiles where they all launched at once and were all weaving around in the pattern...nifty looking, sure...but still not really practical.

Go to forum: Feature discussion and requests

7 Topic by SyberSmoke

(12 replies, posted in Feature discussion and requests)

1. I would like to see the second launch tube on my small launcher actually work.  Kind of bugs me to have a launcher, and only plink away with one missile at a time when it has two tubes on the mesh.

2. More launchers please...with more tubes!!!  OK, so this could be overpowered since a bot with say a small 6 tube launcher would raise allot of hell, especially the robots with launcher bonuses.  But after thinking I also had a thought about that one.

2.a. Individual tube reload rate - The idea is simple really, each tube would be treated as a separate slot in the weapon.  The rate of reload for the weapon would determine the time it takes to load one round into a launchers slot.  SO, after firing a volley and depleting the launchers ammo, the launcher will reload one shot at a time.  From then on the player can wait for it to completely reload.  Or the player can fire rounds as they are loaded.

Better launchers can also load multiple rounds at a time per cycle.  So say while a tier one launcher has to do it one by one.  A tier three could load two at a time.

3. Staggered Fire - Watching others use th medium launchers I have wondered about this, why all at once.  Should they not be fired in a more staggered mode?  Well unless the missiles are very heat resistant and have no chance of colliding with other missiles that are on a parallel track.

Go to forum: Feature discussion and requests

8 Reply by SyberSmoke

(11 replies, posted in Bugs)

Situation: In combat
Weapon Status: Launcher ran out of ammo and auto reloaded.
Effect:  The ammo type changed with out notification.  IF I use B with on round in the launcher, i get the same stuff.  But if I have 0 in the launcher, it goes to chemoactive when it should go to double core.

This was all automated for me, and it happens consistently.

Go to forum: Bugs

9 Reply by SyberSmoke

(11 replies, posted in Bugs)

Stainless wrote:

Same here, did happend with miners and geoscanners too.
Very annoying.

From what Ammo to what ammo.  And is it always the same ammo.  So say if you use Sonic or dualcore does it always go to chemoactive?  A little more detail in the "Same Here..." replies.

Go to forum: Bugs

10 Topic by SyberSmoke

(11 replies, posted in Bugs)

I thought that I would mess around with missiles for a little fun and have found them handy.  BUT what I have found less handy is that the launcher swaps ammo on me when it reloads automatically.

I have three types of ammo in my bot: Chemoactive, Dualcore, and Sonic.  When my launcher reaches zero, the ammo will change from dualcore or sonic to Chemoactive.  This is rather irritating as I did not tell it to change and chose the ammo specifically for the target.

To me, this is a bug since the launcher should reload the last ammo used and not some ammo it thinks is better.

Go to forum: Bugs

11 Reply by SyberSmoke

(5 replies, posted in Feature discussion and requests)

Well Unless the extension adds a +1 to say designated off site stations.  So the player would need to visit the terminal or outpost then designate that outpost as one of his designated places.  Thus allowing remote access.  This would have the effect of limiting the player to ten terminals or outposts.  Additional extensions could be added to allow more terminals as the world grows, but at greater cost.

Go to forum: Feature discussion and requests

12 Reply by SyberSmoke

(5 replies, posted in Feature discussion and requests)

I know, I like Windowed mode just because I have other things going on as I play.  So having it maximized is not an option.  It just bugs me that a web browser can remember how it was sized...but this game can not.

Go to forum: Feature discussion and requests

13 Topic by SyberSmoke

(5 replies, posted in Feature discussion and requests)

This has to be one of my biggest minor issues that I have run into.  That being when ever the game starts in windowed mode, it starts maximized and I have to re-size it each time I play.

The suggestion is simple.  Allow the windowed mode to remember where it was, and how it was when the application using it exits out instead of placing it into a generic state each and every time.

There is no reason this can not be done easily and could probably be implemented with a minimum of hassle.  Please?

Go to forum: Feature discussion and requests

14 Reply by SyberSmoke

(48 replies, posted in Feature discussion and requests)

Preceding Note:  This idea is based on a ground control scheme where the players control a limited amount of territory.  The simple is you expand and control territory based on you initial structure and expansion structures. 

Name: Teraforming Control Pylon
The teraforming control pylon can be placed with in the corporations area of influence to expand that area.  By placing the Pylon, a connection is made to the central base and expands the controllable territory of the clan.  Resources with in the controlled area will offer better yields then resources outside.  Teraforming Control Pylon will connect directly to the central office or nearest control pylon to draw power from the base to power structures with in the towers proximity.  Destroying a pylon in the chain will disrupt power top all remaining pylons.

Name: Small/Medium/Large Fusion Reactor
The fusion reactor is the primary source of power for the base and it's facilities.  Defenses, manufacturing, and other structures all draw power from a pool of reactor production.

Name: Clan Teleport Hub
The clan teleport hub works like other teleports with the exception that the Clan can choose who to let see it and who can not.  Clans can restrict travel to their teleport hub to only clan members, to allies, to specific parties by name, or allow any one through if they desire.

Go to forum: Feature discussion and requests

15 Reply by SyberSmoke

(6 replies, posted in Feature discussion and requests)

In most cases JJ's would not be good for any really large bot type.  The mass of the bot would just take to much energy to get off the ground.  Lights and Assaults would work best with Mechs running third.  That way you can have the attacking heavy mechs and tougher as a distraction force while lighter robots can encircle the enemy.

With additional thought, Personally I would not allow the players to create walls of soil, at least not extremely high ones.  I would allow a reasonable height and then allow the players to build walls on top of them to add height.  But also make those destructible so that an attack force can get up to them and blow a hole in a perimeter defense.

But that is how I think.

Go to forum: Feature discussion and requests

16 Reply by SyberSmoke

(6 replies, posted in Feature discussion and requests)

I do tend to agree that "Proceduraly Generated" is rather dull.  But the term is accurate since your generating a quest or what ever via a defined procedure of steps and random factors.  So at least in this way the Developers know the goal of the idea instead of just calling it something else that may not have the proper terminology.

Alexadar: I agree with you very much.  There are just so many MMO's that stick to the story and forget about trying to make a living world.  One with ebb and flow that the players will account for.  Would it be a good time to attack...a good time to defend.  Will hitting the Nians mining operations help or hinder efforts.  Some just that little more then "Oh hey, there are some red blips in that field...lets kill them".

I like PvP...do not get me wrong.  But some times I do not want the hassle of it and just wana chill.  big_smile

Go to forum: Feature discussion and requests

17 Reply by SyberSmoke

(6 replies, posted in Feature discussion and requests)

Jump jets would work, but would require allot of balancing in terms of stability. Placed in the leg slots of a Robot, using them would drain Accumulator to be able to jump distances.  To prevent Acc stable Jumping....Jump Jets could stop the Acc refill process when in use.  So use it to much and oops.  Oh and do not forget about fall damage...hehe...also another oops.

Go to forum: Feature discussion and requests

18 Reply by SyberSmoke

(6 replies, posted in Feature discussion and requests)

I agree that Story quests should not be repeated since once your finished with that section of the plot line, it would be silly to redo it in most cases.  This would more be for repeatable quests that are less predictable then most go here and do this and that.

As one of my ideas was for say kill quests that would involves actually operating with in the war between the Syndicate and the other Bot factions.  So say in terms of a combat mission you receive a kill order.  In the process of doing that kill order, you get an emergency beacon from a team of allied bots in the area of the kill order.  You can now just persue the kills or help the bots.  Helping the bots, you get options to kill enemis fulfilling the order, or to act further by say killing their leader, or to KO the Support Beacon that they are using to mark their beam in point.

This then can keep branching stacking additional bonuses, but choices can also have negative effects.  Like say you kill the enemy leader.  May be that faction then places a 1 hour debuff on your Robot called Marked for Death.  Where enemy robots have a chance to spawn in around you in an attempt to kill you.

Just something better then the golden four quests of:
1. Go there and kill that.
2. Go there and Collect that.
3. Go there to collect that by killing this.
4. Go there and deliver this.

MMO's can do so much better...

Go to forum: Feature discussion and requests

19 Topic by SyberSmoke

(6 replies, posted in Feature discussion and requests)

For the better part of 24 years I have been playing computer games and table top RPG's.  I have seen allot of stuff and have felt there was allot lacking when comparing the two.  But what I miss most and only encounter so often is the idea of the Branching Quest.  Now what does that have to do with the topic?

Simply put I am suggesting the creation of procedural system that will generate branching quests.  A system that would draw upon defined sets of quest modules, put them together and hand them out as needed.  This would allow variety, choices, and consequences, and in a world that is persistent, there is a significant lack of consequences.


The Branching Quest

Any one that has played a good RPG knows what a branching quest.  So to just explain it to those that may not know here you go.  A branching quest, is a single quest line based on choices.  As choices are made the quest progresses in a manner consistent with the choice.

The benefit of a branching quest is that the quest can not only have curves and choices that can have lasting effects on the player and the world.  But that the player can typically take one of many branches as they progress and the quest will be different each time unless they take the exact path every time.

Making a branching quest is not all that hard, in fact there have been books with branching storyline for a while.  What may be hard is to make a system can can generate quests procedurally.  And to do it in a way that is enjoyable and has enough variation that it will retain a level of enjoyment for those taking part in them.


Procedurally Generating a Quest

The goal of this is to make quests that are varied with out having to make each and every one by hand.  To do this the quests would be divided into blocks and scrips that can be pasted together.  Once there are blocks and the code, the quest will need to have a story arc length.

The Arch Length should vary between two steps for a short quest to up to six or more sections for longer quests.  Each section of the quest can have a small reward or the player may need to finish the entire quest to get their incentive.  Needless to say, longer and more difficult quests will have a greater potential reward.

Finally there will be the quest branches.  At each step the player should have a choice of two to five paths they can take.  This would allow a significant amount of variety and since the value can change from quest to quest and branch to branch this would add allot of variety.


Limiting the Load

Branching quests have the potential to be very large.  A six link quest with five options at each branch would have 5^6 options or 15,625 potential choices that the server would need to generate.  To mitigate this, the server really only has to track the next steps in the quest since any path not taken is null and void.  This a six step quest boils down to only thirty choices, and this shrinks as choices are made.

To do this, the quests would not be generated at the time it has been taken.  Instead it would be generated at each step with variables for the choices determining the next step.  And while this is far more intensive then a single step static quest, the journey could be far more intertaining then just “go there and kill that”.


Lasting Effects!!!

One of the things that always bothered me in any MMO that said it was “persistent” was the application of that persistent nature.  In most cases quests have no real effect on the world, and the only persistent elements are death and any thing in the field made by a player.  This is something that could be changes with a quest system.

The idea is simple that at the end of the quest line or even during there are effects that can be tied to and placed onto the player.  If say you reach a choice and you take the most negative, a debuff for some kind of random event could be applied...like assassin robots spawning on top of you at random time intervals.

In the same note, positive effect could also be applied like having NPC followers for a time.  When they die, they are gone.  But till then they will blast what you blast or what blasts you.  Now these are just ideas and really the possibilities are only limited to what can be dreamed up.  But there is more available then just ammo and gear rewards.

Choices can also negatively impact a players relations with a specific faction.  Or playing your cards right might make you friends where you were once ostracized.  But the final goal is to make a living breathing system where the players choices, be they good, neutral, or nasty, will have an impact on the game in some meaningful and tangible way.


Adding Actors to the Stage

Finally a quest structure of this sort would also need additional actors.  Currently there are three kinds of actors in Perpetuum; Players, Props, and Hostile NPC's.  Quests and longer quest line would facilitate a need for a fourth kind, Friendly NPC's.

These friendly faction NPC's offer a chance to make the world live a little.  Especially since there is something of a war going on.  NPC's could be Indurtrial's that came under attack and need their cargo taken to destination.  They could be a platton of combat robots under heavy attack and the player chooses how to help.  Or may be a caravan of miners that need help to hold their position, or even retreat from the field.

What ever the plot possibilities, Friendly NPC's add to the quest potencial.  And the nice thing is that they not always be there.  Really they only need to be there when a player gets with in scan range to see them.  So their activities need not eat uf island space or resources for longer then necessary.


Conclusion

In any case I hope that I have created a good idea for consideration.  I understand all to well that this is either perceived to be, or is a PvP game at it's heart.  But while I accept that I will be blow the scrap in the process of playing the game, I also would like to have time to my self to enjoy the game world with out the risk of being ganked.  As such there is room for both active PvP and an enjoyable and immersive PvE experience.

I hope you all enjoyed the suggestion and that you will comment constructively.  Please no flaming about how “carebearz sukz” or some other stupidity.  We all pay our money and should have an opportunity to enjoy the game world as we desire in the ways we desire.

Go to forum: Feature discussion and requests