Jump to content


Alpha Tester
  • Posts

  • Joined

  • Last visited

Everything posted by Sawafa

  1. Previously (before Demeter update) territory scanners provided different info depending on how deep it was placed. Will the depth of the Territory scanner being placed in Demeter update influence in anyway to the scanner results?
  2. Sure, the question was only just to know if all existing radar scripts would stop to work. It's OK, as having all the info in the function calls and not in the json is much easier, but it is good to know if your code must be rewritten or it will not work at all.
  3. What are time frames when all these Lua changes described in devblogs will be live? Is it weeks/months/anything else? Question: DevBlog#2 has Radar functions description. Is this the full list of functions for the Radar? I mean, now Radar has .getData() function, will it be still there when these changes will come to live?
  4. What does "container construct" mean? Is it the construct which has only 1 container (what size?) or multiple containers (and only one construct... dyn. core L, for example) combined into hub (multiple hubs?) are also allowed?
  5. Legion's pilots are not so skilled pilots. Our asteroid detector gun-less ship was able to escape pursuing of 3 battle Legion ships simultaneously 2 times out of 2 meetings. 100% success rate. Again, 3 (!!) Legion battle ships were not possible to do any harm to the single gun-less mining hauler! And that is not about diving in the nearest safe zone, all was done 100% in PvP zone, dozens su away from Safe zone. Another issue was at today's night. CVA miners successfully completely depleted fresh not scanned T2 asteroid, and successfully captured 100% of ore from it. That was 2nd time our mining hauler successfully escaped the pursuit by 3 Legion ships. So, Legion pilots do not know how to fly??? Legion, GO HOME!
  6. And to answer your previous original question: I am 99.99% confident this scenario is correct: > What happens of that legate leaves the org? > A - Nothing. The org will not be able to get more cores but the cores remain and the ex-legate is now free to promote another org. And this is not so bad, actually...
  7. No, skills don't work in that manner. +100% per level - it means +500% at level 5.
  8. Why 275 cores per org? We have 2 skills which provide 100% bonus per level each and 1 skill +5 core count per level. So, at maximum we will recieve: +25 +500% +500%. So, it should be ((25 + 5 * 25) + 150 * 5) = 900 cores.
  9. Mining units: I like the idea if mining units will generate ore income depending on available ore in the tile. The more ore tile has the more output would be produced by mining unit. This will reduce the need of ore mining at all and will make territory warfare meaningfully. Another option would be taking into consideration the area of your linked territory (not the total amount of tiles you/your org owns), so the more tiles are connected between each other the more benefits it gives to mining units. This also will make territory ware even more meaningfully.
  10. As constant element upgrader of the ships (and static constructs too!) I am very happy with the solution provided by NQ, I mean RMB -> apply talents. It is very time consuming solution 1000% needed to be done from the start (as well as dismantle the whole construction in one click, for example). Removing/undoing element tends to a lot of problems (like problems with undoing broken element, or element with properties; like problems if you'll just disconnect from the internet because of what ever reason; or just game client will randomly crash).
  11. Declaring this action as exploit is such not obvious decision. YOU CAN'T JUMP ON SHIPS BECAUSE JUMPING ON SHIPS IS CONSIDERED TO BE EXPLOIT. What next step will be in this case? Will it be forbidden to move at all? P.s.: Yes, the rule will be followed (and I am sure, not by all players!) as I suppose it will be in the rules... But not respected.
  12. 1000% agree with this quote! Storing speed while you offline is limitation because servers can't handle movement calculation of all dynamic constructs. But why in this case is not allowed to resume this movement calculation by some player onboard???? Either change this mechanic or declare this action as OK.
  13. If this game will survive the current crisis and will gain a lot of players... there easily (and I'm sure it will!) can happen such situation. Some novian has just installed and launched the game. He finishes all starting tutorials... There is the usage of surrogate pods at the end of tutorial. So, if novian will chose some random destination VR that will be a moving ship towards PvP zone... He will unintentionally bring some ship to the PvP zone where this ship could be pew-pewed by any random player... Well, "good" mechanics, nothing to say. By the way... Even in EvE you're not completely safe in safe zone, if I know right. Why not let players to use game mechanics as intended and allow to transfer the ships into the PvP zone with using only game mechanics and not some bugs like bumping or whatever? If you want 100% to be sure your ship will stay still while you're offline - park it on space static core and you're in safe! No one will be able to steal your ship. Just rename "Safe zone" into "PvP Free zone" and that's all! There will be no PvP in PvP-free zone, but the usage of the normal game mechanics (and not bugs!) will be allowed.
  14. The only thing left without attention is hostile action in safe zone that didn't result in ship being moved towards pvp zone: burying, claiming the territory while 3rd person is mining there (and it is unclaimed), crashing the ships from space to the planet because of gravity force and so on. Are those acceptable actions or are they considered griefing/exploiting? And I am asking here about actions aimed on 3rd party constructs... not something like dick-building or whatever of those kind. Also, I (and many other) would be very happy if your common sense about safe zone would be updated in the rules. Thanks!
  15. If NQ wants to prevent stealing ships from safe zone by using normal game mechanics I see 2 possible solutions: a) the good one. The game mechanic should be changed in such a way that stealing such ships become impossible. Like such changes should be applied: a.1) the ship speed should be restored only when someone enters the seat and not when someone steps on the ship; a.2) The usage of maneuver tool should be nerfed. Maneuver tool should fail with error when target's speed is more than 20 km/h (or target stays steel with stored speed). This will prevent stopping the fast moving ship immediately. a.3) Build mode should be disabled when ship is moving (or stays steel with stored speed) faster than 20 km/h. This will prevent disassembling the ship while it stays still with stored speed. Also this will prevent the killing of elements of the ship when the ship is attacked in normal PvP. These steps may be altered in some way, but the main idea here is to change the game mechanic in such a way that it simply will not allow to proceed with unwanted actions. b) not very good one Not desired behavior should be CLEARLY stated in the rules in a such way, that it doesn't allow multiple interpretation. The rules should not necessary be very detailed, like the long list in initial message in this topic, but they should clearly declare what is and what is not acceptable to do in safe zones. This should cover not only the cases when ship is stolen to PvP zone, but also the cases when ship is buried on free or owned territory / exploded as the result of collision with the planet and so on.
  16. > Moving third party constructs without the RDMS being provided to do so. If this is what NQ responded on your report (ticket?) than it should be also in the rules. As how one can get to know about it? Also, why not specify a little bit more detailing? Is there any RDMS rule that allows activating normal physics when stepping on the ship? If no (and in curently state there is no such rule in RDMS), how could one provide the right to allow or disallow such action? In this case is stepping on the ship regulated by the text quoted? If no, rules should be more specific.
  17. No. First of all this topic is initially not about some specific case you're speaking about, but rather what mechanics are allowed to use and what not and what should be in the rules. To answer quoted part I will say next: player was not looking to a ship vulnerable to any bug. There are many ships in space bug free that start to move when you jump on it. If you want to discuss that specific case - there is another topic about it in the forum. And I understand the green quoted part as like similar bugs like some actions that involve some manipulations with some tool, it could be maneuver tool, or some movement of your bigger ship, or anything else that results in target dynamic ship being parented to the attacker ship that will be able to transport the 3rd party ship where you want, including PvP zone (you have the words there "to replicate this maneuver in its current state" - how this could be interpreted wrong at all?). This is common sense of what "similar bugs/tools" is for " Intentionally parenting any construct...". So, just a simple jumping on the ship doesn't use any parenting mechanics at all. No any 3rd action other then jumping. Also, the Parenting Ships - Dragged to PVP Space rule was introduced right in the moment of time when some people (I do not know who exactly, but I know there were such players in the game) who were parenting 3rd party ships exactly with described (in quoted rule) mechanic. This rule clearly states what it is about - about parenting one ship to another without permission of the owner, even in it's title - Parenting Ships. So, how is this rule broken by not parenting the ship I do not understand. If NQ doesn't want any hostile actions be applied to 3rd party ships in safe zone this should be clearly specified in the rules. The list of 10 issues in my initial message is there exactly because of this - the rule about hostile actions is missing in the rules, there is only rule about one specific hostile action - parenting the ships. So, NQ, please update your rules set to actual one. @Elias Villd As you have maybe the closest contact with NQs, could you please help to sort this thing out with them? This issue really should be fixed, as in it's current state it allows multiple interpretation by different people as is seen from all the situation and discussions.
  18. > Also, you're defending this, why? No, piracy in any of it's kind is not the source of my income. Even not close to 1% of it The only my reason is having strong definitely rules, that doesn't allow different interpretation by other players like what is "parenting constructs". I like to do some piracy-like things, I like to benefit normal game mechanics in doing more piracy/salvaging. But if it is officially forbidden by rules - I will not do it. If it is not - than I will not understand if NQ will take any action against the one, who did something that is not forbidden. That is why rules should be clearly enough.
  19. I agree what Deckard says is good enough. But this is written in Discord, not in official rules. Just update the official rules, and than it will be OK. More over, this was said AFTER the action was done.
  20. No, not a right statement. I will be happy with the rule something like "killing ships left in safe zone is crime/exploit including any possible way even allowed by normal game mechanics/physics" but they say only about parenting. Also, this rule doesn't cover other cases, like burying constructs/crashing ships on the planet... This also could be included in more general easy rule. But this should be clearly stated by NQ, while for now there is no such statement.
  21. From the rules: Parenting Ships - Dragged to PVP Space: This is a hot topic and one we wish to be very clear on. Intentionally parenting any construct without permission of the owner is not intended for game play. Why does NQ speak about specific issue - parenting -, and not general intentional moving/transferring the other player's construction to the pvp zone without braking the game physics lows or using some other bug(s)?
  22. > Trasporting any player or construct without that player/owner permission, is being hostile. And I want to hear such kind of statement from developers as official statement.
  23. Last issues I would like to clarify: What is official position about burying other people dynamic constructs on unclaimed tiles? Is it acceptable action or is it also exploit? And if the tile is claimed by me, can I bury (cover with earth) alien ship? Is it acceptable action or exploit? Let's assume I found some ship staying on unclaimed territory. If I will claim the territory and bury the ship immediately after claiming the tile - is it acceptable action or is it exploit? I will add all these questions to the initial message.
  24. > common sense says that, if it is in the safe zone to begin with, it should be considered untouchable. My (and others) common sense says, that NQ wants to implement somekind of realistic physics which doesn't allow constructs to stop in space when pilot exits the game. In that case the construct should continue to float/move where it was moving. If NQ would had enough server power the movement of such constructions would be calculated serverside and all constructions left in such state in space would be in moving state forever or while they hit some obstacle or will be hit by some player in PvP zone, as they would eventually ended there. I see this is the main intention - let the ordinary classical dynamics work as it is expected. In this case your statement is meaningless. So, I do not see what is bad to help game physics do it's work by NOT USING any exploit. The other case - steal constructs by using some bugs like some manipulation with maneuver tool. This is completely different thing, and I am against it and never used it! You see, your common sense and my common sense are different. And these are not only between me and you. Many other people from both sides are involved. So, NQ, please make a decision to stop all these talks.
  • Create New...