Well, what's done is done. No sense dwelling in it.
Thank you for the clarification and hope everything works out.
It would be a huge waste if this doesn't get finished properly. _________________
Team Black wrote:
interesting seeing your voxel work. They're still better than Aro's!
The notebook with both hard disks removed still shows the same symptoms, so the hard disks are at least not the main problem. Actually, at least one is totally fine, sitting in a new external casing right now, and still delivering a steady stream of bytes in the right order. So it's just a timeout for me, and when I get it back, I'll need a day or two to get going again. So, maybe 14 days. _________________ QUICK_EDIT
Joined: 09 Mar 2008 Location: Osaka (JP)/Hong Kong/Germany
Posted: Tue Dec 08, 2015 12:08 pm Post subject:
A break from a project can be useful for recovering one's motivation and ordering one's ideas (or even getting totally new ones)! I hope that this will happen during this break, so that upon your return, the further progress on Ares will have benefitted from it!
Thank you for your great work so far! _________________
Mao Zedong wrote:
Our mission, unfinished, may take a thousand years.
Hey Alex, hope your Notebook is fine again some time soon!
Got a little suggestion:
* as of now if a building gives a superweapon it will not autofire its occupants [which means that the initial payload occupants will not fire their weapons, if the building has an acctive superweapon too], which is a shame because my high tech buildings have initial payload passengers and should deliver a superweapon at the same time.
* its the same with occupieable buildings cannot have a weapon at the same time.
* and if a bunker has AA and AG units in it the AA won't fire at Air Units... would be great to change that too.
Greetings,
-A- Last edited by Ich-Henker on Mon Dec 14, 2015 8:11 am; edited 1 time in total QUICK_EDIT
I edited it, to make it more clear. I meant that, if a building is occupieable and you made it have initial payload occupants, the occupants won't fire their weapons at nearby targets when the building has an active superweapon on it too.
That is all
Hi guys, my notebook has been sent back (which was last Friday already, way faster than they estimated). The mainboard has been replaced, and the hard disks are just fine, with all files still intact. I had to catch up on my work, but I also managed to update to Visual Studio 2015 Update 1 and work on Ares slightly.
LaunchPad still shows some unconfirmed items, but I haven't updated it lately. I think it would be good to make the current features 0.A, and removing all the ones that have not yet been tested. This means, the next build could very well be the Release Candidate, and I can start writing the documentation. More news soon.
@Ich-Henker: Yeah, there are a few limitations. Buildings (not just occupiable ones) with super weapons will not auto-target objects; if one infantry cannot fire out of a building, the logic gets stuck. The first migth be an easy fix, but I don't know where the logic fails yet, but the latter logic most likely needs to be replaced. _________________ QUICK_EDIT
Joined: 09 Mar 2008 Location: Osaka (JP)/Hong Kong/Germany
Posted: Tue Dec 15, 2015 9:47 pm Post subject:
The issue seems to be related to something else - buildings which can have occupants and CanOccupyFire will never use their own weapons at all. It seems that OccupyFire/SuperWeapons/Weapons are just mixed up with each other in various ways. _________________
Mao Zedong wrote:
Our mission, unfinished, may take a thousand years.
Logics that were not meant to be used together often won't work together. In case of weapons on occupiable buildings the firing logic is overridden completely, and extra code is needed to make them work on a single object. If it works at all. For SWs on buildings i'm not sure what the issue is, but it sounds like there is code in the game that prevents firing then. Sorry, can't check at the moment. _________________ QUICK_EDIT
RA2 has occupy weapons on structures themselves (primary for allies, secondary for soviets), or at least was supposed to have at one point. I wouldn't be surprised if WW just hacked the logic to make it use occupant's weapons instead (thus, the game still considers an occupied structure with an SW as an EMP cannon, preventing it from attacking). QUICK_EDIT
I just uploaded a new binary, which can be considered the RC0. There were some more internal changes which again increase efficiency while the file size decreases, but no new features and/or bugfixes, because Ares 0.A is too big already. Also, someone has yet to document all this in the next few weeks, and incidentally it's Christmas over here, too.
There are a few things I wanted to do still, but alas I don't have a list. I remember Trivial Structure Damage should exclude MultiplayPassive countries. Maybe I'll have time for that. Aside from this, there are eight more issues that are not confirmed as of yet, or they have been confirmed partially.
While you test the new build, I'll start writing the docs. Whatever is not right yet: Now is the time to tell me. As soon as I can, I'll release a proper RC, maybe with preliminary documentation.
---
@Occupy and SWs: A CanBeOccupied=yes building with CanOccupyFire=no or no occupants is simply not allowed to fire. This is checked in several places. And if this is removed, there still needs to be new code to swich between OccupyFire and normal weapons. Also, the guard missions will not switch to Attack when SuperWeapon is set (but apparently when that SW's AuxBuilding= is not satisfied). Try to use SuperWeapon2= or SuperWeapons=. _________________ Last edited by AlexB on Thu Dec 17, 2015 8:45 pm; edited 1 time in total QUICK_EDIT
Just tested the newest build (15.349.109) and now appears to be resolved (I can no longer click the paused cameo)
Also wanted to confirm that if unit has BL (build limit) but structure has no BL, the unit will not be buildable again, even it deploys into the structure with no BL? _________________ Last edited by Allied General on Thu Dec 17, 2015 9:00 pm; edited 1 time in total QUICK_EDIT
Well, yes... I fixed that and maybe two other things. The question is: Was this a bug introduced in 0.A or is it older? If it was 0.A's fault, it will be included, if not, it will have to wait for 0.B. _________________ QUICK_EDIT
I believe this bug emerged during 0.A, since there was no previous reports for this bug. _________________ Last edited by Allied General on Thu Dec 17, 2015 9:17 pm; edited 1 time in total QUICK_EDIT
Joined: 09 Mar 2008 Location: Osaka (JP)/Hong Kong/Germany
Posted: Thu Dec 17, 2015 9:20 pm Post subject:
An issue regarding Spawns and Carryalls:
If a unit is picked up by a Carryall while it has spawned units, those units will be destroyed.
I'm not sure if this is a bug and I'm also not sure what should happen instead, but I feel that the current situation is not how it is supposed to work.
Also a suggestion:
Would it be possible to introduce into Splits/Shrapnel weapons some system that allows to customize what the weapons will consider as valid target? E.g. defining not to consider empty cells, overlays or friendly units as targets. Or to define that units should not be prioritized as targets over random cells. _________________
Mao Zedong wrote:
Our mission, unfinished, may take a thousand years.
Allow Player@X functionality for more script related functions
Customizable CrushDamage Warhead
Different Levels of Solidness for Buildings
Trivial Structure Damage
These features work as so far documented. The thing about Player@X not working for trigger owner mentioned on Launchpad is most likely due to trigger owner using country/house ID string whereas event/action takes numerical index parameter, and thus not really within the scope of this feature. Last edited by Starkku on Thu Dec 17, 2015 9:28 pm; edited 2 times in total QUICK_EDIT
@Allied General: Thanks! The fix will be for post-0.A then. The code will stay as-is.
@Millennium: There were plans, which never materialized. There are some things that Splits hardcodes, like the chance to hit the firing unit, and so on. Many things to improve, but later.
@Starkku: Thank you! Yeah, triggers work differently, they parse their tags differently. Right now, only the events have been made to support Player@X. _________________ QUICK_EDIT
New binary is up. Shipyards and other Naval=yes buildings should be buildable again.
edit: Ok, since the paperchase has already begun: The following issues have been fixed in the last two builds:
Units count against buildings' BuildLimit if deployable, and vice versa (#1119454, #1521738)
AirportBound=yes aircraft respects BuildLimit (but still capped at number of available docks) (#896082)
EMP will no longer make factories forget about waypoints (#896241)
That's it, I think. Or was there more? No, I'm quite sure. There were more changes, but did that really fix something?
Some other changes were regarding the New Construction Options bug debug log feature, which will no longer count a factory as non-existant if it just had no power, like from toggling or because of temporal weapons. This area needs more work (which is already almost done), but that will have to wait for 0.B.
edit 2: Here's the third build in just a few hours. It's called RC1 (and it removes a kinda noisy debug message). _________________ QUICK_EDIT
I noticed that when a cloaked unit is detected, EVA keeps repeating "Enemy unit detected". I think once should be enough. Or was it always like this? QUICK_EDIT
IMO it's the right choice to have it on repeat, however the delay between repeats ought be customizable. In TS it repeats too often, IMO. Same goes for "subterranean unit detected". _________________
Joined: 09 Mar 2008 Location: Osaka (JP)/Hong Kong/Germany
Posted: Fri Dec 18, 2015 5:51 pm Post subject:
I think the last frame of the Map Event box should remain on the unit so the player can track it, but the announcement should only be made if a unit that was not previously inside detection range of any unit or structure owned by a house enters the detection range of a unit or structure owned by that house. _________________
Mao Zedong wrote:
Our mission, unfinished, may take a thousand years.
It's the same logic. Silos Needed is played again only after a real time interval has passed. Cloaked and Subterranean Unit Detection are "event based". If it is detected, it is announced and a radar event is generated (that's two independent actions). There is no (hardcoded) interval that could be changed easily. In a later Ares release this could be changed, but it needs more code. Alas, same in TS. _________________ QUICK_EDIT
Okay. I could swear that it used to play only once when a unit was detected, but I guess I'm wrong (it's been a while since I've played vanilla RA2/YR).
Millennium wrote:
I think the last frame of the Map Event box should remain on the unit so the player can track it, but the announcement should only be made if a unit that was not previously inside detection range of any unit or structure owned by a house enters the detection range of a unit or structure owned by that house.
Yes that's what I was thinking. EVA was getting on my nerves, hence my question. QUICK_EDIT
I think it actually does that. But it announces every unit it detects, without delay. Low Power, Insufficient Funds, and Silos Needed have a delay to not repeat the message every few frames. Thus, two stealth tanks an make the message play twice in just a few seconds. With bases under Cloak Generators, it can get really noisy.
@all: This is my current list of things to change:
Trivial Structure Damage disableable per house, defaulting to MultiplayPassive
Moving SolidLevel from Warhead to Projectile
Is the latter one useful? SubjectToBuildings is on the Projectile, so it would make sense. Would that break anything for anyone? _________________ QUICK_EDIT
Then, I think something should be metioned since we already have InitialPayload logic.
just a common example:
Make an IFV clone with InitialPayload.type=ENGINEER,
It's logical to set this "package" cost=1100 (600+500),
then the problem raises.
You actually got a 1100-cost IFV and a 500-cost ENGINEER.
When killed they actually give enemy more experience than it should.
Thus, I think a separated experience giving system is needed.
like
ExperienceValue= default to cost QUICK_EDIT
not sure if it is the case. always figured that soylent might be used to override experience gain as well. test it out yourself. _________________ ~ Excelsior ~ QUICK_EDIT
Joined: 09 Mar 2008 Location: Osaka (JP)/Hong Kong/Germany
Posted: Sat Dec 19, 2015 2:58 pm Post subject:
How does the engine handle killed Passengers at the moment? For example, if that IFV+Engineer combo is destroyed and the Engineer does not survive, will you get 1100$ (vehicle) PLUS 500$ (engineer) towards your veterancy?
Well, I've been pushing for splitting EXP off Cost, so this is a good opportunity to do so, once more! Plus some extra!
Code:
[TechnoType]
LevelCap= ; max levels this type can have
ExpCap.Level*= ; need this many experience to reach level *.
ExpReward.Level*= ; grants this much experience at level *.
Alternatively, PromotionTypes (ie NextType system) and simple ExperienceReward and ExperienceCap tags on units. _________________
Mao Zedong wrote:
Our mission, unfinished, may take a thousand years.
The cost is recalculated. It is the cost of an object of the same type at the time it is destroyed. That means, there's potentially more broken there, like owning a Factory Plants even reducing the value of units built before the Factory Plant was constructed. _________________ QUICK_EDIT
Joined: 09 Mar 2008 Location: Osaka (JP)/Hong Kong/Germany
Posted: Mon Dec 21, 2015 12:53 am Post subject:
It appears AE.SpeedMultiplier has no effect on aircraft. Someone might want to correct me on this, I find it odd that it has not been reported before, seems like something that doesn't easily escapes attention. _________________
Mao Zedong wrote:
Our mission, unfinished, may take a thousand years.
Aircraft & Jumpjet Speeds are a different tag and AttachEffect itself only applies the speed bonuses for "Speed" Specifically. _________________ ~ Excelsior ~ QUICK_EDIT
Joined: 09 Mar 2008 Location: Osaka (JP)/Hong Kong/Germany
Posted: Mon Dec 21, 2015 2:12 am Post subject:
That does make sense, I wonder if Alex intends it to stay that way though.
Then again, come to think, what should happen if a unit's speed was to drop to 0 while in the air...
Edit:
Also, would it be possible to radically increase the length of object IDs in the next release?
I think it has been established that right now we are limited to IDs of a max. length of 24, plus brackets. This may seem like alot, but I've hit that limit often. It's not a very groundbreaking change to make and has zero bearing on gameplay features, but it would be helpful. _________________
Mao Zedong wrote:
Our mission, unfinished, may take a thousand years.
I don't see how you can reach that limit considering you can have 11,720 different permutations of [GAYARD_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _], may not look pretty, but it's hidden from ingame. _________________ "Don't beg for things; Do it yourself or you'll never get anything." QUICK_EDIT
Edit:
Also, would it be possible to radically increase the length of object IDs in the next release?
I think it has been established that right now we are limited to IDs of a max. length of 24, plus brackets. This may seem like alot, but I've hit that limit often. It's not a very groundbreaking change to make and has zero bearing on gameplay features, but it would be helpful.
How about NO, like you said, it has zero gameplay benefit and your talk of limits sounds ridiculous or you are poor name thinker which is not concern for ARES.
Besides it's best keep those objectnames direct to the shp name, that has its own limits (than always use Image= ) and ideally short.
I guess our pet Millenium wants ID extended so he can write [thisismylolbuildingnameaintitcoolmk2yipeeeyehaaacowboyridesagain!!!]
As if AlexB doesn't have more better things to do as is on his plate.
... QUICK_EDIT
Millennium: I don't plan to change the airspeed modifier.
Increasing the ID length is not a simple task. There is no space for more characters, and thus the ID would have to be stored somewhere else. That means, this location has to be made known throughout the game and Ares. That's easily hundreds of changes.
Also, using only the 26 latin letters, 24 characters allow for over 9 decillion combinations. That is over 9000 million million million million millions. Hard to believe that you are hitting this limit. _________________ QUICK_EDIT
Joined: 09 Mar 2008 Location: Osaka (JP)/Hong Kong/Germany
Posted: Mon Dec 21, 2015 3:55 pm Post subject:
Let me just explain why I made that request.
It's true that recombinations of letters alone offer a considerable amount of possibilities (I did not take the time to calculate them, so I'll take your word for it). However, the possible recombinations for me personally are somewhat limited in that I want my IDs to denote the actual "thing" they are used for, so I have to combine meaningful strings of letters with each other.
Just two examples:
Code:
; Javelin missile shooting against infantry targets with missile deflection
[JavelinLauncher_VS_ECMInf]
; Elite multi-missile which has clusters on its clusters!
[MultiMissileEClusterStage1]
Removing the combinations which have no meaning, or have meanings entirely irrelevant to the objects they denote, there are much fewer possible combinations. No, it does not have a bearing on gameplay, it's more my personal preference really, and it does make coding a little easier vis-a-vis random letter/number strings.
Of course, this could be solved in other ways - I can abbreviate, I can just keep a table of random number/letter strings and the proper objects they denote. Or I will start typing IDs in Kanji! Bless the Chinese modders, every word is just one sign!
I was expecting a string length change would be a simple thing to do, but since it does not appear to be that way, it does not have a high priority for me.
ApolloTD wrote:
Millennium wrote:
Edit:
Also, would it be possible to radically increase the length of object IDs in the next release?
I think it has been established that right now we are limited to IDs of a max. length of 24, plus brackets. This may seem like alot, but I've hit that limit often. It's not a very groundbreaking change to make and has zero bearing on gameplay features, but it would be helpful.
How about NO, like you said, it has zero gameplay benefit and your talk of limits sounds ridiculous or you are poor name thinker which is not concern for ARES.
Besides it's best keep those objectnames direct to the shp name, that has its own limits (than always use Image= ) and ideally short.
I guess our pet Millenium wants ID extended so he can write [thisismylolbuildingnameaintitcoolmk2yipeeeyehaaacowboyridesagain!!!]
As if AlexB doesn't have more better things to do as is on his plate.
...
I'm not your pet. Sounds like your own naughty fantasy.
On-topic, SHP names have a character limit? Below the object ID string limit? Do you know what that limit is? _________________
Mao Zedong wrote:
Our mission, unfinished, may take a thousand years.
Joined: 09 Mar 2008 Location: Osaka (JP)/Hong Kong/Germany
Posted: Mon Dec 21, 2015 4:40 pm Post subject:
I have not said that it is necessary
I have merely explained to Alex how I came to the conclusion that an extension of string length would be helpful, as he seemed puzzled by my request.
But, as I have also stated in my last post, it is not in the least necessary, it's a convenience feature, or a matter of personal preference. But there are certainly ways of achieving the same in-game results without it.
That I do not understand the concept of comments does not follow from anything I have said, does it? _________________
Mao Zedong wrote:
Our mission, unfinished, may take a thousand years.
Also Known As: evanb90 Joined: 20 Feb 2005 Location: o kawaii koto
Posted: Mon Dec 21, 2015 6:35 pm Post subject:
I find making and following a naming convention helps tremendously in this regard. Keeps things short, concise and easily understood by you.
What isn't made clear by the identifier can be explained in a comment above it, or off to the right. _________________ YR modder/artist, DOOM mapper, aka evanb90
Project Lead Developer, New-Star Strike (2014-)
Former Project Lead DeveloperStar Strike (2005-2012), Z-Mod (2006-2007), RA1.5 (2008-2013), The Cold War (2006-2007) Last edited by EVA-251 on Mon Dec 21, 2015 7:47 pm; edited 1 time in total QUICK_EDIT
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum