Shockwave is simply the renamed Blast elemental effect version of Fireball, which is F/2+5, so drain should be OK.
Street Magic p. 168.

Ah, okay. It seems that it's a translation issue with the german language file. The spell "Druckwelle", which translates to "Shockwave" seems to have a double entry, which I missed in the creation. The correct spell would be "Blast".

I would like to correct this in the official file, but I don't get which spell "Shockwave" is in the german version. There is already a fireball spell with (F/2)+5 drain, as well as a electric elemental damage one, which would be my second guess ...

edit: uh, do I get this right? They renamed the spell "Fireball" to "Shockwave" in the english Street Magic rules?

Not quite. In Street Magic they added additional spell elements in addition to Fire, Electricity, etc.

The Blast element as an area effect spell is called "Shockwave". This is similar to the area effect Fire element called Fireball.

The listing of the new element spells based on name and target (single vs. area) has a sidebar chart in Street Magic p. 168, at least in the english version.

Ah, now I see that chart -.- And there is a spell named "Druckwelle", too. So that's a duplicate entry in the german rules to begin with :/
Thanks for helping to clear that confusion.

I'd like to put in a couple of requests again...

1:
An option to allow Free Spirit PC Force to set the Maximum AND Minimum for all of their attributes (effectively making their attributes = their Force, just like every other spirit), as a recent thread over on the SR4 forums has brought up that the actual explicit rules seem to say this.

2: Kind of big one, but I really think it needs doing~
A back-end overhaul to move free spirit powers from a list in their racial entry, to a full subset in the powers.xml file, adding a new tag to the power entries (something like <type>[adept, spirit, both],<type>) that would denote where the power is for adepts, spirits, or allow the option for custom powers to be both. This will also allow free spirit powers to have actual mechanical functionality.

3:
If I've said this before, I'm sorry, but I'd like request that natural weapons have an option to set their damage = Magic attribute, so that it will appropriately scale with Spirits.

Thanks as always, and keep up the good work!

Once again thanks for all your hard work, quick suggestion:

Can we get commlinks and programs on their own tab? As I'm adding PACKs and other gear all the other tabs are well laid out but "gear" tab is always a mess.

The Shadowrun 2050 versions of Cyber- and Bioware seem to be missing, even if you select the sourcebook in the options.

Hi Nebula

I found a problem with armor modifikations with <armorcapacity>FixedValues ... </armorcapacity>. When ever I add a mod to an armor with <armor><armorcapacity>0</armorcapacity> the capacity is reduced by rating and not by the value of the <mods><armorcapacity>FixedValues ... </armorcapacity> section. If there is a fixed value at <armor><armorcapacity> it works fine.

best regard

Silverangel

Edit: I just had a mistake in understanding the german rules.

On his list. Quoted his text as I'm patiently waiting for the same thing (IMG:style_emoticons/default/biggrin.gif)

No stats for the Chrysler-Nissan G12a Hovercraft?

I too think a commlinks tab would be very useful. Here are some ideas to go with that.

Instead of commlinks tab, make it a Matrix Nodes tab, and include the matrix node information from commlinks, nexi, drones, living persona, and the matrix related information for any piece of equipment that has more than a simple device rating. With enough reference information to tell which node is which.

Related to that, for items that have a node, and do, or can, have independent matrix attributes, options, modification, accessories, add a "node" location to collect all of that together. First place I ran into that, was upgrading a PMV to have higher ratings, fuzzy logic, additional autosofts, etc. Fuzzy logic takes up a modification slot, but the rest of that is zero capacity cost for the vehicle upgrade. It would be nice to be able to just collapse a single location to hide that, while working on the 'actual' vehicle modifications. The node related information was overwhelming the vehicle modification information. The Vehicle Sensor component, with add as plugin does a good job of that for the sensor functions. A Node, Matrix Node, or Vehicle Node component to handle the matrix related functionality rating information would really help. The Fuzzy Logic modification might or might not 'fit' in there, since it DOES use a modification slot for the vehicle, in spite of being very node specific.

I can already create a Vehicle Node location, and can add gear to it. So the added programs and autosofts can be filed there, but the upgraded pilot and matrix attribute information will not move.

I have not gotten far enough with this yet, to see if any vehicle related dice pools will get modified by the the added gear.

The Vehicle Sensor nicely groups all of the sensor function together, but I think it should also show the current sensor rating when the "Vehicle Sensor" is selected in the list, instead of needing to go back to the vehicle entry itself. I do not think there should be anything outside of "Vehicle Sensor" that would affect the sensor value. The same would be true for the proposed "Node" component. It should show the matrix stats. (if can get the upgrades in there, as well as the added gear). This might need an extra tag in the matrix related xml information, to mark items (gear) that should go in a "Matrix Node" component, if it exists.

Separate question: When a basic Ares-Segway Terrier is added to the Vehicles & Drones tab, it initially shows "Sensor: 2 (Signal: 5)". What is the Signal: 5 about? I have not seen anything that changes that value, and do not know what it is used for.

Bug I think: in create mode, adding a matrix program at rating 1 automatically (and correctly) adds program options Copy Protection (Rating 1) and Registration. However, increasing the main program rating after initial purchase does not increase the copy protection rating. While it is possible to have those to ratings different, it would be unusual FWIK about programs and program options. As a minimum, I think the copy protection rating should be adjusted to match the main program rating, if the ratings are the same when (before) the main program rating is changed.

Maneuver and Targeting prompt for details about equipment the autosofts are for. That should not really be needed, since those autosofts are always specific to the equipment they are purchased for. At least if the autosoft is purchased as gear for a vehicle or weapon. Purchasing a Targeting autosoft could be different, since it could be purchased for (the node of) a vehicle that has multiple weapons. In which case a drop down similar to the fake license seems appropriate.

praise and issues (IMG:style_emoticons/default/cool.gif)

Love the program. I was looking at developing a web app with similar capabilities, but never got past the preliminary design stage. Got bogged down in the complexities of interactions between things. BTW, seeing your email address in one of the posts triggered a check of your bio info. You and I are 'neighbors'.

Context: Build 418

Building compound items [with modifications and options] is very awkward in career mode. Advanced Lifestyle, Drone, commlinks, armor, weapons for start. Adding and removal of accessories and modifications, or changing ratings is much simpler in create mode.

Suggestion: Have some sort of 'in design' state that uses the more flexible editing from create mode, and does not create any transactions until the finalized / commit / buy button is clicked. Just brainstorming, 'buy' the base item, set it to edit / customize / design, do multiple customization steps, then finalize (or reject). Generate a transaction for initial purchase, then one more for the batch of customization transactions on commit. That process should work whether acquiring a new item, or making changes to something previously purchased.

I realize that that could be complex to implement. I saw a request in the posting history to be able to use a PACK in career mode. That would be another, possibly simpler, way to improve the functionality. Perhaps limiting the items that are allowed in a PACK to be used in career mode. An extension to that, would be to be able to 'buy' an item from another 'character', whether the 'store front' character is in create or career mode. That way you could keep one or more characters in create mode just to design and build things, then from the career mode character just 'import' one item at a time from the saved create mode chum file, copying the nested xml structure, and creating the appropriate transactions. Depending on tracking needs, that could be a single transaction for the complete customized item, or a group of transactions showing only the final customized result.

Build 371 includes information about copy and paste, in create mode only, pending figuring things out. How is that figuring going? Copy and paste between characters, where the destination character is in career mode, would cover this nicely. I can see issues around this, if the 2 characters are not based on the same settings, but PACKs have the same problem I think. One way to implement this that I can see, is to convert an item into the series of operations needed to [re]create it, then pass that script to the other character to execute (in a transaction) in its own context. With errors causing a rollback, to handle cases were the target character is not compatible in someway. DB terminology, but the concepts hold.

I have another use for scripted operations. The career mode character improvement tab provides a way to turn on and off some optional or conditional bonuses. Another thing that can be useful, is to be able to change the configuration of multiple things for 'standard' situations. A character with multiple suits and armor components could specify all of the components that make a single 'outfit', then equip that outfit, unequipping all other items. At the same time, with multiple available weapons, the equipped items and loaded ammunition could be selected. For matrix work, pick the complete set of programs to be loaded, to provide the currently desired functions, while minimizing degradation from too many programs running. This could also be used to move a standard set of items from one location to another. Packing the van in preparation for a trip 'to the barrens', and putting everything away again before going to the club.

hello,
i have an issue with a vehicle modification : Lighter than air

This doesn't work with chummer.

I've noticed that you're not able to put gear into a fingertip compartement. Altough it states in SR4 Corebook p.342 that it is often used to hide a monofilamentwhip. I wish I could assign my whip or monofilament garrote to the fingertip compartement.

Sensor packages have a Signal Rating (p. 334, SR4A) to express the range of the installed sensors.

Ah! Makes sense. But what determines that range (for the sensor package)? Ultrawideband radar AR60 specifically has a signal rating of 2 (now that I know what I am looking at), but putting it plus a directional microphone (range 100m, which SR4A222 translates to signal 2) in a Dragonfly minidrone, using up all 3 slots for the sensor package, still leaves the drone sensor signal rating at 3. What ever is used to calculate the initial value does not seem to get updated when the sensor package is modified to contain specific sensors.

Read the aforementioned page...the Signal Rating of sensors depends only on the size of the Sensor Package, and specific sensors still can have their own range limits.

i assume you mean
combined with the capacity and signal table at the bottom of the page. That does match the numbers I have been seeing. In the past though, I have been considering that signal rating as the wifi signal range for the package. In other words, how far it could be away from your commlink, and still be (directly) part of your PAN. When I looked at this section previously, I was looking at worn and carried sensors, plus any discretely placed for 'information gathering'. Two different ranges: how far the sensor function can see, and how far the sensor package can send the information. Things like 'leaving' a handheld sensor containing a MAD or Cyberware scanner on a table, then moving away while still receiving data from it, independent of how far the sensor can detect things (5 or 15m for the function versus 400m for the signal rating). Continuing the text quoted above
the word though does imply a different meaning, and cross checking between that table, and the signal range table on SR4A222 does show differences:

Sensor Packages
• RFID signal 0
• Handheld/Minidrone signal 3
Signal Range
• signal rating 1 examples of RFID tags and handheld electronics

Micro sensor package signal 2 does match signal rating 2 example micro-drone sensors.
Sigh, I need to rethink some of the personal electronics capabilities.

I really fail to see the problem. The Signal Rating of a sensor package is the default value for sensor ranges, individual sensors (such as the UWB you already mentioned) may of course have different ranges.

And yes, RFID sensors can obviously "look" further than an RFID-sized device can send...given that most sensors are merely passive receivers I'd say that makes perfect sense...

Single sensors [other than things like sonar and radar] are passive receivers, but when they are added to a package, the package itself typically contains a wifi transceiver. Otherwise it could not connect to a PAN. Bi-directional, so sensor options [select sound] can be selected and configured. Think handheld scanner with a wifi/AR display. That transceiver is why sensors themselves can be subscribed, hacked, spoofed. That transceiver functionality is what I have been associating with the sensor package signal value, which does not necessarily have anything to do with how far the sensors in the package can see. I have been using the "reach" from the quoted text to mean a specification for the wifi range of the sensor package. Instead, it appears that all standard sensor packages have wifi signal range of 0 or 1 [3 or 40 meters]. To get more than that, a signal upgrade will be needed [for the package].

A problem with this, is that many sensor [functions] do not have a range specified, so they will supposedly be able to *see* as far as the signal value of the sensor package they are in. I would really like to have a directional microphone in an RFID package that can hear from more than 3 meters. Same for a laser range finder or motion sensor. A laser range finder should be a LOS device, affected [only] by visibility modifiers.

Reproducable error using gear imported from PACK
Context: build 418; Windows 7 64 bit
I created a custom PACKS kit containing a commlink, OS, and Basic+ program Suite. The OS and suite are plugins for the commlink. In the source chum file used to create the kit, selecting the commlink shows a cost of 6900, which includes the plugins. When I add the created PACK, clicking on the commlink shows 5000, just the cost for the commlink. Clicking the OS plugin [the first plugin], I get a crash from object reference not set to an instance of an object. Clicking the suite, any of the programs, or any of the program options gets the same crash. Saving the new character containing the kit, close and reopen chummer result in the loss of the plugins.
There is only a single settings file, and it was not changed between creating the PACK and using it.
Steps to reproduce:

• new character; default information; any metatype
• Street Gear; Gear; Add Gear
• Transys Avalon
• Add As Plugin
• Novatech Navi
• Add As Plugin
• Suite: Basic+
• Save
• Special; Create PACKS kit
• kit name; custom_my_packs.xml; check only Gear; OK
• close chummer; open chummer; new character; default information; any metatype
• Special; Add Packs Kit; Custom; my kit; OK
• Street Gear; Gear
• Click Transys Avalon # cost shows 5000
• Click Novatech Navi (plugin) # crash

Email with source chum and xml files about to be sent, soon as I post this to get a reference ID to put in the email.

This isn't really the place to discuss the rules regarding sensors, so I would suggest if there needs to be further clarification about how sensors work that a thread be made about such in a rules thread.

But for the record...


Emphasis mine.

The underlined section explicitly says that the Signal range indicated for the sensor package represents the range that the sensor sees.
The bold section states that individual sensor function types might break the sensor packages sensor range.

An RFID sized sensor as far as I know is a passive device, not really much of a sensor in its own right. These are the little microchip tags that are put in devices that are meant to be picked up by an RFID scanner and whatnot. You could probably make an RFID sensor network that is installed in devices so it can pick up certain conditions. In fact, I took a look at the page reference listed in the Sensors for the RFID sensor and I noticed it is in fact listed as its own price (Yes you have to pay extra to extra miniaturized sensors, 500 nuyen each before sensor function cost).


Not sure how you would plan to have an RFID sensor that could be used at a sizable range. Most of the spy toys would fall under a Micro Sensor. These would be things like a camera in your lapel pin, or a laser pointer that has a laser microphone or something.

Now all of that is just for the sensors and their functions. As has already been mentioned, it would need to be attached to a comm device of some sort so that you could actually communicate with it over long distances. You could use any of these sensors in a drone which would have its own commlink and at least a Minidrone can hold up to 3 capacity of sensor functions and has a sensor signal range of 3 before you upgrade its sensors (see Augmentation vehicle mods).

Context: build 418, Windows 7 64 bit
Adding a "Bike Racing Helmet" to Street Gear; Armor show a capacity of 6(6 remaining). Adding Gear; Skinlink to that, which has a capacity of 0 changes the helmet capacity to 6(3 remaining). Adding Thermographic further reduces to 6(2 remaining). I do not *think* that vision enhancements to the visor should use up capacity, even if it not 0 capacity, and the first addition starts counting the included image link and flare compensation. The helmet capacity should be for armor modifications, or new sensors. The virtual surround-sound music system mentioned on AR48 is not included either, although that is minor.

Crash adding vehicle armor
Context: build 418; Windows 7; 64bit; Character build
If a low rated armor modification is added to a vehicle (Horizon-Doble Revolution in this case), the rating can be increased only to 12. AR133 says armor rating is from 1 to 20. When adding the armor, the rating can be increased to 20 (before clicking OK to add it). However, if the rating is higher than 12, then after it has been added, selecting the armor modification causes a crash saying:
Value of "13" is not valid for "Value". "Value" should be between "Minimum" and Maximum". Parameter name: Value.

Saving the character file after the high rated armor was added, close and reopen the file, and the armor is gone.

Reproduced on a freshly created character.

A vehicle can have up to twice it's Body in armor (or three times Body rating for drones), up to a maximum of 20 for regular armor. This is right in the Armor mod entry, on page 133.

The Horizon-Doble Revolution has a Body of 6.