Nyeste innlegg

Sider: 1 2 [3] 4 5 ... 10
Minecraft / Sv: Minecraft Pjatt
« Nyeste innlegg av Emilpoika 10. November 2016, 11:16 am »
Vel, tar man i betraktning utfallet av det amerikanske presidentutvalget så må jeg gjøre en liten endring på muren.
Den skal gå tvers igjennom kartet mellom OPs&VIPS og skille dem fra vanlige spillere, og de vanlige spillerne skal selv betale for muren!
Minecraft / Sv: Hebblocks
« Nyeste innlegg av Emilpoika 23. Oktober 2016, 16:35 pm »
Om dere vet om noe jeg kan forbedre eller kommer på noen redstone eller commandblock ting jeg kan bygge og lage video om så håper jeg dere sier i fra til meg. x)

Har sett mange "dansegulv" av både redstone og vanlige blocks (via commandblocks/World Edit).
Hva med å forsåke å lage et slikt selv?
Evt. med egen musikk fra notebocks/commandblocks?
Minecraft / Hebblocks
« Nyeste innlegg av Hebelub 23. Oktober 2016, 15:06 pm »
Jeg har nettop startet en Youtubekanal som heter Hebblocks, (fordi jeg heter Hebelub) --> https://www.youtube.com/channel/UCB5xudO3WK3bxc2vB-ryf1g
Den inneholder alt fra redstone til commandblocks. :P Om dere vet om noe jeg kan forbedre eller kommer på noen redstone eller commandblock ting jeg kan bygge og lage video om så håper jeg dere sier i fra til meg. x)
Minecraft / Sv: Minecraft Pjatt
« Nyeste innlegg av Emilpoika 20. Oktober 2016, 23:00 pm »
Oi! Lenge siden sist det har skjedd noe i denne tråden nå :o

Ja, men det er jo ikke mye aktivitet på serveren heller ;)
Selv har jeg alltid forumet åpent i en fane på maskinen. -Til og med nå! Gamle vaner er vond å vende.
Men da er jeg vel en av de få (eneste?) som fortsatt får med seg at noen poster i forumet rett etter de har gjort det?
Floyd er vel kansje en av de som er oftest innne, regner jeg med?
Minecraft / Sv: Minecraft Pjatt
« Nyeste innlegg av argh99 20. Oktober 2016, 20:31 pm »
Oi! Lenge siden sist det har skjedd noe i denne tråden nå :o
Generelt teknisk / CentOS 7 nmap-ncat does not support SOCKS5
« Nyeste innlegg av Floyd-ATC 16. Oktober 2016, 19:59 pm »
Tunneling an ssh session through a SOCKS5 proxy (e.g. using Tor) should be possible by adding the following to your
Kode: [Velg]
/etc/ssh/ssh_config file:

Kode: [Velg]
Host *.example.com
        CheckHostIP no
        Compression yes
        Protocol 2
        ProxyCommand ncat --nodns --proxy-type socks5 --proxy %h %p

Unfortunately, RHEL7/CentOS 7 ships with a rather antiquated version of nmap-ncat (a modern replacement for the now unmaintained BSD netcat) and this version only supports socks4.

Trying to use socks4 is similar to using no proxy at all, it fails with the following rather cryptic error message:
Kode: [Velg]
get_sock_port: getnameinfo NI_NUMERICSERV failed: ai_family not supported
Uninstall the useless version of nmap-ncat:
Kode: [Velg]
yum erase nmap-ncatDownload the newest RPM from https://nmap.org/download.html
Install it. Example:
Kode: [Velg]
yum localinstall ncat-7.30-1.x86_64.rpmFix your
Kode: [Velg]
/etc/ssh/ssh_config as shown above.
Generelt teknisk / Powershell: Round to nearest integer
« Nyeste innlegg av Floyd-ATC 14. Oktober 2016, 10:07 am »
For some bizarre reason, Microsoft decided that Powershell should by default use "Banker's rounding" which by their logic is more "natural" than what people "entrenched in C" (as well as any other programming language and elementary school level mathematics) would expect.

Long story short, Powershell will by default round both 1.5 and 2.5 to 2, 3.5 and 4.5 to 4 etc.

Workaround? Define the following function to get the universally expected "round UP from .5" behaviour:

Kode: [Velg]
function round( $value, [MidpointRounding]$mode = 'AwayFromZero' ) {
  [Math]::Round( $value, $mode )

Kode: [Velg]
PS> [int]3.5
PS> [int]4.5
PS> round 3.5
PS> round 4.5
Generelt teknisk / Powershell: continue does quite the opposite in a piped foreach loop
« Nyeste innlegg av Floyd-ATC 21. ſeptember 2016, 15:29 pm »
In these two code snippets, the "continue" keyword does quite the opposite of what it's supposed to:
Kode: [Velg]
PS C:\> ('a','b','c') | % { $_; continue }
Kode: [Velg]
PS C:\> ('a','b','c') | foreach { $_; continue }

When spelling the code out like you would in a sane scripting language, it works as expected:
Kode: [Velg]
PS C:\> foreach ($i in ('a','b','c')) { $i; continue }

Go figure.
Kode: [Velg]
PS C> $PSVersionTable.PSVersion

Major  Minor  Build  Revision
-----  -----  -----  --------
4      0      -1     -1

Screeps / A method for tile based path caching in Screeps
« Nyeste innlegg av Floyd-ATC 12. ſeptember 2016, 19:51 pm »

Because path finding is one of the most CPU intensive ("expensive") operations in Screeps, the need to re-use paths is a well known topic. Generally speaking, the following factors must be considered when choosing a cache strategy:

- CPU cost of learning new paths (insert)
- CPU cost of changing existing paths (update)
- CPU cost of looking up paths (select)
- CPU cost of pruning outdated entries (delete)
- Storage space

For any caching scheme to worthwhile, we must assume that each path in the cache should ideally be inserted once and selected as many times as possible. Because changes are inevitable and there is no absolute way to determine how often an individual path will be selected, the scheme must allow update and delete operations to be carried out with reasonable performance.

Most scripting languages offer built-in data types that fulfill all of these requirements but in Screeps there is another factor which severely limits the options: Storage performance.

Because all information in Screeps Memory must be serialized before storage and deserialized before use, the total number of objects in Memory soon becomes an important factor in addition to the already tight restrictions on storage space. Add to this the fact that data structures like arrays and hash tables introduce storage overhead when serialized, and it soon becomes obvious that storing fewer and bigger strings is favorable over smaller and more numerous variables.

What's in a path

An important realization is that an individual path from Pos1 to Pos2 contains much more information than just how to get from Pos1 to Pos2. Given a cluster 10 positions around Pos1 in one room and a second cluster of 10 positions around Pos2 in another room, it is fair to assume that the majority of the steps in each of the 10*10=100 possible paths between the two clusters will actually be the same. This is especially true if there is a road between the two clusters. Storing multiple instances of the same information is not only a waste of storage space (and therefore a waste of CPU resources to serialize/deserialize) but also means more information has to be processed when performing insert/update/delete and select operations.

Possible solutions

This leads to the obvious solution that information should be stored per tile so that each tile contains information about how to reach other tiles from there. At this point one might think in terms of a simple nested hash:

   cache[from_tile][to_tile] = direction

There is a number of problems with this approach. First, let's say we have 10 rooms, each room may have up to 2500 tiles (of which atleast 1% are in use). A very conservative estimate of 250 first level entries with 250 second level entries means we have 62500 objects in memory that need to be serialized and deserialized each tick. It soon becomes obvious that with all the information needed to uniquely identify each position this puts us well above the 2048K limit even before we put in any directions. One might therefore consider normalizing the information by separating information per room:
   cache[from_room][from_tile][to_room][to_tile] = direction

This eliminates the need to spell out each room name 250+250 times but we still have over 62500 objects in memory and use a non-trivial amount of storage space just to store structural characters such as "{},:".

Custom serialization

In response to this, a common idea is to consider other ways to serialize and deserialize Memory. I do not suggest doing this, because of several reasons:

- Performance is unlikely to be that much better unless you place severe limitations on what can be stored in memory.
- The built-in Memory access scheme relies on the possibility to access Memory in a certain way. We must either accomodate this or reimplement everything, hopefully without hurting performance.
- It is much more beneficial to address the fundamental problem and reduce the number of tiny objects we need to store. In a way, this means applying our own idea of serialization but targeting only a specific part of the data structure.

Packing information as densely as possible

One critical bit of information about the Memory object in Screeps is that it can handle UTF-16 characters. At first glance, this may seem irrelevant because room names and tile coordinates do not contain special characters, but coupled with Javascript's built-in methods for storing and retrieving UTF-16 character codes this gives us a rather convenient way to store and retrieve 16-bit values (albeit with a few important restrictions, google UTF BOM for details.)

Why is this useful? Consider the fact that a single tile coordinate can be expressed using 6+6 bits (remember, 6 bits can store a single number from 0 to 63) and a direction can be expressed using 3 bits. We have to keep in mind that certain special character codes in UTF-16 are invalid but it turns out that we can actually use the 16th bit as long as we keep those 4 highest bits in the range between 0 and 8 inclusive.

This puts us at 16 bits (2 bytes) per tile even with the direction, but we can do even better than that. If a tile happens to contain directions to multiple consecutive destinations we can choose to store them as a "span", similar to how Run Length Encoding works. Distinguishing between a span and an individual destination can be done using a "magic" direction of 0:

   code1 = x1 + (y1*50) | (1<<12) // 0x1000   Single destination with direction=1

   code1 = x1 + (y1*50) | 0       // 0x0000   Span begins at x1,y1
   code2 = x2 + (y2*50) | (3<<12) // 0x3000   Span ends at x2,y2 with direction=3

Strings of these codes can be stored for each tile, effectively reducing the number of objects to serialize/deserialize by atleast a factor of 250. For rooms with a large amount of walkable tiles, this factor can be even higher.

An alternative to the x+50y approach is to use bit shifting exclusively:

   code1 = x1 | (y1<<6) | (1<<12)

I have not bothered with benchmarking these to see which one is faster. My guess is that the difference in terms of CPU time is negligible.

Implementing access

Even if the problem of storage space and serialization/deserialization performance has been solved, there is still the non-trivial matter of implementing efficient methods to insert/update/select and delete information. These are our findings:

- The codes should always be sorted by tile address (x+50y). This eliminates the need to search the entire string to the end in both the case of a cache miss and a new insert, because the search can be aborted as soon as a higher address is encountered. The search is always carried out on the packed data structure to search the shortest string possible.

- Only when an insert/update is needed, the packed format (with spans) should be unpacked (without spans) so individual addresses can be inserted, updated or appended as needed. The unpacked data structure must be sparse, otherwise the compression operation will require a constant loop of 2500 iterations even for a string with no actual information in it.

- Only when all modifications have been made, the unpacked structure should be packed (with spans). This is the most expensive algorithm of the three in terms of CPU time because the entire unpacked string must be processed. It is therefore beneficial to put as much information into the string at once rather than making small, incremental changes.

Pseudocode for learning

Kode: [Velg]
for each tile T1 in path including start(1)
  stop if T1 is in a different room from start(2)
  get next direction as D
  fetch routing table for tile T1
  for each tile T2 in path including target(3)
    update table T1; move in direction D to reach T2
  store routing table for tile T1

1) The path will typically start with the first move, not the first tile. We need to put information into the first tile because that's where creeps will (hopefully) start later too.
2) The pathfinder may provide suboptimal results for rooms where we do not have vision. Instead of trying to deal with this in each case, simply learn the path leading to the next room and recalculate the path once we get there and see the roads etc. This also serves as a safeguard against the script spending ages on learning just one very long path.
3) The creep will probably want a path leading to the target later on, not the tiles in between, so don't forget this crucial little detail. The information about the tiles in between are just a nice bonus. You may want to try reducing the cache size and learning time by only learning the ultimate destination but in my experience this reduces the overall efficiency by causing more path searches. (See "What's in a path".)

Actual results

My current implementation runs at GCL4 with path information for 11 rooms and 40+ creeps. My total Memory is around 200 Kbytes total but I can pretty much decide how much memory to use by adjusting the cache age. My current setting is 1800 ticks, which seems to work pretty well. According to screeps-profiler, the average time to move creeps is 0.370ms, this includes pathfinding, learning, routing and the occasional fallback to moveTo/ignoreCreeps:false for collision avoidance. I use the new Pathfinder and typically see between 0 and 3 path searches per tick. Take info account that I am relatively inexperienced with both Javascript and Screeps so your results may differ. Anyway, this is what my current data structure looks like:

Kode: [Velg]
    r Container object for routing information
      E##N## One hash per room
        xxyy Tile coordinates formatted as 4 digits, one hash per tile
          mru Game.time of last access
          local String of UTF16 characters for this room
          E##N## String of UTF16 characters for destination room
          E##N## String of UTF16 characters for destination room

Possible improvements

- This is just one possible storage structure, but I strongly recommended to store one string per combination of rooms, together with cache control data such as a MRU timestamp. This makes it trivial to discard data for any single room or tile when needed.

- Cache invalidation such as handling blocked paths resulting from new structures or using new roads is a huge topic and the full discussion is well beyond the scope of this document. One simple strategy is to introduce a small random chance to recalculate paths even if cached information exists. Another strategy is to drop random tiles from the cache to trigger recalculation.

- The suggested concept of spans form horizontal "stripes" of adjacent tiles. One possible improvement might be to form rectangular areas, either by using a more complicated algorithm to begin with or by splitting and combining adjacent "stripes" in a second pass. It is unclear if this added complexity would provide a net savings in terms of CPU performance and/or storage space.

- It might be worthwhile to store other information (such as path cost) together with the routing information in the form of trailing characters. Although the non-trivial increase in complexity and memory use would require serious consideration, this could be helpful if one wanted to write a modified pathfinder capable of taking cached information into account. 

I'm sharing this in the hope that you will find it useful. If you discover a cool way to improve the efficiency or find a stupid fault in my logic, your in-game feedback would be greatly appreciated. Preferably in the form of a message, not an invasion.

Cloulez aka. FloydATC
Generelt teknisk / Lost password on DataDomain DD510, DR530 (possibly others)
« Nyeste innlegg av Floyd-ATC 25. Juli 2016, 19:18 pm »
Shamelessly stolen from Rodney Barnhardt, https://www.experts-exchange.com/questions/28129776/Data-Domain-DR530-Password-Recovery.html#answer39194436

1.Connect to the serial port with the following settings:
o 9600 baud
o 8 data bits
o none/no parity
o 1 stop bit
o none/no flow control

2.Reboot the Data Domain system
3.During RAM test hit one of the following keys (BIOS version depends on which one works)
d.ESC 2
4.Enter the password, which from what you say, yours should be: d500d
5.Select Server Management (or advanced) and then Console Redirection
6.Set Legacy OS Redirection to ON (MAKE SURE NO OTHER CHANGES ARE MADE!)
7.It will look like it is rebooting, hit the TAB key at the boot screen
8.Type “p” at the prompt and enter the following password: ddrc0s (that is a zero)
9.Select “a” to append the boot-serial option
10.Make the following change by adding this to the kernel boot line: goto-bash console=ttyS0 (this is a zero)
11.Hit ENTER to save the change and then press “b” to continue booting.
12.When the reboot halts, enter the following commands
a.mv /bin/sh x
b.ln –s /bin/bash  /bin/sh
c.dd_bootmodule  --reassemble-only
13.Use the following command to get the root name: cat  /proc/cmdline
14.Depending on what is returned, you will use the following to mount the device:
a.If root=/dev/root-pl1, use dd_dg00p15
b.If root=/dev/root-pl2, use dd_dg00p5
c.If root=/dev/dd_dg00p15, use dd_dg00p15
15.Mount using the results from above. EXAMPLE: mount  /dev/dd_dg00p5
16.Edit the shadow file in vi by typing : vi  /sysroot/etc/shadow
17.Remove the encrypted password from the sysadmin account. The line will look something like this: “sysadmin:#3465@^fg/$GJITFD:13371:0:99999:7:::” After editing, it should look like the following:”sysadmin::13371:0:99999:7::: 
18.Enter :wq to save and exit the editor
19.Then enter the following commands to properly exit and reboot:
a.sync; sync; sync
c.umount  /sysroot
20.Once the system has rebooted, create a new password with the following command: user change password sysadmin
Sider: 1 2 [3] 4 5 ... 10