Chaosforge Forum

  • October 14, 2024, 17:48
  • Welcome, Guest
Please login or register.



Login with username, password and session length

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - yaflhdztioxo

Pages: [1] 2 3 ... 18
1
Discussion / Re: Quick questions thread!
« on: August 14, 2017, 15:58 »
Looks like you're using the 64 bit Lazarus and thus compiling a 64 bit program.  You'll need to use the 32 bit version.

Rather than try being clever about it, I'd recommend nuking your 64 bit setup from orbit and starting over again from scratch with only 32 bit lazarus installed.

2
Releases / Re: Jailbreak 0.2
« on: July 15, 2017, 06:54 »
There's a third link that's a regular forum attachment.  It's the most up to date.

3
Releases / Re: The Elevator of Dimensions (0.9.2)
« on: July 15, 2017, 05:41 »
aah, memories.  The gameplay suffers heavily from an unstable equilibrium and if you're patient enough you can beat it standing still--but that's no fun.

I tend to think of it more as a modding demo; instead of the randomness you usually expect with a roguelike here's a very predictable, structured telling.  With lots of easily stolen features for future modders.  Alas modding didn't revitalize the DoomRL community as much as I would have hoped.  But we got tehtmi's work out of it so that's a plus.

You can edit the mod and lengthen the timeout if you like.  Maybe add a screen flash.

4
Requests For Features / Re: some challenge mode ideas
« on: May 27, 2017, 05:53 »
Personally I like these sorts of threads.  Sometimes you get some really fun ideas in them and it's always fun thinking about how you could implement them.


You can't disable run exactly but you can make it unusable.  Set player.tired = true every level and adjust everything that sets it false.

Giftdropping is an exploit in the being AI, which you can change, so you could disable giftdropping by modifying all monster AIs to ignore items.

Removing items on a timer, realtime or turn based, would be very tricky.  I think you'd have to scan the level every tick for items, push new ones into a queue with a timer, and destroy them when their timer is up.  Lot of busy work as items get picked up, used, or destroyed naturally though and it might not be possible to 100% know what items have been 'dropped' by a monster vs a player.

A modified pacifism where you can attack after getting most health globes would mean generating and totaling extra health globes every level, either counting them as you use them or scanning the level periodically since they can be destroyed, and adjusting the OnFire hook to only work if the globes are collected and the wielded weapon is the scythe.  And creating a new scythe with the modified alt fire.  A fair bit of work overall and a rickety solution but doable.

5
This is a known issue that affects several of the more complex monster AIs.  Unfortunately it's knee deep in the engine code and a casual fix isn't easy for a non-pascal coder; there's a more detailed ticket on the code repo if anyone else wants to take a crack at it.

6
Discussion / Re: How do I run open-source DRL?
« on: March 07, 2017, 07:43 »
Admittedly I know nothing about those newfangled phones kids have these days but would it possibly be easier to just port DoomRL to whatever unix flavor the Androids use?  Linux DoomRL does exist...

7
Discussion / Re: How do I run open-source DRL?
« on: December 22, 2016, 17:38 »
Great!  Now you can play WolfRL which lives on in GitHub as well...

8
Discussion / Re: How do I run open-source DRL?
« on: December 22, 2016, 12:24 »
Easiest way around that is to yank the dlls that come with a regular boring old 0.9.9.7 windows DoomRL release.  You'll need it anyway for the sounds and stuff.

9
Discussion / Re: How do I run open-source DRL?
« on: December 22, 2016, 09:01 »
* yaflhdztioxo cracks knuckles

We haven't yet gotten maintainers set up or a clear direction for what we're going to do with old and busted DoomRL; the code wasn't released when KK was good and ready so he's busy with Jupiter Hell and all the fallout from that.  It's a free for all until things settle down; eventually we'll get there.  Right now data is scattered about, mostly in the GitHub issue threads, and here's the gist of it (Windows is easiest, I haven't gotten linux to work yet):

Quote
    Grab DoomRL and FPCValkyrie. Both are here on GitHub and owned by ChaosForge. Place their root directories side by side.
    Grab a copy of DoomRL. You'll want the sounds and music from it and those aren't on GitHub. You'll also probably want the DLLs if you're on windows (unix users have it tougher--they have to actually get all the extra packages themselves)
    Get FreePascal and Lazarus. As of this writing you should REALLY GET the x86 versions; DoomRL will compile but won't work as a 64 bit program so that'll make life easier for you. Unfortunately linux users have to deal with a bug that causes optimization to explode spectacularly; either get the latest fpc from trunk or turn off optimizations.
    Fire up Lazarus. It'll look for things it needs; if it can't find something grab that package. Curse the Lazarus multi-window interface.
    Open up the DoomRL project. That'd be doomrl/src/doomrl.lpi. You might be interested in makewad too but most modders prefer to leave everything uncompiled.
    Compile. Hopefully it'll work. There's a couple of nice debug flags that you might want to toggle too such as the one that highlights cells you can see that opponents can't see you from >).

For your specific question fpcvalkyrie is built alongside DoomRL.  I'm not a freepascal expert (if it were pure C most of us would have had this down pat a while ago) but from what I gather fpc doesn't use shared libraries the way c devs think of them; the project file expects valkyrie to be alongside the doomrl directory so that's where you put it.


If you need further help you can also try asking on our IRC channel or joining the discussions on GitHub.  It being the tail end of the year you might not get a response very quickly; it's just the timing of it all.

10
Off Topic / Re: C++ and STL. How portable is JH?
« on: December 17, 2016, 07:39 »
It's closer to Java than C++ in terms of family and behaviour.

shhhhhhhh.

Those words.  We don't say those words out loud.
Those words upset the code monkeys.

11
FPC Valkyrie / Re: Getting "Error while linking" on makewad stage.
« on: December 15, 2016, 07:07 »
I have successfully compiled DoomRL (and by extension FPCValkyrie) on windows  That one's easy.  Another person has successfully compiled on OpenPandora of all things, a third has made progress on a linux build that requires backporting some FPC bug fixes, and to the best of my knowledge no one has gotten it working on a mac.  There's a couple known bugs that are on hold til KK gets a newer mac too.

Between the open sourcing and the kickstarter things are still chaotic.  Most of these convos are being had straight on GitHub now and it'll be a while before things shake out and we determine who maintains what.  If you want to be the apple maintainer you are welcome to it :).  But there's nobody that I know of who can help you right now.

12
Reproduced.  It appears to happen if you die immediately after placing the nuke, or potentially it has to do with the AI's current state.  The bug is clearly in the AI referencing the monster's self property even though the monster no longer exists.

This COULD be solved in the AI with judicious checking of the self.__ptr property but methinks the engine should be keen on NOT continuing the mastermind's AI after it has died.  I'll poke around the engine code later (it's not my specialty but kk is busy).

13
Discussion / Re: Suggestion
« on: December 10, 2016, 10:10 »
Saves in DoomRL only happen between level transitions (so by saving on a staircase you automatically descend--sounds like you missed that detail, maybe it could be made more explicit?)
It's been suggested before, and there's merit to the idea.  In my mind save scumming a new level isn't much different from save scumming the original level.  The no N! saving is solely to deprive save scumming--a bit on the overkill side but nobody said N! was fair.  Adding a mid-level save just makes things that much more flexible for everyone else.

But like Sereg said DoomRL is played quickly, and there's a bit of charm to the current method.  Also changing that would mean more work and testing on a feature that most people probably consider 'good enough'.  The work-to-value ratio isn't in this issue's favor; if someone outside the dev team does it and submits a pull request it might get in but I doubt anyone will push hard for it.

14
Discussion / Re: OpenPandora port and a thanks
« on: December 09, 2016, 11:33 »
Holy crap that was quick.  We're still having problems getting the linux version to build right for people not named kk...

As I'm sure he knows the GitHub project is getting some attention--mostly from people trying to wrap their heads around pascal--and we have an IRC channel on quakenet as well.  We're still just getting organized... and you've already released an ARM port... Wow.

15
Modding / Re: WolfRL
« on: December 08, 2016, 17:07 »
Valkyrie does not have build instructions.  Free Pascal doesn't work like that I'm told.  Valkyrie simply compiles alongside DoomRL.

We're still working out a good set of build instructions.  There's a lot of back-and-forth on Github about that.  You can also try IRC.

Pages: [1] 2 3 ... 18