Kyle873's Doom RPG Mod [0.10.0 Beta]

[Soledge]

I don't know an exact version, but the date was 6/7/2016 the latest at the time of the issue.
EDIT: After doing a fresh install, it works now.. so well thanks.

[Soledge]

Actually now I am dealing with more issues, the first being where is my health counter? And second what is this text when I switch to a weapon aside from my fists saying "ACS: I don't know what 'RLPistolDemonArtifacts' is" and the last issue I am having is the lag spike which makes the game unplayable.
EDIT: The lag spike was fixed but still having problems with the hp and ammo counters missing and the whole "RLPistolDemonArtifacts" that happen with every weapon aside from the fists as previously mentioned.

[subenji]

the ACS messages are an annoyance, (recent change in the latest development build) but everything's working correctly. I've prevented the messages in my fork, which I'm hoping is stable enough to merge in soon.

As for the missing health, that's mentioned in the FAQ:
https://github.com/Kyle873/DoomRPG/wiki ... r-ammo-etc

The usual status bar is blank in DRPG, and you have to expand the hud once further.

[DarkkOne]

I get a lot of ACS error messages with your fork (typically something about not knowing about mods for a particular gun). Are the messages prevented in the version on github, or have you not pushed them to that yet? Or am I experiencing some other issue. I don't seem to notice any gameplay problems with them, other than the headache of message spam if I'm carrying around one of the guns afflicted.

Edit: Also the DRLA classes don't show their image when I'm selecting them starting a new game.

I've tried it with both the most recent GZDoom build and the last GZDoom stable release, both 64-bit versions.

[subenji]

The most recent gzdoom build added an error message when doing a check for an inventory item that doesn't actually exist.
I've actually prevented all cases I could find that were coming from DRPG - but DRLA also performs the same behaviour.

The errors are related to weapon modpacks - when a check is run on what weapon modpacks are on a weapon, a check is done for "weapon name"+"mod name" - for each mod in turn. But some weapons can't take come mods: Demon artifacts on non-demonic weapons being the obvious example, and as such that item doesn't actually exist.
Before, that didn't matter - the function returned a fail state quietly, the code handled it, and everything is fine. The only thing that changed is now it complains about the attempted check for a nonexistent item.

[subenji]

As the latest changes have proven to be stable, my fork has been merged in! The DoomRPG Launcher will now download the update.

As per the discussion earlier with user variables, the recommended version of GZDoom is: 2.2pre-889, built March 21st 2016.
http://devbuilds.drdteam.org/gzdoom/gzd ... 904a027.7z

With this build you have nothing to worry about using savegames.

As always, feel free to report issues here.

[StarController]

the recommended version of GZDoom is: 2.2pre-889, built March 21st 2016.
http://devbuilds.drdteam.org/gzdoom/gzd ... 904a027.7z

With this build you have nothing to worry about using savegames.

Would you be kind enough to please link to the x64 build of pre-889 as well? my attempt to find it on the DRD site failed. :/

[subenji]

There isn't one.
http://devbuilds.drdteam.org/showall.ph ... &order=asc

[DarkkOne]

Using the build of GZDoom you linked, the latest DRLA and the latest DRPG, I still see the messed up character preview images in the Class Select screen. They all show the Marine flashing on a sort of wavy maroon-ish background. If I remove the DoomRPG files, but leave everything else untouched (same config, same version of GZDoom, same DRLA files) then the class selection screen looks perfectly normal.

[subenji]

I am aware, but thanks for the report.

[DarkkOne]

Mostly just wanted to make sure it wasn't something wrong with my setup. I 100% always assume I've done something wrong, and it's not a bug, until someone else confirms it's happened to them too.

[subenji]

I've discovered a script termination bug in testing today, related to "kill reinforcements" missions. It's not 100%, but it can cause all scripts to terminate on the next map load.

[DarkkOne]

I've run into one problem so far. When performing assassinate missions, sometimes when I kill something I don't get the reward for it. This has happened with angelic boots and... one of the demonic guns. Not the pistol, assault rifle, or unmaker. The other one, I can't remember what it's called right now.

If I set the game to auto-send to locker, the item goes to my locker. I can then retrieve it, and pick it up (when I failed to get them the first time, I tried again from a save. On the second fail, I tried that, and it worked).



Edit: Also getting the occasional freeze during the hacking minigame on locked crates.

[whateve]

From the github issues list:

I just noticed that one can use any skill, with no EP cost and without having actually learned it, by pukenameing its script—even if cheats are disabled (e.g. on Hell or Armageddon difficulty). Appropriate checks should probably be done at the beginning of those scripts.

This could actually be useful, by the way. This would let the player bind a key to a specific skill, rather than to a skill ring slot, allowing for more than eight skills to have key bindings and freeing up skill ring slots. At the moment, though, doing so would be cheating, and that's no fun.

Question: could one alias these so that you could call the magnetize and recall (the thing that sends you to the outpost, might have the wrong name) ability skills at a keypress? Running over credits is tedious and being able to return to the outpost because a lame event or aura combo stopped me cold would be useful.

[subenji]

You could always bind both skills to the same key. Teleport takes a couple of seconds playing an animation so it'd work out.

Edit: Found the cause of the script terminations from Reinforcements missions, also similar behaviour in the loot generator. Updated my Fork.