This is some good data.  Thank you for experimenting here.  I'll have to digest the data later, as I'm slow-witted after a busy birthday with the kids, and just chillin' for a bit.

Did you get all your questions answered?

This brought to my mind another short experiment:

[Private to Homunculus:  This message is missing its end bracket...

Yeah, I'm glad the private lines from NPCs seems to work the same way as from PCs, so that we could see it happen.

And, yeah, the missing end bracket prevents the private line from forming at all.

Thanks for tinkering with me.
This message was last edited by the player at 01:50, Sat 09 June 2018.

My pleasure.  Come back when you want to play some more, or if anything here is of use to you.

There's a thread on RPoL Development that spawned this experiment and other work (my Fate Character Sheet and Game Creation Worksheet) to which I must give due credit:  https://rpol.net/display.cgi?gi=36224&ti=23  link to a message in another game.

In that thread, Escribblings introduces a technique of "wrapping" a character sheet done in Easy Tables in HTML table tags.

I'm curious in this current experiment as to whether or not we can also use width=xxx style tags to constrain a larger image in a post.  For the purposes of this experiment, I'm using the following image (one of my own, which shows my wallpaper for my laptop at home):



This image has a native resolution of 800 X 500 pixels.  As a result, it fits neatly into my post (I am presently using a 1600 X 900 display panel).

Let's first see what enclosing this in table tags does:

{the code:}

<table width=400><tr><td>
<img src="http://mypics.findmoore.net/images/horusfalcon/precisionm4600traveller.jpg">
</td></tr></table>

{produces the table:}



Hmm... it looks like the image expanded the table to fit itself instead of constraining to fit the specified table width of 400 pixels.  I half-expected this would happen.

Just to confirm, <img src="imageURLhere"> tags are not supposed to accept the width= parameter (at least according to the Help file).  Here goes:

{the code}

<img width=400 src="http://mypics.findmoore.net/images/horusfalcon/precisionm4600traveller.jpg">

{produces:}

<img width=400 src="http://mypics.findmoore.net/images/horusfalcon/precisionm4600traveller.jpg">

So, yeah, it appears the image cannot be constrained here by what would be normal HTML methods or attributes.

As of right now, the best way forward for using images in posts is to constrain them to a reasonable width prior to inclusion.  Of course, what is "reasonable" will usually be what fits on the smallest display in a given play group.
This message was last edited by the GM at 04:19, Mon 06 Aug 2018.

Hi, I'm here to check out the Character Details tab. I'm not really sure what the two options: 'fixed width, word wrap off' and 'variable width, word wrap on' mean, and I've found nothing in the Rpol FAQ to explain it.

I've noticed that different entries, even in the same game, can give different formats when using 'variable width, word wrap on'. Sometimes the character details show up in a window and sometimes they spread right across the screen. I want to find out why, and hopefully how to force the thing to display within a window every time.

Tinker has provided me with a RuBB script that will force it to a window, but I want to know how to make it do that for itself, so I don't have to add script. <I'll add the script here when I go and find it>

Tinker has set me up with a character sheet here, and it is currently displaying in a window. I intend to do things to it, and see if I can find some content that makes it expand to full screen width. If I can find such content, I intend to see if removing it is a reversible process and takes me back to a window view.

I assume the sheet is currently set up to 'variable width, word wrap on'.

The confusing thing is that, to me, a window is a 'fixed width', but obviously that's not what the term means to the Rpol developers. Maybe I can find out what they mean by the term.
This message was last edited by the GM at 16:09, Fri 26 Oct 2018.

In reply to Dabbler (msg # 16):

The settings for the character sheet are Fixed Width and No Word Wrap.  (At least that's what I see.  Since the sheet is editable, you may be able to change this.)

Part of the difference may be in how the editor window behaves vs. the viewing window?

The editor window accepts plain text and markup (HTML, Easy Tables) as its input.

The viewing window renders variable width text in a different font than fixed width (non-proportional) text.

Let me know if I need to explain the difference between fixed and variable width fonts.  (I wouldn't think so...)

I take fixed vs. variable to mean the type of text used in rendering in the viewer.  So far my observations support this.  It also seems to be a default setting that can be overridden by markup.

Viewing the Traveller Plus character sheet I appended to your character earlier, I see where I actually created an accidental "mini table" at the top, which affected the font rendering for that section.

What word wrap might mean is anyone's guess, but I suspect it has to do with table cell behavior if the available text exceeds the cell's specified dimensions.

It appears a large width (800 px) graphic just extends the virtual viewing window, but experiments in this regard are preliminary at best.

The text ruler below is in Monospaced (a fixed width font) for reference.

         1         2         3         4         5         6         8
12345678901234567890123456789012345678901234567890123456789012345678901234567890

UPDATE:  One thing I do notice after inserting the graphic:  centering of text is affected in the non-wrapped <i>Traveller Plus sheet, whereas the Fate character sheet, wrapped in its table tags, is not affected.  This argues strongly for use of this technique, with any accompanying graphics being placed outside the table tags, perhaps as header and footer banners?</i>

This is actually a new area of experimentation for me, because I usually produce PDF documents from my Open Document spreadsheets (which do the arithmetic for me), then link to the PDFs (stored on my Google drive) in the character sheet editor here on RPoL.  Spreadsheets are just so much easier to maintain.
This message was last edited by the GM at 16:10, Fri 26 Oct 2018.

The setup (width/wrap) is not player editable, only the content is editable. Sheet setup can only be changed by the GM.

Using pre-generated character sheets and images goes way beyond where I want to experiment at present. I just want to input plain text for now, starting right at the beginning.

I’m aware of the difference between monospaced and proportional fonts, but I had no idea that that was what the setup referred to. That may be something else for me to look at.

Because of my lack of understanding of the terms used, I’ve always used ‘variable width, word wrap on’, because I wanted my words to wrap within the window. Can we start with a setup of ‘variable width, word wrap on’ and no pre-gen, so I can just type words as a player and see what happens to them?
This message was last updated by the GM at 16:12, Fri 26 Oct 2018.

In reply to Dabbler (msg # 18):

Sure.  Let me nip out and take care of that...

Done!  Boy, that makes the Traveller part look a lot differently when viewed.

(I really need to sit down and do a table-wrapped EasyTables version of this sheet, anyhow...)

I'll clean up the window so it's ready to go, too...

Done!  The edit window is presently blank, so edit away, please.
This message was last edited by the GM at 16:13, Fri 26 Oct 2018.

I've made an entry and it is going the full width of my page. It wraps, but only at the edge of the page. Whatever setup this is, it's producing the layout I don't want.

Is this Variable Width, Word Wrap On?
This message was lightly edited by the GM at 16:14, Fri 26 Oct 2018.

In reply to Dabbler (msg # 20):

Yeah.  Variable width, word wrap on.  Let's see where it wraps.  I played with it a bit.  Wow.  Not what I would have expected, either.  Must sleep now - got home late.
This message was last updated by the GM at 16:15, Fri 26 Oct 2018.

Hi Horus, I've been chatting with Skald about a possible feature of the site, if we have at least two players and a GM willing, can we set up an experiment to test this here?

The chat:
link to a message in another game

Basically, you'd need to set up a secondary character, say Joe, for me and at least one other player, and see if everyone can post as Joe as well as our primary character, or whether there are differences between Joes, and what the limitations might be.

Cheers. :)
This message was last updated by the GM at 16:19, Fri 26 Oct 2018.

Hi, Dabbler,

I'm game if you are.  Note:  I did some reorganizing of subjects, including your last post.

If Bax The Slayer (my only other current player) is out there and reading, yeah, I like this idea, and would be grateful if you could play along.  I suppose I could rMail and invite Skald to play along (or at least read, since the interest is there...)

Let's get enough people involved and make it happen.

Dabbler, I'm going to let you take control of the experimental design since you're the one who wants to prove or disprove a hypothesis here.  Tell me what you want done and let's do it.  If you want to be on the GMs side of the screen for this one, let me know and I'll make you a co-GM for as long as needed.

So far, we need a character, Joe, assigned to all participants.  I'll go ahead and create your Joe and mine.

UPDATE:  I have created a character named Joe for Dabbler, baxtheslayer, and Chief Tinker (me).  Just for the sake of experimental documentation, I did this via the GM Menu --> Character Management --> Add (Existing) screen.
This message was last edited by the GM at 16:47, Fri 26 Oct 2018.

(Dabbler)
Thanks Tinker. Testing my Joe now.
Yep, he works for me. Now we just need to see what happens when others post for Joe.

It would be useful if each of us starts their posts with their primary name, as I've done, so we know which Joe is posting. It might get confusing otherwise.

I don't need to see behind the screen just yet, thanks.

(Dabbler)
I've just updated my Joe with a portrait (mmb002) a bio line and a Cast List description - could the other Joes please make identical changes, so that we have Joes that are identical in every way? That way, we know that all players of Joe can share his details.

Maybe these details are already showing up on your Joe?

I've noticed that my Joe doesn't have a Character Sheet, does that need to be created by the GM?

If you can set up a character sheet for your Joe, Tinker, and put a few words in it, I'll see if I can see it in my Joe.

Thanks. :)

(Chief Tinker, aka Homunculus)

Other Joe here!  I'd better nip out and select a portrait... let's see what Joe Prime used?  (mmb002 under Male, Modern, Business).

Hmm... I note that my Joe shows up as an NPC?  Hmm... that's just how it's tagged.

The character sheet for my Joe contains the following non sequitur text:


This message was last edited by the player at 03:43, Sat 27 Oct 2018.

Just from initial observations, these Joes are not all the same Joe.  Dabbler's Joe has a different character sheet, is assigned to him, and and has different text in its character sheet that my Joe has, since mine is assigned to me.

This only makes sense.  Each of these characters, even though they have the same name, is a separate entity assigned to different players/GMs.

Let me nip out and add some more text to my character sheet, though, because I created it first.  Maybe it will now update both sheets, but I think not.  More on this theory later, and Jase will probably back me up on this if we ask him.

My additional text is now there on my character sheet, and the page has been updated.

Incidentally, when looking at your Joe's Character Details page, look to see the value of ci= in the URL in your browser.

Mine is ci=319072.  Dabbler's is ci=319071.  baxtheslayer's is ci=319073.

Ipso facto, these three Joes may be triplets, but they are not the same
database entity.

Let's step back for a moment, re-read the referenced thread, and see if the design of the experiment to this point needs to be revised to better test the hypothesis.  Perhaps I misunderstood?
This message was last edited by the GM at 03:45, Sat 27 Oct 2018.

(CT, aka H)

I selected one of the Joes not assigned to me for this post.

(CT, aka H)

And... now I'm sock-puppeting Dabbler.

(The real one)

No, I didn't expect that these would be the same database entity - I suspect that can't be allocated to different players, but I was just checking to make sure.

I've checked my Character sheet (which exists now, thanks), but it's empty, so that, and the fact that you didn't inherit my portrait, confirms that that data is not automatically transferred between Joes, and that they are, in fact, separate entities as far as the Rpol database is concerned.

What I want to do now, is to make the Joes functionally identical, so they all have the same portrait, bio line, Cast description and character sheet contents, and differ only in Rpol's ID number - to make sure that making them identical doesn't fruit up Rpol's ID system (I'm expecting it won't).

Then I want to see if everyone can post as Joe such that, apart from having our personal moniker in brackets, there's no way to tell who's posting for Joe on each occasion.

I suspect from what's happened so far that we can do this - which is exactly what I was trying to achieve. It means that the GM can set up several identical Joes, one for each player, and then any player can post as Joe, enabling the NPC to be carried by the team, rather than being in the hands of the GM all the time.

It's a bit long-winded, creating several examples of each redshirt, but if it works, it's do-able. :)

Please welcome Skald as a "player" here at Heru's Tinkertoy!  A Joe has been created, but is not yet fully identical.  I shall take care of that when I get home tomorrow after work.



I underestimated you.  I'm sorry.  I'll try not to do that again.



I think I did misunderstand.  You're trying to test a different set of conditions than I first thought.



Nor do I.  Each record in the database can hold the same data so long as they have unique key identifiers (those long numbers shown as ci=).



I don't see why that shouldn't work. A micro-game, perhaps?  Free-form with no rules whatsoever aside from those of civil conduct?  Could be fun!



The approach is a bit ham-handed, since it created as many copies of the NPC Joe as there are players. (That will make keeping all those Joes identical a chore...)

A GM or Co-GM can post as any character in a given game, and can assign any secondary character from one player to another, as I understand it.  Just some points to ponder there, but I digress...



I think we've already proven it's do-able.  Let's explore what ramifications doing it might have.  I think there are also other hypotheses which were put forward in the thread in Technical Discussions which are worth exploring if you are all game.

One last question:  Might it be useful to transfer further experimentation into its own topic?  This may go on at some length.  What say all of you?
This message was last edited by the GM at 20:05, Fri 09 Aug 2019.

Hi and Welcome, Skald. :)


No worries, it's better to underestimate than to overestimate. I quite often miss the boat! :)


What did you think I wanted - whatever it is might be worth exploring?


Suits me!


True, but the method you suggest there requires the GM to pre-empt each player wanting to post for Joe, and then allocating Joe to the right player. Taking time-zones into account, that could be even more of a PITA than copying and pasting occasional updates onto half a dozen character sheets.


Suits me. :)

If you do intend to set up a mini-scene, the original problem I was trying to solve was a situation where I had 3 or 4 players playing NCOs in a squad of mercenaries.

I wanted each of the NCOs to be able to post for any or all of the Redshirt Privates, so that they could carry their squad forward, and I could concentrate on handling the opposition.

I didn't want to hand 3 redshirts to player A, 3 redshirts to player B, etc, I wanted more flexibility than that.

Smiles and waves !  ;>

I do enjoy 'pressing buttons to see what happens' (ah, in a literal sense, not trying to annoy people !) so jumped at the chance to contribute to the sum knowledge of the RPoL world when our illustrious Chief Tinker asked.

To the subject at hand ...

Yes, as we discussed in technical, the system allows for all players to have their own Joe so there's no trap on identical names, but as you've proven here, they all have their own Character ID, so they're actually separate characters.

That would definitely have been a deliberate decision by jase - the prime concern is that we (GM/Mods/Admin) can work out who posted what, just in case inappropriate content crept in - so each player can be uniquely identified by the character attached to them by that Character ID, if it comes to pointing fingers and assigning blame.

But I don't think that necessarily has to make for too much extra work to maintain - you'd need to set up everyone with their Joe or NCO1, NCO2, NCO3 in the first instance, but once you've got the portrait, bio and description in place for all of 'em that should be it ... the trick would be NOT to populate the character sheet for each, but instead to have a separate thread where the character sheet sits - put it inside a "Private to Joe" tag or use a particular group if you want to hide it from any players who don't have a Joe.  The GM would have to edit that post to update the character sheet, but just the once, not for every character sheet attached to an instance of Joe.

Also note that you can see which Joe posted by hovering the mouse over the player name in the info block to the right of the post as the Character ID ("ci=") forms part of the string that's visible in the status bar (assuming you have that turned on in your browser).

{Waves back} Hi!



Yup, that's the whole point of this little discussion board.  Glad you could join us.



That only makes sense.  It's more or less inherent in the defaults of most SQL-based databases.  I think it's possible to require a secondary field (other than the key ID) to be unique, but it's not generally done by default, and doing it here would have been an unfortunate choice for us as players and GMs, so I'm glad Jase didn't do that.

Moderator duties aside, from what I've seen of the design here the philosophy seems one of elegance:  no unnecessary restrictions, and no features that aren't truly useful, either from the view of a player, a GM, or a Moderator.



This makes eminent good sense.  I especially like the bit about common character sheets in subtopics residing in private groups.  That makes managing player access a significantly more simple matter, especially when multiple NPCs of this type are needed in a game.  The only drawback I see to this approach is that one could rapidly run out of private groups if multiple NPCs were needed in groups accessible by differing groups of players.

If this were to take place on a large scale, and I was tasked with designing the game, I'd probably make as few groups of this type as possible, and tend to assign as many of these NPCs as possible to the same private group to reduce the confusion.



Please see subtopic 2600 - Micro-Game for Experiment Six, everyone.  This present topic will remain open for future experiments, but let's move further discussion to the micro-game topic (until if spills out to other subtopics, of course).

It's back to bed for me.  Re-adjusting to nights after working days yesterday.
This message was last edited by the GM at 16:31, Sun 28 Oct 2018.

The experiments I am about to perform will be based on the General RPoL thread:

Multiple Rolls with Manual Die Roller?

The basic issue discussed in the linked thread was that making multiple rolls "manually" in the dice roller resulted in some strange errors if the first roll in the set was one preceded by a constant from which the first dice roll was subtracted.

The example string of dice rolls was:



This led to further experimentation by the original poster, chiefly moving the 14-3d6 roll to the end of the queue.

An assertion (which appears to be correct if the individual results are considered separately) was made by a respondent that the subtraction (or negation) that occurs in 14-3d6 was also applied to the subsequent dice rolls in the set.

Well, the short answer so far is that symbols of inclusion (such as parentheses, square brackets, or braces) all throw syntax errors.

Additionally, enclosing each expression in its own set of quotes (as the dice roller examples below the field indicate) also throws an error.  The expression list must not be bounded by quotes at all, since the dice roller adds them automagically around the entire list.

It's beginning to look like the intended syntax for each comma-separated expression is XdY plus or minus DM value (where DM = Dice Modifier) with the sign and DM value optional and omissible.

In some cases, an X value of 1 may be omitted, and dice strings for the rolling of one die with Y sides may be expressed simply as dY.  Note that for certain forms of dice roll strings (notably reversed strings involving subtraction) this "implied 1" format does not work correctly.

Hmm...

Using the string 3d6+7,2d6-4,d20+8,d16-7 yielded:

01:40, Today: Homunculus rolled 12,2,12,-5 using 3d6+7,2d6-4,d20+8,d16-7 ((2,1,2,1,5,4,2)).

Let's see now:

2+1+2+7 = 12
1+5-4 = 2
4+8 = 12
2-7 = -5

It would appear that so long as the dice come first in each string, the operations remain properly correct and separate from each others' influence sign-wise.

Hmm...  the string 20-d20,12-d12,6-d6 throws an error stating that - is an invalid number of dice.

Replacing this with 20-1d20,12-1d12,6-1d6 yielded more interesting results:

01:48, Today: Homunculus rolled 2,5,3 using 20-1d20,12-1d12,6-1d6 ((18,7,3)).

20-18 = 2
12-7 = 5
6-3 = 3

So far, so good.  It's worth noting that in a reversed (Constant - dice roll) expression, so long as all dice rolls are of this type and all dice are preceded by a number (even if it is a 1), their results were correct.  Omitting preceding numbers in dice strings (the "implied 1" form) tends to lead to errors in reversed form strings.  That is:

20-1d20,12-1d12,6-1d6 is acceptable for reversed format entries, but...

20-d20,12-d12,6-d6 is NOT acceptable for entries of this type.

 Let's see what happen if the sign changes for the middle roll in this set:

20-d20,12+d12,6-d6 yields:

01:57, Today: Homunculus rolled 3,0,4 using 20-1d20,12+1d12,6-1d6 ((17,12;2)).

20-17 = 3
12+12 <> 0 (!) {it appears that first "subtraction also negates the + in this expression.}
6-2 = 4, so the negation did not carry over to negate the subtraction.

CONCLUSIONS:

So long as a number greater than zero is always specified in the dice string in the X position of XdY (not considering any preceding sign), the dice roll strings will be parsed correctly so long as none of them is expressed in "reversed subtractive" (Constant - Dice Roll) format.

If a reversed format roll is needed, it is best to express it singly, more especially so if it involves subtraction as opposed to addition, however, if multiple reversed rolls involving subtraction are needed, so long as they are not mixed with those requiring addition, their results will be parsed correctly.

(This has some possibly interesting implications for those of us using The Black Hack, The Petal Hack, or systems which use a similar "Stat Check" mechanic where success is achieved by rolling below a given value.)

We theorize from the foregoing that reversed subtractive format rolls were not anticipated in the design of the dice roller, and that the rules of their parsing are an unintended consequence rather than by intentional design.

{Please note this is not intended as a criticism of the Dice Roller.  It is, rather, an observation on the tendency of users to find exploits, loopholes, and other hidden flaws in a coder's designs.  This sort of thing amounts to a hack of the Dice Roller to get it to perform in some ways beyond its original specifications.}

As such, while there are special cases where reversed format dice rolls are parsed correctly, namely "all additive" or "all subtractive", care should be exercised in using any other cases, and results should be verified to be in line with those expected.