• Content count

  • Joined

  • Last visited

Community Reputation

46 Neutral

About Jon

  • Rank
    code scholar
  1. Here's a suggestion, that may or may not sound like a good idea, based on my experiences of trying to bash out specifications in the Debian project, where mailing list conversations often get too large to keep a clear big picture of the state of the proposal. The idea is for a small pool of editors (perhaps one) to keep a summary page on a wiki somewhere. The discussion about the summary page could continue here, but it would always be about the current draft which would be a wiki page. The important thing is you don't have a lot of people all edit-warring on the wiki page, the editor(s) would basically need to be convinced of a change to make it. Which puts them in the position Fraggle outlines, of having to exercise careful judgement. Said page should cover the points Fraggle describes (rationale etc) and it would be wise to document rejected proposals too, so people coming along later and saying "what about..." can be pointed at that. If you have a doomwiki account already, you could set it up as a sub-page of your User space, e.g.
  2. The one thing I remember about fragglescript is Fraggle suggesting that nobody should use it anymore.
  3. To be clear I agree and am not advocating them for this effort; l also don't think features to aid in "poor Man's" scripting should be in scope either. For those who want scripting, look at lua/JavaScript etc.: this effort is for other things.
  4. Lua is dross platform and doing very well as an embedded script language in hundreds of games (including commercial ones). JavaScript is doing well, too.
  5. I agree with you. Useful features like more friendly scrollers, etc. is worthwhile, but scripting should be addressed by a proper scripting language, whatever that is, out of scope for this effort.
  6. That's fine, nobody should be expected to work on something they're not interested in their spare time. That's not fine, nobody should be shamed from working on what they want in their spare time. In terms of priorities for chocolate doom I think the blockers for v3 are all relating to building on Windows. If you think we should be focussing on that, then I'd love your input on those, especially as you are the only windows-using developer on the project. But to be clear, if you don't want to work on that that's fine from my POV, because, to restate, I don't think anyone can expect or demand any volunteer to spend their free time on something they're not interested in. Edit: actually I'm mistaken and the windows build issues are not marked as blockers for v3. (the actual blockers)
  7. This is a really good way of expressing what I feel about it.
  8. FWIW I care much more about getting HOM right :)
  9. It's pretty important to me, at least, that a PWAD that would make doom unplayable on vanilla has a similar effect on chocolate. Replicating the *look* of medusa is not the hard part anyway, and Quasar has basically already implemented that.
  10. I think this is why you guys are off doing interesting ports with new features rather than working on chocolate, because we see things so differently ;)
  11. The main reason to do something more drastic than draw some ugly lines (like tutti frutti) is one of the reasons chocolate emulates old bugs is to for mappers to know whether their map will work on vanilla, or not. Tutti frutti is pretty benign and sometimes unnoticeable. We could make sure medusa was much more visible, but it might still be something that a mapper may leave in, or ignore; whereas in vanilla it's something that you absolutely must address. I'm actually starting to wonder if slowing down just the renderer is a good idea. Imagine an imp fireball travelling towards you as you turn the viewpoint to incorporate a patch of medusa. With vanilla, the fireball's travel (and all other game logic) would also slow down; with my proposal, you could dance a jig in front of the fireball, all at normal speed, but just not see it. Not a bad suggestion, thanks.
  12. I think we agreed that we would slow down the renderer, but not try to artificially tax the CPU. We want rendering framerate control for framerate interpolation support, so we could use the same mechanism to artificially drop the framerate when medusa was in view. I'd been intending to look at adapting the stuff that's in crispy doom (but haven't got very far)
  13. There's a bunch of things in the pipeline that might be useful like whatever is killing web assembly. They managed to get Quake 3 in browser after all
  14. Wish I did! doesn't look like I did though.