Idea for new Weapon - Active Module - Sonic Wave

Will see about this idea. But, guys, those walls of text are almost impossible to read. I’ll appreciate short and complex information in the future.

 

That *WAS*  the short versions…

I left out the Functional and Technical Requirements and the Logic Changes and actual lines of code and where to make the statement changes…

 

If i included those, there’d be nothing to do but code it… LOL

 

About your idea, the one use only is perfect to me. I don’t know others, but i haven’t a fast way to eject cargo: It is required.

 

 

 

Thought about that statement last night some…solution… Expand the KEYBINDS for a new set of keys.

 

New ones.   LIke 1,2,3,4,5,6,[7 8] on the 10 Key Pad or the top number rows.  

(7 and 8 being the added cargo module) To eject that Cargo Compartment quickly.    

Or even Pick Up cargo and place into that compartment.   Like a cargo toggle.  Load/Eject per Cargo Compartment.

 

Right now its INTERACT keybind and logic (probably an Array and Index Pointer to the next open compartment) that does that until filled.

That Logic could be kept as is, and new logic added to check if a new keybind is pressed, do the INTERACT and place into that Compartment number.

 

Your flying and want to drop a 1-Time device… press a number for the cargo compartment its stocked in and it drops.

Flying and come upon some Loot?   the scanner chime signals and either press INTERACT or press a number…Loot is taken in via AUTO or into a compartment number.

 

I know Id love the selectable inbound loot.   I hate it when fuel and containers get mixed up in cargo and I eject the wrong one because something shifted.

Ive done that while in dogfights and I want a Loot and still shooting…theres no time to look and sort things out and something shifted. 

So Fixed Cargo would be a godsend at times.

 

Not a total logic replacement…both…enhanced logic…Fixed Cargo and Auto Cargo.    Depending on interaction and key pressed.  

If you elect to press a Fixed Cargo inbound key and the slot is occupied… one just heard that err…err chime sound one hears when all the slots are full, as it does now.

 

Empty slot and you elect to eject… err err chime again…

The Onboard Ship Computer then laughs at you and silently calls you a Stupid Human Nobb.

The slots shouldn’t move once something is in it - simply make the one you ejected stay empty do not move the rest down!

That *WAS*  the short versions…

I left out the Functional and Technical Requirements and the Logic Changes and actual lines of code and where to make the statement changes…

 

If i included those, there’d be nothing to do but code it… LOL

 

When we need to implement any idea, all the details are changing a lot during development cycle. Except maybe from some original sence of it.

CinnamonFake, I totally understand where youre coming from.

Im an Analysist / Developer also RL.   I specialize in New Product Development for Businesses…

So I get it as to what youre to encounter and face based on some of this discussion.

Its sort of the reason for some the in-depth and detailed explanations actually.  

So as to present the entire Scope for a possible implementation based on how the thread feed out and not just an off the cuff post for some new gadget 

 

What Ive always felt from day one of logging in and using it though was this…  The application feels to me as if it was three smaller ones combined into one,   There’s the PvP, the PvM and the Open Space.    Cargo Holds, for example, are only in Open Space, as if that’s the module they were designed for but didn’t make sense in the other two sub-sections.   So they are hidden or the logic just doesn’t exist in them.  If this was the case of the origins of the 3 areas we are well past that in the Life of the overall application, wouldn’t you agree?   From a users perspective, its one game application with different areas.

 

Its under this thinking that I’ve also tried to express how one could incorporate the different areas of separate logic into something that later down the development road, the logic would be simplified to add in future objects, since that’s what users want and see.   What new weapon or ship module am I getting in this update.  That sort of thing.  They never know that sometimes huge chunks of code had to be redesigned or developed just for some new thing that they interact with either with a mouse or see on the screen.   

 

I realize that the Thread started out as a simple suggestion for a new device and grew in scope.   But if implemented, the Application Product becomes rejuvenated all on its own and logic paths for future objects would then exist.   That’s good for your side of things also, not just pleasing the users, but making a product that warrants more development (of playable objects, not of internal game infrastructure logic ).  Cargo Bays in all three sub-subsections would function the same then,and not special logic to ignore them in some and activate them in other areas.    Its cargo bays…they work like this…one area of logic to support them and no weird logic for IF THIS THEN THAT, ELSE THAT OR IF NOT THEN,  THAT type of logic.    If that was hard for some of you all to read and understand, imagine it in Syntax…and a bunch of them in code mixed in with algebraic expressions doing calculations to move your ships and compute all that stuff in almost real time… …and I used a simple pseudo form expression to portray that thought…

 

SImplier code.   Less headaches for future changes, more cool Objects to play with for Us Users.  So when can we expect delivery?  Next century?   lol.  yeah, I TOTALLY understand your side of the fence.  Start with Staff Meetings and toss out some of this on the table…watch all the Coders mouths drop open…Tell them no overtime either…lol

 

Sorry, I was having some laughs here with that last section.   

The slots shouldn’t move once something is in it - simply make the one you ejected stay empty do not move the rest down!

 

 

I totally agree, but lets not rip out WORKING logic.   Enhance whats already there.  

So users that don’t like change still feel comfortable with taking in Loot as is.  

Less of a learning curve for those users and less whining here in the forums on changes they don’t like.

 

Hey, that would make a good POLL QUESTION in the game hanger…

 

CARGO SLOTS

A) I like self adjusting Cargo Slots

B) I like Cargo to remain fixed in a slot and not move around

C) Cargo?  What is Cargo?  I don’t see cargo slots.  (PvP PvM)

D) Teach me how to eject cargo.

E) Can I carry more bombs in any of those slots?

F) I want to buy a Transport and have lots of Cargo Slots?

The slots shouldn’t move once something is in it - simply make the one you ejected stay empty do not move the rest down!

 

Wait, solution - Its a GAME OPTION  a Check box…

Use Enhanced Cargo Cargo Slots   ?

 

Box is defaulted to NOT checked – after upgrade is installed.  

Box is checked, then it would use the enhanced type that doesn’t auto-shift around and the pilot binds with keys to pick and and drop into slot numbers.

 

Simple.   The No Change Whiners are appeased and the Give Me Control Freaks are appeased. 

I’ll try to explain how things works. We have some “need to do right now” stuff, “important, but next time” stuff and “sometimes later” stuff. And the first group is almost always consist something completly new, cause the game needs new content all the time it exists.

Everything in every game could be done optional. Every game could be improved by additional features. But there are some resons, time and resources, why it’s impossible to do everything just right away.