oStorybook

Notice: Undefined index: tasklist_type in /data/web/b7/3e/2d/ostorybook.tuxfamily.org/htdocs/support/includes/class.tpl.php(128) : eval()'d code on line 85 Notice: Undefined index: tasklist_type in /data/web/b7/3e/2d/ostorybook.tuxfamily.org/htdocs/support/includes/class.tpl.php(128) : eval()'d code on line 90
  • Etat New/Nouveau
  • Pourcentage achevé:
    0%
  • Type de ticket Feature Request
  • Catégorie
  • Assignée à Personne
  • Système d'exploitation All/Tous
  • Sévérité Haute
  • Priorité Normale
  • Basée sur la version 4.10.00
  • Due pour la version Non décidé
  • Date d'échéance Non décidé
  • Votes 0
  • Privée Non
Concerne le projet: oStorybook
Ouverte par favdb (favdb) - 2015-10-17
Dernière édition par favdb (favdb) - 2017-02-14

FS#21 - Improve the relative date

The Relative Date should have some more dropdowns. In particular, I'd like to choose between "days after" and "hours after", so that I can set something to be 3 hours after something else. It might also be nice to have a "before" dropdown.
(from wayland in discussion forum)
favdb (favdb)
lundi, 18 avril 2016, 07:50 GMT
Le champ date relative doit être modifié de int en String pour traiter une forme "(-) DD/MM/AAAA HH:MM:SS". Le signe moins s'il est absent est considéré comme positif. La date relative peut être incomplète, ainsi "+ 1" sera anlysé comme "plus un jour", "- 5:0" est interprété comme "moins 5 heures et 0 minutes", "+ 5/1" = "plus 1 mois et 5 jours", etc...
La fonction de calcul de la date est à re-écrire.
favdb (favdb)
dimanche, 24 juin 2018, 07:57 GMT
from donedwards

Chronological view (and possibly other stuff) doesn't work when a scene's date is relative to another scene that also has a relative date; it just omits those scenes.

Similarly, the Memoria skips over all relative dates. If there is no fixed scene on a date, it simply doesn't happen - no matter how many scenes occur on relative dates that happen to land there.

It would be nice if this were fixed so all relative dates that can be calculated, are calculated, and are used in both those places. And elsewhere as appropriate (such as a column on the Scene list).

Here's one way to deal with it.

New table DateCalc will contain fields SceneID, CalculatedDate. It only needs an index on SceneID, which may be the primary key.

When it's time to refresh the calculated dates - all of them, or only some:

Start by deleting from DateCalc whatever Scenes you want to recalculate (possibly the entire contents)(if you didn't just delete everything) Delete from DateCalc any Scene dependent on a Scene not in DateCalc; repeat until this deletes nothingInsert into DateCalc the SceneID and Date of all Scenes that have fixed dates and aren't already in DateCalcRepeat as long as there is at least one Scene whose SceneID is not in DateCalc but is dated relative to a Scene that *is* in DateCalc: Insert in DateCalc the SceneIDs of all such scenes, calculating the dates.When that is done, any Scene that has a relative date but still is not in DateCalc has one of two errors: it's relative to an undated scene, or it's part of a loop of relative-dated scenes (simplest case, and probably common: it's relative to itself).

A scene being dated directly relative to an undated scene (not relative to another scene that is relative to an undated scene) is easy to detect so the user can be notified; if there are none of those, then any remaining relative-date scenes with no dates must be part of loops.

This could be embellished easily enough to flag all scenes that are dated directly or indirectly relative to an undated scene. It would require another field in DateCalc, to distinguish deliberate undated scenes from the ones dated directly relative to them, and those from the ones indirectly relative. Then any other relative-dated scenes that can't have dates assigned, must be in loops. Don't try to figure out the loops, just flag the affected scenes for user attention.

Chargement...