1
WeiDU / Re: weidu next generation - rewrite weidu into popular language
« Last post by Mike1072 on June 22, 2017, 07:57:19 PM »Ain't nobody got time for that.
Recent Posts
2
WeiDU / Re: weidu next generation - next version should abandon auto-overwrite design
« Last post by The Imp on June 22, 2017, 07:18:46 AM »When you abandon this auto-overwrite scheme, you will be free to do everything you always wanted. You can introduce breaking changes without caring about 10+ years of the historic past. And that might be biggest impact for weidu progress. You cannot have progress without changes.The thing is, are you sure this can be done without affecting say billions of things. As in, the crap is already in the pants as the auto update is in every version of weidu since at least v202 from what I remember.
And you can prevent it locally anyways with the "--noautoupdate" -command if you want, as you are aware of ... but the weidu.log'ing will be difficult, let alone all the other things a I have no concept of.
Have you tried to get the BWS to run without the update command it has build in it, at the start ?
Yeah, I am sure is it will be a cheese show.
- when Westley Weimer stopped weidu developing, Valerio Bigiani, AKA The Bigg took his placeYeah, sure, and the update was actually the solution for the unregistered edits of the weidu.exe a few programmers made their mods under, but that was a decade ago. Aka v186 ... v202.
- new weidu versions above 185 have changed the way how regexp works
- to this day, some modders refuse/forbidden to use new weidu versions because of the changed behavior and even if they did it because they are lazy, they still did it
weidu 241 break EET and BWS at the worst time ...The weidu.exe's need testing too, and there might not have been a EET tester at their post.
But all of this aren't even the main reasons to abandon auto-overwrite update. I believe it's the basic design principals of how to create stable and consistent system/framework/sdk.The weidu has had the make--biff command that made it impossible to stack uninstall, but that was a feature that has been undone.
Is there any other that has a similar feature, I have no idea... do you ?
3
WeiDU / Re: Parsed error with WeiDU 240.02
« Last post by Gwendolyne_FP on June 21, 2017, 03:58:45 PM »Thanks. The quotes work fine. 
I read the MODULO definition but forgot its synonym.
I read the MODULO definition but forgot its synonym.
4
WeiDU / Re: Roadmap
« Last post by AL|EN on June 21, 2017, 09:22:13 AM »In my opinion, the day of releasing Zeitgeist is a perfect day for abandon auto-overwrite design and threat every weidu SDK instance as standalone.
5
WeiDU / Re: Parsed error with WeiDU 240.02
« Last post by Argent77 on June 21, 2017, 06:57:06 AM »WeiDU 241 introduced the MODULO operator which uses REM as synonym.
Edit: You can probably keep the entries as long as you enclose the strings in quotes.
Edit: You can probably keep the entries as long as you enclose the strings in quotes.
6
WeiDU / [SOLVED] Parsed error with WeiDU 240.02
« Last post by Gwendolyne_FP on June 21, 2017, 06:50:08 AM »I recently digged up an old component that WeiDU installed fine a few years ago, but that produces parsed error with new WeidU version:
If I comment those lines
Everything runs fine. In other words, WeiDU seems to consider "REM" as an instruction or something else and stops the process. Is it the case?
Edit: I didn't try with WeiDU 241.
Code: [Select]
ACTION_DEFINE_ASSOCIATIVE_ARRAY GW_Food_Intoxications BEGIN
// Durée CON STR DEX INT CHA DI1 DI2 Slow Fatg1 Fatg2 RM Mes Color no_sorts Dégâts Int. Suite Time/% => Sort
// (6) (4) (5) (7) (9) 1 1 1 2
//---0 ---- 1 - 2 - 3 - 4 - 5 - 6 - 7 ----- 8 - 9 ---- 10 - 11 - 12 --- 13 --- 14 ---- 15 ---- 16 --- 17 ----- 18 ---------------------------------------------------
300, 0, 0, 0, 0, 0, 1, 2, 0, 0, 0, 3, INT, INT, N, N, 0, N, 0 => GWDis11T // Intoxication (1 T) : 1 HP / s.
120, 0, 0, 4, 4, 0, 0, 0, 1, 0, 0, 3, VER, VER, N, N, 0, N, 0 => GWDis22T // Vertiges et migraines (2 T) : DEX-INT (-4) - Lenteur.
300, 2, 2, 6, 0, 0, 0, 0, 1, 4, 0, 3, INT, ALL, N, N, 0, N, 0 => GWDis31H // Convulsions et abattement (1 H) : DE (-6) - CO-ST (-2) - Lenteur - Fatigue (+4).
300, 2, 2, 2, 0, 2, 1, 2, 0, 0, 0, 3, ALL, ALL, N, N, 0, N, 0 => GWDis61H // Allergie (1 H) : 1 HP / s - ST-DE-CO-CHA (-2).
300, 2, 2, 2, 0, 2, 12, 3, 1, 0, 0, 3, NAU, NAU, N, N, 0, N, 0 => GWDis71H // Syndrome gastro-intestinal - Nausées et diarrhées (1 H) : 1 HP / 12 s - ST-DE-CO-CHA (-2) - Lenteur.
7200, 2, 2, 2, 0, 2, 0, 0, 1, 0, 0, 0, NAU, NAU, Y, GW012D01, 60, N, 0 => GWDis81J // Syndrome gastro-intestinal - Nausées, diarrhées et vomissements (24 H) : 1 HP / T - ST-DE-CO-CHA (-2) - Lenteur.
300, 2, 2, 2, 0, 0, 12, 3, 1, 4, 0, 3, OCC, OCC, N, N, 0, N, 0 => GWDOcclu // Occlusion intestinale (1 H) : 1 HP / 12 s - ST-DE-CO (-2) - Lenteur - Fatigue (+4).
7200, 4, 4, 4, 2, 4, 0, 0, 1, 150, 2, 0, NAU, NAU, Y, GW012D10, 60, GWPHALJ3, 7200 => GWPhalJ1 // Syndrome phalloïdien (90 % mortel) - Nausées et diarrhées (1 J) : 10 HP / T - ST-DE-CO-CHA (-4) - IN (-2) - Lenteur - Fatigue (150 %).
7200, 5, 5, 5, 5, 5, 0, 0, 1, 200, 2, 0, REM, NAU, Y, N, 0, GWPHALJ4, 0 => GWPhalJ3 // Syndrome phalloïdien (90 % mortel) - Convulsions et abattement (1 J) : ST-DE-CO-CHA-IN (-5) - Lenteur - Fatigue (200 %).
7200, 2, 2, 2, 2, 2, 0, 0, 1, 200, 2, 0, HEM, NAU, y, GWPF1, 6, GWFDMORT, 90 => GWPhalJ4 // Syndrome phalloïdien (90 % mortel) - Hémorragie (1 J) : 1 HP / Rd - ST-DE-CO-CHA-IN (-2) - Lenteur - Fatigue (200 %).
3600, 3, 3, 3, 2, 2, 0, 0, 1, 150, 2, 0, NAU, NAU, Y, GW012D10, 60, GWPHAMJ3, 3600 => GWPhaMJ1 // Syndrome phalloïdien (10 % mortel) - Nausées et diarrhées (12 H) : 10 HP / T - ST-DE-CO (-3) - CHA-IN (-2) - Lenteur - Fatigue (150 %).
3600, 3, 3, 3, 3, 3, 0, 0, 1, 150, 2, 0, REM, NAU, Y, N, 0, GWPHAMJ4, 0 => GWPhaMJ3 // Syndrome phalloïdien (10 % mortel) - Convulsions et abattement (12 H) : ST-DE-CO-CHA-IN (-3) - Lenteur - Fatigue (150 %).
7200, 2, 2, 2, 2, 2, 0, 0, 1, 150, 2, 0, HEM, NAU, Y, GWPF1, 30, GWFDMORT, 10 => GWPhaMJ4 // Syndrome phalloïdien (10 % mortel) - Hémorragie (1 J) : 1 HP / 5 Rds - ST-DE-CO-CHA-IN (-2) - Lenteur - Fatigue (150 %).
7200, 4, 4, 5, 2, 4, 0, 0, 1, 200, 2, 0, VND, NAU, Y, GW012D10, 60, GWGYROJ2, 0 => GWGyroJ1 // Syndrome gyromitrien (1 % mortel) - Vertiges, migraines, nausées et diarrhées (1 J) : 10 HP / T - ST-CO-CHA (-4) - DE (-5) - IN (-2) - Lenteur - Fatigue (200 %).
3600, 3, 3, 4, 2, 3, 0, 0, 1, 150, 2, 0, VND, NAU, Y, GW012D01, 60, GWGYROJ3, 0 => GWGyroJ2 // Syndrome gyromitrien (1 % mortel) - Vertiges, migraines, nausées et diarrhées (12 H) : 1 HP / T - ST-CO-CHA (-3) - DE (-4) - IN (-2) - Lenteur - Fatigue (150 %).
3600, 2, 2, 3, 2, 2, 0, 0, 1, 150, 2, 0, VND, NAU, N, N, 0, GWFDMORT, 1 => GWGyroJ3 // Syndrome gyromitrien (1 % mortel) - Vertiges, migraines, nausées et diarrhées (12 H) : ST-CO-CHA-IN (-2) - DE (-3) - Lenteur - Fatigue (150 %).
7200, 3, 3, 4, 2, 3, 0, 0, 1, 150, 2, 0, VND, NAU, Y, GW012D01, 60, GWCORTJ3, 0 => GWCortJ2 // Syndrome orellanien (5 % mortel) - Vertiges, migraines, nausées et diarrhées (1 J) : 1 HP / T - ST-CO-CHA (-3) - DE (-4) - IN (-2) - Lenteur - Fatigue (150 %).
7200, 2, 2, 3, 2, 2, 0, 0, 1, 150, 2, 0, VND, NAU, Y, GW012D01, 30, GWFDMORT, 5 => GWCortJ4 // Syndrome orellanien (5 % mortel) - Vertiges, migraines, nausées et diarrhées (1 J) : 1 HP / 5 Rds - ST-CO-CHA-IN (-2) - DE (-3) - Lenteur - Fatigue (150 %).
300, 2, 2, 2, 2, 2, 0, 0, 1, 200, 0, 0, VND, NAU, Y, GW012D01, 30, GWMUSC3, 0 => GWMusc2 // Syndrome panthérinien - Vertiges, nausées, diarrhées, larmoiements (1 H) : 1 HP / 5 Rds - ST-DE-CO-IN-CHA (-2) - Lenteur - Fatigue (150 %) - Cécité.
END
If I comment those lines
Code: [Select]
7200, 5, 5, 5, 5, 5, 0, 0, 1, 200, 2, 0, REM, NAU, Y, N, 0, GWPHALJ4, 0 => GWPhalJ3 // Syndrome phalloïdien (90 % mortel) - Convulsions et abattement (1 J) : ST-DE-CO-CHA-IN (-5) - Lenteur - Fatigue (200 %).
3600, 3, 3, 3, 3, 3, 0, 0, 1, 150, 2, 0, REM, NAU, Y, N, 0, GWPHAMJ4, 0 => GWPhaMJ3
OR Change them withCode: [Select]
7200, 5, 5, 5, 5, 5, 0, 0, 1, 200, 2, 0, RSN, NAU, Y, N, 0, GWPHALJ4, 0 => GWPhalJ3 // Syndrome phalloïdien (90 % mortel) - Convulsions et abattement (1 J) : ST-DE-CO-CHA-IN (-5) - Lenteur - Fatigue (200 %).
3600, 3, 3, 3, 3, 3, 0, 0, 1, 150, 2, 0, RSN, NAU, Y, N, 0, GWPHAMJ4, 0 => GWPhaMJ3
Everything runs fine. In other words, WeiDU seems to consider "REM" as an instruction or something else and stops the process. Is it the case?
Edit: I didn't try with WeiDU 241.
7
WeiDU / weidu next generation - next version should abandon auto-overwrite design
« Last post by AL|EN on June 20, 2017, 04:07:05 PM »If there is one thing which I consider a major weidu flaw it would be weidu auto-overwrite design. I cannot stress enough how irrational it looks to me, compared to every other SDK's.
Let's look at the historical example:
- when Westley Weimer stopped weidu developing, Valerio Bigiani, AKA The Bigg took his place
- new weidu versions above 185 have changed the way how regexp works
- to this day, some modders refuse/forbidden to use new weidu versions because of the changed behavior and even if they did it because they are lazy, they still did it
- yet, many players will extract more than one single mod into game directory and weidu will overwrite old version of the setup-mod.exe > mod code won't be processed exactly as the author wanted
- this might lead to inconsistency between the state of the game which player has vs state of the game which mod author expects
this might look like not so important problem, but there is recent example: weidu 241 break EET and BWS at the worst time when it might happen - when EET in on hold and BWS is out of support. How mod authors can work with a framework/sdk which has a chance to break their mods in the future?
But all of this aren't even the main reasons to abandon auto-overwrite update. I believe it's the basic design principals of how to create stable and consistent system/framework/sdk.
How is even possible to have consistency when:
OCalm might change
weidu code can change
game itself might change
Combine it all and you have huge probability to have inconsistent installation of the same mods but for the different time because the weidu version which was used to create and release mod is not the last one. When you have one simple mod, it might work for 10 years but EE have some very complicated mods like T&B/F&P.
Also when you have 100+ mods, removing auto-overwrite design can have positive impact at uninstallation consistency. Mods will be installed and uninstalled using exactly the same version which was used by author at the time of their creation.
Wisp, by putting huge effort into testing and code regression testing, you have saved modders community from some major breaking changes disaster. But at the same time, taking care about "does changing one single byte can cause old mods to breakup?" is major drawback of the improvements.
When you abandon this auto-overwrite scheme, you will be free to do everything you always wanted. You can introduce breaking changes without caring about 10+ years of the historic past. And that might be biggest impact for weidu progress. You cannot have progress without changes.
tl;dr: weidu should not auto-update itself, allowing mods to be installed using always the same version of the weidu. Also it will allow for breaking changes/improvements but changes will not affect the previous mods
Let's look at the historical example:
- when Westley Weimer stopped weidu developing, Valerio Bigiani, AKA The Bigg took his place
- new weidu versions above 185 have changed the way how regexp works
- to this day, some modders refuse/forbidden to use new weidu versions because of the changed behavior and even if they did it because they are lazy, they still did it
- yet, many players will extract more than one single mod into game directory and weidu will overwrite old version of the setup-mod.exe > mod code won't be processed exactly as the author wanted
- this might lead to inconsistency between the state of the game which player has vs state of the game which mod author expects
this might look like not so important problem, but there is recent example: weidu 241 break EET and BWS at the worst time when it might happen - when EET in on hold and BWS is out of support. How mod authors can work with a framework/sdk which has a chance to break their mods in the future?
But all of this aren't even the main reasons to abandon auto-overwrite update. I believe it's the basic design principals of how to create stable and consistent system/framework/sdk.
How is even possible to have consistency when:
OCalm might change
weidu code can change
game itself might change
Combine it all and you have huge probability to have inconsistent installation of the same mods but for the different time because the weidu version which was used to create and release mod is not the last one. When you have one simple mod, it might work for 10 years but EE have some very complicated mods like T&B/F&P.
Also when you have 100+ mods, removing auto-overwrite design can have positive impact at uninstallation consistency. Mods will be installed and uninstalled using exactly the same version which was used by author at the time of their creation.
Wisp, by putting huge effort into testing and code regression testing, you have saved modders community from some major breaking changes disaster. But at the same time, taking care about "does changing one single byte can cause old mods to breakup?" is major drawback of the improvements.
When you abandon this auto-overwrite scheme, you will be free to do everything you always wanted. You can introduce breaking changes without caring about 10+ years of the historic past. And that might be biggest impact for weidu progress. You cannot have progress without changes.
tl;dr: weidu should not auto-update itself, allowing mods to be installed using always the same version of the weidu. Also it will allow for breaking changes/improvements but changes will not affect the previous mods
8
WeiDU / weidu next generation - rewrite weidu into popular language
« Last post by AL|EN on June 20, 2017, 03:22:53 PM »First, let me quote some part of the "BWS retrospections" regarding AutoIt:
Now, what it has to do with weidu? Well, weidu is written using not-so-popular-language: you won't find OCalm here https://insights.stackoverflow.com/survey/2017#technology
Wisp, you became "single point of failure" - if you life will change and you won't be able to support weidu, unless there will be a miracle and takeover of the development, weidu will be dead. The chances to takeover the project which use Ocalm are 10x more unlikely compered to project which use c#,python,java.
I urge you to focus you effort into rewriting weidu into popular language like c#,python,java etc I don't know you technical background but if this is beyond something which you can do by yourself, then ask community for help. Maybe there are developers who love IE games and they are willing to put their time into such rewrite. We will never know until you ask.
Quote
While AutoIt nature being scripting language allowed dabus to create such wonderful application in reasonable short amount of time, without spending hours to code basic functionality, let's lets face it: AutoIt is overly complicated, limited and inconsistent language with no real debug ability and without minimum set of good tools. To name couple of things:The poor quality of the language was main reason for me to not put lot of effort into changing BWS code. I had a lot of ideas and they all endup as a disappearing sparks in the darkness every time when I wanted to take look at code and modify it. AutoIt was the reason why BWS exist in the first place but it is also the reason why development of this tool died when dabus quit. If it would use c#/python I would put lot of effort into improving codebase itself because those language are high quality, easy and fun to code. And today, we would have a tool which require zero effort from modders and maintainers. Now it's hell for both groups.
- AutoIt editors are terrible compared to Visual Studio/Powershell ISE/any other editor I've used
- you can't simple select code inside editor and execute it, you have to save file ?!?!?
- you can't re-declare variable as parameter inside function WTF?
- no support for more object oriented programming
- no support for unicode/utf-8
- many things are not consistent with even basic programming principles: new array also contain additional element with the number of elements! WTF!?!
Now, what it has to do with weidu? Well, weidu is written using not-so-popular-language: you won't find OCalm here https://insights.stackoverflow.com/survey/2017#technology
Wisp, you became "single point of failure" - if you life will change and you won't be able to support weidu, unless there will be a miracle and takeover of the development, weidu will be dead. The chances to takeover the project which use Ocalm are 10x more unlikely compered to project which use c#,python,java.
I urge you to focus you effort into rewriting weidu into popular language like c#,python,java etc I don't know you technical background but if this is beyond something which you can do by yourself, then ask community for help. Maybe there are developers who love IE games and they are willing to put their time into such rewrite. We will never know until you ask.
9
WeiDU / Re: weidu next generation - improve uninstallation consistency
« Last post by Wisp on June 19, 2017, 12:35:54 PM »Sure, if you have data and reproducible test cases for stack-operation failures, I'm interested.
10
WeiDU / Re: Version 241 released
« Last post by Wisp on June 19, 2017, 12:33:47 PM »VirusTotal gives results typical for false positives for both files.