Valid issue, but it's another consequence of an existing task, merging them together.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jun 7 2017
Server Log file:
The NOT block can't be used to send rail changes anymore. A true or false signal doesn't do anything when trying to set the rail type or change its orientation.
Hm thanks, adding a blocking task to this one then.
Duplicate, merging tasks.
Duplicate, merging tasks.
Can't reproduce although I managed to get an exception that broke any weapon.
I tried out with a modified config, 500 pulses per second but even firing that for 30 seconds didn't break anything, doing an auto-save while doing that didn't do anything either.
What you describe, is what handles the explosions dies, and only a server restart would resolve that (till it breaks again).
In T2328#101765, @lancake wrote:-feedback-
Unfortunately I can't reproduce. I have tried it out with a quite large sector (10 mil blocks total), even making sure the spawn location would be occupied by chunks, loads in just fine and time to load/spawn is pretty much the same as usual.
Do you manage to get past the loading screen and you just end up unable to spawn after clicking the spawn button, or do you timeout during the loading screen? Could you upload your log file too for the client that is timing out? Logs are located in the Starmade/logs folder, logstarmade.0.log is the most recent one. Upload that file here by drag and dropping it in phabricator's message box.
Any rail that was docked to, cannot be used again with create docking if that entity has moved to another rail already. Only undocking that entity will "unoccupy" it.
Error message: "Cannot create dock!\nDock is already in use!"
In T2367#101960, @lancake wrote:-rejected-
Rejecting, not a bug, just the result of a mechanic that prevents your own weapons from hitting the ship it's on. Needs to be changed at some point perhaps, or become a config option.
Without this mechanic, you would always need to make sure there's empty space in front of any weapon which is quite a big design change.
Same issue as in T2215. This is an invalid rail link, a relatively recent check was added to prevent rails from working in case an invalid connection is found. That's probably why previous blueprints still worked because the check wasn't there yet to prevent rails from working.
Rejecting, not a bug, just the result of a mechanic that prevents your own weapons from hitting the ship it's on. Needs to be changed at some point perhaps, or become a config option.
Without this mechanic, you would always need to make sure there's empty space in front of any weapon which is quite a big design change.
Duplicate, merging tasks.
Related to T390 too
One of the older tasks, merging them together.
This issue will automatically be resolved with the upcoming power priority queue, as your priority queue will make sure power will go where most needed which is something you determine.
Supposedly hasn't happened in a long time, at least from the few people I've asked.
Not getting any new tasks related to it for sure. Wireless links getting lost is unrelated with this one and most likely that is fixed too now.
Is this only happening for displays you copy/pasted around? In the description you mention that just writing and exiting out of a display is enough to make it show [no data] again but any further details implies that it only resulted after pasting them.
If this only happens with pasting, it's a duplicate task of T118.
A bit late to the party, but this isn't a chaotic naming system. It's using lower camel-casing.
First word has lower case letter, any subsequent first letters of other words are capitalized.
Great, closing this task then.
Typo for 2 names:
Ertharadine -> ErthParadine
Ithiahad -> Ithirahad
Oh my, we didn't notice :(
Sorry about that!
If this still happens and you can get a blueprint to reproduce it consistently (assuming it's a regex issue), please upload the blueprint here: T2388
Will merge this one another task though since the original nullpointer was fixed (or it changed into T2388), which was at the time the same issue you were talking about.
More of a future feature than a bug, we need UI scaling to really support 4K resolutions. In this case, also caring about DPI.
Sensor is reading it fine, it's just that you can't fill up a storage chest completely if that one already contains a block already.
The reason why the storage says it's 100 volume out of 100 volume is because of rounding. 1999 blocks out of 2000 is 99.95% but it rounds to 1 decimal, so rounds up to 100.0
Yeah, was reported before, will merge tasks together.
Unfortunately I can't reproduce. I have tried it out with a quite large sector (10 mil blocks total), even making sure the spawn location would be occupied by chunks, loads in just fine and time to load/spawn is pretty much the same as usual.
Also related to T957
Duplicate, merging tasks together.
Possibly the same, or similar issue as mentioned in T2230
If you only had 1 (player) faction in each world, they both would have had faction ID 10 000. I'm not sure why it would also display a different name for a station but perhaps that's also saved in the faction.fac file.
I assume both stations were homebases so that could be it.
We had an old task about this issue but it was closed as presumably fixed.
Scrollbar pops up, but does not seem to use the correct number of lines.
Couldn't find another task about it, putting in queue. Template preview doesn't perform well, not a bug but it's definitely something that will need to be addressed later on.
If you still have this problem, can you upload your recent log file? Go to starmade/logs and find logstarmade.0.log after reproducing the problem (in your case, just logging in, trying to load a few ships and then leaving again).
Drag and drop that file in phabricator's message box to upload it here.
Jun 6 2017
-QA Testing-
Related, if not the same issue of another task. Merging tasks and info together. The reason why you're not encountering the problem again during that session is because all the blueprint info has been cached and can be re-used, or related to blueprint migration (although not sure about the latter).