We don't have a public issue tracker, we have a team/internal one. -
We have updated our Community Code of Conduct. Please read through the new rules for the forum that are an integral part of Paradox Interactive’s User Agreement.
We don't have a public issue tracker, we have a team/internal one. .png){kind=avatar}
Oh, I didn't realize I was team/internal
(from your sig): https://www.assembla.com/spaces/meiouandtaxes/support/ticketsPerhaps the text at the top doesn't match actual permissions any longer or something; I didn't have a ticket to submit.
Well, uh... quick, @Korbah, delete all of our posts on this topic immediately.
EDIT: It's this at the top of the page that may have confused me, as I'm told the only people effectively reporting any tickets that are listed there are team members:
Last edited:
EU4 was a PITA with insufficient documentation when it came out, there was little notification that the mods go in a different folder from EU3, indeed EU4 when it was installed created a mod folder where you aren't supposed to put mods and didn't create one where we were supposed to put them.Oh, I didn't realize I was team/internal
Perhaps the text at the top doesn't match actual permissions any longer or something; I didn't have a ticket to submit.
Well, uh... quick, @Korbah, delete all of our posts on this topic immediately.
EDIT: It's this at the top of the page that may have confused me, as I'm told the only people effectively reporting any tickets that are listed there are team members:
Yeah, and that's the problem. Offering users access to a frequently-updated dev version is a useful and good thing that Paradox is prohibiting in this case.
- 3
that's something i especially don't understand. if things like github or SVNs stay locked to public access and a password is needed to access them, why not just have the password on the mods' thread? it fits all other criteria and allows content creators to allow the community to play and playtest their mod right out of the box (which is kinda the point) instead of the usual 1-4 releases per year which can only allow for so much interest (not to mention debugging) before the mod fades into the background.
prime example: Elder Kings. in the considerable time between its 0.1.5 and 0.1.6 releases, people were constantly wondering (and dismissing it as dead) if the mod was dead since the last release was for a now badly outdated version of CK2. so the modders opened access to their SVN. surprise surprise, version 0.1.6 was released and far more feedback than even the largest teams of testers could achieve.
it's things like this that even huge companies like the gaming antichrist EA have realized: more people investing time = more fixes, more publicity, more movement. and PDS themselves have done a brilliant job with this too via beta patches, even ones that needed to have their accompanying and upcoming DLCs removed beforehand. so why in the hell do the mod creators who've been doing this for quite some time now get forcibly restricted to a system the majority of the entire industry now knows is in most cases obsolete?
- 2
Why should they be deleted? Anyway deleted posts aren't actually deleted and can still be seen by mods/admins.Well, uh... quick, @Korbah, delete all of our posts on this topic immediately.
It was intended as public tracked (before the rules were formulated), but outside contribution was pretty non-existent. I just never cared to update the description.
Ah, damn, didn't pay attention to that… thanks for pointing it out.Oh, I didn't realize I was team/internal
It has been difficult to event get developers like me to use it despite it being useful.
Semi-joking. Didn't want to be the reason somebody's bug tracker got nixed.
Just as long as you guys understand that wasn't some kind of stab.
I would be the last person on Earth to intentionally cause troubles for a mod team w/ a public bug tracker (to be clear to anybody else again at this point, though, M&T's is NOT public).
Indeed, I think that even within the spirit of these here Rules™, public bug trackers-- particularly those that disallow any form of direct communication between bug report / issue submitters (only submitter->team and team<->team communication involved)-- ought to be allowed. It's not an external forum. It doesn't expose any paradox IP in any way. It's just a streamlined form of users & team sending their bug reports to a QA email and having that QA person clarify the issue and then potentially elevate and assign it to somebody(s) on the team.
Most definitely not a stab, allowing me to correct an oversight.Just as long as you guys understand that wasn't some kind of stab.
Quick question, can I include an event picture from Common Sense in my parliamentary election mod? Common Sense had parliament event picture I wanted to use but I'm reluctant to exclude anyone from using my mod if they don't have the DLC. I'm a bit unclear on the rule #7 about this. If not, I'll just have to revert to vanilla republican debate event picture.
If it is an EU4 mod, you should be able to simply reference the event picture without having to actually include it in your download.
Just copy the command specifying the picture from a Common Sense event that uses that image.
I'm concerned that won't work for anyone who don't have the DLC. I found the event picture in ZIP file under /DLC so that would most likely not work for anyone who don't have the DLC. Ideally, I'd like to have something like alternative_event_picture in case someone without DLC used the mod but that's for another discussion.
If you put the command for the DLC-specific event picture, then the players who don't have that DLC will have the default event picture. There is no way around it, as you can't put the DLC event picture in your mod, and you can't have alternative event pictures coded in the event (although it might be worth making the request in the mod section...
The only alternatives are to either pick a vanilla event picture for everybody... or make your own event picture.
- 1
That's a shame. I'll revert it to Republican Debate event picture, then.
It *could* be accomplished. Instead of event X, send a hidden event A. That event detects whether the player has the DLC, then sends either event X with the DLC pic, or event Y with a vanilla pic. X & Y should otherwise be the same. It's an ugly kludge, but it would work.
- 1
True. Well, you wouldn't even need the hidden event A.... just have event X and event Y be exactly the same except for the event picture, the event ID and the DLC trigger.
- 1
If it's on MTTH, or an on_action, yes. I was assuming a called event, which was probably too much assumption.
But even for those, I might prefer my method, because it leaves fewer MTTH & on_action items to evaluate.The hidden decision is to wrap the other 2 up so that they can be called from elsewhere as a unit. If you're only ever going to use it from one place, you can make the distinction there, but if you're going to call it from several other places, it's worth the effort make event A. One of the things I learned from my programming training: encapsulate when reasonably possible.