Jump to content

Bluestorm

Alpha Tester
  • Posts

    132
  • Joined

  • Last visited

Everything posted by Bluestorm

  1. Merci pour le retour Il y a des choses intéressantes! _______ Thanks for the feedback There is some interesting stuff!
  2. I guess trade without taxes (hand to hand trades) with people being physically there to exchange goods and information with high level of secrecy.
  3. There could be a system in multiple steps : 1) Random generation like HS4-RD 2) First pioneer to put a TU on the planet can rename it once. 3) When an organization get 70% of the planet's TU they can rename it again. All name of a planet should be saved somewhere so the "history" of a planet should be accessible for lore purposes.
  4. There will be PVE content generated by players they said it on multiple occasions, the only thing is robots will be inefficient compared to what a real player can do.
  5. Cool idea. One way of doing this would be to create an organization of the name of the space station and sign treaties of non aggression with all big organizations. Then create a rule (is it possible with TU in space?) that all the people that want to board must first sign the treaty and would not be able to fire any weapon in the controlled area. Of course the space station would also have a protection bubble for exterior attacks (in case some pirate differ with the NAT)
  6. A logo can also have a meaning for an individual to showcase his brand as a successful builder or scripter for example. We don't say everyone should be able to create one but only the one worthy of it. It could be for example tied to skills and you would have to be a specialist to get this right where organizations would get the right out of the box. It seems more fair as well as limiting their number (and thus making it cooler).
  7. This. Logos should definitely be available to individuals as well as organizations : both can need a little advertising. High level seems like a good way to filter inappropriate content as the higher your level the more you played and the more you will want to preserve the game.
  8. I second that as well, being private lists and not public it would encourage player interactions like "Asking around if they know someone competent for this job" while removing the burden of having to remember it by heart. Such list should have player-created tags and comments addable to detail more why such individual was better or worse than others like : - Player X [builder] [Fast] [bit expensive]: Best ship I ever ordered! It was a little expensive but worth the money. The job was lightning fast! - Player Y [Troll] [Rude]: Ruined my base for giggles and insulted me. - Player Z [Guard] [bounty hunter] : Very efficient at his job whether it is guarding against or eliminating a target.
  9. The "only player can mine things" sure might makes self-replicating robots more difficult to do but not impossible : If robots (scripts) can sell items and load/unload cargos, then you would have to build one or multiple autonomous factories making popular items, selling them on the market and from the money generated acquire the resources needed to run the money-generating factories and the robot-generating factory. It would take a while but it would work. In any case there would be multiple ways to make it stop : - Destroying the factories - Attacking the cargos of goods - Harassing the factories enough to make the productivity drop to the point where they would lose money (no more money and they can no longer operate) - Devaluation of the price of the items used to generate money (again to make their productivity drop) - Total annihilation with superior forces - ...
  10. I agree, and people can then nickname it however they want if they want to like with you're example it could be "H-Sard' -> Sard
  11. Yes, the DACs should only be used for subscribing purposes. I guess if intruders activates the script it will already be something but I'm afraid for long range defense mechanism it would not be as effective if there is a range limitation. Also if we are able to give rights to maintain scripts activated to an organization, it could allow to approach the continuous script activation Graal : the more organization members are spread (and active) across the time zone there closer it gets. The only setback is that the one(s) activating the scripts must be close to it and that is a boring activity to just stand near the script all the time doing nothing. To address that, locally fixed activities such as research or maybe devising blueprints may be stationed near valuable scripts to ensure there is frequently someone around but it also have it's flaws as it would mean you only get part of an organization to help maintaining the script and not all of its members which could decrease the time zone coverage.
  12. Hey, I've been digging and I found this post from NQ-Nyzaltar : https://board.dualthegame.com/index.php?/topic/335-player-systematics/?view=findpost&p=1269 At the question : He answered : So it seems to be possible but with limitations. Good news (actually old news ^^)
  13. I don't think the problem lay with trades. They are the things I'm most confident in since it will be goods and/or money against goods and/or money so no way to cheat your way out of those. Tracking these could be cool but will only be useful for the trade department of a company to show their results or be investigated upon (and maybe as personal historic for individuals). Contracts are much more interesting because it could provide a mean for entrepreneur to exchange much more than just goods and money : services. And as the game will be emergent, services are the thing we want to be supported by some helping features. Thus being able to track at least what the service is, what are the parties involved and what the reward will be is primordial.
  14. Well you always have the possibility to seclude yourself in a faraway planet to have enough time to create the replicating army before the first settlers come.
  15. True so wait and see. There is plenty of way to avoid any server stress and they have already implemented one : the scripts are client-side run. Others might be : - Limiting the CPU power of a script with a soft cap such as the more CPU it needs, the more resources (fuel and so what) it takes exponentially. - Limiting CPU-consuming scripts to be ran on external servers only. (Like the API system of @iWicpar) - Limiting the total CPU usage of a script to X altogether - Force quitting a script that consumes too much CPU - Name it...
  16. Great ideas over here! I think an Arkship seeds should be event-released by the admin and the information of its arrival broadcasted (maybe with a count down) and not some lucky guys stumbling upon it on a faraway planet. It would allow for some epic development with raging wars for this treasure. Something like the Arkship sending a broadcast message to announce to all settlers their arrival in 1 month at these coordinates (x,y,z) (chosen to be near an untouched planet or at equal distance of inhabited worlds). It would then come out of hyperspace from the galaxy we all come from.
  17. No one has to be responsible of anything it is just a matter of trust between the parties. The responsibility part will only take place if one of the party is part of an organizations that thrives to regulate the quest system. In your example, whether there is a contract/quest system or not the guy is screwed because no one knows that he did do his job (apart from his unreachable friend). With the contract/quest system he has at least a beginning of proof even if it might be judged inappropriate by the one judging his case : with handshake deals you have no way of enforcing or proving anything happened which make it too risky especially for big transactions (think billions of in game currency for contracts between the biggest organizations). Plus in this particular case it suffice that the contract was done with the HR department, and not with a particular individual, to handle the problem. And if no one is in the HR department it means you're company is pretty much dead and you should leave it. But you'll be happy when after a while the company runs again and you can ask for your due thanks to the contract you signed.
  18. Ok, but that's on the current wiki. How frequently is it updated? Is it actually up to date? It may also be possible that the future we will get to dig with more powerful tools and who knows, those tools may be usable by an automated construct. Hope will keep us going!
  19. Source? I do believe it is not in their main interest to allow player to create such creatures, but be sure they will be many of us to try it anyway ^^
  20. I think it means that if the stretch goal is not reached we will have to wait for the first update(s) after the official release (so after end of 2018) for construct vs contruct (including ships vs ships) PVP. Because after official release they will be in a continuous game development process with updates every now and then.
  21. So you say that fully automated constructs should be possible but take much more time? That's interesting and work in the case of automated factories or mining, but what about automated defense mechanism or automated exploring mechanism that needs real time reaction to avoid utter destruction? Then that won't work. I don't think it will become grindy and tedious to refuel or replenish the necessary resources because of storage : it will be a task to do only every X hours/days. Plus it will limit the size of these automated constructs because everything would scale with size and in particular the frequency you will have to refuel. It would work as a soft cap limit.
  22. I know but then you have the AFK issue where players just stay logged online to achieve just that and that is not fun at all (ok it could be fun to hunt AFK guys for a while but that's it). If they don't want fully automated factories maybe they should move the issue to fueling or providing the necessary resources to the factory necessitating having a player to make the "refuel".
  23. Yes it could also be a security measure. As for that I'm not sure because it would give a edge to people knowledgeable in API development where the LUA was actually meant as a bridge to players not used to code. Yes the "you have to be close of your construct" issue is a hard one to circumvent :/ I wish i knew why they made that constraint.
  24. First are we sure that we can delegate/give rights to run a script to individuals or organisations? I think it could be cool to be able to build sandboxed CPU units with different processing powers to run our scripts in our place, this way the scripts would be costly and thus would naturally reduce the actual CPU usage on their server and prevent infinite loops/heavy loads to crash the servers (only the sandboxed unit will crash). They could always make them number limited and destroyable to limit further their impact on the servers.
  25. I do think (and hope) the Quest system NQ is going to implement will be contract-like as in : 1) A party issue a quest, where he stipulates what the rewards are and what the proof(s) of completion should be for him to trust completion of the quest (nothing, items, money, information, screenshots and, why not videos). 2) The quest is shared to second parties (individuals, organisations or publicly) 3) The second parties take the quest and such action is registered (there can be multiple second parties in case of bounty hunter for example or if you need the quest to be fulfilled more than once) 4) The second parties complete the quest and brings proof of it or the second parties cancel the quest (registered). 5) The first party upon presentation of proof(s) rewards the second (registered upon approval of receipt by the second parties) or refuse to pay (registered) according to his trust towards the proof(s). -> At the end of the day, each party make the other's party reputation and trust is the key essence and every party involved have some log of the quest status to use as proof of completion for their boss, claim of breach of contract to judges or for statistics purposes.
×
×
  • Create New...