Jump to content

Samedi

Alpha Tester
  • Posts

    58
  • Joined

  • Last visited

Contact Methods

  • Website URL
    https://bornsleepy.com/about/

Profile Information

  • Gender
    Male
  • Location:
    Stornoway
  • backer_title
    Sponsor
  • Alpha
    Yes

Recent Profile Visitors

334 profile views
  1. Sorry, what? You said "Drop Lua". I said "Lua isn't really the problem". Maybe be careful to use the right words, if you said "Drop Lua", but didn't mean "Drop Lua".
  2. Lua isn't really the problem, and it's very lightweight and relatively easy to integrate into other apps, so it's a sensible choice. The problem is everything that surrounds it - the tooling, support for external libraries, versioning, debugging, and so on - along with the richness (or not) of the in-game APIs. Just switching to JS wouldn't necessarily solve those problems. You wouldn't automatically be able to use npm and just pull in any random library you wanted. There would be all sorts of implications in terms of overhead, and the logistics of making sure that every client was running exactly the same code. Most of those problems could be solved, with the right level of investment, but they could also be solved for Lua.
  3. Hah, yes. Obviously it would be work, but a v2 API would give the opportunity to really clean things up. At the very least, there should be some sort of `system.getAPIVersion()` call. Given how dynamic Lua is, that would be enough (though not ideal). Not versioning a public-facing API is a bit of a schoolboy error tbh.
  4. Sorry, but you can, you just need to add a versioning scheme to the API. All existing scripts use v1. You could add a completely rewritten v2, and have a setting on the controllers where script authors can opt into v2.
  5. Rather than an all-or-nothing cancellation of warp, it would be a lot more interesting if hits on it reduced its reliability, which in turn gave the possibility of it failing later, and dropping you out of warp in the middle of nowhere. Similarly it would be nice if other elements could take hits and become unreliable, spring leaks, etc, etc. That moment when you think you've got away, then you realise that you're leaking fuel out into space and are about to become a sitting duck...
  6. On that topic, why don't NQ organise some actual events on the PTS? Something along the lines of "we're all going to have a big battle in location X, on date Y, come and test the PvP with us". You could do similar events for other changes too, for that matter: "let's all fly over to location X and test out the new docking rules"... etc.
  7. As a coder I am biased, but instead of “IF IT’S BROKE, FIX IT” I'd rather hear “IF IT’S MISSING, LET THE PLAYERS ADD IT”. I get that most players in the long-run may be more interested in using stuff than building it. I also get that you may worry that opening up more flexibility is a Pandora's box that could lead to game-balance problems later. However, to quote that well-known fan of open-world sandbox space simulations, Voltaire: "Perfect is the enemy of good". This is still a beta. You have a finite number of designers and coders at NQ, and a lot to do. You have another army of both out here in the game: stop trying to do everything yourselves! If you give us more API hooks and better tools, we will prototype things for you, and we will fill in a lot of the gaps for now, whilst you focus on the infrastructure. With a modest number of additional hooks I'd say that we could have a community-run mission system and player markets already; they wouldn't be perfect, but they'd exist! If the community adds something and NQ later replaces it with something built-in, few people will complain as long as it is an improvement... and if it's not an improvement then arguably you should be spending your time on something else instead.
  8. I agree that this is a dilemma. Do I spend time experimenting in the PTS, or advancing my actual progress on the real server? A suggestion that would help for those of us who build things: implement a JSON interchange format for blueprints, then allow us to copy/paste them, so that we can move them between the servers. This would allow people to spend time building potentially complex things in the resource-rich PTS environment, then deploy them in the real environment. We wouldn't gain any material advantage - I could build a palace in the PTS, but I'd still only have a blueprint on the real server. However, the time on the PTS would become productive time, and we would be able to experiment with exotic materials, so we'd have an extra incentive to be there. You could probably achieve this with another mechanism for moving blueprints, but I would suggest JSON because from time to time there are bound to be incompatibilities between the two worlds - a text based format is flexible enough for us to hand-mend things. Having a JSON format for blueprints would also open up a whole range of possibilities for external tools (material swapping, for example).
  9. I liked the original changes, though I agree with the general consensus that they were badly rolled out, and it seems that NQ did not fully think though their consequences (eg on the ore price, and the knock-on effects for new players). What frustrates me now is that I got fully on board the new direction, and sunk pretty much all of my money into buying up stock of some scarce elements. Not, I should note, schematics (I bought some of them too), but actual stock. I was playing the market and thought I was doing the thing NQ wanted us to do. The changes caused a big spike in prices, and it would have taken a while for production to ramp up on various complicated items, so I bought up some of them whilst my competitors were still snoozing. This was a gamble, of course, but probably a valid long term strategy given everything that NQ (and particularly JC) had stated in the discussion surrounding 0.23. Now I find myself with a lot of stock where the prices are probably about to plummet. Not because the market has recovered, or for any other in-game reason, but because the goal posts have been arbitrarily moved again. I cannot see that I am going to be compensated in any way for this. I might get a bit of cash back for a few schematics, but that's a drop in the ocean compared to the stock I hold. I'd also like to point out that I also re-sold some schematics on the market, and bought and shipped some schematics for other people. In both cases the people who ultimately ended up with them are unlikely to see the compensation. I can live with all of this. It's frustrating, but the game is in beta and I'm fine with anything that happens which ultimately leads to a better game. I do think though that NQ need to take a long hard look at how deeply they are thinking through the consequences of their changes. Improved testing via a public server will help, but with most of what's gone wrong in 0.23 feels to me to have been quite easy to have predicted. The fact that it wasn't is quite concerning. Similarly, the knock on effects of what feels like a bit of a knee-jerk backtracking now also don't seem to have been thought through. I'd like to see some clearer thinking, better communication, and some better change management. For example, the schematic prices could have been introduced slowly, with the figure being reduced a bit each day. The schematic changes that 0.23 introduced could have been brought in for T5 items only at first, then slowly rolled backwards down the tiers. The talent point reset should have been thought about before 0.23, could have been made optional, and could have been applied only to the affected talents. And so on...
×
×
  • Create New...