Jump to content


Alpha Tester
  • Posts

  • Joined

  • Last visited

Everything posted by Zeddrick

  1. Fixing stacked elements is a great change and I like that there's a way to detect overlapping elements now. But in the screenshot you included all the player knows is that at least one of the 118 retro rocket brakes (for example) is disabled. They don't know where that element is and finding it might be tedious. Will the stacked elements glow red like obscured ones to to make it easier? It would be really great if LUA could do this. Perhaps a core.getStackedElementIdList() function to return a list of disabled elements on the core. Then this could be incorporated into existing LUA scripts (damage control perhaps?) to put arrows up pointing to the broken elements, highlight overlapping ones on an element map of the construct, etc.
  2. NP, I was fairly sure it was an honest mistake. It was just a quote I didn't really want attributed to me. Sorry if my tone made you uncomfortable though. I don't think my first message was particularly aggressive but will tone it down in future nonetheless.
  3. Allowing people to hold tiles forever is a bad idea. At a minimum there should be some sort of upkeep for them (outside of sanctuary moon). Perhaps that's coming with the territory changes? There are quite a few players now who can claim whole moons (IIRC it would cost a little over 1 billion to claim the smallest moon which is about a week of mission running for some people) and then they could go AFK forever and leave massive chunks of the game unusable.
  4. Also, given that we have the transponder changes which allow us to see/set the tags assigned to a ship, would it be possible to have a radar.getMatchingTransponderTags(constructId) call to allow us to see which of the tags we programmed into our transponder match the target? That would allow for the HUD to display extra information based on the matching tag (is it an org-mate, ally, NIP person, etc) and there would be the potential for the LUA to do clever things like changing transponder tag to see if the target also changes to match.
  5. I just took in this one: radar.getConstructInfos(<int> cid) : Returns a list of working elements on the given construct if identified. Is that going to give me a full list of elements on the ship (potentially hundreds of them) or just the same information we currently see in the 'info' section of the JSON for an identified target?
  6. Are you expecting a wipe to attract new players here, or to attract back the ones who previously left? The population before the 0.23 update was built up over a number of years of alpha so you'd think most people who would be interested in the game would have already been playing at that point. So then it would be returning players who the wipe would be attracting? @Zychov it sounds like you're still in touch with at least some of those 20-30 people. Would any of them come back if the game wipes/relaunches?
  7. I want to PvP and just blow up everything I can find.
  8. I've been here since alpha and didn't know about that page. NQ, do this! It's a great idea.
  9. You have seen the recent Q&A video, right? Talent points for new players, sadly, are something I think would get exploited when DAC (DU's equivalent of a plex) becomes a thing. People will very likely start farming large numbers of alts which generate money through mission running, passive ore miners, or whatever and these will partially fund themselves. Adding skillpoints to a new alt (of course you will 'refer' your alts) just reduces the amount of training time required for the alt to become 'useful' (you can train passive mining skills instantly, for example).
  10. I don't think anyone has said that about talent points have they? Seems to me a wipe and fresh start would be completely undermined if some people start with 50m talent points (about a years worth) and newer players start from zero.
  11. Can you actually read? Generally if someone says they were misquoted it's clever to go back and see if they actually were before brainfarting out another reply. Someone else said drop lua. I replied to it saying that I'm not a lua fan but dropping it was a bad idea. You replied to me, edited the message and bungled it so it looked like I said drop lua. GO back and read the thread if you don't believe me!
  12. Each to their own. Personally I'm not a fan of micro transactions for skins, etc in a game where I'm already paying several subscriptions. Particularly not in a game where the majority of the content is created by the players! I feel like for a sub things like skins should be available for free and if anything is being charged for it should be the ability to add a custom texture/skin/whatever you made yourself. Eve has a lot of this sort of thing and it resulted (for me anyway) in lots of immersion-breaking nonsense like t-shirts that cost more than dreadnoughts and ship skins which cost 100s of times the price of the ship they're skinning. I hope that sort of thing doesn't come to DU.
  13. It's a bit annoying that any accounts I already recruited (OK, they are my alt accounts but whatever) are not eligible for the program any more because I made a purchase before the program started running. Given the possibility of a wipe anyway (so no real benefit in training SP on alts) I'm now thinking I might be better off unsubbing the paid accounts then waiting for the wipe and creating a new set afterwards. Or will you be grandfathering in existing accounts somehow?
  14. You made it look like I said something in your quote there when I actually said the exact opposite! Be careful to quote people properly ...
  15. Yes, I did consider doing partial parsing of the string. However: -- I don't like doing things like partial parsing of JSON strings because that sort of code is inherently flaky. I know you aren't allowed to name a ship "},{constructId=XX,name=YY}" but if you could you would be able to completely break most of the regexp-and-string concatenation types of parsers people would probably make. And this type of code isn't nescessarily all that future proof against the JSON structure changing and adding more nested data, etc. I just like to know my code is protected against a lot of things like that. -- I'm not just re-constructing the original JSON. I'm also taking the construct ID, mangling it into a tag and putting it on the front of the name for each element on the list before updating the radar widget. That would require a reasonably deep parsing of at least part of the JSON so I decided I might as well parse it all and gain the above robustness. Building it on a table is sort of viable, but I would need to be able to build the data up completely and not all of the information is there. For example, one of the fields tells the radar widget how far along identification is. That isn't exposed in the new API so instead of seeing a progress bar when identifying a target people would see it jump straight to 50% (say), then wait and jump straight to 'identified'. Also the code isn't that future-proof against new things getting added to the radar data and being used by the radar widget. Thanks for the response though.
  16. Thanks for the second part of the series. Reading about the radar changes you seem to be adding a bunch of API calls so one can access the radar data without using the radar.getData() method. I like this, not in the least because calling json.decode(radar.getData()) in a busy location overloads the CPU, causing the script to be killed, so using the radar data needs a bit more thought. However one of the things my script (and most PvP scripts I imagine) wants to do is produce filtered subsets of the radar widget so instead of just a 'radar' box there are 'friendly', 'neutral', etc widgets which are separate. Doing this means getting the JSON data from the radar, modifying it and adding the modified data to custom widgets with system.updateData (or whatever it's called). In order to make the code which does this robust, my script has to decode the JSON (using a custom version of dkjson with yield statements!), manipulate the data into multiple structures, re-encode those back into JSON and update the widget data. What this means is: - I always have a binary copy of the radar data kicking around anyway. This comes for free as part of the above process. So I don't need the new calls you're adding because looking at the data tables is probably going to be faster than making the API function calls. - The updated radar API has done nothing at all to solve the pain points when developing a PvP radar script. I still need a complete copy of the JSON parser and have to keep wasting CPU encoding/decoding JSON constantly. What would work better, IMO, is to have a binary version of the getData() call which returns the decoded structure and a matching updateDataFromTable (or whatever) call to allow modified versions of that raw data to be fed back into the display widgets. That would make my script much easier to write and remove the part which takes the most CPU -- the need to constantly encode/decode JSON to make the IFF widgets.
  17. 'radar' here is a variable set up with a radar object. You either need to have the autoconf system set it when your .conf file is applied or you'll need 'local radar=slot[2]' or whatever after you linkit to a particular slot. Also I think getConstructIds got taken out? A.
  18. Every time I write LUA for DU I wish they'd chosen JS instead. LUA is just wierd, I regularly use about 10 different programming languages and none of them are like LUA when it comes to the basic syntax (which seems to derive from Pascal?). WASM is an interesting concept, but I don't know how easy it is to extend a WASM engine with plugins so you can implement things like the element object API, etc and have it invoked from whatever language compiled to WASM? With WASM you might be able to have LUA compiled to it so you could keep compatibility with existing scripts. But don't you think that this is just a product of DU's age? Wasn't the project started in 2012 when LUA was a much smarter choice? Sometimes when developing software you have to keep running with the things you already made and build on top of those rather than re-making things you already made. Do you think NQ should spend a large amount of time changing out their scripting engine now rather than implementing new game features or fixing the in-game systems they already have? And is it really worth making people re-write scripts and possibly learn a whole new language? IMO this is something to re-visit later when the game is finished and making money ...
  19. OK, so there are two things here. Firstly, LUA in DU is not like the LUA in WOW. In DU the lua is part of a construct which can be killed, cored and taken by someone else. And without DRM *the person who takes the construct gets your scripts* when they kill your ship. Or they might get the scripts belonging to whoever gave you them, etc. However DRM doesn't really enable you to sell scripts at all (outside of certain special situations where you trust another player a lot) because it doesn't work for scripting. The DRM owner of a script is whoever deployed the original construct and built the ship. It's not the person who wrote the script. So as a script writer you either become a ship builder too and sell ships or you're SOL when it comes to selling scripts because you can't have any DRM protection at all on them. You can't even put PvP scripts you write on your own PvP ships unless you built them from scratch because you have to ask the original owner to enable DRM, then every time you want to change your own script you have to ask them to come do it again. Or you can fly without DRM and if someone kills you then they get to take your PvP script and they can sell it to other people if they want. The whole thing is miserable. I'm waiting for NQ to do it properly before I even think about selling scripts. Until then my scripts are for me only.
  20. Thanks for documenting this. Am looking forward to part 2 and the radar changes. Will you be introducing any new things with the radar API or just telling us about the way it behaves at the moment?
  21. I have to say this thread is surprisingly quiet on the subject. I'd have expected more reactions one way or another to the possibility of a wipe.
  22. No it won't. The game has unlimited production capability. So if you bring back element destruction (and it doesn't make players quit after they break their 500+element mission ship for the 3rd time due to framerate bugs causing it to crash with a tower which didn't render) then demand will go up. Briefly the economy will work. People will then produce more (a lot of people have a lot of factories turned off right now due to low demand). Supply will increase again until it is just above demand and we will be back where we are now again. And people will be saying the problem is that there isn't enough consumption.
  23. If there is a wipe, the most active and organised groups will be the ones to profit most from it because they will recover the most quickly due to better organisation multiplying out more collective hours spent playing. And within a few weeks everyone will be complaining that Legion won DU again
  24. Yes they are if they're in the PvP zone. The clue is in the name you see. It's a PvP zone. It's for PvP. You go in it if you want to PvP and you don't if you don't. It's not a hard concept and I don't think it needs complicating ...
  25. You make it sound like PvPers only want to attack unarmed ships. In fact, for most PvPers, unarmed ships are something of a disappointment but we'll take it anyway if it's on offer. You also make it sound like the only way to get T3-5 ore is to go into the PvP zone. It isn't. You can still get it from planets or you can buy it from the markets. Perhaps mine some T2 (the market really needs Natron right now!), sell it and buy T3-5 with the money. The T3-5 ore put there in the PvP zone is partly there to give PvPers something to fight over and partly there to entice people to take the risk and come out where the PvP players can shoot them. It's a sort of reward. What you want is to be able to grab that reward without participating in the intended purpose of asteroids, which is generating PvP encounters. If you don't want to participate, get your ore somewhere else like you did before asteroids were introduced!
  • Create New...