Forums » Suggestions
I would like to propose a logical extension of Pizzasgood's "trains in space" idea.
If we could have trains, why wouldn't we have container ships ?
The container ships would be created exactly the same way as trains, but while in trains we attach cars next to each other in a single line, in container ships we would do it in all 3 dimensions.
So that would essentially allow constructing ship of any size or shape using "blocks".
Details:
== There are 2 kinds of basic modules:
...== Cube-shaped container module (adds cargo hold space and mass, has no use otherwise) - has very little HP.
...== Marauder engine module (adds engine power + mass, no cargo space) - has a lot of HP
== The ship would be towed by any number of engine blocks (probably marauder-like ship since it fits that purpose perfectly).
== Every marauder-like engine module adds its power/mass/HP to total stats of the ship, increasing the the ships speed/other stats etc.
== All of the container HP, mass and cargo hold space is added to total ship stats
== The ship could have unlimited number of cube-shaped blocks, arranged in any way (or perhaps arranged automatically in the initial implementation)
== This would allow creating extremely, INSANELY big, yet almost defensless ships
== People could construct such ships automatically using some kind of new "create new ship" interface, or construct it using Tractor Beams, physically towing all blocks to the construction site and connecting them to the engine.
== Would probably replace trains, because this is essentially a train in every way, except cars create a 3D, not 1D structure.
Pros:
++ Creates a new class of capship
++ Very real life-like. Enormous, heavy ships, difficult to steer, difficult to defend. Suspectible to somalian pirates especially :D
++ Pirates should love it, because it creates a lot of great opportunities for them.
++ Creates new ways for people to earn money in the game
++ Extends all existing occupations in the game:
...++ Trading would be more fun and more profitable,
...++ Pirating would be more profitable,
...++ Guarding convoys would have more sense,
...++ Team mining with a container ship waiting to collect stuff would be easier now.
++ Shouldn't be that hard to implement in game. It also doesn't require almost any new graphics.
.
.
Cons:
-- ???? (help me here)
If we could have trains, why wouldn't we have container ships ?
The container ships would be created exactly the same way as trains, but while in trains we attach cars next to each other in a single line, in container ships we would do it in all 3 dimensions.
So that would essentially allow constructing ship of any size or shape using "blocks".
Details:
== There are 2 kinds of basic modules:
...== Cube-shaped container module (adds cargo hold space and mass, has no use otherwise) - has very little HP.
...== Marauder engine module (adds engine power + mass, no cargo space) - has a lot of HP
== The ship would be towed by any number of engine blocks (probably marauder-like ship since it fits that purpose perfectly).
== Every marauder-like engine module adds its power/mass/HP to total stats of the ship, increasing the the ships speed/other stats etc.
== All of the container HP, mass and cargo hold space is added to total ship stats
== The ship could have unlimited number of cube-shaped blocks, arranged in any way (or perhaps arranged automatically in the initial implementation)
== This would allow creating extremely, INSANELY big, yet almost defensless ships
== People could construct such ships automatically using some kind of new "create new ship" interface, or construct it using Tractor Beams, physically towing all blocks to the construction site and connecting them to the engine.
== Would probably replace trains, because this is essentially a train in every way, except cars create a 3D, not 1D structure.
Pros:
++ Creates a new class of capship
++ Very real life-like. Enormous, heavy ships, difficult to steer, difficult to defend. Suspectible to somalian pirates especially :D
++ Pirates should love it, because it creates a lot of great opportunities for them.
++ Creates new ways for people to earn money in the game
++ Extends all existing occupations in the game:
...++ Trading would be more fun and more profitable,
...++ Pirating would be more profitable,
...++ Guarding convoys would have more sense,
...++ Team mining with a container ship waiting to collect stuff would be easier now.
++ Shouldn't be that hard to implement in game. It also doesn't require almost any new graphics.
.
.
Cons:
-- ???? (help me here)
This idea is easily summed up:
@Lecter
Sir, this was so utterly predictable.
When you troll me, at least do it properly and put some effort into it.
Sir, this was so utterly predictable.
When you troll me, at least do it properly and put some effort into it.
Heh, have a little sympathy for those of us that have to sort such incidents out in RL Dr L. It's a kind of real job in the real world. The sort of thing men do for a living.
RP-wise it makes sense - more compact than a proper train, and less susceptible to having the head cut off.
Gameplay-wise I don't know if I'd like it. A train is interesting because it is different - very long and skinny, and severable. A conglomerate ship like you propose is a lot more like a standard ship in terms of shape, and therefor less interesting.
I think I'd rather just see really big capships than big conglomerate ships.
That said, the ability to build an arbitrarily shaped ship out of the cargo modules might be fun - you could have it hollow with rooms and hallways and stuff. Could be interesting.
Gameplay-wise I don't know if I'd like it. A train is interesting because it is different - very long and skinny, and severable. A conglomerate ship like you propose is a lot more like a standard ship in terms of shape, and therefor less interesting.
I think I'd rather just see really big capships than big conglomerate ships.
That said, the ability to build an arbitrarily shaped ship out of the cargo modules might be fun - you could have it hollow with rooms and hallways and stuff. Could be interesting.
@Pizzasgood
[[[more compact than a proper train, and less susceptible to having the head cut off.]]]
Actually, since the ship will consist of Z meters x Z meters cubic blocks, it should (in theory at least) be the most space-efficient way of transporting goods. Exactly as in real life too.
.
.
[[[I think I'd rather just see really big capships than big conglomerate ships.]]]
Well, what i meant is that we could always have... both. Right ?
.
.
[[[That said, the ability to build an arbitrarily shaped ship out of the cargo modules might be fun - you could have it hollow with rooms and hallways and stuff. Could be interesting.]]]
Exactly. This allows player to use their creativity to make both cool & usefull stuff ingame.
I think that each player should experience the game in their own, personal way.
This cannot be achieved in a constant, fixed, predictable, non-random game world, so the universe should be more flexible, suspectible to shaping & rebuilding by players. Container ships is a step in that direction.
[[[more compact than a proper train, and less susceptible to having the head cut off.]]]
Actually, since the ship will consist of Z meters x Z meters cubic blocks, it should (in theory at least) be the most space-efficient way of transporting goods. Exactly as in real life too.
.
.
[[[I think I'd rather just see really big capships than big conglomerate ships.]]]
Well, what i meant is that we could always have... both. Right ?
.
.
[[[That said, the ability to build an arbitrarily shaped ship out of the cargo modules might be fun - you could have it hollow with rooms and hallways and stuff. Could be interesting.]]]
Exactly. This allows player to use their creativity to make both cool & usefull stuff ingame.
I think that each player should experience the game in their own, personal way.
This cannot be achieved in a constant, fixed, predictable, non-random game world, so the universe should be more flexible, suspectible to shaping & rebuilding by players. Container ships is a step in that direction.
What's that, Ecka, ensuring that containers filled mostly with useless imports make it safely to the mindless consumers in some foreign country? How terribly meaningful. Which is not to defend the meaningful nature of what I do, but nothing you could possibly be describing holds any sort of a superior position.
And at your age, I doubt you do anything much but suck at the UK's tit for a living.
And at your age, I doubt you do anything much but suck at the UK's tit for a living.
Really off your game there Lecter.
This makes me think of the "Leviathan" from EV: Nova...
Anyway... the OP seems like an incredible time sink but, something like these wouldn't be bad.
Anyway... the OP seems like an incredible time sink but, something like these wouldn't be bad.
@ryan
[[[the OP seems like an incredible time sink but]]]
Whose time do you mean ?
[[[the OP seems like an incredible time sink but]]]
Whose time do you mean ?
The Developers, though Im certain that if we could do this quite a few of us would kill hours in design.
/me pulls out assault rifle and fires into the air...
"EVERYBODY DOWN ON THE GROUND!!! THIS IS A THREADJACKING!"
http://www.vendetta-online.com/x/msgboard/3/24020
/me pulls out assault rifle and fires into the air...
"EVERYBODY DOWN ON THE GROUND!!! THIS IS A THREADJACKING!"
http://www.vendetta-online.com/x/msgboard/3/24020
@PaladinOfLancelot
[[[, though Im certain that if we could do this quite a few of us would kill hours in design.]]]
- For graphics, just use existing 3D marauder modules & engine models. Multiply them in space Y x Z times, and join together automatically, creating kind of a ship-matrix which is then treated by the game as a single ship.
.
.
[[[The Developers]]]
Time ?
- Judging from my programming experience, this task should require not more than 2000 lines of code (but i would bet 1000 should be more likely).
This really isn't rocket science in development, I can easily imagine how to write that.
This is how it should look, very roughly:
1. Create new type of ship - "compound ship" that can have dynamic shape, size, weight & other parameters. Add the new type to ship type database
2. Create creation algorithm for "compound ship matrix". The algorithm enters location of all components into the ship matrix, calculates its size, weight, thurst etc etc.
3. Create algorithm that groups ship compounds together and tells the game to treat the compound as one big ship
4. Add algorithms that will draw, move, damage and repair the matrix of components as a whole ship when players interact with it.
5. Create simple interface for creating compound ships.
If this 5 things take significantly more than 2000 lines of code, that will probably mean that the engine is poorly written. This shouldn't be that difficult at all if the code is clean, clear & professionally done.
[[[, though Im certain that if we could do this quite a few of us would kill hours in design.]]]
- For graphics, just use existing 3D marauder modules & engine models. Multiply them in space Y x Z times, and join together automatically, creating kind of a ship-matrix which is then treated by the game as a single ship.
.
.
[[[The Developers]]]
Time ?
- Judging from my programming experience, this task should require not more than 2000 lines of code (but i would bet 1000 should be more likely).
This really isn't rocket science in development, I can easily imagine how to write that.
This is how it should look, very roughly:
1. Create new type of ship - "compound ship" that can have dynamic shape, size, weight & other parameters. Add the new type to ship type database
2. Create creation algorithm for "compound ship matrix". The algorithm enters location of all components into the ship matrix, calculates its size, weight, thurst etc etc.
3. Create algorithm that groups ship compounds together and tells the game to treat the compound as one big ship
4. Add algorithms that will draw, move, damage and repair the matrix of components as a whole ship when players interact with it.
5. Create simple interface for creating compound ships.
If this 5 things take significantly more than 2000 lines of code, that will probably mean that the engine is poorly written. This shouldn't be that difficult at all if the code is clean, clear & professionally done.
- Judging from my programming experience, this task should require not more than 2000 lines of code (but i would bet 1000 should be more likely). This really isn't rocket science in development, I can easily imagine how to write that.
From the sounds of it I'd guess your claim of being a programmer is based on writing some scripts in a high-level language using existing libraries/api's, likely basic or flash? Really unrealistic expectations of how long it should take to program something in a low-level language. Think the following things that need to be glued/reworked for something like this to work:
* collision meshes on multi-component ships (having every element have it's own collision mesh would quickly cause problems if several of these ships were around simultaneously).
* grouping AI, convoys have grouping AI and it's not great, AI for something like this would likely be even more complex, unless you treat it as a single ship/unit AI, in which case you have other problems associated with mass/toque/etc changing as parts of the whole are destroyed or split or etc.
* user-interface for creating these, would be well over 2000 lines of code alone, unless you are keeping it as minimal as possible and only allowing very very limited customization of pre-configured barges. (and even then 2000 lines? or 1000? there's plugins that do much less that are much bigger in lines, and plugins are written in a high-level lua scripting language rather then a low-level C/C++).
* docking?
* FF handling of individual components hitting each other, interacting with other ships/hive/etc.
* container loading/unloading? How to distribute what gets jettisoned/destroyed/etc when damaged/destroyed.
* much more I'm not even thinking in depth here.
That all said, I do like the idea... But saying, "I'm a programmer and this should take no more then 2000 lines of code to implement or there is something wrong with the engine" just makes you look like a know-it-all douche to anyone/everyone that knows even a fraction of what you claim to understand. Please tell us where it is you program so I/we can all avoid ever having to work with you.
I'm sure alot of corners could be cut to make a very basic barge-ship, but would likely cause other unforeseen problems that would need to be dealt with quickly (which adds significant implementation time to the task at hand) and need to be re-worked at some point later to a proper implementation (which would require even more time to implement and cause unforeseen problems to the quick-fix hacks that would have had to be added to cut corners around initial implementation).
You may think highly of yourself PoL, but no one else here does. If you're gonna assert stupid claims back them up with something other then "because I said".
From the sounds of it I'd guess your claim of being a programmer is based on writing some scripts in a high-level language using existing libraries/api's, likely basic or flash? Really unrealistic expectations of how long it should take to program something in a low-level language. Think the following things that need to be glued/reworked for something like this to work:
* collision meshes on multi-component ships (having every element have it's own collision mesh would quickly cause problems if several of these ships were around simultaneously).
* grouping AI, convoys have grouping AI and it's not great, AI for something like this would likely be even more complex, unless you treat it as a single ship/unit AI, in which case you have other problems associated with mass/toque/etc changing as parts of the whole are destroyed or split or etc.
* user-interface for creating these, would be well over 2000 lines of code alone, unless you are keeping it as minimal as possible and only allowing very very limited customization of pre-configured barges. (and even then 2000 lines? or 1000? there's plugins that do much less that are much bigger in lines, and plugins are written in a high-level lua scripting language rather then a low-level C/C++).
* docking?
* FF handling of individual components hitting each other, interacting with other ships/hive/etc.
* container loading/unloading? How to distribute what gets jettisoned/destroyed/etc when damaged/destroyed.
* much more I'm not even thinking in depth here.
That all said, I do like the idea... But saying, "I'm a programmer and this should take no more then 2000 lines of code to implement or there is something wrong with the engine" just makes you look like a know-it-all douche to anyone/everyone that knows even a fraction of what you claim to understand. Please tell us where it is you program so I/we can all avoid ever having to work with you.
I'm sure alot of corners could be cut to make a very basic barge-ship, but would likely cause other unforeseen problems that would need to be dealt with quickly (which adds significant implementation time to the task at hand) and need to be re-worked at some point later to a proper implementation (which would require even more time to implement and cause unforeseen problems to the quick-fix hacks that would have had to be added to cut corners around initial implementation).
You may think highly of yourself PoL, but no one else here does. If you're gonna assert stupid claims back them up with something other then "because I said".
I really like the idea of containers. This is undoubtly a very efficient way to transport diversified stuff.
If you notice, we ALMOST have it in VO. Those crates that contain Xcu of anything, from ore to weapons. To make them real containers, they simply would have to not magically re-compress itself into one crate containing Xcu, but instead spread X crates of 1cu each.
Crates would be a great addition to capships. Like, most stations cannot dock a cappie, then smaller freighters move the containers around, one or many at time, probably more fun as a train...
FS2 explores it exaultively. Check http://www.hard-light.net/wiki/index.php/Containers or http://www.hard-light.net/wiki/index.php/FreeSpace_2-era_craft#Transports_and_freighters. There, basic concept is everything is packed on those containers, and every large ship in game can carry/use them, either docked outside or stored inside the ship. They can be moved, captured or destroyed.
+1 for modal transport using containers as long-term goal.
-1 to minecraft or lego in space. Only simple arrangements possible: line or cube.
If you notice, we ALMOST have it in VO. Those crates that contain Xcu of anything, from ore to weapons. To make them real containers, they simply would have to not magically re-compress itself into one crate containing Xcu, but instead spread X crates of 1cu each.
Crates would be a great addition to capships. Like, most stations cannot dock a cappie, then smaller freighters move the containers around, one or many at time, probably more fun as a train...
FS2 explores it exaultively. Check http://www.hard-light.net/wiki/index.php/Containers or http://www.hard-light.net/wiki/index.php/FreeSpace_2-era_craft#Transports_and_freighters. There, basic concept is everything is packed on those containers, and every large ship in game can carry/use them, either docked outside or stored inside the ship. They can be moved, captured or destroyed.
+1 for modal transport using containers as long-term goal.
-1 to minecraft or lego in space. Only simple arrangements possible: line or cube.
"-1 to minecraft or lego in space. Only simple arrangements possible: line or cube."
Awww... How about on a planetoid? :P
Awww... How about on a planetoid? :P
@drazed
[[[From the sounds of it I'd guess your claim of being a programmer is based on writing some scripts in a high-level language using existing libraries/api's, likely basic or flash?]]]
Actually, only PHP/SQL/Javascript for now.
But in my job history i have been programming in Pascal, Delphi, C (very shortly), Visual Basic, 3D studio Max scripts, Flash and few others.
I have also done few interesting 3D animations using 3D Studio Max, so i know a little about meshes and how 3D objects work.
.
.
[[[Really unrealistic expectations of how long it should take to program something in a low-level language. Think the following things that need to be glued/reworked for something like this to work:]]]
Taht is not unrealistic at all.
After 7 years of vendetta programming, the devs should already have some kind of framework for doing stuff on higher level than the usual very low level of C/C++.
I realize that C/C++ is pretty pain-in-the-ass language where doing anything requires a lot of work, but after few years working on the same code, you can easily create kind of framework / template system that allows to do things waaaaaaaay faster than it would take when writing a new program from scratch.
Well, after 7 years of development (it is a lot of time) VO should already have such framework or something like this, otherwise the code will quickly become (or has already became) unmaintainable.
Somehow i fear that is the case here.
.
.
[[[* collision meshes on multi-component ships (having every element have it's own collision mesh would quickly cause problems if several of these ships were around simultaneously).]]]
Wrong. You don't have to do mesh collision calculations for every possible object.
You write an algorithm which joins all the objects (YxYxY square boxes) together, calculates their external dimensions, and treats them like single object/mesh.
Well, in initial implementation explosions of such objects will probably look like shit (because all of the internal meshes are not being taken into consideration when object is destroyed), but yeah - it will work.
.
.
[[[* grouping AI, convoys have grouping AI and it's not great, AI for something like this would likely be even more complex, unless you treat it as a single ship/unit AI, in which case you have other problems associated with mass/toque/etc changing as parts of the whole are destroyed or split or etc.]]]
I will not have such problems, because i join all the object into a single mesh, and treat it as such.
Then, calculate torque, max speed parameters etc. Perhaps even roughly in initial implementation.
So (in the initial implementation) :
- you cannot split the ship into parts,
- you cannot detach containers and make them float in space,
- you cannot damage/destroy parts of the ship. You can only damage whole ship
- ship is always seen as a whole. Only when you dock, you can disassemble it completely, and/or create new ship or change the number of containers in the existing ship.
- you cannot place containers in specific places. everything is done automatically when you purchase container ship. All ships parameters are calculated on purchase/selling etc. only.
Of course, such ship would be very hard to drive, turn, accelerate, stop and such, but that is the point.
A container ship should be defensless and almost useless except for the cargo transport capabilities.
.
.
[[[* user-interface for creating these, would be well over 2000 lines of code alone, unless you are keeping it as minimal as possible and only allowing very very limited customization of pre-configured barges. (and even then 2000 lines? or 1000? there's plugins that do much less that are much bigger in lines, and plugins are written in a high-level lua scripting language rather then a low-level C/C++).]]]
Well, assuming that the devs didn't do some automatic template system for creating UI's (which is very unprobable considering that code would be unmaintainable then), then we can do even more minimal implementation.
Player could do it using vendetta's console.
/createcontainership [Name_of_container_ship] [Name_of_engine_ship] [number of containers]
Where [Name_of_engine_ship] is name/ID of docked marauder ship that will tow the containers.
Voilla.
.
.
[[[* docking?]]]
Once docking capships will be implemented, that will not be a problem.
But i can see some other quick solutions.
.
.
[[[* FF handling of individual components hitting each other, interacting with other ships/hive/etc.]]]
Not necessary. Join whole ship into single mesh. See above.
.
.
[[[* container loading/unloading?]]]
Treat all containers as single ship. No loading or unloading of single containers.
Only treat the ship as a whole.
.
.
[[[How to distribute what gets jettisoned/destroyed/etc when damaged/destroyed.]]]
Treat whole ship as single cuboid, and then calculate where the center is. When cuboid gets destroyed, drop stuff in the center of the explosion.
Jettison stuff just behind the ship, in the center of rear rectangle of the ship's cuboid (container ship is treated as cuboid in the initial implementation).
.
.
[[[That all said, I do like the idea... But saying, "I'm a programmer and this should take no more then 2000 lines of code to implement or there is something wrong with the engine" just makes you look like a know-it-all douche to anyone/everyone that knows even a fraction of what you claim to understand. ]]]
Well...
I'm just good in this stuff. I have written a lot of code in my life, my abstractive thinking evolved and now i can imagine things few or several steps ahead.
I offer my sincere apologies to anybody that got offended by this.
.
.
[[[You may think highly of yourself PoL,]]]
I simply know what i can do and i know what i cannot do.
.
.
[[[ but no one else here does.]]]
But who cares ?
.
.
[[[ If you're gonna assert stupid claims back them up with something other then "because I said".]]]
You haven't proven yet that the claims are stupid.
[[[From the sounds of it I'd guess your claim of being a programmer is based on writing some scripts in a high-level language using existing libraries/api's, likely basic or flash?]]]
Actually, only PHP/SQL/Javascript for now.
But in my job history i have been programming in Pascal, Delphi, C (very shortly), Visual Basic, 3D studio Max scripts, Flash and few others.
I have also done few interesting 3D animations using 3D Studio Max, so i know a little about meshes and how 3D objects work.
.
.
[[[Really unrealistic expectations of how long it should take to program something in a low-level language. Think the following things that need to be glued/reworked for something like this to work:]]]
Taht is not unrealistic at all.
After 7 years of vendetta programming, the devs should already have some kind of framework for doing stuff on higher level than the usual very low level of C/C++.
I realize that C/C++ is pretty pain-in-the-ass language where doing anything requires a lot of work, but after few years working on the same code, you can easily create kind of framework / template system that allows to do things waaaaaaaay faster than it would take when writing a new program from scratch.
Well, after 7 years of development (it is a lot of time) VO should already have such framework or something like this, otherwise the code will quickly become (or has already became) unmaintainable.
Somehow i fear that is the case here.
.
.
[[[* collision meshes on multi-component ships (having every element have it's own collision mesh would quickly cause problems if several of these ships were around simultaneously).]]]
Wrong. You don't have to do mesh collision calculations for every possible object.
You write an algorithm which joins all the objects (YxYxY square boxes) together, calculates their external dimensions, and treats them like single object/mesh.
Well, in initial implementation explosions of such objects will probably look like shit (because all of the internal meshes are not being taken into consideration when object is destroyed), but yeah - it will work.
.
.
[[[* grouping AI, convoys have grouping AI and it's not great, AI for something like this would likely be even more complex, unless you treat it as a single ship/unit AI, in which case you have other problems associated with mass/toque/etc changing as parts of the whole are destroyed or split or etc.]]]
I will not have such problems, because i join all the object into a single mesh, and treat it as such.
Then, calculate torque, max speed parameters etc. Perhaps even roughly in initial implementation.
So (in the initial implementation) :
- you cannot split the ship into parts,
- you cannot detach containers and make them float in space,
- you cannot damage/destroy parts of the ship. You can only damage whole ship
- ship is always seen as a whole. Only when you dock, you can disassemble it completely, and/or create new ship or change the number of containers in the existing ship.
- you cannot place containers in specific places. everything is done automatically when you purchase container ship. All ships parameters are calculated on purchase/selling etc. only.
Of course, such ship would be very hard to drive, turn, accelerate, stop and such, but that is the point.
A container ship should be defensless and almost useless except for the cargo transport capabilities.
.
.
[[[* user-interface for creating these, would be well over 2000 lines of code alone, unless you are keeping it as minimal as possible and only allowing very very limited customization of pre-configured barges. (and even then 2000 lines? or 1000? there's plugins that do much less that are much bigger in lines, and plugins are written in a high-level lua scripting language rather then a low-level C/C++).]]]
Well, assuming that the devs didn't do some automatic template system for creating UI's (which is very unprobable considering that code would be unmaintainable then), then we can do even more minimal implementation.
Player could do it using vendetta's console.
/createcontainership [Name_of_container_ship] [Name_of_engine_ship] [number of containers]
Where [Name_of_engine_ship] is name/ID of docked marauder ship that will tow the containers.
Voilla.
.
.
[[[* docking?]]]
Once docking capships will be implemented, that will not be a problem.
But i can see some other quick solutions.
.
.
[[[* FF handling of individual components hitting each other, interacting with other ships/hive/etc.]]]
Not necessary. Join whole ship into single mesh. See above.
.
.
[[[* container loading/unloading?]]]
Treat all containers as single ship. No loading or unloading of single containers.
Only treat the ship as a whole.
.
.
[[[How to distribute what gets jettisoned/destroyed/etc when damaged/destroyed.]]]
Treat whole ship as single cuboid, and then calculate where the center is. When cuboid gets destroyed, drop stuff in the center of the explosion.
Jettison stuff just behind the ship, in the center of rear rectangle of the ship's cuboid (container ship is treated as cuboid in the initial implementation).
.
.
[[[That all said, I do like the idea... But saying, "I'm a programmer and this should take no more then 2000 lines of code to implement or there is something wrong with the engine" just makes you look like a know-it-all douche to anyone/everyone that knows even a fraction of what you claim to understand. ]]]
Well...
I'm just good in this stuff. I have written a lot of code in my life, my abstractive thinking evolved and now i can imagine things few or several steps ahead.
I offer my sincere apologies to anybody that got offended by this.
.
.
[[[You may think highly of yourself PoL,]]]
I simply know what i can do and i know what i cannot do.
.
.
[[[ but no one else here does.]]]
But who cares ?
.
.
[[[ If you're gonna assert stupid claims back them up with something other then "because I said".]]]
You haven't proven yet that the claims are stupid.
"You haven't proven yet that the claims are stupid."
I did, you missed the whole point, you're above solutions to the implementation are the exact retarded "cutting corners" solutions I'd mentioned at the end that would end up costing much more time then doing it right in the first place. And saying "they should have a framework after 7 years" for everything to make it faster is retarded. VO has changed ALOT in 7 years, any frameworks would need to be re-written many times over and cost time and likely still be useless after 7 years. They do have LUA for UI, but I mentioned that many plugins are over 2000 lines of LUA and do much less. Any solution for lua ui would still require many lines of C/C++ code to manage the "container-ship" specific aspects of creating/loading/etc the ship.
That all said, you just re-asserted how little you know and how highly you think of yourself for it. Writing some PHP scripts or VisualStudio scripts DOES NOT QUALIFY YOU to know how things should be done in a low-level language game, let alone an MMO with many layers of interconnected dependence that nothing you worked with would even give you a glimmer of what is really going on.
If you're gonna suggest stuff then do so, then stfu and let them work on it (or not if they so choose as most of your suggestions are crap). Comments about how you could create this stuff in hours will not get it done faster. If you're really such a wiz, then stfu some more then go write an MMO, it should only take you a few weeks by your estimates.
EDIT:
Even at a few thousand lines of code this would not happen any time soon. Only 3 devs, and one of them doesn't dev much. Writing 2000 lines of code often requires writing/rewriting/etc so it ends up being far more written before the final count is done. A poor "cut-every-possible-corner" solution would probably be possible in just a few thousand lines of code, but would require so much work to maintain and extend afterwards, it's hardly worth pulling someone away for a solid week+ just to get this out the door, especially with other (even more cool" stuff is in the pipes, and other (less cool but more important stuff) will get in the way.
PoL expectations == failed planning and impending disaster.
I did, you missed the whole point, you're above solutions to the implementation are the exact retarded "cutting corners" solutions I'd mentioned at the end that would end up costing much more time then doing it right in the first place. And saying "they should have a framework after 7 years" for everything to make it faster is retarded. VO has changed ALOT in 7 years, any frameworks would need to be re-written many times over and cost time and likely still be useless after 7 years. They do have LUA for UI, but I mentioned that many plugins are over 2000 lines of LUA and do much less. Any solution for lua ui would still require many lines of C/C++ code to manage the "container-ship" specific aspects of creating/loading/etc the ship.
That all said, you just re-asserted how little you know and how highly you think of yourself for it. Writing some PHP scripts or VisualStudio scripts DOES NOT QUALIFY YOU to know how things should be done in a low-level language game, let alone an MMO with many layers of interconnected dependence that nothing you worked with would even give you a glimmer of what is really going on.
If you're gonna suggest stuff then do so, then stfu and let them work on it (or not if they so choose as most of your suggestions are crap). Comments about how you could create this stuff in hours will not get it done faster. If you're really such a wiz, then stfu some more then go write an MMO, it should only take you a few weeks by your estimates.
EDIT:
Even at a few thousand lines of code this would not happen any time soon. Only 3 devs, and one of them doesn't dev much. Writing 2000 lines of code often requires writing/rewriting/etc so it ends up being far more written before the final count is done. A poor "cut-every-possible-corner" solution would probably be possible in just a few thousand lines of code, but would require so much work to maintain and extend afterwards, it's hardly worth pulling someone away for a solid week+ just to get this out the door, especially with other (even more cool" stuff is in the pipes, and other (less cool but more important stuff) will get in the way.
PoL expectations == failed planning and impending disaster.
@drazed
[[[I did,]]]
No, you didn't - you're just thinking you did.
.
.
[[[you missed the whole point, you're above solutions to the implementation are the exact retarded "cutting corners" solutions I'd mentioned at the end that would end up costing much more time then doing it right in the first place.]]]
I don't think that joining meshes together would cost more time that calculating everything for every single mesh separately.
In fact, that is impossible.
It is relatively very simple to join a mesh into single object. Actually i was hoping VO already has similiar algorithm (as it is would be very useful).
.
.
[[[And saying "they should have a framework after 7 years" for everything to make it faster is retarded.]]]
No, that is not retarded because I start every program from writing a minimal framework for it (or using existing framework), because otherwise it would be royal pain in the ass to do anything.
If you don't have framework/templates then you start from scratch every time, which is not good at all.
.
.
[[[VO has changed ALOT in 7 years, any frameworks would need to be re-written many times over and cost time and likely still be useless after 7 years.]]]
Sorry, but an engine that has to be rewritten many times over 7 years is not a good engine.
They may have rewritten parts of the framework, but the core should stay intact.
.
.
[[[They do have LUA for UI, but I mentioned that many plugins are over 2000 lines of LUA and do much less.]]]
Your argument is invalid.
You can write a program that has 100.000 lines, and all it does is SHIT.
And you can write a program that has 1.000 lines, and does 10 x more.
.
.
[[[Any solution for lua ui would still require many lines of C/C++ code to manage the "container-ship" specific aspects of creating/loading/etc the ship.]]]
No, this is crap you are saying.
Simply create a new class of ship that has dynamic parameters, including cargo hold capacity.
Very little coding necessary.
.
.
[[[That all said, you just re-asserted how little you know and how highly you think of yourself for it.]]]
That is your opinion. Of course, there is not point in trying to convince you.
.
.
[[[Writing some PHP scripts or VisualStudio scripts DOES NOT QUALIFY YOU to know how things should be done in a low-level language game,]]]
It's not the language that matters, it's the abstractive thinking & skills that matter.
You can be a C/C++ programmer for 10 years and still know shit about programming.
From what you are saying it seems that you think that programming in certain language magically makes you better programmer. But that is bullshit.
It's the same bullshit as the one about paper from better academy/university giving you better education or making you better employee.
FYI, I am not "yet another php programmer".
I am an expert in optimization, programs that i write are extremely perfomant. I haven't met another programmer that would write programs so optimal as mine in my job history.
.
.
[[[let alone an MMO with many layers of interconnected dependence that nothing you worked with would even give you a glimmer of what is really going on.]]]
You have proven that you cannot think abstractively at all.
You don't need "interconnected dependences" here. In fact, you barely have to add much code.
All you need is add another type of ship, that has dynamic dimensions, flexible speed, torque, other parameters, and can change skins on the fly.
That is the quick & easy solution that i was talking about when i said "2000 lines of code".
Actually, now after i thought about it some more, this should be much less than 2000 lines.
.
.
[[[then stfu and let them work on it (or not if they so choose ]]]
Is STFU the best you can do ?
[[[as most of your suggestions are crap]]]
Of course they are. Because you said so.
.
.
[[[). Comments about how you could create this stuff in hours will not get it done faster. If you're really such a wiz, then stfu some more then go write an MMO, it should only take you a few weeks by your estimates.]]]
Actually no, only writing 3D engine is few years of work minimum. But you don't need so much work once you ALREADY HAVE A FUCKING FULLY-WORKING ENGINE.
[[[I did,]]]
No, you didn't - you're just thinking you did.
.
.
[[[you missed the whole point, you're above solutions to the implementation are the exact retarded "cutting corners" solutions I'd mentioned at the end that would end up costing much more time then doing it right in the first place.]]]
I don't think that joining meshes together would cost more time that calculating everything for every single mesh separately.
In fact, that is impossible.
It is relatively very simple to join a mesh into single object. Actually i was hoping VO already has similiar algorithm (as it is would be very useful).
.
.
[[[And saying "they should have a framework after 7 years" for everything to make it faster is retarded.]]]
No, that is not retarded because I start every program from writing a minimal framework for it (or using existing framework), because otherwise it would be royal pain in the ass to do anything.
If you don't have framework/templates then you start from scratch every time, which is not good at all.
.
.
[[[VO has changed ALOT in 7 years, any frameworks would need to be re-written many times over and cost time and likely still be useless after 7 years.]]]
Sorry, but an engine that has to be rewritten many times over 7 years is not a good engine.
They may have rewritten parts of the framework, but the core should stay intact.
.
.
[[[They do have LUA for UI, but I mentioned that many plugins are over 2000 lines of LUA and do much less.]]]
Your argument is invalid.
You can write a program that has 100.000 lines, and all it does is SHIT.
And you can write a program that has 1.000 lines, and does 10 x more.
.
.
[[[Any solution for lua ui would still require many lines of C/C++ code to manage the "container-ship" specific aspects of creating/loading/etc the ship.]]]
No, this is crap you are saying.
Simply create a new class of ship that has dynamic parameters, including cargo hold capacity.
Very little coding necessary.
.
.
[[[That all said, you just re-asserted how little you know and how highly you think of yourself for it.]]]
That is your opinion. Of course, there is not point in trying to convince you.
.
.
[[[Writing some PHP scripts or VisualStudio scripts DOES NOT QUALIFY YOU to know how things should be done in a low-level language game,]]]
It's not the language that matters, it's the abstractive thinking & skills that matter.
You can be a C/C++ programmer for 10 years and still know shit about programming.
From what you are saying it seems that you think that programming in certain language magically makes you better programmer. But that is bullshit.
It's the same bullshit as the one about paper from better academy/university giving you better education or making you better employee.
FYI, I am not "yet another php programmer".
I am an expert in optimization, programs that i write are extremely perfomant. I haven't met another programmer that would write programs so optimal as mine in my job history.
.
.
[[[let alone an MMO with many layers of interconnected dependence that nothing you worked with would even give you a glimmer of what is really going on.]]]
You have proven that you cannot think abstractively at all.
You don't need "interconnected dependences" here. In fact, you barely have to add much code.
All you need is add another type of ship, that has dynamic dimensions, flexible speed, torque, other parameters, and can change skins on the fly.
That is the quick & easy solution that i was talking about when i said "2000 lines of code".
Actually, now after i thought about it some more, this should be much less than 2000 lines.
.
.
[[[then stfu and let them work on it (or not if they so choose ]]]
Is STFU the best you can do ?
[[[as most of your suggestions are crap]]]
Of course they are. Because you said so.
.
.
[[[). Comments about how you could create this stuff in hours will not get it done faster. If you're really such a wiz, then stfu some more then go write an MMO, it should only take you a few weeks by your estimates.]]]
Actually no, only writing 3D engine is few years of work minimum. But you don't need so much work once you ALREADY HAVE A FUCKING FULLY-WORKING ENGINE.
"All you need is add another type of ship, that has dynamic dimensions, flexible speed, torque, other parameters, and can change skins on the fly."
You mean a type of ship that is not currently handled by the engine? Sure the engine is crap in your way of thinking. Then again, every major engine out there gets updated almost every year. For good reason, you can always make them better. VO's engine has improved much over 7 years, it's not like the wrote it and stopped working on it. A 7 year old engine/core would be useless today, and you're lack of understanding that is a waste of time.
"ALREADY HAVE A FUCKING FULLY-WORKING ENGINE."
Again, a fucking fully-working engine still needs large update/refactors/changes to keep it current. And what you want to do witha fully-working engine is not in the original design of the current engine so it requires major changes. It's not that the current engine is crap, it's that ANY engine is crap by your overzelous standards.
As for your optimized programs. BULLSHIT!! You talk lots but show little and expect us to eat your bullshit. Go do something useful or stfu (no that is not my best comeback, it's just more then sufficient to call you out).
I'm done here, have fun.
You mean a type of ship that is not currently handled by the engine? Sure the engine is crap in your way of thinking. Then again, every major engine out there gets updated almost every year. For good reason, you can always make them better. VO's engine has improved much over 7 years, it's not like the wrote it and stopped working on it. A 7 year old engine/core would be useless today, and you're lack of understanding that is a waste of time.
"ALREADY HAVE A FUCKING FULLY-WORKING ENGINE."
Again, a fucking fully-working engine still needs large update/refactors/changes to keep it current. And what you want to do witha fully-working engine is not in the original design of the current engine so it requires major changes. It's not that the current engine is crap, it's that ANY engine is crap by your overzelous standards.
As for your optimized programs. BULLSHIT!! You talk lots but show little and expect us to eat your bullshit. Go do something useful or stfu (no that is not my best comeback, it's just more then sufficient to call you out).
I'm done here, have fun.
@drazed
[[[You mean a type of ship that is not currently handled by the engine? ]]]
You act as if you actually knew what the engine can and cannot do.
So are you VO programmer or what ? Or perhaps a former VO programmer ?
.
.
[[[Sure the engine is crap in your way of thinking.]]]
I didn't say that. But an engine which requires more than 2000 lines of code just to add new type of ship that can have dynamic parameters that can be changed when docking may possibly be crap, yes.
.
.
[[[Then again, every major engine out there gets updated almost every year.]]]
That is not what we were talking about.
Updating != Rewriting.
.
.
[[[For good reason, you can always make them better. VO's engine has improved much over 7 years, it's not like the wrote it and stopped working on it. A 7 year old engine/core would be useless today, and you're lack of understanding that is a waste of time.]]]
I never said that the engine shouldn't be updated. But whole engine certainly shouldn't be rewritten many times.
Many engine core rewrites = crap, unflexible engine. The core should be extremely flexible with design allowing wide modifications. It shouldn't need complete rewrites, only extending of existing functionalities...
.
.
[[[As for your optimized programs. BULLSHIT!! You talk lots but show little and expect us to eat your bullshit. Go do something useful or stfu (no that is not my best comeback, it's just more then sufficient to call you out).]]]
I do not care if you believe me or not. But I don't use lies in a discussion just to "win" it. That would be far below my standards. I don't really care about "winning" too. I just always want to get to the bottom of things.
.
.
[[[I'm done here, have fun.]]]
Giving up so quicly ? I expected more.
[[[You mean a type of ship that is not currently handled by the engine? ]]]
You act as if you actually knew what the engine can and cannot do.
So are you VO programmer or what ? Or perhaps a former VO programmer ?
.
.
[[[Sure the engine is crap in your way of thinking.]]]
I didn't say that. But an engine which requires more than 2000 lines of code just to add new type of ship that can have dynamic parameters that can be changed when docking may possibly be crap, yes.
.
.
[[[Then again, every major engine out there gets updated almost every year.]]]
That is not what we were talking about.
Updating != Rewriting.
.
.
[[[For good reason, you can always make them better. VO's engine has improved much over 7 years, it's not like the wrote it and stopped working on it. A 7 year old engine/core would be useless today, and you're lack of understanding that is a waste of time.]]]
I never said that the engine shouldn't be updated. But whole engine certainly shouldn't be rewritten many times.
Many engine core rewrites = crap, unflexible engine. The core should be extremely flexible with design allowing wide modifications. It shouldn't need complete rewrites, only extending of existing functionalities...
.
.
[[[As for your optimized programs. BULLSHIT!! You talk lots but show little and expect us to eat your bullshit. Go do something useful or stfu (no that is not my best comeback, it's just more then sufficient to call you out).]]]
I do not care if you believe me or not. But I don't use lies in a discussion just to "win" it. That would be far below my standards. I don't really care about "winning" too. I just always want to get to the bottom of things.
.
.
[[[I'm done here, have fun.]]]
Giving up so quicly ? I expected more.