Search results

Inferring both players and admins should be equally trusted and/or distrusted is nothing short of a compositional fallacy; just because something is true of a part, does not mean the same truth applies to the whole. With that said, I can see your concern, and in the spirit of the original...

The difference between players and admins is an apples to oranges comparison. While an Admin can play on a server, they will also always have the ability to purge everything you have, to block or otherwise impair your ability to access that server, to modify a spawnpoint, copy raw database...

I disagree with you on the server admin's access; administrative level entity duplication has proven a necessary evil. Quite frankly, if you can't trust a server admin, you really shouldn't be there. Although thinking about this more...in pursuit of the original posting's intent (to hinder easy...

There's a mechanic built-into the existing blueprint system to do that: it saves the original ship core names (copy your BP to a linux or OSX system, and run the command "strings" on it). This particular function was incredibly useful when dealing with some major server abuse issues a while...

Wrong again. A boolean "AllowCopy" flag on a ship core does not control use, modification, or distribution of the copyright works: you can still fly the ship (e.g. use it), you can still modify it, and you can still give/sell (distribute) the ship to others. Therefore the original posting does...

That's the whole point of this suggestion: not to eliminate an ability to copy designs, piece-by-piece, or in template-sized chunks, but to make it more difficult for the unauthorized to copy an existing build with quick two mouse-movements. No, that's not a quote from the original posting...

Wrong. Re-read the original posting. I expect a direct quote from the original posting, taken in context, to refute this, or the whole silly "DRM" derailment in this thread dies here. Umm, that's exactly what my original posting asked for: a boolean flag which can be set at time of entity...

The forum member ignore option works remarkably well :-) Anyways...some excellent, logically-sound, and well-formed additional justifications have been broached in support of this proposal. Thanks all for taking the time to put those thoughts out here.

Shipyards

There's talk of one, but ideas are still being worked-out. Contributions are greatly appreciated.

A timeout would be wonderful - IMHO the point of shop docking isn't to facilitate multiple invulnerable HBs, but to help facilitate trade, and to ease a newer player's introduction to the server. Perhaps for the timeout: charge players XX credits per hour. After player's account is depleted...

Been running smoothly for nearly 5 hours...quite happy to see more than one thread busily churning away. Thanks for the optimizations!

Would also be neat to incorporate a randomizer which produces sounds like

Hmm...laser gun: shoot item for response. That might just work: have many docked entities, each one being a separate "switch" that players can shoot.

Consider capturing console output with a tool designed for log collection: rsyslog. From there, tools can readily monitor the logfile in a non-blocking way. For instance, by using standard features of logsurfer, a tool designed for very high speed & high volume log parsing, any scripts that you...

Maybe just get rid of warpgates, and adapt the existing wormholes to fill this gap (e.g. a wormhole computer that must be programmed with your destination, and also have adequate power to "focus" your jump). Having chokepoints in the game would certainly add an interesting twist for...

Shipyards?

I kind of like this idea: bigger missiles = easier to hit.

If you had an existing customFactionConfig/FactionConfig.xml prior to the update, you WILL have to make MANUAL revisions to update the file. As the game engine DOES NOT do it for you, despite what QA observed/expressed in the original ticket: ⚓ T1420 Typo in FactionConfig.xml and...

Fairly accurate account of events, although I disagree on a few points, and to help fill a few missing links: There was never any logged evidence of a laggy mass core spawn during the May 22nd-June 1st timelines, and that is something that the server would have logged, if it really did occur...